Optimising TLS handshake through certificate caching
TLS is the standardised offspring of the old and well known SSL (Secure Socket Layer) TCP/IP encryption protocol by Netscape.
The main TLS specification (TLS 1.2) is available from http://tools.ietf.org/html/rfc5246
I have posted a new standard draft to the IETF proposing a simple method to optimise the TLS handshake, significantly reducing the bits on the wire for repeated connection to the same site.
The draft is available from: http://tools.ietf.org/html/draft-santesson-tls-certcache-00
Tee major rationale is outlined in the introduction:
“A server certificate sent to the client during a TLS handshake can be of considerable size. This is the case in particular if the server certificate is bundled with a complete certificate path, including all intermediary certificates up to the trust anchor public key.
Significant benefits can be achieved in low bandwidth and high latency networks, in particular if the communication channel also has a relatively high rate of transmission errors, if a known and previously cached server certificate path can be omitted from the TLS handshake.
This specification defines the CachedCerts TLS extension, which may be used by a client to and a server to omit sending known certificate data in the Server Certificate message.”
Simplified, this solution allows the client to say
- Hello, I have talked to you before and here is a checksum identifying the certificate information you sent to me last time.
And allows the server to respond.
- Hello, that matches the certificate I intended to send to you. Since you already have it, I will save some bandwidth by not sending it again.
This information is carried in a TLS extension that is included in the client and server extended Hello messages. The format of the extension is very simple as it just contains a Hash of the previously cached server certificates
struct {
opaque certificate_hash; <1..2^8-1>
} CachedCerts;
Within this format, the Hash algorithm would be locked on SHA-1, while others have argued that there should be an algorithm identifier, allowing the certificate hash to chosen freely and specified in the protocol. With algorithm identifier included the extension would be expanded to:
struct {
HashAlgorithm hash;
opaque certificate_hash; <1..2^8-1>
} CachedCerts;
HashAlgorithm is defined in RFC 5246 and is an enumeration of hash algorithms:
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
The need, or no need for algorithm agility here is somewhat controversial. The industry is moving away from SHA-1 as hash algorithm as it has been discovered to not be as strong as originally assumed against certain attacks. This is highly relevant when using a hash algorithm in a signature scheme. In this case however, the hash algorithm is just a convenient way to calculate an identifier. No serious security threat will be the result of a collision making the random properties of SHA-1permanently sufficient for the intended usage in this protocol. In the worst case scenario, if a collision would occur (two different cert paths generate the same hash value) and this would trick the server into not sending its server certificate, the only thing that would happen is a failed TLS handshake, followed by a new one without using the certificate caching optimisation.
A previous and a lot more complex proposal to achieve a similar optimisation was proposed in the Fast-Track draft http://tools.ietf.org/html/draft-shacham-tls-fast-track-00. This initiative was never adopted by the TLS work group in the IETF. The current proposal is an attempt to revisit this problem space with a significantly simpler solution, just focusing on cert caching.
The main TLS specification (TLS 1.2) is available from http://tools.ietf.org/html/rfc5246
I have posted a new standard draft to the IETF proposing a simple method to optimise the TLS handshake, significantly reducing the bits on the wire for repeated connection to the same site.
The draft is available from: http://tools.ietf.org/html/draft-santesson-tls-certcache-00
Tee major rationale is outlined in the introduction:
“A server certificate sent to the client during a TLS handshake can be of considerable size. This is the case in particular if the server certificate is bundled with a complete certificate path, including all intermediary certificates up to the trust anchor public key.
Significant benefits can be achieved in low bandwidth and high latency networks, in particular if the communication channel also has a relatively high rate of transmission errors, if a known and previously cached server certificate path can be omitted from the TLS handshake.
This specification defines the CachedCerts TLS extension, which may be used by a client to and a server to omit sending known certificate data in the Server Certificate message.”
Simplified, this solution allows the client to say
- Hello, I have talked to you before and here is a checksum identifying the certificate information you sent to me last time.
And allows the server to respond.
- Hello, that matches the certificate I intended to send to you. Since you already have it, I will save some bandwidth by not sending it again.
This information is carried in a TLS extension that is included in the client and server extended Hello messages. The format of the extension is very simple as it just contains a Hash of the previously cached server certificates
struct {
opaque certificate_hash; <1..2^8-1>
} CachedCerts;
Within this format, the Hash algorithm would be locked on SHA-1, while others have argued that there should be an algorithm identifier, allowing the certificate hash to chosen freely and specified in the protocol. With algorithm identifier included the extension would be expanded to:
struct {
HashAlgorithm hash;
opaque certificate_hash; <1..2^8-1>
} CachedCerts;
HashAlgorithm is defined in RFC 5246 and is an enumeration of hash algorithms:
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
The need, or no need for algorithm agility here is somewhat controversial. The industry is moving away from SHA-1 as hash algorithm as it has been discovered to not be as strong as originally assumed against certain attacks. This is highly relevant when using a hash algorithm in a signature scheme. In this case however, the hash algorithm is just a convenient way to calculate an identifier. No serious security threat will be the result of a collision making the random properties of SHA-1permanently sufficient for the intended usage in this protocol. In the worst case scenario, if a collision would occur (two different cert paths generate the same hash value) and this would trick the server into not sending its server certificate, the only thing that would happen is a failed TLS handshake, followed by a new one without using the certificate caching optimisation.
A previous and a lot more complex proposal to achieve a similar optimisation was proposed in the Fast-Track draft http://tools.ietf.org/html/draft-shacham-tls-fast-track-00. This initiative was never adopted by the TLS work group in the IETF. The current proposal is an attempt to revisit this problem space with a significantly simpler solution, just focusing on cert caching.