Happy Birthday SSL 3.0: The Terrible/Adored Child - And The King of Flaws

Happy Birthday SSL 3.0: The Terrible/Adored Child - And The King of Flaws

What would you do if your child nearly brought down 2/3rds of the Internet?

What would you do if you child wasn't allowed to cross a border, without being so restricted in what they did in a foreign country, that they could hardly do anything?

What would you do if you child did something that protected terrorists, and bad people, and stopped them going to prison?

So, on this day in August 2011, the world saw the birth of something that is the torment of digitial investigators and security analysts, but has protected the privacy rights of the people involved. It has also been the source of some of the most terrible software bugs around and also nearly brought down the Internet.

So who/what is it? Well this dull little document ... RFC 6101 outlines its full beauty/evilness [here] ...

It is SSL 3.0, the terrible/adored (delete as required) child of Netscape, is 20 years old today. It is one of the most disruptive and flawed child around, and who has been so great, but who is so completely flawed. We have ended up with PKI (Public Key Infastruture) and which integrates with SSL, and which can often be broken with a man-in-the-middle attack.

Introduction

Netscape's main product was Netscape Navigator, and it lived as a Web browser from Version 1.0 (released in 1994) to Version 4.0 (1997). It was originally known as Mosaic but they had to drop the name due to legal action from the National Center for Supercomputing Applications (who created NCSA Mosaic). It continually innovated with integrated mail in Version 2 (Netscape Mail), and then with a WYSIWYG editor in Version 3.0. With a large scale of the market, Microsoft spotted an opportunity, though, and started to erode Netscape's market share with a free version of Internet Explorer. The last main version of the browser was Netscape 4 - Netscape Communicator:

Netscape's legacy

The application of encryption to network communications traces its roots by to Netscape. They used a handshaking method and a digital certificate to create a shared key which was used by either side of the communication, and also which provided the identity of the server to the client. With this, a server sends a digital certificate to the client, and which contains its public key. If this certificate has been validated by a trusted issuer, the client can trust the identity of the server.

Netscape first defined SSL (Secure Socket Layer) Version 1.0 in 1993, and eventually, in 1996, released a standard which is still widely used: SSL 3.0. While many in the industry used it, it did not become an RFC standard until 2011 (and which was assigned RFC 6101 and defined as a historic standard). 

Along with classics like IP (RFC-791), TCP (RFC-793), HTTP (RFC-1945) [here], it is an out-of-the-box classic:

It was often bundled with AOL Online - a leader at the time in getting people on-line - and AOL enventually took over its development. The browser itself reach 9.0, until it was pulled:

A footnote message from the Netscape 7.0 page, lasted updated in 2002, gives a hint to its past:

Onto TLS

The child become much more success than its parent, which eventually left the stage after Verion 9.0, but since then TLS (Transport Layer Sockets) has been used to overcome the problems of SSL. If you are interested, here is how SSL works:

Figure 1 outlines how network protocols fit together, where we use insecure protocols such as HTTP, TCP and IP to communicate with a Web site. Each of these protocols were designed at a time when security was not an issue on systems. The fix to improve security was to insert a layer between the network layer (IP) and the transport layer (TCP), and is named SSL. This later secures the upper-level protocol, and creates a secure and encrypted tunnel between the client and the Web server, so that no-one can crack the communications for the connection.

Figure 1: Networking stack with SSL integration

There are several different versions of SSL, from 1.0 to 3.0 , and with 3.1 it changed its named to TLS (Transport Layer Socket), so that SSL 3.1 is also known at TLS 1.0. Most systems now use TLS 1.1 or 1.2, and which are free of flaws which compromised previous versions.

SSL (as illustrated in Figure 2) works by the client telling the server which type of encryption it would like to use (such as RC4) and the other cipher parameters it can support. The server replies back with its preferred cipher scheme, along with its digital certificate. This digital certificate contains its public key, and the proof of its identity. The client then creates a new session key for the encrypted tunnel, and then encrypts this with the public key provided by the server. It then sends this to the server, where the server decrypts it, and thus has the same encryption key as the client. After this, the client and server can communicate with the session key (and the chosen encryption method) – thus creating a tunnel between themselves. This tunnel should be almost impossible to crack, as it uses a session key, which would take a long time to crack through brute force.

Figure 2: Outline of SSL tunneling

FREAK

SSL has now been exposed by many problems including with FREAK ("Factoring RSA Export Keys") and was introduced to comply with US Cryptography Export Regulations, where the keys used for exportable software were limited to 512-bits or less (and were defined as RSA EXPORT keys). This allowed the NSA to break the encryption, as they had powerful computers. The RFC states:

5.6.3. Server Key Exchange Message

   The server key exchange message is sent by the server if it has no certificate, has a certificate only used for signing (e.g., DSS [DSS] certificates, signing-only RSA [RSA] certificates), or FORTEZZA KEA key exchange is used.  This message is not used if the server certificate contains Diffie-Hellman [DH1] parameters.

   Note: According to current US export law, RSA moduli larger than 512 bits may not be used for key exchange in software exported from the  US.  With this message, larger RSA keys may be used as signature-only   certificates to sign temporary shorter RSA keys for key exchange.

By 2015, it was fairly easy to get a cloud-based instance to factorize 512-bit keys (which involves finding the matching key to a 512-bit public key). The exploit could thus involve a man-in-the-middle, and who could step back the keys used to 512 bits.

POODLE

Few things can be kept secret within computer security, and it has been the case with a flaw in SSLv3, where there were rumors of a forthcoming announcement. So it happened on Tuesday 14 October 2014 that Bodo M?ller (along with Thai Duong and Krzysztof Kotowicz) from Google announced a vulnerability in SSLv3, and where the plaintext of the encrypted content could be revealed by an intruder. The flaw itself has been speculated on for a while, and this latest announcement shows that it can actually be used to compromise secure communications.

The vulnerability was named POODLE (Padding Oracle On Downgraded Legacy Encryption) attack, and it relates to the method that Web servers deal with older versions of the SSL (Secure Socket Layer) protocol. An outline is here:

Heartbleed

Heartbleed was another serious flaw around SSL, and was caused by a software flaw in the implementation of the Heartbeat protocol with the OpenSSL library. Here is an overview:

https://www.dhirubhai.net/pulse/20141108092239-15260610-the-most-amazing-computer-security-story-ever

Conclusions

With major debates going on around the usage of encryption, many are pointing as the usage of secure tunnels, and it is mainly down to the work of Netscape that we have secure communications for our emails, and Web accesses. Export laws have caused problems in the past, and it will be seen if countries around the World try to limit the scope of encrypted tunnels.

As a crypto researcher, SSL is terrible, but I love it. It's flawed, and that gives us places to look and probe. Overall it's a human v computer thing in crypto, and the humans have sometimes been the winners in the greatest moral battle of the 21st Century:

Cypto Wars!

Come and see the future of cryptography at our event on 21 Sept 2016 with Prof Alan Woodward showcasing how quantum computers will defeat SSL/TLS, and crack every single secure thing you currently send. Also Dr Owen Lo will show how the most secure encryption method - AES - can be cracked in 30 minutes, just by listening to the power supply:

要查看或添加评论,请登录

Prof Bill Buchanan OBE FRSE的更多文章

社区洞察

其他会员也浏览了