This article highlights the issues raised at the Florida State University lecture for “Offensive Security” regarding SSL and TLS protocols, namely their background, infrastructure, flaws and known crypto attacks.
The outline for today’s talk is we’re going to go over SSL and TLS and cover its history, its flaws, the important attacks, and I guess the lessons learned or ignored from all of its faults. And then we’re going to go over attacks for it; sslstrip is what I want to show in demo, also sslsniff and some other crypto attacks that came out very recently.So, SSL is Secure Sockets Layer. It was developed by Netscape. It is a predecessor to TLS. It’s essentially a cryptographic protocol that provides secure communication over the Internet. The encryption is done at the application layer. I list the TCP/IP model as opposed to the OSI model. I guess, conceptually, the encryption in the OSI model would occur at the session layer, and perhaps in the presentation layer, because the browser handling of SSL also provides that little presentation of either that lock on the URL bar or that green little segment to the left – basically the same: “This is Microsoft verified, signed by VeriSign, this is a valid certificate, your browser trusts this”.
Essentially, there’s three parts to it. There’s a first initial handshake to set up SSL, and then there’s the second handshake that uses asymmetric cryptography to establish a session key. And the session key is the symmetric key. And so, the third part of SSL, the last part, is the final handshake that begins to rest the communication for the session over asymmetrically encrypted channel using that session key. It also uses the net in the remainder of communication message and authentic codes to provide message integrity.TLS is Transport Layer Security. It’s defined in RFC 5246. It is seen as the successor to SSL, whereas it’s actually derived from an earlier version of SSL. It is, basically, in theory, the same as SSL conceptually. It’s basically a cryptographic protocol that provides secure communication over the Internet, and the encryption happens at the application layer. It uses asymmetric cryptography to establish a key, and that key is a symmetric key, and that key is used to provide encryption to establish confidentiality for the rest of the communication. It also uses message authentication codes for message integrity.
These two things are used everywhere. They’re used in web browsers, they’re used in email; apparently, Wikipedia says they’re used in Internet faxing – I’m not sure if that still exists; they’re used in instant messaging, they’re used in Voice over IP and other things.SSL came from the 1990s, early 90s, basically, the dawn of time. It was developed by the engineers at Netscape who were tasked with a task of providing a protocol for making secure HTTP requests. At the time there was very little known about secure protocols. There were no best practices, there were no good examples, academic examples on: “Here’s a protocol we’ve established, here’s an attack, here’s how we defended against it, here’s an attack against that defense”, and so on.
Also they were under intense pressure to get the job done, facing common deadlines that we face today. They had to make a lot of 4am decisions. And this gave us SSL. It’s actually really amazing that it lasted this long and still works as well as it does. But now the fundamental system engineered back in the 90s faces serious problems with authenticity. We’re seeing, because of various events, a really diminishing trust; hackers are much smarter than they were back in the 90s; and we also now know much more about how to secure things.
So, what does a secure protocol need to provide? It needs to provide secrecy – in other words, someone can’t eavesdrop and find out the contents of your communication. It needs to provide integrity – it means that malicious man in the middle can’t manipulate your traffic, flip bits here and there, change a plus sign to a negative sign – perhaps, instead of taking money from him, have money go from you to the attacker. And also it needs to provide authenticity – in other words, a message sent from Alice is definitely sent from Alice. This is, basically, non-repudiation and authenticity there.Here’s the basics to the SSL/TLS handshake (see right-hand image). The following is sent in plaintext: the client’s SSL version number, his cipher settings and his session data, along with some other stuff. The server responds with something very similar. The server responds with its SSL version number, its cipher settings, its session data, as well as its public key certificate.
The client uses the provided certificate to authenticate the server’s identity. If this fails, the user is warned that an encrypted and authenticated connection cannot be established. Often browsers will pop up a warning saying: “I cannot authenticate this certificate, or this is a self-signed certificate that doesn’t stem from one of the root certificates that we trust in our browser settings”. Usually users proceed anyways.
At this point, using the public key certificate, some encrypted communication begins. And this is supported by asymmetric key encryption. Essentially, depending on how the cipher settings are chosen, the details here can vary, but essentially the handshake here establishes a shared symmetric key. And then the remainder of the communication uses that shared symmetric key to provide confidentiality and uses message authentication codes to provide integrity.
It’s made in the very beginning; it’s influenced by the user’s browser version and that browser’s settings. Maybe it’s an old version of Firefox and it doesn’t support the latest SSL and TLS. By default the decision usually chooses the most recent version of whichever protocol between the two. So if the server supports version 1, 2 and 3, and the client supports 1 and 2, but not 3 yet, they’re going to choose 2.
HTTPS uses these certificates. Essentially, the certificate authorities say: “This key that was provided by the server belongs to this website and the browser does trust it”.Like I said, implementation details can vary, and they can definitely vary over versions. And so, the client authenticates the server based on the server certificate. Usually the server does not require the client to authenticate itself. There’s some other mechanism behind that, like there’s a login prompt on the page that the user authenticates through – that’s totally sufficient. There are versions of SSL and TLS that require mutual authentication, but they are not very commonly encountered by the average web user.
All of this is basically automated to not involve the user, unless there is a certificate of unknown origin signed by unknown certificate authority or chain or certificate authorities that can’t be traced to a set of certificate authorities that the browser trusts.So let’s talk about this issue of trust (see right-hand image). Essentially, at some point, it was decided that trust is just too hard for the normal user to think about. So the browser vendors decide, basically, the trust for you. It’s pretty nice of them. Let’s look at the trust decided for you. This is just using the certificate information and my version of Chrome on my home machine, just a default setup of Chrome. Default setup of Chrome ships with 40 trusted root certificate authorities and 25 intermediate certificate authorities that are trusted to sign certificates. And then users can always add their own certificates, and sometimes the default option is just to click Yes.
Let’s think about this. Personally, I don’t even know 40 people that I would trust with that information. I certainly wouldn’t trust more than 3 people in my life with my banking information. And so, 40 organizations in the world are securing your banking data. Think about that for a second.