 Before we go through the example of the handshake operation, back to our sort of our practical implementation, we said that in HTTP, your browser sends a GET request to the operating system. And that uses TCP. With HTTBS, your browser sends the request to some SSL software on your computer, which then sends to the operating system. Where is this SSL software? Well, it turns out for many browsers, when you install your browser, either the SSL library is included with the browser, or, so either the SSL software is just packaged with the browser, or the SSL is provided by your operating system, or it comes installed when you install your operating system. With a browser, usually it's specific to the browser. So it depends upon the different operating systems. There are many SSL libraries. So this web page on Wikipedia lists most of the SSL, or here, TLS libraries. And I never remember the names, but some of them that we know about, or some common ones, we know there's open SSL. Most of the browsers you use today, they may not use open SSL. But many web servers use open SSL. So the Apache web server, by default, uses open SSL to implement SSL at the server side. What does your browser use? Well, some of the other ones, which you may see around, GNU TLS is one other implementation. Network security services, NSS, comes with Mozilla, Firefox. So NSS is one that's been used to implement SSL with Firefox. It may have changed some versions of Firefox, but that's one of the common ones. So when you install Firefox, NSS comes with it, and NSS does that SSL component. So it may be hard to see if we can zoom in. Network security services, Firefox, and other applications. Open SSL is a separate project. RSA was one used by many companies at its own one. Microsoft has a library called S-Channel. So when you write an application that runs on Windows, then when you write that application, if you want encryption, you may use S-Channel to implement the secure sockets there. And Apple has secure transport. So if you have an Apple application that wants to use SSL, you don't need to implement the encryption operations. You use the secure transport library provided by Apple. So there are some other ones which are available. And a good thing about having libraries is that you don't have to implement the encryption techniques, the cryptographic techniques. Now, with security, of course, even if the algorithm is secure, but someone then implements that algorithm and makes a mistake, and they have some bugs in the implementation, now maybe the implementation is no longer secure. So having secure implementations is very important. Trying to do it yourself, there's a high chance you'll make a mistake and lead to a security flaw in your application. So that's one of the benefits of using a well-known library. Many people have developed them and spent lots of time testing and trying to show that they are secure. So that was a little bit about the implementation aspect. Just before the detailed example, one last thing. Any application that uses TCP may use SSL, not just HTTP. It's just the example we're using uses web browsing, but other applications also use SSL in a similar manner. So with that, let's look at the example that shows these handshake messages, not all of them, but the main ones used by HTTPS. So what I have done before is I accessed a website, and before was actually a couple of years ago, so I did it before. I accessed a website, but importantly, I told my browser to use HTTPS. How do I tell my browser? The URL contains HTTPS. If you click on a link, that link either uses HTTP or HTTPS. That's how you tell your browser which protocol to use. So I accessed a website using HTTPS, and then I captured all the messages sent between my browser and server, so we're going to look at and draw those messages. You can download this capture, and the other one, I think it's linked to on the course website, and look at yourself in Wireshark. Let's just summarize first. It's different addresses than in the previous example. My browser is 192.168.1.7, and the server is 10.10.10.6 in this example. So just remember, those two IP addresses identify my browser computer and the server computer. And be aware, even though with HTTPS we're trying to encrypt and keep the messages sent between browser and server secret, we want confidentiality, we don't keep the server that I'm contacting secret. Someone still knows I'm accessing this website, but they won't know which particular page on that website I'm accessing. So when I say the URL is encrypted, well, the page will be encrypted, but someone can still intercept and see that this computer is accessing this computer, then they can do some investigation and find that this 10.10.10.6 corresponds to the ICT web server. And they know I'm accessing the ICT web server, but which page on the ICT web server will see that's encrypted. What do we see in this exchange? We see that there are some TCP messages at the start, and briefly, here's our TCP connection being set up between browser and server, the SIN, the SINAC, and AC. So that's the normal as with HTTP. Before we send any data, set up a TCP connection. Note that the port number used by a web server is different when we use HTTPS than HTTP. The port number used by a web server with HTTPS is 443. And that's what we see in this summary information. We're connecting from our web browser port, some random number, to the server using 443. With a normal HTTP server, it would be 80 here. We set up a TCP connection. Then we start to perform the SSL handshake. In this case, we're using actually TLS. We say SSL and TLS are the same, but there are some small differences in some of the versions. My software here shows me it's listed as TLS version 1.2. But when I say SSL, I also mean TLS here. There's a three-way handshake for TCP, and then we see the SSL messages. There are some TCP acts that come back, but I'm going to hide them so we can focus just on the security messages. So I'm going to filter out and show it only the SSL messages, and it becomes a little bit easier to look at in summary. And the protocol, there's no need to see that. We know it's the same. And this is the exchange of messages for our SSL connection between browser and server. So we'll go through these and see what's happening. Remembering, there are four phases. Negotiate capabilities, say hello, phase one. Phase two, the server authentication is performed using a certificate. And key exchange, server key exchange. Phase three, in phase three, it's optional to allow a client to send a certificate to the server. That's not commonly used in web browsing. So we will not see the certificate sent from client to server, but we will see the client key exchange in phase three. Phase four, they finish up with the change cypher spec and finished. Then there's data that is sent, but encrypted. What's shown in the info column here is the SSL messages, the client hello and server hello. A certificate messages is sent from server to client. Server key exchange, sorry, from server to client. Client key exchange from client to server, and some change cypher spec. We'll see one that's not listed in the slides, new session ticket. We'll return to that later when we see a more complicated example, and a change cypher spec. And then these messages, application data, they are the actual data from our application. But encrypted. So when we look at them in detail, we will see that we cannot see the HTTP get request. We cannot see the web page coming back, because it's all encrypted. We can guess that that's what these messages are. One of these is the browser sending a message to the server saying, I want to get a page. One or multiple are the server sending back to the browser saying, here's the web page. But when we zoom in on the data, we will not see the HTML, because it's all encrypted. So let's go through and we'll draw the exchange. I will not draw the TCP three-way handshake. We know there's a SIN-SIN Act, an Act will focus just on the SSL messages. So the first one is a client, hello, send from my browser to the web server. And we'll keep track of them as we go, and keep track of some of the information that's sent as well. So the first message is a client, hello, message. I'll simply list as hello. It's coming from the client, it's going to the server. What does it contain? That's of interest to us. So let's look inside and see what the client sends to the server in this case. I would double-click to look at the message in detail. It's a SSL message sent using TCP and IP. If we zoom in on the SSL message, I expand that, maybe just to start. First we see this is sent using the record protocol. So every message with the SSL is sent using the record protocol, but it's a special type of message, it's using the handshake protocol. So remember the first start of SSL, we do a handshake. And the type of handshake message is a client, hello. So we'll look inside, there's a structure of this message, some fields to say what type of message, the length. But inside the client, hello message, we'll see the important information. I will not show every field we've got the length and so on. First there's a random number. So commonly we've seen with key exchange and other protocols for security, we often use nonce values and we use random numbers for different purposes in security. So what they, both the client and server will do, the client has generated some random bytes and sends them to the server. They will be used later by the server, okay? So the client and server know both of those values. Note what an attacker can do, an attacker sees this. Anything we see on the screen, the attacker can see because they can intercept as well. So this is not secure, these random bytes. But we'll come back later, the random bytes, we'll see it in use. What else? The cipher suites, let's scroll down. So this is, there are 11 set of options sent by the client. This is the client saying what it supports. And the client supports 11 variations. Let me select say this one because it's a little bit easier, then we'll go back to the others. What does it mean, all this long string here? And there's common in exam question, here's a string, what does it mean? It's not so hard, it's split into different purposes, all right, TLS is the protocol we're using, we're using TLS, SSL. DHE, what do you think DH means? Diffie-Hellman, so the purpose of this string is the client is saying to the server, what do I support, what algorithms? And one of them I support Diffie-Hellman, and the first one is used for key exchange. So we support Diffie-Hellman for key exchange. Now, what does E mean? Is ephemeral, Diffie-Hellman ephemeral, there are slight variations on Diffie-Hellman, this one, which is the most common, means that with Diffie-Hellman, we would generate a public key for this instance, and if we do it again, we'll use a different public key, we'll keep changing the public key. There's a fixed Diffie-Hellman where we use the same public key every time. But that has a problem that if the public key or the private key is compromised, all of our subsequent communications are compromised. So Diffie-Hellman ephemeral, the e, means let's just use a Diffie-Hellman public key, private key pair now. If we do this again, we'll use a different one. I think they all use that, all that use Diffie-Hellman. So the first value is the algorithm for key exchange. RSA, what's that used for? We're going to exchange a secret using Diffie-Hellman, what may we use RSA for then? So not for key exchange, what? Generate a key, what type of key? Why do we need to generate a public-private key? We know RSA is a public key algorithm, so yeah, we can generate key pairs. We're saying Diffie-Hellman will be used to exchange a secret. So why would we need RSA as well? We could use RSA to exchange a secret. In fact, then two down, the key exchange algorithm is RSA. So that's an option as well, use RSA to exchange a secret. But here we're using Diffie-Hellman to exchange a secret. RSA will be used for authentication. Remember with public key crypto, with Diffie-Hellman a man in the middle attack is possible. The server sends its public key to the client, a man in the middle can modify that. So we need to somehow authenticate the public key. We will use RSA to authenticate the public key for Diffie-Hellman. And how do we authenticate? Well, we use digital certificates. So RSA will be the algorithm used for the certificate of the server. Diffie-Hellman will be used to exchange a secret. And to make sure that there's no man in the middle attack on the Diffie-Hellman exchange, the certificate will be used. So key exchange algorithm, authentication algorithm with symmetric key cipher. To encrypt our data, we're going to use AES, 128 bit key, CBC mode of operation. Last one, hash algorithm. So when we perform hashes, we'll use char in any of the operations necessary in here. We'll see when we generate some keys, we'll use a hash algorithm. We'll see that come up. My browser supports different variations. You see the 11 it offers to the server there. What's different? Different key lengths, AES, 128, AES, 256. Which one's better? 256 is better, why? Better for what? Better for security, better for making it harder for the attacker to find the key. Worse for performance, okay? So there's a trade off there. If we think 128 bits is sufficient, maybe we want performance, so we stick with that. This one, RSA is used for both key exchange and authentication. So we don't use Diffie-Hellman for key exchange. We would exchange a secret by encrypting with the public key and sending that encrypted message, and we'd authenticate also using RSA certificates. So we can combine key exchange with authentication if we want. What else do we see that's different? CBC mode of operation, we see that AES has a special mode of operation that we didn't cover called GCM, designed for AES. So there's another mode of operation which is common. Last one that's different here, EC. Elliptic curve cryptography. If you remember Diffie-Hellman, Diffie-Hellman is based upon the challenge of solving discrete logarithms. So the reason Diffie-Hellman is secure is because solving a discrete logarithm is hard. Well there are other mathematical problems which are hard. For RSA it's about factoring primes. For Diffie-Hellman, solving discrete logarithms. There are other math problems. One is finding points on curves. And it's referred to as elliptic curve cryptography, EC. And there's a variation of Diffie-Hellman that uses this elliptic curve cryptography to, can be used for secret key exchange, EC-DH. And similar, DSA is an authentication or signature algorithm, an alternative to RSA. The digital signature algorithm can be used in different modes. Triple desk is also an option down here. So the client says what it supports. What else does it include? What compression algorithms it supports? The client supports which compression algorithm? It doesn't support any. Null is the compression algorithm meaning we're not gonna compress anything. I can't decompress anything. In other cases you may see the client supports specific algorithms like ZIP, GZIP and other algorithms. But here Null means the algorithm is don't compress. Some of these algorithms have some initialization parameters. And the extensions may include some of them. For example, for elliptic curve cryptography you need some other parameters. So there's some extensions that include some parameter values. But we're not gonna go into those, we won't need them. The main purpose of this message is for the client to say what it supports. Let's see the next message. The server says hello, the server hello. Now what was in this hello message? Some things of interest, some random bytes. And the, we'll say the preferred cyphers. The preferred algorithms, I'll say ALG. The preferred algorithms, those 11 sets that we prefer. We send that to the server. The server sends back a hello message. What's inside that response hello? Note that within SSL there are actually two messages here. The server hello is coming back. And also the next message, which is a certificate, is also coming back. The client says hello, the server says hello back, but then the server sends its certificate. So there are actually two separate messages, but when we send them across the network we can put them into one packet to save how much we need to send. So there are two different logical messages, but we see it's, both of them are put into one packet here. So let's look at the first one first, the server hello. Here it is. It includes random bytes as well, some random bytes from the server, and it includes the selected set of algorithms. TLS, Diffie-Hellman, Ephemerial, for Key Exchange, RSA for Authentication for Certificates, AES128CBC and SHA for a hash algorithm. So what the server did, the server knows the set that it supports, it knows what the client prefers, it chooses the highest preference from the client that it also supports. In this case it's got this one. No compression. So what comes back is also some other random bytes, we will use them later, and the selected algorithms. And in our example, what do we select? We have for Key Exchange, Diffie-Hellman, for Authentication, Authentication of the server we'll see RSA, for Encrypt, that is the data Encrypt. It was AES128CBC and for the MAC or the hash, which we also use for the MAC, we'll use SHA. So the MAC function that we're going to use is HMAC with SHA. Remembering that a hash function takes just data as input, a MAC function takes data and a secret, we can turn a hash function into a MAC using a technique defined as HMAC. HMAC turns SHA, a hash function into a MAC function. So we use the MAC for the data integrity. Next message. And this next SSL message is in the same packet. What is it? It's the certificate of the server. And in the last lecture, we looked at certificates and some examples and if we expand and expand, this is a signed certificate. We have the subject, the subject is who's certificate it is and you see that the common name is the domain name of the ICT server. So the website I accessed in this exchange was the ICT server. This is the digital certificate of the ICT server. The subject is ICT and the issuer is the authority that signed it. I think in the time that I did this capture, then it was a self-signed certificate, let's check. We didn't have a real certificate then, right. Here the subject was ICT and the issuer was also ICT. That is it was a self-signed certificate and that's when accessing the ICT web server wasn't secure and if you access the registration website at the same time, you've got that warning message because we didn't have a real certificate there. But since this capture, we've got a real certificate for both ICT and registration which is signed by Komodo which we saw in the last lecture. So this is the digital certificate in the same format as what we've seen in previous examples. So let's draw that and I'll draw it as a second message even though it's sent in the one packet and it's the, what is it? We could think it's the certificate of ICT signed by an authority. What happens next? Browser receives this message, what happens next? Server, before the next message, what does the browser do next? You're the browser, you just receive the certificate from the server, what do you do with that certificate? You verify, you check if it's correct. So your browser, when it receives the certificate, it checks, is this signed by someone I trust? If yes, then it will proceed. If no, that's when your browser will show you this warning. You've just accessed a website that I don't trust. Do you really wanna proceed? Yes, we trust this certificate, so we proceed. Let's close that message. What's next? Another message sent still by the server to the browser, server key exchange. What's inside? The server key exchange. What algorithm are we using for key exchange? Diffie Helman, we negotiated. So this is the part of Diffie Helman now. We now need to exchange a secret between browser and server. So the server is sending a message called server key exchange inside that message, which is 523 bytes, is what? And if we look, unfortunately, Wireshark doesn't show us very clearly, but if we look at this message, here it is, here are the 523 bytes. What are all these values? Think of Diffie Helman. What does the server send to the browser? Remember the Diffie Helman exchange? The server selects its private value X and calculates its public value Y and sends Y to the client, to our browser. So inside here, my Wireshark software doesn't show it clearly, but these bytes include the public value Y of the server. What else is sent in here? What else must the client know for Diffie Helman? You need to remember the Diffie Helman key exchange. There were two public values at the start, alpha and Q. Remember, we have alpha as a base and we have Q as a modulus. So these two public values are also actually sent inside here. This message contains three values, alpha, Q, and Y of the server. It doesn't clearly show in this software the separation, but I know that that's how they are included. So we'll draw that message, say key exchange, and inside that are the Diffie Helman values, the public values, the global public values, alpha and Q, and the Y value of the server, I'll denote as YS. Of course, the server also knows its private value, XS, that's saved at the server. What happens next? What do we expect to see as the next message? What is the client going to send back eventually? You look from the picture, you'll see the next message, but for Diffie Helman, what do you expect next? Public key of the client, the browser. So eventually, there needs to be a message coming back containing Y of the client, where that can then be used to calculate the shared secret. And that will be in the client key exchange message. But there's something else before that, as you noticed. So we've done hello, client and server hello. Server sends the certificate, it also sends the Diffie Helman public values. We're not going to send a certificate request to the client, we're only going to use certificates for the client to authenticate the server, for the client to check it's talking to the right server. For the server to check it's talking to the right client with HTTPS, we don't normally use certificates, we use the form-based logins. So the user provides a username and password via the HTTP form. So there is no certificate request, there is no certificate from client to server, but we have a server hello done message and then the client responds with a client key exchange, including its Diffie Helman public value. So we'll write them down. First, let's see them, the hello done is included in this message, so the server key exchange and the server hello done are in there. Hello done is saying we've finished that stage. There's nothing of interest inside there. And then the client, once it's got the Diffie Helman parameters, note that we can record the XS is not sent, but is known by the server here, it generated its private value and the client does the same, it generates its private value, XC and calculates the public values, YC. The client key exchange and here inside that message we'll see shortly should be the Diffie Helman public key YC, the public key for client C. Let's have a look at that message and then we'll return to our diagram. So here from the client to the server, client key exchange is included, plus some other things, but look at the client key exchange, Diffie Helman client parameters. Public key, so why shark in this case shows me the specific value, there's only one. Here is YC, the public key, the Diffie Helman public key for our client. So that's sent to the server. What happens next with Diffie Helman? When the server gets this next message, what's gonna happen? Generate before RSA, how do we finish Diffie Helman? Calculate the secret key, that's the purpose of Diffie Helman to exchange a secret K in this case. So when this public key is received by the server, the server can calculate the secret key. We'll denote here as KCS, a key shared between client and server. And similar, the client also finds the same value. That's the idea of Diffie Helman. They can both get the same value. It's gonna be a long diagram, but that will take us to the finish of this topic. So send the certificate to the server, from the server to the client. The client verifies it's talking with the correct server. It verifies the certificate and when it verifies the certificate, it learns the public key of the server. So now the client has the public key of the server. Coming back to the key exchange. How do we know a man in the middle attack didn't take place? Server sends alpha Q and its public value to the client. Maybe a man in the middle modifies that public value from YS to Y of their malicious user. How does the client know that didn't take place? What else is needed here, which we haven't shown? It's not shown, we haven't drawn it yet. How would we make sure that when we receive the public Y value, that it hasn't been modified? How do we make sure something's not modified? Add a Mac, but we can't use a Mac yet because we don't have a secret exchanged. So what do we do to authenticate? So basically two ways to authenticate, add a Mac, but we don't have a secret to use a Mac. So what's the other way to authenticate? Not random bytes. Time stamp. Not timestamp. How do I authenticate messages? The server can sign the message. The server signs the message using its private key, private RSA key. Note that the certificate contains the public key, the public RSA key of the server. When we receive the certificate, we learn the public key of the server. So let's write that down. The certificate contains the public key of the server. So when I say PU here, I mean the public RSA key. We're using two public key algorithms, RSA and also Diffie-Hulman. PU is for that public RSA key. So in fact, this key exchange message, it is not just alpha, Q and YS, but it's signed using the private key of the server. So that server key exchange message, which contains the Diffie-Hulman public value, is signed with the private RSA key of the server. When the browser receives this key exchange message, it uses the public key of the server to verify the signed key exchange message. How does it know it's got the right public key of the server? It verified the certificate. Using the authorities public key. So we've got the combination of two public key algorithms here. The RSA certificate makes us, the client knows, talking with the right server and has the correct public key of the server, correct RSA public key. Then we use that to verify that the correct Diffie-Hulman public key is received. So now we know that YS is the correct value and we're sure that the KS values we generate have not been intercepted by a man in the middle attack. Questions so far. Our aim in the last 20 minutes is to finish this example, that's it. But it's a very important one because it captures, brings everything together. You can answer an exam question, explain what these steps do. You may not have to remember all the steps, but if I show you the steps, explain what some of those steps do. What's the purpose? Okay now, any questions? Good. In summary so far, we receive the public key, the RSA public key of the server in the certificate. We verify a certificate using the authorities public key, which we already have. Then the Diffie-Hulman public key, YS, is received and we verify it's the correct one using the RSA public key of the server. And that's how we prevent men in the middle attacks. Maybe just note that. We verify the certificate with the public key of the authority, the CA. And we verify this message with the public key of the server. These are both the RSA public keys. We know we have the right public key of the server because of the previous message was verified. Of course it all assumes my browser has the public key of the authority, which was preloaded into my browser when it came installed, the certificate authority. We're almost done with the key exchange. I think the last message now is what client hello done are not quite. Client key exchange and now the client says, let's change the cipher. Let's go back to the summary. We've done the key exchange. We both have a master key, KCS. So now we can stop using Diffie-Hulman and start encrypting our data. So the idea is that the client tells the server, let's change to use AES. And similarly in the next message, the server will tell the client, let's change to use AES. They actually do it in both directions because in theory you can have different algorithms in both directions, one using AES, one using a different one. So that's the purpose of the change cipher specs to say let's move to now encrypting our data. But there's this other message in here which we'll draw and then we'll explain news session ticket later with a slightly different example. So let me just draw those two messages and that almost finishes this one. And you see that the server also sends that. The purpose of these change cipher specs to say we're no longer sending plain text messages for the key exchange, we're now about to encrypt our messages using AES. It's like we're changing the cipher from no cipher to AES. And I think there's one last message. We'll see that, we'll guess that in a moment. Before we see the next messages, what keys do we have? Currently we know KCS, both sides. What do we use to encrypt? With AES. We're going to have a key to encrypt and another key to do a MAC. And we're going to have separate ones for both directions. Just going back to our slides. We need a key to calculate the MAC and we need a key to do encrypt and we use two different keys. And we actually have a key for sending from client to server and also a key for sending from server back to client. We have four keys there, four secrets. Two MACs, two encrypt keys. But currently we only have one. We have one secret, KCS. We need four secrets. How can I get four secrets from one? Split it into four parts? That's possible except we need the length to be long enough such that we can split into there. So we have KCS. If we wanted to split it into four parts then we'd need KCS to be four times as long as the individual parts. So that's a bit of a problem because we need a large key exchange to occur. So we can use an algorithm to generate a random number from this key. And a hash algorithm is the algorithm that we use here. What both the client and server do, they take a hash of the original key combined with some other characters which are known and we know a hash algorithm should produce random output. So we take the key as input to the hash algorithm plus another string, we get a random value as output. And then we do it again but with a slightly different input. It's hard to write down but I'll summarize the idea. What do we do? The concept is we take a hash of KCS combined with our random bytes, combined with some fixed string, let's say call it A. And that produces as an output a secret key running out of space K to encrypt from client to server. And then we do it again. We take a hash of the same KCS combined with our random bytes. Which random bytes? The ones which were exchanged between client and server. So we have two values of random bytes, one from the client, one from the server. We use them as input. And another known string, let's say B, and we get as an output another key. I'll call KESC. What we're trying to do is use this one shared secret to generate four secrets. We've got two so far. What we do is we take a hash of that original secret, some random bytes, random dot bytes are known by both client and server. They both know those values. And some fixed string, I denote A, but it's defined in the protocol, what it will be, known by both client and server. And we get some random output. A hash function produces a fixed length random output. We'll use as the encrypt key from client to server. We do it again, but with a different fixed string, I denote as B. Note the hash functions, two different inputs. We'll get two different outputs. Two different random values as outputs. When the server does this, it does exactly the same. The server will use KCS. It will use the random bytes, both the same at both sides. And it must also know the value of A. The value of A is defined in the protocol. It's known in the algorithm, so everyone knows it. So the server will generate K encrypt CS, K encrypt SC, and we'll do it again with two more times and we'll get the MAC keys. There will also be K, a key from MAC, from client to server, and also a key from MAC from server to client. The server generates those same keys. Okay? And I get all them right? What are the four keys for? E means for encrypt the data. Remember when we used the record protocol, we both calculate a MAC which takes a key and we encrypt which takes a key. So we'll say there's a MAC key and an encrypt key. K-E-C-S I'm going to use when I want to encrypt data going from client to server. K-E-S-C I'm going to use when I want to decrypt data from server to client if I'm the client. We'll have different keys for each direction. K-MAC-CS, when I calculate the MAC to send data from client to server, I'll use K-MAC-CS. And when the server sends me data, and it also has a MAC calculated, to verify that MAC, I'll use K-MAC-SC. So CS-SC is just for different directions of data communications. The values of A, B, there'll also be a C and D are defined and known up front. The server, sorry, an attacker may know A, they may know the random bytes, but they don't know K-C-S. So the attacker cannot generate the specific keys. Questions before we finish the exchange? So K-C-S is like a master key and the other four are like session keys. We can generate them again later if we want to. Or generate new ones if we want to as well. Where do we get to? We've done client key exchange, change cypher spec, finished, and change cypher spec finished. Have we seen the finished messages? Let me try and find them. Where are the finished messages? And I ran out of space. No one told me I missed one. In this message from client to server, client key exchange, change cypher spec, and this third one says encrypted, an encrypted handshake message. Let's look in what it is. Encrypted is just some random bytes. It's encrypted. I cannot see the contents because after we do the change cypher spec, we shift to using AES. So everything we send is encrypted. What do you think it is? What handshake message do you think this one is? Even though you can't see the contents, can you guess based upon the slide? It's the finished message. It's this one. We know that the client sends a finished message. It's just that it's encrypted. We can't see it in the capture. Similar, there's a finished message from server to client. So I'll draw them. But I forgot to include one in the client. This is the finished message. But it's encrypted. And there's also one in this direction. Finished. But it's encrypted. We don't actually see the contents. But we can guess. It's just a message saying, let's move on to the data now. What happens next? Here's the next message from browser to client. Let's look at the contents. Encrypted application data. My Wireshark software doesn't know what's inside. It can't decrypt it. Because it doesn't know KCS. And it cannot generate the subkeys and therefore cannot decrypt. So I just know that it's some application data. What do we think it is? You can guess. It's the HTTP get response from browser to server. What URL did I request? What page on the ICT server? It was the ICT server. We saw that. But what page? What file did I request? You don't know. You can't see. It's encrypted. So there's one aspect of confidentiality. So this is the request. We guess. And then you see in the other direction from server to browser some more encrypted data. What's in here? It's encrypted data. We can guess. It's the web page coming back. What is the contents of that web page? We don't know. It's encrypted. So this is the purpose of our SSL set up so we can securely communicate the HTTP messages. And that keeps going. Let's draw that to finish. This is the data. But it's encrypted. So anyone who intercepts this data cannot see the contents. And that was the purpose of the whole Handshake protocol at the start. So I think we got through that entire exchange. There are some other steps at the end. You can close the connection. But we're not looking at them. But we want to get how do we send the data. Any questions on this exchange? Random bytes? The random bytes were different on both sides. The client sent random bytes to the server. The server sent its own random bytes back. Both of them are used in the key generation. So we can use as many random bytes as we've got. That's okay. There's a specific algorithm designed here. I think it's not as simple as concatenate just the random bytes. What is the value of B? It's almost that simple. That is, you hash the key, the random bytes, some fixed string, and you get some key as output. But what is the fixed string? I don't have it on the slides, I think. Yup. The random bytes used in the hash function, this random bytes and this random bytes, they are the same. And the attacker knows what they are. Because they were sent in the clear across the network. So the attacker knows the algorithm used here. It knows how they combine this. They know the random bytes. They know the fixed string. But since they don't know the master key, they cannot work out what the generator key was. So it's about securing the master key and keeping it secret. It's actually called the pre-master key because we go through other steps by combining with the random bytes, we get a master key. Any other questions on this exchange? The KECS on both sides is the same. KECS calculated at the client must be the same as KECS here. Because when the client sends data to the server, it encrypts with KECS. And when the server receives data from the client, direction, client to server, it decrypts with KECS. The random bytes were sent across the network. Let's go back to the top. The value of the random bytes was sent from the client to the server. So the client knows that value and the server knows the value. And same with the other direction. So they are known, even though they're random, the same value is known by both sides. Is change cypher spec encrypted? No. There's just a short message saying, let's change now. So no, the next one after that was encrypted. The finish was encrypted. So the question, why do we have four keys? Why not just use the same KCS? Because everything's generated from KCS. It's the same reason for master keys and session keys. Later, we can use the same master key, KCS, but if we exchange some different random bytes, we can generate different session keys. And the concept, the security concept is change keys as often as possible because someone intercepts this data. If one of the sub keys is compromised, not the master key, but one of the sub keys is compromised, then other messages will not be compromised because we've got a different one. So that's the common principle, change keys as often as possible. And this allows that. We have five minutes left. We're going to go for another five minutes. Because there's one message, and I'll not draw anything new, there's one message we skipped over, new session ticket. Let's see what its purpose is. And I'll show you, because it's not in the slides, I'll show you a slightly different capture. And it'll be clear. This is a different capture. Very similar, but I accessed multiple pages. So I clicked on some links. So very quickly we see that we do the normal key exchange at the start. Client, hello, certificate, the key exchange, change cypher spec, encrypt the application data, request and response. And then later I accessed the web page on the same server. And although we do a hello, there's no key exchange here. In this second access to the same server, we don't need to exchange a key again. We don't need to exchange the certificate because we used from the previous exchange. So we have a cut-down handshake. How do we know to use the keys from the previous exchange? That new session ticket is the thing that is used so that when the client contacts the same server again later, in one of these messages, the client includes the session ID. So the server knows, ah, you're the client that contacted me before. Let's keep using the same keys that we used before. Let's not go through the key exchange steps again. Let's not go through the certificate verification again. Let's keep using the old ones. So that was the purpose of the new session ticket so that in subsequent accesses we can minimize the steps for doing the handshake. We can omit the key exchange steps. So it saves on performance. We access again and there's a client hello. There's no key exchange. So that's the point there. It allows them to reuse old keys from previous handshakes. The client hello message in this second access includes a session ID. And with that, the server knows, ah, you're the one who contacted me before. Let's keep using the previous values that we've agreed upon. So that's the role of the session. We've gone through the handshake operation. We've seen examples of the record protocol. We've used HTTPS as an example of SSL, but other applications can use SSL. For client authentication, we normally use passwords for websites.