Published on October 3rd, 2014 | by admin
How to break https – How secure is your web browser?
A quick crypto reminder, as it relates to HTTPS / TLS;
In cryptography, we have a public algorithm, which you use with a secret key to encrypt plaintext to ciphertext. Even if the algorithm and the ciphertext are disclosed, you can’t get to the plaintext without the key.
TLS secures communications over the Internet. It uses two different stages of cryptography, each with its own type of algorithm. In the initial stage, asymmetric cryptography is used to securely exchange a session key. The session key is then used in the second stage to encrypt the http data symmetrically.
1. Asymmetric cryptography
Also known as public / private key cryptography, this type of algorithm uses two keys; one for encryption, and a different (though mathematically related) key for decryption. Asymmetric encryption means being able to encrypt with the public key, but only being able to decrypt with only the private key.
Asymmetric cryptography is used to securely exchange the session key, and to authenticate the site – information contained within an X.509 certificate.
2. Symmetric cryptography
The same session key is used for both encryption and decryption. It’s less secure that asymmetric, because if the key is compromised, then so is the cipertext. So why use it at all? Because it’s more efficient – which was historically important when TLS was first introduced. Having lots of crypto overhead on creaky web servers and client hardware was considered unnecessary back in 1996. The designers compromised by specifying that the key be changed every so often.
So, what happens when you point your browser to https://www.twitter.com ?
First, your PC performs the usual DNS lookup – it asks for the IP address associated with www.twitter.com
Secondly, your browser initiates a TLS handshake with that IP address.
-> ClientHello (SSL version, random number, supported encryption algorithms etc) <- ServerHello (random number used to generate a master key, the selected encryption algorithm etc) <- Certificate <- ServerHelloDone -> ClientKeyExchange -> ChangeCipherSpec <- ChangeCipherSpec
To demonstrate this, I’ll access https://www.twitter.com, and show the resultant Wireshark capture:
Here’s www.twitter.com communicating its ssl certificate back to your browser:
And this is (some of) what your browser sees, after the handshake with https://www.twitter.com has completed:
--- SSL handshake has read 3222 bytes and written 444 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: CC7136243ED3D4C111C87232A49E6A57AD554E4DD6B0D45B5D80CAF4B4580173 Session-ID-ctx: Master-Key: A150808791531866D1332835BA78BAE64632A8D71C950C8D3D6C695DD3E1F118670D0D0F40F6B63A8AAD11463B6C213C Key-Arg : None Start Time: 1408019975 Timeout : 300 (sec) Verify return code: 0 (ok)
Finally, your browser can request a web page securely, using the session key to encrypt the data (symmetric cryptography). This encrypted data will be the HTTP request (GET / POST etc) followed by the HTTP response (eg. HTTP/1.1 302 Found) – and the actual web page you see in your browser window.
How can my https session be decrypted?
Just how secure is this communication method, designed way back in 1996, in practice?
Let’s get the various ways of tricking someone into revealing their https session out of the way – for example:
- Fraudulent sites: phishing tricks you into giving up your passwords, by enticing you to click on a link in a spam email. The link will be a forgery of a legitimate site, designed to harvest passwords that victims will unwittingly enter. This type of attack relies on the victim not noticing that the web site address at the top of the page looks unfamiliar.
- DNS spoofing: If you’re connected to the internet on an untrusted network (for example, a compromised WiFi hotspot at an airport), your DNS request to www.twitter.com may be simply redirected to a different IP address. All modern TLS implementations have built-in safeguards against DNS spoofing, so https://www.twitter.com can’t be easily redirected.
So what are the practical methods?
- Compromising the device
Malware in the software (or hardware) of your laptop renders any TLS useless, since the attacker can use a back door to your device to see your communications in plain text, before it’s been encrypted. This approach doesn’t scale, and may be noticeable by the victim, however malware placed on the web server itself may be less detectable.
- Man In The Middle” (MITM) attack
On an untrusted network (for example, a compromised WiFi hotspot at an airport), an SSL interception proxy can be added in between you and the internet. TLS sessions may be broken by the SSL proxy, and then re-established with the intended server, such as www.twitter.com. This method isn’t usually effective, because your web browser will spot the fake certificate and warn you with a pop-up box – unless the bad guy has added the SSL proxy’s certificate into your web browser, typically used within a corporate IT infrastructure.
- Attacking the Certification Authority (CA) system
Your web browser came with a built-in list of around 65 Certificate Authorities (CA), such as Comodo and VeriSign. A CA vouches for the identities assigned to a private key, by producing a tamper-resistant X.509 digital certificate. Anyone who can subvert a trusted CA can issue certificates for bogus public keys – this has happened with CAs such as Globalsign, Comodo and DigiNotar. Chrome and Firefox have implemented HPKP X.509 Certificate Pinning, which provide safeguards against this type of attack.
- Compromised keys
Keys can be stolen, and SSL can be ‘brute forced’ with computers capable of quickly factoring public keys – the NSA is rumoured to be able to crack keys of 1024 bits in length, such as those used by The Onion Router (TOR), on a large scale. Google and Facebook now use the Perfect Forward Secrecy cipher-suite, which makes it harder for session keys to be derived from a compromised asymmetric secret key.
- Attacking weaknesses in the SSL implementation
This happens rarely on widely deployed https servers. An exception was Heartbleed – a vulnerability discovered in April 2014 in the OpenSSL library, widely used in web servers. A buffer over-read bug, it allowed attackers to read data contained in the affected server memory, and resulted in potentially compromised data across a huge amount of web sites, such as Wikipedia and Reddit.
The mathematics behind most ciphers commonly used with https implementation is solid, despite the fact that they have been around for a long time. Though some claim to be able to decrypt your https communications, it’s unlikely to be in a scalable way – any genuine method, publically disclosed, would attract huge media attention.