Let’s take a history dive into Secure Sockets Layer SSL and learn more about it before covering the solution of SSL Convergence, which helps mitigates against TLS MITM.
Secure Sockets Layer, the industry standard for secure communication over an unprotected network internally or externally is in danger. Created in 1994 by Netscape, the secure sockets layer, SSL, was launched to protect web-based traffic on the Hypertext Transfer Protocol. SSL itself is actually two protocols per session. There is the record protocol, at the session layer and the handshake protocol at the presentation layer. The Secure Sockets Layer works on behalf of the underlying transportation layer which segments carry the encrypted data.
The handshake protocol authenticates one or both sides of the SSL session and establishes a unique symmetric key used to generate keys to encrypt and decrypt data for that SSL session. It uses asymmetric cryptography, digital certificates, and SSL handshake flows, to authenticate one or both endpoints of an SSL session.
The digital certificate is consist of of a public key and identifying information a trusted Certificate Authority (CA) has digitally signed. Each public key has an associated private key. The private key is not stored with the certificate. In both server and client authentication, the endpoint, which is being authenticated, must prove it has access to the private key associated with the public key contained within the digital certificate.
With server authentication, the client will ensure that the server certificate is valid and it is signed by a CA, which the client trusts. Secure Sockets Layer handshake protocol flows to generate a symmetric key, which will be used only for this unique SSL session. This key is used to generate a set of keys, which are used for encrypting and decrypting data, which will flow over the SSL session. Subsequently, when an SSL handshake has completed, one or both ends of the communication link will have been authenticated. In addition, a unique key will have been generated to encrypt and decrypt the data. Once the handshake is completed then application layer data will flow encrypted across SSL session.
The SSL handshakes are very intensive operations occurring because of the cryptographic operations using the public and private keys affecting performance of the initial client/server negotiation. However, after an initial SSL session has been established, the SSL session information for these two endpoints can be cached in secure memory to speed up subsequent SSL session. When an SSL session is resumed, the two endpoints use an abbreviated handshake flow to authenticate each has access to unique information without using the public or private keys. If both can prove that they have access to this unique information, then new symmetric keys are established and the SSL session resumes.
As the industry standard, SSL has become the de facto of all server to client communications. The Secure Sockets Layer evolved and matured it was found to be insecure and quickly replaced by Transport Layer Security first in 1999. The IETF updated TLS in RFC 5246 (August 2008) and RFC 6176 (March 2011). The protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP). An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key. Focusing on the web browser, Wikipedia offers a nice compatibility chart for TLS, which is the chosen industry standard alternative course of action.
SSL Convergence TLS MITM
Transport Layer Security introduced the hashed-based message authentication code, H-MAC, standard and its pseudorandom function output to create the keys. Each system starts with a premaster secret then creates the master secret lastly creating the key required material.
The biggest difference is that SSL uses RSA, Diffie-Hellman or Fortezza output to create key material. This output then generates secret information based on the cipherSuite and Parameters selected during the session. In SSL, the CertificateVerify message requires a complex procedure of messages. With TLS, however, the verified information is completely contained within the handshake messages previously exchanged during the session.
In TLS, the PRF output of the H-MAC algorithm is used with the master secret and either a “client finished” or a “server finished” designation to create the Finished message. In SSL, the finished message is created in the same ad-hoc manner that key material is generated.
Regardless of the Secure Sockets Layer or Transport Layer Security, there are still some fundamental issues with the overall processes and ‘trust’ taken place. In addition, there has been legal battle regarding the use of variants of these standards to help assure privacy, authentication, and reliability.
SSL Convergence
Moxie Marlinspike during DEFCON 17 introduced these fundamental issues of trust to the mass public. He explains web browsers initially had many positive reinforcement indicators that your connection was secure; however, web browsers have now moved to negative reinforcement with huge warning signs. These warning signs are so intrusive it takes multiple clicks and a certain level of knowledge to bypass these guards. Although there is a problem with these negative reinforcements by simply removing the warnings, it is assumed secure. With his cleaver SSLsniff and SSLstrip tools by man-in-the-middle, he was able to break OSCP, install any application, and read all traffic in plaintext.
The evolution of the protocols and automating the entire CA process to issue certificates has allowed these vulnerabilities to exist, especially when it comes to verifying the commonName at the time of the presentation. The problem is with both the CA and the web browser and how they handle the commonName attribute. Since most web browsers are programmed in C, the browser would stop reading the commonName field on the cert when it saw a \0 or null. This allowed anyone to create an A record with a null at the end of their certified and trusted second level domain. Moxie used the example https://www.paypal.com\0.thoughtcrime.com and demonstrated by offering this trusted cert to the client during a man-in-the-middle attack the victim had no visual of the compromise.
In addition, Moxie demonstrated how to break OSCP, which checks to see if the certification has been revoked during an audit. However, simply by returning an ASCII message of three from the foraged OSCP location the browser automatically assumes the OSCP is busy and needs to validate later. In fact, it is actually named TryLater.
If the whole spec was broken including the standards and the various methods of verifying the whole certificate process during SSL session was not enough there is another bit of evil among us in this vulnerable space, intellectual property.
There has been a recent destitute where a patent troll company TQP Development made online retailer Newegg to pay $2.3 million in a dispute over an encryption patent. TQP Development has sued a hundreds of tech companies including Apple, Google, Intel and Samsung.
Newegg was the only company to challenge the patent claim in court, and experts such as Whitfield Diffie, the creator of public key encryption, testified on their behalf. Diffie says the patent in question was not relevant to type of encryption used by web companies such as Apple and Google, who relied on techniques older than the Jones patent. Experts like Lotus Notes creator and former Microsoft CTO Ray Ozzie also testified in support of Newegg, presenting examples of prior art, such as the algorithms underlying Secure Socket Layer.
There might not be much hope for the fight against patent trolls; however, At DEFCON 19 Moxie Marlinspike comes back with an idea how to reshape SSL and the future of authenticity and trust with SSL Convergence.
Moxie’s idea for SSL Convergence comes from the fundamental issue with CAs, once a browser has given trust to a root CA there is not a realistic way to suspend or remove that trust if it has been broken. In his example, COMODO was compromised three different times; however, for a browser to remove trust from this CA would break around a fifth of all SSL traffic.
SSL Convergence comes with trust agility where a trust decision can be easily revised at any time and an individual user can decide where to anchor their trust without losing availability. He approached this method as an alternative of the next adopted step of DNSEC; however, the limitations of putting trust forever in the name registrar, the owner of the TLD and then ultimately root (ICANN).
The way SSL Convergence works is by selecting a random notary to be a ‘bounce’ server. This server will know who you are but not what you are visiting. The notary servers will know what you are visiting but not know whom you are. The best part of Convergence is the Internet would not need a facelift for this to be implemented. With a simple plugin, CAs would be obsolete if it was rolled out into all four of the major browsers. Lastly, it only is validated if there is a collective trust throughout the notaries therefore weeding out the minority would not break anything.
There are some disadvantages to using Moxie’s purposed method and it mentions that some large websites *cough* Citibank *cough* do not follow SSL standards anyway so they would need to conform to the standard before it would work. In addition, if there was captive portals where you need to pay to use the Internet this trust could not be validated by SSL Convergence because most captive portals block out http; however, they leave DNS open, allowing SSL Convergence still to be able to function with a small modification.
Continuing to evolve the SSL/TLS platform in itself is not enough. As you can see even with the current revisions of SSL/TLS, most of the websites out there do not even bother to check or implement the newer solution. Therefore, I believe we need to tackle this problem from both ends. Continue to educate and implement proper secure SSL/TLS, along with removing Certificate Authorizes without agile trust.
