Should you always trust that browser padlock?

Originally published on Hakin9 Magazine

We’ve always been taught that you are safe if your browser is displaying a little padlock. But is this still true? To answer this question let’s go back to the roots of HTTP (Hyper Text Transfer Protocol).

What exactly is HTTP(S)?

HTTP is the most prevalent protocol used by your computer’s browser to communicate with a website hosted on a web server. This is a clear text protocol with no encryption, so it is very easy to eavesdrop on. Think of each message sent to the web server as a paper postcard you are sending with your message clearly written on the side. Anyone that saw this card on its journey to the destination could easily read the message if they so wished. Therefore using this type of protocol for reading the news or just browsing the web was fine. It was also a lot faster due to no encryption overhead; back then CPU power was a precious commodity.

Encryption

In order to understand HTTPS, it is important to understand how encryption works. We must first realise there are two main types of encryption algorithms; asymmetric and symmetric algorithms.

• Asymmetric algorithms use a private and a public key to create a secret key with which the data is then encrypted. The secret key can decrypt the data, in other words the remote user is then able to read the data. The public key is shared openly but the private key is exchanged securely.

• Symmetric key cipher such as AES is faster in encrypting data but the sender has to exchange the key that encrypted the data in order for the sender to read the data.

So how is HTTPS different?

As the internet expanded over time with the ever increasing demand for online transactions, data security became crucial. In 1994 Netscape invented HTTPS which is HTTP using SSL (secure socket layer) to encrypt the data transmitted. SSL allows for establishing an encrypted channel between two computers so the exchange of data packets remains private. This could be your browser and a web server. HTTPS was created to prevent eavesdroppers from reading and editing clear text data submitted on the HTTP protocol. Data such as online banking and account login details could now be passed to a remote server from your computer in a secure fashion. HTTPS is typically indicated with a green padlock and letters ‘https’ on your browser address bar.

Referring back to the earlier postcard example, SSL allows you to put a message in a secure envelope. Only the person it’s addressed to can open and read the message.

How does it all work?

In order for HTTPS to function, the following five step process has to be completed:

1. Client browser connects to website exchanging a handshake message that has the information needed to connect via SSL

2. Web Server sends a copy of its SSL certificate to client browser to prove its identity

3. Browser Checks the certificate with the certificate authority

4. Exchange keys so the data exchanged can be symmetrically encrypted.

5. Server and browser are now using an encrypted tunnel

What are the problems?

With this secure connection you would think there would be no flaws in HTTPS, realistically there is no problem with HTTPS itself but as we now know, HTTPS is a combination of HTTP and SSL. Any flaws found in either two could have a domino effect on the integrity of HTTPS. During the lifespan of SSL there have been numerous problems, therefore SSL have moved away from SSL to TLS (Transport Layer Security). TLS and its predecessor SSL are still referred to as ‘SSL’

HTTPS Exploits;

Protocol downgrade attack: Tricks the web server into negotiating a connection with an obsolete version of TLS such as SSL v2. Attackers can accomplish this by removing the high security ciphers from their local machine, forcing the web server to establish a less secure connection.

DROWN: Attackers leverage SSL v2 even when connected on TLS 1.0. This is accomplished by intercepting TLS 1.0 packets and repeatedly sending them to the web server using SSLv2. Each time a packet is sent, a bit more information is learned about the session key. The end result will be the session key stolen and the session hijacked. Note this only works if TLS is communicating using RSA.

BEAST: Is a man in the middle attack where TLS 1.0 is vulnerable. Attackers catch authentication tokens and reverse them to gain access to the data passing between the web server and web browser.

CRIME: Is a vulnerability that is exploited by recovering data in the web cookies when data compression is used with TLS/SPY. To distinguish a successful attack from an unsuccessful attack, attackers look at the response size. Once the data is gained from the cookie an authentication cookie can be compiled and used to launch a session hijack on the authentication of a web session

BREACH: Crime and Breach are similar however Breach is used on HTTP by injecting plain text into an https request and seeing the length of the compressed https response to guess the secret. From this the attacker will be able to see plain text traffic from the SSL stream. This attack only works against RSA

LUCKY 13: An attacker will wait for a slight time difference were TLS error messages will appear on the network (web browser to client ) to recover a complete block of TLS encrypted plain text. To make sure the session to the web server does not time out a piece of software is normally installed to keep the connection to the web server alive. Once the attacker has pieced together the message, the attacker can then eavesdrop onto the web server. This will only work if HMAC-SHA1 is being used.

POODLE: If using SSLv3 or TLS1.0 block cipher, you are able to decrypt a single byte at a time with a probability of 1/256. Repeating this process you will gradually be able to read the whole message. This is done by snooping/sniffing traffic to the web server.

FREAK: Another man in the middle attack where a requester will send a request to the web server. The attacker will then replace it with weak “export grade” encryption. The server gets the attacker’s request and responds to the user’s browser. The user’s browsers doesn’t notice the weaker key and sets up the SSL session using the weaker key. Attacker can now snoop your session and break into the information at a later date.

Heartbleed: A serious flaw in OpenSSL works by sending echoes of less data size to the server and receiving the response plus the additional data filled from the memory. An example of this would be sending a request “hello I’m sending 128 character of data” when you realistically send only 12 characters, the server now responds with your 12 characters of data and adds an additional 116 characters from memory to make the 128 characters you said you sent. Therefor in memory data is exposed.

Understanding the problem

To understand the problem we must first understand the term “Cipher suite”. The easiest way of thinking of cipher suites are gears on a cog that all rotate together for everything to work in harmony. But let’s first have a look at a cipher suite:

SSL_RSA_WITH_RC4_1258_SHA

To break this down into readable format:

• Pseudorandom function – SSL

• Key exchange algorithm – RSA

• The bulk encryption – RC4_1258

• The message authentication code algorithm – SHA

Don’t let the terms scare you we can break this down into very easy to understand portions where you will be able to easily understand what each part means:

Pseudorandom function is the hash function used to create the “master secret”. The master secret key is the mechanics used to create randomisation for the session key.

Key exchange algorithm is used to determine how the server will authenticate during the very first handshake.

The bulk encryption algorithm is the stream used to encrypt messages as well as determining other features such as size.

The message authentication code algorithm, the final part of the puzzle is a cryptographic hash used for each block in the message stream.

Solution to the problems

Now that we have a basic understanding of ciphers, we can look at mitigating the risk of these vulnerabilities.

• To start with we need to remove SSLv2/3 and TLS 1.0

• Further hardening can take place by disabling SSL Compression to stop crime attacks

• Regularly scheduled penetration and vulnerability testing of your web sites

• Regular software patching schedule

• As an end user regularly updating your browser can also help reduce these risks

Testing

There are several sites out there offering free automated SSL vulnerability testing but nothing beats a human conducted manual intense scan where they can investigate a vulnerability with many tools, scripts and code. From my own experience I have seen a few popular automated scans show nothing wrong but when tested manually there are errors present.

Ask yourself that question again. Should you always trust that browser padlock?