[SOUND] In this lecture I want to talk about the SSL/TLS protocol. And there are really two reasons I want to do this. The first reason is that this is an important cryptographic protocol. It's a protocol that you use probably every day, and it's a protocol used by millions of people around the world. It's implemented in every browser, and it under pins secure electronic commerce today. And so for that reason, if you could get out of a course on cryptography without seeing this protocol, it would be a real shame. The second reason I want to cover this protocol, is because it really provides a very nice way to pull together every thing we've learned through out the entire course. And gives you a chance to really see how these different primitives we learned about, can operate together, and again how these things are used in the real world. So the fundamental problem that the protocol that we're talking about here is solving, is how can you securely send your credit card information to, for example, Coursera? And there are different protocol that were designed, used under slightly different names. SSL stands for Secure Socket Layer. This was a protocol developed by Netscape, beginning in the mid 1990s. And TLS stands for Transport Layer Security. This was really an attempt to standardize the SSL protocol and make it more widely used. And there are several versions of this protocol that were developed. TLS 1.0 was developed in 1999. TLS 1.2 was standardized in 2008. And is the current version of the TLS protocol. And TLS 1.3 is currently in draft form. And you can follow that and see how it continues to progress. And as I said a moment ago, the TLS protocol is used by every web browser when it initiates an https connection. That is, a secure connection to a website. Now, the goals in describing the TLS protocol to you, are to understand at a high level. This very important real-world crypto protocol, and as I said at the outset, to show you how everything we've learned together, we've learned in this course, can be pulled together. I want to make clear that it's not my goal here, to convey to you the low-level details of the TLS protocol. Or exactly how the various components of TLS are implemented. You can take out, you can look a the standard to get a sense of that. There are books available that discuss these things in more detail. That's not the goal of my lecture here, and so I'm actually going to be a little bit fast and loose with details. Because I want to convey the high level picture without getting lost in the weeds. I also want to be clear that it is not a goal here, to discuss what kind of security SSL/TLS is trying to achieve, or trying to prove any kind of formal security statement for the protocol. This is actually a current area of research in the cryptographic community. And again it's not something I want to get bogged down in right now. Because I really want to focus on conveying the high level picture of what the protocol is doing. So with those caveats in place, let's move on. In the TLS protocol, it operates in two phases. First, there's a handshake protocol, that allows a client and a server, that is a user and web server that they're connecting to, to establish a shared key. The record layer protocol, is then a second phase of the protocol which allows those party to use the share key they just generated for secure communications. So for example, when connecting to a web page and initiating say, the sending of a credit card number, the handshake protocol would be used to allow you and the web server to share a key. And then the record layer protocol would be used to actually communicate both the credit card information as well as details about the specific transaction that you're performing to be sent securely from your computer to web server at the other end. The handshake protocol, at a high level, works in the following way. So on the left hand side we have a client, who you can imagine running this protocol in their web browser. And as we discussed in the previous lecture, that client has the public key for some certification authority stored in their browser, and I've noted that by indicating that the client has the public key pkCA. At the the other end on the right hand side is a merchant with whom the user is communicating, and that merchant has a private key and a public key pair, along with a certificate. Find by the, by the certification authority, again as we spoke about in the last lecture. Certifying the binding, between the identity of that merchant and their public key. When the users initiates a connection by typing in an https request, say to the websitebank.com, as part of that initial request, the client's web browser will generate a non. It's a random value denoted here, N sub c. And that will be sent, along with other information, to the bank, to the merchant at the other end. That party will respond with a copy of their public key, their certificate, and their own random value, their own nons, here denoted by N as well. And now, the client first needs to verify, that the public key that they've attained, is indeed the correct public key, right? As we talked about in the last lecture, you want to prevent an attacker from injecting their own public key, their own fake pub, public key and claiming that that's the public key of the web server with whom this client is trying to communicate. So the client needs to verify the certificate. Needs to verify the signature using the public key of the CA that they know. And indeed to check whether the public key that they've received, matches the URL, of the entity with whom they were trying to reach, with whom they were trying to communicate. If that verification succeeds the client now knows the copy of the public key of the other side. Note here that there's also an asymmetry, I guess I can go back. There's an asymmetry here because the client does not have a public key of their own. And this matches our typical expectation of what happens in practice. Right? Most of us, probably all of us have I would venture to guess, don't have public keys that we use in establishing TLS communication sessions. And that's simply because in part, we don't want to manage those public keys, and also the CAs don't want to deal with individual, end users. They only want to work with companies and will certify in their public keys. The protocol then continues by having the user generate a random value called pmk, which stands for premaster key. And encrypting that value using the public key of the web server. That results in a cypher text fee which it sends as the third message over here. So here we're using public key encryption to communicate a secret value from the client to the webserver. And I should note here, that ideally we would like this public key encryption scheme to be CCA secure. Because we like to protect even against an active adversary trying to interfere with the communication. In fact the TLS protocol does not quite use CCA encryption, in all it's different instantiations. But al least ideally, you can understand from our discussion, in week six that that's what you would like to use here. The client can, at the same time it's doing this, use a key derivation function, KDF. To derive MK, a master key, from the PMK and the nonces from both sides. It can then apply a sutorandom generator G, to the master key to derive four different keys. On the other end after receiving the cipher text the web server can decrypt and recover PMK and than apply the same procedure as the client did. Namely apply the key derivation function to obtain mk, and then apply a single random generator to mk to expand that short secret value to a set of four different keys. The client then computes a message of authentication code over the entire transcript of the communication thus far. And it computes that message authentication code using the secret value, mk, that its computed, and then hopefully the other side has computed as well. The web server can then verify this message authentication code. Check that not only is the tag correct, but that the tag is correct on its own view of the transcript of the protocol up to that point. The idea here is to make sure that any message sent by the client, by the user, was received unmodified by the web server and vice versa. And then if so, the web server will do the same thing in reverse. It will compute its own message authentication code, using mk on the transcript, up to that point in the protocol. And note it that the transcript is slightly different here because there's been an extra message in between when the client sent its own MAC, and when the server responded with its own. And for those of you who are particular here, I will point out that this is not exactly how the handshake protocol works, but this ist he core idea of how the handshake, with the final two messages of a handshake protocol work. The client of course has to verify that tag as well so that it can check that no messages were modified in it's interaction with the web server either. Now after a successful completion of the handshake protocol. The thing to note is that the user and the webserver now share four different keys. And it's those keys that they can then use in the record layer protocol to secure their communications. So again the parties now share these four keys kc, kc prime, ks, and ks prime. And the client is going to use kc and kc prime to encrypt and authenticate all the messages it sends. If you remember back to one of the earlier weeks in this course you remember we talked about the notion of authenticated encryption. And said that one way to achieve authenticated encryption is the encrypt, then authenticate approach, using independent keys and you can see here that TLS exactly provides independent keys for encryption and authentication to the client. Analogously, the server will use KS and KS prime to encrypt and authenticate all the messages that it sends. And if you remember back to our discussion of secure communication sessions, we mentioned there that one potential issue is a reflection attack. Where a client sends a message and then an attacker re-directs that back at the client and the client verifies and everything seems okay. there, we found that we addressed that issue by incorporating identities into what was authenticated. Here that problem is being addressed by having the client and server use different keys. So the reflection attack would not work in that case. Now, we also talked in our discussion of secure communications sessions about the need to prevent replay attacks to prevent the message as being replayed and being accepted as valid. By the other side, I'll mention that sequence numbers, kind of like the counter base solution we talked about then, are used here to prevent such replay attacks. And that concludes our discussion of the protocol. Now you know about how a real world protocol you use everyday, actually works.
