Netscape's Security Legacy

I did a little bit of history on Flash last week [here], so let's look at another company who have left a legacy: Netscape. It's main legacy is secure communications: SSL.

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:

Since then TLS (Transport Layer Sockets) have been used to overcome the problems of SS. 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.