Duncan's Security Blog An enthusiasts musings


HTTPS security


HTTPS is a secure layering of the HTTP protocol used for communication over a computer network, most notably used on the internet. It achieves this security by using the SSL/TLS protocol, which is the standard as far as securing web applications go. In particular, HTTPS is used by banks, social networks, live streaming services, email, instant messaging and more. SSL/TLS extends HTTP by providing a secure tunnel through which a web browser and web server communicate. By encrypting transmissions, SSL/TLS provides confidentiality and prevents unauthorised and undetected modifications, which preserves integrity.

Authenticity is ensured with a digital certificate, which establishes a binding between a public key and an entity(Eg. address, company name, persons name, hostname etc). In HTTPS' case, the public key is used by SSL/TLS to negotiate a key between the browser and server. The certificate contains the entity with its key, and is digitally signed by a certification authority(CA).

The CA is responsible for checking that the public key and entity really belong together. The entity itself can be a certificate, so the original entity can be wrapped up in certificates signed by multiple CA's. In general, a certificate can be considered valid by a web browser if there is a chain of certificates from a CA the web browser trusts, to the certificate which is checked.

Public Key Infrastructure, in a nutshell
By default, web browsers ship with a list of CAs which they may consider trustworthy. These CAs have been added to the list by the browsers creators, once they have reviewed them. The CA is audited to see if the standards imposed by the CA are sufficient (so far as verifying key-entity relationships are concerned). It is also important that the CAs systems are secure and well tested. The audit should ideally be redone annually, to ensure that the standards are kept, and that new security developments are accomodated for. Of course, the browser vendor has an interest in keeping its list of trusted CAs up to date, or else they will expose their users to potential security risks. Ultimately, the certificate acceptance is determined by the browser if it establishes at least one chain of trust to a CA it trusts.

Public key infrastructure failures

VeriSign-Microsoft certificate
In 2001, and anonymous attacker managed to persuade VeriSign(a major CA) that he was an employee of Microsoft. He was granted several certificates(with his public key) to use as a result. VeriSigns checks in 2001 were clearly not good enough to ensure a secure infrastructure.

MD5 collisions
Cryptographic hashes of the certificate are signed instead of signing the entire certificate(for various technical reasons). In the early days, the most commonly used hash function used was the MD5 hash. Many weaknesses have been found in the MD5 hash, and its use is therefore discouraged these days(in favour of one of the SHA hash functions).

An MD5 collision occurs when two different certificates have the same hash. In this case, a signature on either certificate would also be valid for the other. This was proved in 2008 when security researchers managed to generate their own sub-CA using an MD5 collision. This sub-CA then requested a signature from a CA, and then copied the signature received into their own sub-CA certificate. This meant that they were able to operate their own CA, and issue arbitrary certificates for any hostname and email address they wanted to. Soon after this proof of concept, CAs stopped using MD5.

Dutch CA, DigiNotar, had become compromised when an attacker gained access to their systems and granted a certificate for *.google.com to himself, and subsequently launched a man-in-the-middle attack on Gmail. DigiNotor was removed from all browser vendors' trusted lists, and soon afterwards DigiNotar went bankrupt. The attacker who claimed responsibility remarked that other CAs were susceptible to attack, and it is therefor only a matter of time before a similar attack happens again.

Preventative measures available
Three measures available can be implemented by the website administrator, and do not require CA involvement, nor do they need to modify certificates.

The default assumed protocol for web browsers is HTTP. If a user types an address in their browser, the browser will send an HTTP request. This request would be redirected to HTTPS in the event that the website uses HTTPS. The problem comes in where the redirect request is not protected, and can be exploited via a man-in-the-middle attack which would suppress the HTTPS request, and return a bogus page to the user, in the hope that the user enters valuable details which can be recorded.

HSTS was designed to avoid this, by specifying that every subsequent request sent to the web server shall be done over HTTPS, and that the web browser should never use HTTP on that particular website. Although still in its infancy, HSTS is used by some high profile websites, such as paypal.

Public key pinning
Public key pinning works by the web server specifying which public keys may be used in the certificate chain for a particular website. When a browser connects to the website a second time, the public keys offered in the server certificate chain are compared to the list of allowed public keys for that website. If no certificate in the chain matches at least one allowed public key, the connection is terminated.

DANE (DNS-Based Authentication of Named Entities)
If the CA is compromised, public key pinning wont work because a first time user can be impersonated. DANE can protect even the first visit to a website. Instead of pinning a public key on the first visit, the pins are stored in the users DNS records. Instead of a chain of trust from an arbitrary CA to a certificate for your hostname, a chain of trust from the operator of the DNS root zone to the DNS records for your hostname is established. The benefit of such as system is that there are over 1000 CAs which can issue valid certificates for any host name on the internet, but there is only one authority responsible for a top level domain. DANE is also not limited to HTTPS, and may be used on any SSL/TLS connection. As with public key pinning and HSTS, DANE is still in draft stages.

Presently a combination of HSTS and public key pinning is the best solution for securing a HTTPS web server against compromise or other attacks on CAs. DANEs complexity makes it more preferable when a higher level of security is required, but presently is badly supported amongst the browsers.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.