Web PKI: 3 improvements

Written on 24 September 2017, 03:09pm

Tagged with: , ,

Some insights about web security from the excellent ‘Bulletproof SSL and TLS‘ book from Ivan Ristic.

– the Internet was not designed with security in mind
– the first efforts to improve this were in 1995, when SSL3 was released (by Netscape). Then TLS followed up.
– TLS 1.2 – the most recent version – was released in August 2008 (its successor – TLS 1.3 – is still under development, as of September 2017)
– the goal back in 1995 was to enable e-commerce. Today we have that (‘commercial security’), but we want much more.

One of the biggest problem with the Web PKI is the approach to certificate validation. The following improvements aim to fix that:
1. Public Key Pinning:
– addresses the fact that any CA can issue a certificate for any domain name without the owner’s permission.
– with pinning, site owners can select (pin) one or more CAs that they trust, creating their own (small) trust ecosystem
– delivered via HTTP headers (Public-Key-Pins)

2. HTTP Strict Transport Security (HSTS)
– allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
– also, when an invalid certificate is encountered, it instructs compliant browsers to replace warnings with errors, disallowing bypass.
– delivered also via HTTP headers (Strict-Transport-Security)

3. OCSP stapling
– There are two standards for certificate revocation (revocation is used when the private key is compromised or no longer needed)
– CRL (Certificate Revocation List) is a large list of revoked certificate serial numbers maintained by the CA. Because of the size, the lookup is slow
– OCSP (Online Certificate Status Protocol) allows browsers to obtain the revocation status of a single certificate.
– the problem with OCSP is that the individual lookup can slow down browsing and can affect the performance of the OCSP responder for high traffic websites
– to address this, OCSP stapling allows each server to embed an OCSP response directly into the TLS initial handshake

In the end, do not forget that the current Web PKI is controlled by 2 actors: Certificate Authorities (interested in profit) and browser vendors (interested in market share).

Neither group has strong security as its top priority, but they are not necessarily to blame—at least not entirely. They won’t give us security until we, the end users, start to demand it from them.

Update 10 October 2017: I have just enabled HSTS here. Inspired by Troy Hunt.

Leave a response