 So we're looking at how we use SSL to encrypt our application data when that application uses TCP. So the application creates data, wants to send it using TCP. Before we send it with TCP, we use SSL. And we want to look at two parts of SSL, really, the handshake protocol which is done before we send any data. We perform some negotiation of parameters between client and server. And then everything that we send is then encrypted using the record protocol. So in fact, we have the concept of connections and sessions. Normally in TCP, we have a TCP connection. Let's try and draw it again. So we have a client and a server. Not so good. So from the internet perspective, we have IP, TCP, the application. But in between the application and TCP, we've inserted this secure protocol, SSL. So everything we send can be secured. And at the client and similar to the server, both implement SSL. So in SSL, we have these two concepts called connection and a session. In TCP, we know we have a connection. In TCP, before we send data, we do the SIN-SINAC-AC. We set up a connection. And SSL connection directly corresponds to a TCP connection. So if we have one TCP connection between client and server, we have one SSL connection. So how do we define a connection in TCP? This computer has an IP address, 2222. And this one's 1111. And we use port numbers as well. So let's say we have a port number 80 at the server and at the client 40123, just some random port number. We can say this TCP connection is uniquely identified by these four values. It's a TCP connection between 1111 and 2222, the IP addresses. And in particular, between the application using port 40123 and the application using port 80 at the server. So those are the four identifiers of a normal TCP connection. The same with an SSL connection. When we create one TCP connection, that's also an SSL connection. We'll see the role of them in a moment. But in SSL, we can also have what's called a session, which can encapsulate multiple connections. So a session is an association between a client computer and a server computer. So when you access and download a web page with your web browser, there's one web server, one computer. Your computer is the client. But often if that web page has images on the server, what your browser may do is create multiple TCP connections to the server and download the HTML, the images in parallel. So a common setup with a web browser and server is that we have our client, browser, and our server. And the server uses port 80. The client, the web browser, creates a new port for every connection it wants to establish to that server. This is with TCP. So 40123. And another TCP connection, for example, to download an image from that server. Because web pages often have images or flash objects or other objects. So it's possible to create multiple connections, multiple TCP connections from one computer to the other computer by using different port numbers at the client normally. You could use different port numbers at the server, but commonly it's at the client. So this would be three TCP connections between the same computers, between my client computer and server computer. It's just that my web browser for each connection is using a different port. So we have three parallel TCP connections. That can sometimes speed up the download of individual web components or objects. An SSL connection is associated with each TCP connection. With SSL also, we can group those connections together in a session. We say that each of these are connections. So connections, three connections. But together, we say this is one SSL session because the connections are all between the same application on the client and the server. So the web browser application on the client and the web server application on the server. Why do we do this? Because many parameters when we do encryption and authentication will be the same across those connections. So what SSL allows you to do is, of course, to still establish a connection and have some parameters for each connection but have common parameters across those connections to all connections within a session. What are those parameters? It's some information needed to support the encryption or the security protocol. For example, inside a connection, there may be some random values because we often use random numbers for some authentication scheme as a nonce value. We use random values. The keys to encrypt with, because we're going to encrypt data with some secret key, what is that key? Well, we store it per connection. The MAC secrets, so also MAC functions have keys. So we store them. Some initialization vectors, some initial values, sequence numbers and so on. So in our example, my client computer has three connections to the server. With each connection, we'd have a different key to encrypt. Whenever I send data on connection one, I encrypt with one key. On connection two, a different key. Okay, so they're different now. But then across the session, which covers those three connections, we may have some identity. So this is session ID one. A certificate of the server. When we receive from a web server its certificate, it's common for all three connections. We don't need a separate certificate for each connection. So we store one's certificate for the entire session. We can usually use a common compression protocol. Compression's not for security, it's just to reduce the size of the packets being sent. So we can use that common across the connections and a Cypher spec is a specification of what algorithms to use. What encryption algorithm? What MAC function? Again, common across the connections. So my session may be using AES. One, two, eight. And as a MAC function, it may be using, I can't remember a name. There's some on later slides. Some MAC function, MAC, HMAC. So this Cypher spec indicates what functions or what algorithms are used for all connections. And then in connection one, we're using AES with 128 bit key and the key would be some value. And for connection two, we use a different key and connection three, another key. So we have some values common across the connections and some values specific to the connections. So the keys are specific to connections. So when I am downloading a web page, some HTML, a JPEG, a flash object, I may have three different connections using the same Cypher using different keys to have that encrypted. This information of what certificate, what compression algorithm, what Cypher spec, what keys they are created using the handshake protocol. So before we do anything, we perform this handshake between client and server and we agree upon these values. What algorithm to use, what key to use. So that's the role of the handshake protocol. Once we've set up that, then we use the record protocol as we finished before the break. We take our data from the application, depending upon the session and the connection that this data belongs to. We encrypt, sorry, first we fragment, we split it into smaller chunks, usually to support efficient encryption. So it's not too big to encrypt. We compress or optionally compress, use some Mac function, which also takes a key where the key is associated with the connection. Encrypt, add a header, send across the network using TCP in this case. So what we wanna look at mainly is this handshake protocol. How do we agree upon these parameters? What have we got? Okay, before that, some more details of the record protocol. Okay, some parameters. Fragmentation, there's some maximum size. So it has to be less than 16,384 bytes. Compression algorithms, you can have no compression, they or some lossless compression algorithm. Lossless, for example, zip, rah are lossless compression algorithms, which means we take our data, we compress it. When we decompress, we get the exact same data back. We don't lose any information. A lossy compression algorithm not used here is something like MP3. You take some song, you compress using MP3, and when you decompress, you've lost some of the information, and that's why you get lower quality audio. But we don't use lossy compression here, lossless. The algorithm is chosen in the handshake. We need to specify which or choose which Mac function to use. HMAC is a common one. There's, as you remember, a Mac function uses a key, so we need to also choose a key to use, and it's applied per connection, and added at the end of the fragment. We encrypt using some algorithm, again chosen in the handshake, and there are multiple algorithms to choose from. The SSL record header that we add at the end indicates the content type, which indicates, so the header here has different fields. It indicates whether this is a handshake protocol, a cipher spec, an alert, or coming direct from the application. Some version of the protocol and the length in bytes. That's a way to view this packet. If we look at this packet in some more detail, we have a header and the encrypted data. We have the header with four fields, everything encrypted, which is the compressed data and the Mac. This is just the value of the content type. No need to go through this one. So there are four types of content, change cipher, handshake, alert, or the application protocol. We don't wanna go into the details of how the protocol works, just the basic concepts, and we'll go through an example to see it. How do we exchange or negotiate parameters? What algorithms to use? What keys to use? We use a handshake protocol. That happens at the start. We negotiate the algorithms and the keys. For example, the key exchange algorithms, RSA or Diffie-Hellman. So how do we work out which key both sides will use? So we can use Diffie-Hellman to exchange a secret key. We can use RSA and certificates to encrypt something. So if I have another user's public key, we can encrypt with the public key a secret and then send that to the other user. So the key exchange algorithm, the Mac function, HMAC. Remember, HMAC takes a hash function and turns it into a Mac function. A hash function just takes data as an input and returns a hash value. A Mac takes a key and data. Some example hash functions are MD5 and SHA. So what HMAC does is takes these common hash functions, MD5 and SHA, and allows them to also work with a secret key. Hence they become a Mac function. Encryption, different algorithms can be chosen. Desk, triple desk, AES and so on. So how does the handshake protocol work? There are four main phases. The client and server advertise what capabilities they have, what algorithms they support. So we'll see the client says, I support or I propose these algorithms. The server selects one of them and they use that one. That's the start. Then we need to authenticate the server, make sure that we're communicating with the correct server and also exchange keys with the server. And then we can do client authentication. The server wants to make sure that it's talking to the correct client and some key exchange so that we can exchange a secret key that can be used later in the encryption. And then there's some messages to say, we've finished the handshake, we can now send data. So there are four phases. There are different message types that can be sent here and they are listed here, but we'll try and describe them with the example. The example I'll show you is going to be similar to this, but not exactly the same. What this one shows, the four phases. Phase one, two, three, four. The first phase we send hello messages. The client contacts a server saying hello. These are the algorithms I support. The server sends back a response saying, let's use these algorithms. Once that's done, the server can then send a certificate. So a digital certificate containing the public key of the server and some messages to perform a key exchange so that we can do, for example, Diffie-Hellman. So remember Diffie-Hellman, we exchange a secret key. Later we need a secret key to encrypt our data. Which secret key? Well, we can do a key exchange. Optionally, the server can request the client to send a certificate back. And if so, the client sends a certificate to the server. It's not mandatory. And when the server's done it sends hello done. I'm done with this step. The client sends its certificate, some information to exchange a key and some information to say it verified the server's certificate. And then effectively they finish. They say let's start using our cipher. That's what this change cipher spec message does. Saying let's start encrypting our data. And we finish, we tell each other to let's start encrypting data. And then we start sending the data. We're gonna go through that using HTTPS as an example. You use it on a regular basis where you connect from your browser to a web server in a secure manner. Anyone use HTTPS? Facebook. Okay, when you log into Facebook. When you log into Facebook, for example, it usually, well, I think by default now, it reverts to HTTPS for your login. So that when you send your username and password between your browser and the Facebook web server, it's done in a secure manner. Moodle, bank websites, many websites. Now, if there's some information to protect, we'll use HTTPS. What is it? It's in fact, just HTTP, the normal get response messages, but sent using SSL. So there's no different protocol. We just take our normal HTTP messages at the application layer and use SSL to encrypt those messages. So it's really HTTPS is HTTP using SSL. How do you know or how do you tell your browser when to use it with the scheme HTTPS instead of just HTTP in the address? What about a server, a HTTPS server? It's just a web server. Exactly the same. It listens by default on a different port number, port 443 instead of port 80. And of course it also, our server implements SSL. So in fact, a server will normally use port 443. And once we establish the connection between your browser and the web server using the SSL handshake protocol, the data is encrypted. That includes when you send a get request, remember you say get index.html and many parameters like the host name. That's the get request that is encrypted by SSL, which means anyone between the browser and the server cannot see this request. They don't know what page you're requesting. They don't know, they know the destination IP address and therefore they can work out the server. So imagine now, here's the Facebook web server, your browser, here's your internet connection and your ISP. So the question is, can we hide our, or keep our data private from your ISP or other internet service providers between you and Facebook or anyone who has access to these networks? Because your data goes to a router in the ISP, goes to another router and eventually goes to the Facebook web server. Can we keep your data private or confidential from those intermediate users? Well, yes, using SSL. This get request is first encrypted. We take the get request, SSL encrypts it and then sends it. So anyone in between, all they see is some random text because it's encrypted, the ciphertext they see. They see the destination IP address and they see the destination port number because that's carried in the IP header and the TCP header respectively. So if we draw the packet that is sent, sent across the network, there's an IP header, the TCP header and then the SSL header and then the data. Anyone in between can see the IP address. They can see that it's 1111 sending to 2222. So they know who's communicating. They know it's between some port number and some server port number 443. So they can guess that it's to a secure web server and it's using SSL, but they can't see the data. Anyone in between cannot see this request. So they don't know what URL you're going to. They can work out the domain you're going to based upon the IP address. So they can work out that you're visiting Facebook but not the specific page on Facebook. Of course, when the server sends back a response, it's also encrypted. So the contents of the document that comes back, the response that comes back is encrypted. Things like when you enter data into a form, a login, a username and password and you press submit or you enter in a lot of data on a form and press submit, all that data is encrypted. So no one can see that. In particular, your login. When you log into Facebook, there's this login username password, you type it in, press submit. That information is carried encrypted inside this packet. So no one can see your username and password. Cookies, any of the contents of the HTTP header like the host name, it's all encrypted. So that's for confidentiality. For authentication, HTTPS uses certificates for the server. That is, how does your browser know that you're connecting to the right server? You've typed into your browser, HTTPS colon slash slash Facebook.com. Your browser connects to the server, eventually the server will send back its certificate. And that certificate should be signed by some authority. And your browser will verify that certificate and make sure that the public key inside that certificate is in fact for Facebook.com. It's not for malicious user.com, okay? Because if it's the public key for Facebook, then you can use that public key to encrypt information to send to Facebook. But if the certificate is for someone else, then your browser should detect that and present a warning or an error saying, you've received an invalid certificate. Don't trust this connection. So the client confirms the server's identity using a certificate. But what about the server checking who the client is? Well, the client doesn't send a certificate back. Instead, the client uses normally a username and password. So how does the server know that it's you, the right person, logging into Facebook? Well, what you do, they give you a form, you type in your username and password, you send that encrypted to the server and then the server checks. Okay, it's the correct username, correct password. It must be you that's logging in. So the server authenticates the client normally based upon passwords. The client authenticates the server based upon certificates. The certificate is exchanged using SSL. The password is not exchanged using SSL. That's part of the webpage using HTTP. I've got a capture of an exchange. Let's spend the last 20 minutes having a look at that capture. So I've done two things in this capture. First, I've accessed a insecure webpage just to remind us how it works and then using HTTPS. Let's see. Everyone's experts on Wireshark. They see the green ones in this case are our TCP connection being set up. So we have a client and in this example the IP address of the client 192.168.1.5 and the server is 125.25.4210. The first two messages are DNS. It's my browser finding out the IP address for the domain name. So what I typed into the browser was in this case HTTP, not HTTPS and the domain name. And possibly that's it, slash, I think. So I typed that into the address bar of the browser, pressed enter. What happened is my web browser query DNS found the IP address for that server, 125, so on. And then in the highlighted orange packet, here we're not using SSL, just normal TCP. We set up a TCP connection. So we have a SIN, SINAC, ACC, set up a TCP connection between client and server and then HTTP goes to work. We send a HTTP GET request requesting the slash, which is the root directory which will default to index.html and we see some header information in this request. The host name, user agent, so the identifier for the web browser and some other parameters that my browser sets. A cookie is seen in here. So that's sent to the server and then there's a TCP ACC that comes back and it's not a good example because what the server sends back in this case, so I send a request to the server, the server checks the web page and sends the web page back. Well, not exactly in this case. Normally, or in a good example, it would send back 200 okay, including the web page. Unfortunately, in this example, I'd access the web page slightly earlier and it sends back not modified meaning you've already got a copy of that web page. But this is the response from the web server. Of course, nothing is encrypted. Anyone in between the client and the server on the internet who had access to the routers or any of the links between them could, in theory, see all of this. So for example, the first router that my computer connects to that run by the ISP, that internet service provider, someone can intercept all of these packets and see the content that I'm requesting and that's coming back. Of course, that's not good if I'm requesting access to my bank account and sending usernames and passwords. So the next example, we close the connection. The next example is I did it again, but I used HTTPS. That is, I told my browser to perform an SSL handshake to set up a secure connection between my browser and server. Again, there was a DNS query, so that's not part of HTTPS. That's normal for your browser. And then TCP sets up a connection. So SINAC, but note the port number and it's here. The SIN is sent from the client computer to the server computer. The source port is 60214, chosen by my browser. The destination port is 443. Whereas in the previous one, although I didn't show it, the port number was 80. So the server is listening on a different port number. So we set up a normal TCP connection. SIN, SINAC, ACK. And now TLS, SSL goes to work. Here it's shown as TLS. I've called it SSL, they're the same, effectively. What happens is we do the handshake between client and server. Client sends a hello message. And this is similar to on the slides. Sends a hello. I want to set up a SSL connection. Let's make some space. And inside this hello message, we're using the handshake protocol. This is the client hello message. Some values of the type, the length. And importantly, the parameters or the algorithms that the client is willing to use. The set of ciphers, 36 different sets of ciphers that it may use are listed here. For example, this one. Let's start with the one that we may recognize easier here. Use Diffie-Hellman to exchange a secret key. Use RSA for certificates for public key encryption. Use AES with a 256 bit key with CBC as the mode of operation for our symmetric key encryption. And use SHA as the hash function. So my client is saying, I support all of these combinations. The server needs to choose one. The one that the server supports and wants. So this is the client saying hello. I support all of these algorithms. Choose one. And the next message. So this is the client saying hello. This is a TCP act. They're saying the server received that TCP message. Then the server sends back a response. A server hello. And let's expand and see what the server said. Hello. And it selects one of them. In this case, RSA. AES with a 256 bit key for symmetric key encryption. Using CBC and SHA as the hash function. So it's going to use RSA public key encryption to perform authentication and to exchange a secret key. So the basic approach is take the public key of the other user. Choose a secret. Encrypt that secret with the public key and send it. And the other receiver decrypts with their private key. And then once we've exchanged the secret we'll use AES 256 to encrypt the data. Because AES is much faster than RSA. So we start with the public key cipher and then for the data encryption switch to a symmetric key cipher. So this is really negotiating the parameters or the algorithms to use. In fact, they also say whether to use compression. In this case, there's no compression. No. Don't compress. So that's the hello. Which was these two messages. Client, hello, server, hello. That's phase one. Next phase is the server sends some information for authentication like a certificate. These are the generic messages but we can combine them into one packet. Because note that the server is sending a hello, then a certificate and then a key exchange. Instead of sending three different packets across the network put them all inside one packet. And that's what we see in Wireshark. We see this one packet contains three different messages. It contains a server hello, a certificate message and a server hello done message. So it's all included just for performance reasons. So we've looked at the hello message. The next part is the certificate. This is where the server sends its digital certificate to the client. And we'll see it in here. 582 bytes. And we can see the actual signed certificate. So when we looked at key distribution in the previous before passwords we saw the structure of an X509 certificate which had the issuer, the subject, how long the certificate is valid for and the public key information. And we can expand these to see who the subject is. So the country name, the province and so on, the common name which identifies in this case the domain name of the server. So this sandylands.info should match the server that the browser tried to contact. Because we typed in the domain name at the browser we should get the certificate which contains that domain name. And the browser will check that. Because if we get a certificate for someone else then it may be someone who's pretending to be that server. And we shouldn't encrypt data and send to them. So when the browser receives this certificate it checks the domain name and verifies using the certificate of the issuer. Remember we verify a certificate using the authorities public key. And the authority is the issuer in this case. In this example it was, and it's a bit old, I should do it again, but it was a self-signed certificate. So it would have presented a warning on my browser saying do you really trust this certificate? It's self-signed. I said yes. So the certificate is sent back and then the server says I'm done for this phase. So in this one message or one packet the server selects the algorithms, sends its certificate and then says I'm finished this phase. Hello done. When the browser receives that certificate it verifies it. So Firefox looks in the list of authorities that it knows and checks the certificate received. Is the domain name correct? And is it signed by an authority I trust? If not, then present a warning or an error to the user saying you've just contacted a server with an invalid certificate and then it's up to the user, the human user, to check whether they trust it or not. What we're seeing in this example is slightly different from the generic approach. This is the generic approach. Not all of these messages are needed. So we've just seen hello certificate, hello done. There's no key exchange in this case. And we don't request a certificate from the client in this case. Once the client verifies the certificate it responds and we see it has a key exchange message, change cypher and then we'll see an encrypted message. Let's zoom in. What the key exchange message is doing is the client's telling... The client tells the... The client chooses a secret key and will eventually encrypt that using the public key of the server. It receives the public key of the server in the certificate. And this is saying that we're about to exchange a secret key. The key exchange. The change cypher spec just indicates let's start using the cypher to encrypt our information. Up until now, nothing's been encrypted. We can see everything. Change cypher spec says let's change and start using our encryption algorithm. So we have key exchange indicating we're about to exchange a key. Change cypher spec to indicate let's start encrypting. And the third part of this message we don't know what it is because it's encrypted. It says it's an encrypted handshake message in that we cannot see the contents of this. If we look at the bytes, they make no sense to us. These 48 bytes are some cypher text because it's a message sent from the client to the server that's been encrypted. So most likely it's the secret key that's been encrypted. And it's been sent to the server no one in between can see the value. How do we encrypt it? Using our cypher that was specified in the server hello message. We're almost there. So key exchange, change cypher and then something was encrypted. Server sends back some response message. Saying it's encrypted. I cannot see what it is. Let's change our cypher. It's most likely an acknowledgement saying everything that I just received from you is okay. And now change cypher means everything I'm going to send to you is also encrypted. So we have a change cypher here. Something encrypted. And that's the end of this handshake. So this is just the handshake. We do it the start of the connection. We select parameters or select algorithms. Server gives the client a certificate. Client checks that. Exchange a key so they select a secret to use for encryption. And then they send although encrypted these finished messages. They're saying we're finished this step. And then once those four phases are finished we see the application data. We see it or at least we see the cypher text for it. Because when we intercept it we cannot see what the original contents are. This is most likely the get request going from the client to the server. But it's encrypted so anyone who intercepts cannot see what the get request is. And similar the server sends back a response in the next message. What is the response? Well, most likely it's the web page that the server is sending back. But it's encrypted. No one can see the actual contents of that web page. And all subsequent messages are encrypted. So we see the process of setting up the connection. And importantly the server sends the certificate to the client. And once they've set up that connection and done that handshake all the data that they send all the HTTP requests and responses are encrypted. And anyone who intercepts will just see the cypher text.