HTTPS, SSL and TLS
Since I’ve recently done an essay on the (very) basics of HTTPS, I thought it would be a good idea to rehash some of it here, to explain roughly how symmetric and asymmetric encryption work together to encrypt taffic over the Web.
HTTPS involves TCP packet encryption between the Application Layer and the Transport Layer of the OSI reference model, and so it works independently of Internet-enabled applications (usually web browsers). Of course, this would have meant minimal effort on the part of application developers to support this, and this is perhaps how it became more widely used than S-HTTP.
(Edited to add: I think this actually happens before the data is encapsulated as TCP packets.)
When we talk about HTTPS, we’re not referring to a protocol or the encryption methods themselves, but a prefix used in place of the standard HTTP to signal to the browser that a connection should be established through Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to encrypt whatever data the browser sends to the transport layer and TCP sockets.
SSL and TLS
SSL and TLS are both very much the same thing. The former was developd by Netscape Communications throughout the 1990s as a proprietary technology, and is almost as old as the World Wide Web. TLS was the successor, based on SSL 3.0, by an open community of developers and defined in RFCs 5246 and 6176.
But there are differences between the two, though. SSL would start a secure connection from the beginning of a request, while TLS will only do so after the HTTPS handshake between the client and server or drop the connection if this isn’t possible. HTTPS/SSL would use a different port to standard HTTP, whereas HTTPS/TLS wouldn’t. This could make it harder for a packet inspection system to differentiate between an encrypted and unencrypted connection.
Overall, the whole thing is a hybrid encryption scheme consisting of at least two ciphers and a procedure for negotiating which ones the client and server should use. One cipher will be symmetric and the other asymmetric. There’s a very straightforward reason for this.
The most efficient encryption is symmetric, such as Triple-DES, RC2 or R4, since it works by permutation, substitution and XORing plaintext with key bits instead of factoring vast numbers, and therefore require less computing resources.
Unfortunately the symmetric cipher can’t be used without first sharing the session key over the Internet, which could perhaps be intercepted at any point between the client and server. To solve this, public key asymmetric encryption is used to exchange the symmetric encryption key. The problem with this approach is current asymmetric ciphers require far more computing resources as it involves generating and factoring very large numbers.
It’s after the handshake, key and certificate exchanges that this switch to symmetric encryption is made, so by this point the client and server should have already authenticated each other and negotiated a scheme for communication.
The whole process for establishing a secure connection between the client and server can be summarised as:
1. Client checks server’s identity.
2. Server checks client’s identity.
3. Establish the best encryption methods supported at both ends.
4. Generate and exchange asymmetric cipher key.
5. Exchange the (session) key for symmetric cipher using asymmetric encryption.
6. Switch to using symmetric cipher after the key has been safely communicated.
Certificates, Authentication and Trusted Parties
How does the client know it’s communicating with a given server, and not a malicious party? The answer to this is it doesn’t. The best guarantee are the ‘certificates’ exchanged when establishing an HTTPS session.
A client uses the following to confirm the server’s identity.
Is the current date within the validity period?
Is the issuing Certification Authority (CA) trusted?
Does the issuing CA’s public key authenticate the issuer’s signature?
Do the server and certificate domain names match?
If the answer to any of these is no, the server cannot be authenticated and the browser should display a warning to the user. At this point, the user has the option of rejecting the connection or making a decision based on a closer examination of the certificate. Of course, the user might choose to ignore the warning and proceed.
The major certification authorities, such as Verisign, GeoTrust and GoDaddy, are considered ‘trusted parties’, and issue certificates to be installed in all the main web browsers. The certification authorities are also considered ‘trusted’ because we must rely on their certificates as evidence that server x belongs to organisation y and on z domain. Again, certificates are evidence and not proof of this.
Basically, a domain owner will buy a certificate from one of the trusted certification authorities, and browsers visiting the server at that domain will be able to confirm its certificate is genuine, since both the client and server should recognise.
If a certificate was self-signed, which should theoretically be the case if the domain owner’s being impersonated, the browser will warn the user that the certificate is invalid.
HTTPS and Defence in Depth
In terms of Defence-in-Depth and network defence, communications encryption is something of a double-edged sword, especially in relation to corporate networks. The network administrator might want to protect the organisation’s data while preventing malicious traffic passing through firewalls and Intrusion Detection Systems (IDS) encrypted.
HTTPS and communications encryption in general should be considered only one component of a Defence-in-Depth scheme. It’s also a difficult problem to solve, as the same measures can also be used by malware and internal threats to export sensitive information to another server outside the network.
HTTPS doesn’t provide security on its own. It only ensures a connection between two points is secure, and could be defeated using one of two methods:
It’s possible for a third-party to impersonate both sender and receiver, by placing a server that intercepts and relays the data. Both the sender and receiver would still be communicating over secure connections, but the connections would be to the attacker.
Malware could be used to exfiltrate the data from a target before it’s sent over the secure connection.
ARTHUR, C. 2011. The Guardian: Rogue web certificate could have been used to attack Iran dissidents. [WWW]. http://www.guardian.co.uk/technology/2011/aug/30/faked-web-certificate-iran-dissidents. (10th April 2013).
CLULEY, G. 2011. Sophos: German ‘Government’ R2D2 Trojan FAQ. [WWW]. http://nakedsecurity.sophos.com/2011/10/10/german-government-r2d2-trojan-faq/. (10th April 2013).
DIERKS, T. A. 1999. Internet Engineering Task Force: Request for Comments (RFC) 2246.
The TLS Protocol, Version 1.0. [RFC]. http://www.ietf.org/rfc/rfc2246.txt. (12th April 2013).
FRIER, A. KARLTON, P. KOCHER, P. 2011. Internet Engineering Task Force: Request for Comments (RFC) 6101. The Secure Sockets Layer (SSL) Protocol Version 3.0. [RFC]. http://tools.ietf.org/html/rfc6101. (12th April 2013).
KANGAS, E. 2008. LuxSci FYI Blog: SSL versus TLS. [WWW]. http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html. (9th April 2013).
MOZILLA FOUNDATION. 2005. Mozilla Developer Network: Introduction to SSL. [WWW]. https://developer.mozilla.org/en-US/docs/Introduction_to_SSL. (8th April 2013).