Client-server, end-to-end encryption. All the HTTP traffic between the client and the server is encrypted, preventing anyone from understanding it even if they can intercept it.
Message Integrity. Integrity checks ensure that the messages making up the HTTP traffic cannot be altered in transit, neither can messages be added or removed from the sequence, without detection.
Strong authentication of the server. Simply providing encryption and message integrity gives little security if you do not know who the other party in the conversation actually is. With plain HTTP, your only assurance is that your browser has probably connected to the host whose name appeared in the URL you followed. This may not be the case (for example it is easy to subvert the name-to-address mapping process), and in any case it is difficult to tell who is actually operating any particular server. It is also fairly easy to mount a "man in the middle" attack against plain HTTP.
Under HTTPS, all servers offer the browser a cryptographic "certificate". These certificates are issued by trusted third parties and contain information that identifies the server and the organisation operating it. How this works, and how the trusted third parties are nominated, will be covered later.
Optional authentication of the browser user. Optionally, HTTPS also allows the browser to supply a certificate to the server. This can provide strong authentication of the identity of the browser user, but this feature is rarely used, probably because of the difficulty of issuing such certificates to all users. Certificates are also large, making it difficult for mobile users to have them to hand when needed. Embedding certificates in portable tokens is one approach to solving these problems. This issue is addressed further below.