 So remember, HTTPS is really just HTTP using SSL. SSL and the latest release is TLS, Transport Layer Security. SSL slash TLS can be used for any TCP based application, not just for HTTP. You can use it for email. You can create your own application that will make use of this. So it's for any transport protocol or any application based upon TCP as the transport protocol. But we're using as an example HTTP because that's what we commonly see. We said, and we haven't gone through the details yet, but we have said that really there's a record protocol that does the encryption of data and authentication of data using MAC. So everything that we send, once we've set up a secure connection, we encrypt and attach a MAC for authentication, and that is part of the record protocol. But before we do that, we must exchange keys and agree upon algorithms to use, and that's part of the handshake protocol. Alerts when things go wrong, change cypher spec is just to say, let's change from the path set of keys and let's use the new set because the approach is to exchange a secret using public key cryptography and then encrypt our data using symmetric key cryptography. So we started going through an example from a packet capture from a web browser to a server, and we'll try and finish that today. What we got to is that first there's the normal TCP connection set up. That's the same as normal HTTP, SIN, SINAC, ACK. And then before we send the request, the HTTP get request from browser to server, we actually need to establish a secure connection, the SSL connection. And we started seeing some of the messages involved there. First, the browser sends a hello message to the server, indicating several things, but we noticed that it included some random bytes, and we'll see those random bytes used later as a sort of nonce value, and also a list of preferred sets of cyphers. So there are different sets of cyphers that we are going to use, and we said that in the response eventually that the set of cyphers chosen in this specific example was Diffie-Hellman ephemeral, which is a Diffie-Hellman algorithm used to exchange a temporary secret. Diffie-Hellman's used for secret key exchange, and that's what we use it for here, but we only use that secret for a short time. It's not for a long-term secret. Now the problem with Diffie-Hellman is that a man in the middle attack can occur, so we need to know, say from the browser's perspective, when it receives the Diffie-Hellman parameters, it needs to know it is from the server. It's not something pretending to be the server. And we use RSA authentication there. So in addition to Diffie-Hellman, the server will send a certificate to the browser, and in fact that private key of the server will be used to sign the Diffie-Hellman parameters. So when the Diffie-Hellman parameters are sent by the server to the browser, they are signed by the server. And if they are signed by the server, we need the public key of the server to verify. And the public key of the server is contained in the certificate that it receives, but we must verify the certificate. And we'll see that the certificate we received is signed by an authority. So assuming the browser trusts the authority, it can verify the public key of the server, and therefore it can verify the Diffie-Hellman parameters it receives because they are signed by the server. So one purpose of this combination of two forms of public key cryptography, Diffie-Hellman to exchange a secret, RSA used to verify that those parameters in that exchange are from the server. Once we exchange a secret, when we want to send data between client and server, browser and server, we encrypt using symmetric key encryption. In this case, it will be AES128 using CBC as the mode of operation. So that's the data encryption. Also, all the data we send, we apply a MAC, a message authentication code. What we do is we calculate based upon that data or that fragment of data. We calculated a MAC value using some secret key, and it gives us some tag or some code that we attach. And it allows the receiver to verify that the fragment it receives has not been modified. So that's message integrity. And in this example, the algorithm's chosen, it's always using HMAC, which is a general algorithm to turn a hash function into a MAC function, and the specific hash function used is SHA in this case. So those parameters were exchanged in the hollow messages. Actually, first, the browser sent its list of preferred set of algorithms, and when the server responded with a hello, it sent back the selected set, the ones we saw on the previous picture. And also some random bytes, some different random bytes from the server. The next message from the server contains its RSA certificate. So it contains the public key of the server, matching the domain name we accessed and signed by some authority. And the last message we got to, there are more to come, is a key exchange, a server key exchange message, and it includes the Diffie-Hellman parameters. And if you remember back to Diffie-Hellman, the algorithm, remember there was some public values, alpha, q. Both sides need to know that. The server chooses the alpha and q and sends it to the browser. The server calculates its value of y. Diffie-Hellman was we choose a private x, then we calculate y as alpha to the power of x mod q. So in this key exchange message, the server tells the browser its value of alpha, q, and y, ys there. And when the browser receives it, to check that this is not a man in the middle attack, it's not someone pretending, sending these fake values, that data is all signed with the private key of the server, the RSA private key. So we use the public key of the server to verify that data is correct. So let's see what happens next. Before we do so, any questions on what's happened so far? Today we hope to finish this exchange and we're seeing multiple algorithms being used in practice in this exchange. We got to the server key exchange. Note that some of the SSL handshake messages are sent inside the one packet. So it's possible that you can, in this one for example, from server to browser, it was one packet sent across the network, one TCP packet, but it contained two handshake messages, the low message and the certificate. So that's possible, depending upon the size. And the key exchange contained the key exchange packet. If we look in there, it doesn't show us because it's all signed, but it's 532 bytes. That is the values of the Diffie-Hellman alpha, q, ys, all signed with the private key of the server. But this packet also contains another handshake message. It's server hello done. So the server's done at this point. It's sent the public parameters. It hasn't calculated the secret yet, but when it receives a response from the client, it will calculate the secret and it can start doing the encryption. So we'll draw the next message and then see what the client does. So what do we get? So the server's done. Now let's look at what the client does. The next message contains actually multiple handshake messages. The client key exchange and we'll see some others eventually encrypted. This is the client key exchange. So the previous one was the server key exchange message. This is the client key exchange. What does it include? The Diffie-Hellman parameters from the client. Remember, Diffie-Hellman, there's alpha and q. They were sent from the server to the client. YS, the public value from the server, was sent also. And then eventually the client, when it receives them, it chooses its private value, X of the client, calculates its Y value, YS, sends it back to the server. And this message from client to server contains that value of Y from the client. It's listed here, the public key of the client in this case. So this is the Y of the client coming back. 128 bytes or 1,024 bits is the length of the public value in this case. So let's make note of that and then look at the next two. And once... So from the client's perspective, it receives alpha, q. It can now calculate... It chooses its private value, X, calculates YC and sends that back to the server. It can also calculate the secret. So to note here, we have some secret between the client and the server. And when the server receives this key exchange message, it can also calculate that secret, KCS. This is the Diffie-Hellman secret shared through that algorithm. Because if you remember back to the algorithm, we calculate based upon the Y values and the X values. And they both get the same value. That was the idea of the Diffie-Hellman algorithm. So after sending this, the client knows KCS and when the key exchange is received by the server, the server knows or can calculate KCS, they now have a shared secret, which was the aim of this key exchange steps. They'll use that to encrypt their data, but they'll not use it directly. It's a little bit more complex than that. Let's look a little bit about what happens with those secret values. So there's one secret value, which is called the master secret. Actually, it's called slightly different. This is a bit too much detail. It's called the pre-master secret. So this value that we just calculated using Diffie-Hellman is called the pre-master secret. And then there's an algorithm defined that both of them will follow that says we take that value, combine it with some other values, such as the random bytes that were sent in the first messages, use some hash functions and generate another secret. And the idea is to create a secret, which is eventually the master secret, which will be used for other steps. We will not go through the exact algorithm for converting the pre-master into a master secret, but it combines the... It uses some hash functions. It's known by both sides, including the attacker, and the output is really a master, the master secret. And both sides will get the same value, because the algorithm that they follow is the same. Then that master secret will then be used to generate another secret. Secrets for doing the encryption and secrets for doing the Mac. So in the steps for encrypting the data, which we'll see shortly, there's not just one key used. Remember, our AES uses one key, a Mac function uses a key, and they should be separate for security. We should use different keys for the different operations. So we need two keys there. Some of the algorithms, remember, the modes of operation sometimes have an initialization vector. They are usually kept secret and generated as random bytes. So I think if that's another secret value generated. So again, we take this master key and apply a known algorithm to generate multiple different secrets as output. And essentially what it does is it takes the relatively short master key and produces random bytes, and some of those random bytes are used for the different keys. So the master key is combined with... If we go back to the start, these random bytes from the client and also the random bytes from the server, they are all combined together plus random bytes and using some hash functions. And we don't need to know the detail. It's in the specification, but using some hash functions, it produces as an output different keys. The encrypt key, a MAC key and IVs, initialization vectors and even some other values that may be used for other operations. It actually uses different keys for each direction of data encryption. So I will not list it here, but this master plus the random bytes which were exchanged at the start are all input to a function that produces many keys as output. There's an encrypt key for the data that browser will send to the server. There's a separate key for decrypting from what the server sends to the browser so that each direction, they have a different key for encryption. Similar, they have a different key for the different directions for applying the MAC. So in fact, there are two MAC keys, two encrypt keys, two initialization vectors. They are all generated from this master which actually came from the pre-master which was obtained using Diffie-Hellman. I will not draw it for the server, but because it uses the same input and they apply the same algorithms, they'll get the same keys as output. So they both know the same set of keys. So where do we get to with our protocol? That happens. That's processing at the browser and the server, the client and server. Inside this message, there was the client key exchange and as a result of that, after that the browser now has a set of keys that it can use. So the next message it sends is this special change cipher spec. This is just saying to the other side, let's swap from doing the key exchange to now start to use those keys that we just generated. The encrypt key, the MAC key and so on. This is telling the other side it's time to change to the other keys. And from then on, we'll use those keys to encrypt the data. So there's another message that comes. But if we try to look at the contents, we don't see it. It just tells us, Wireshark tells us, this is an encrypted handshake message. It's encrypted with a key which we cannot, we don't know, we've captured, we don't know what the key is. So we know it's a message sent from client to server, but we don't know what the contents of that message are because it's encrypted using the keys that we just generated. So we'll write that. So we had a change cipher spec and then this last handshake protocol message. Anyone want to guess what this one is? Let's go back. So this, from the client, client kicks change, change cipher spec. And this one is from Wireshark's perspective that was us capturing the packet, intercepting. It can't see what it actually is, but we know from the protocol how it's defined what it probably is. If we go back to our slides, there's an example of what the exchange normally contains. Where is it? Here. We, let's see what we've seen. The hello message from client and server. The server sent a certificate to the client. Then a server key exchange. Hello's at the start. Certificate, server key exchange. This diagram shows the general case where a certificate is sent from server to client. In addition, the client sends a certificate to the server. But that's optional. And it's not normally used for web browsing. With web browsing, we only have a certificate stored at the server and send that to the client. This client, your web browser doesn't have its own certificate. So in fact, there's no certificate request. The next message was the server hello done. We skipped this phase three because there's no certificate sent from client to server. We got the change cipher spec and then finished. So the client's actually sending finished. I'm done. Finished the handshake. So this last one here would be an encrypted finish message. But note it's encrypted when we look at it in Wireshark. That's the finish of the handshake step. What comes after that is the data for the application. From the client, we had client key exchange, change cipher spec, then this encrypted handshake message which we think is the finished message. Even though we cannot see it in Wireshark, we know based upon the protocol operation. What happens next? Almost done. This is from the server back to the client. There's this handshake protocol message called news session ticket. This is a new feature in TLS. So if you look at our slides, it doesn't contain that message in there. So in one of the recent versions of TLS, this was added. So we'll come back to that later. Let's assume, let's skip over it for now. We'll see its purpose when we finish the handshake. So in fact, from the server's perspective, it sent the server hello. It sent the certificate, the server key exchange. There was no certificate request. It sent server hello done. Then change cipher spec and then finished. So these last two messages, change cipher spec and finished, are here. Change cipher spec. Let's start using the other algorithms and the keys related to them. And then this is the finished message, but it's in fact encrypted. We can't see that when we capture. There was this one in between, news session ticket, which we'll return to shortly. Let's draw them to finish this. Those last three messages, news session ticket, change cipher spec. Let's switch to the other ciphers and now we're finished, but that last one was encrypted. And we'll go see the summary. But now, there are no more handshake messages. The handshake is complete. We now start sending data from, in this case, from browser to server and in response. And in Wireshark, we see that as simply listed as application data. We know it's application data, but let's look at it. So this is from the browser computer to the server. What's inside? It's a TCP packet going to port 443. It's going to the secure web server. So someone who intercepts knows that. What's inside? Random characters. That is, we cannot see what's inside. We know, because we know that it was web browsing, that this is actually the HTTP get request. Remember that HTTP get request, get this URL and maybe some fields. That's what this packet is. But we don't know what the details are. We don't know the URL. We don't know what the fields are inside that header because it's all encrypted and also a MAC is implied. And subsequent messages are just listed as application data. And again, if we look at the details, we'll see that that's just encrypted packets or encrypted payload. Anyone want to guess what these messages are? So this is most likely the HTTP get request from browser to server. This may be a TCP ACC coming back. Actually, no. The TCP ACC is not encrypted. This could be the response coming back, the HTTP response including the web page coming back and some other encrypted data that we could be sending multiple packets. There may be later requests for other resources as well. And that's it. So these messages are the application doing its job. In this case, the web browser sending a request and the server sending back the web page. And the purpose is that we hide that information from anyone who intercepts the packets. We'll not draw them because now it moves on to the encrypted data. We're just drawing the handshake. Actually, what happens next is the data. The data flows in both directions, but it's encrypted. There's also some messages at the end to close the connection. We'll not draw that. So at the end to close the SSL connection and the TCP connection. Any questions about the handshake protocol? This diagram is a specific instance of this one on the slides. So this is the general case if there is a certificate from client to server. But what we saw is a specific case where that certificate is not included. With a slight variation of this new session ticket. So let's explain that. Let's look at the rest of the capture. Slightly later there's another client-hello, server-hello. And some more application data is exchanged. Client-hello, server-hello and more. Why? Remember when you visit a website, you download that web page. There may be images included. So then you request the image, download the image, request the style sheet, download the style sheet and so on. So usually there's not just one request. And then you may follow links and so on. All between your browser and the same web server. So in SSL we normally for every TCP connection we need to do this handshake. If we go back and see the TCP packets as well. What most likely happened is that this is the end of the first connection, the TCP connection. We finish the connection. And then we do a SINAC, an act to set up another TCP connection from browser to same server. To request the second resource, let's say the image or the style sheet. And then we do a client-hello, server-hello and go through the handshake again. Now the problem with this is that every time we want to request a resource from the web server, not only do we need to set up a TCP connection, those three SINAC SINAC act, we also need to do all of these messages. So in theory if we need to do this for every TCP connection, then there's a significant overhead. Normally with TCP we need to send three packets to set up the connection before we can send data. But now with SSL we send those three plus another, what, one, two, three, four actually in both directions. One from browser to server, one from server back to browser because they can be combined. And then client back to server and then back to client again. And extra two round-trip times at least are needed there before we can send data. And that can incur a significant delay in our web browsing. Every time we want to download a resource from the web server, the SSL has to exchange these messages. And that includes introduce a delay which the user may start to notice. That's a problem, the performance issue here. There's a small optimization that can be achieved and that was the role of this new session ticket. The idea with SSL is once you establish a session for the first instance, you exchange some information like the certificate. But subsequent access between that same client and server you don't need to exchange all the same information again. You reuse what you've exchanged in the past. So within a session you have multiple separate connections so that you don't have to go through all of these steps again. And this new session ticket is just some way for some information about that session to be stored by the client. And we see it if we go back and see SSL. In the first instance we talked to the server. We had hello, the response back. So we had four exchanges at least between browser and server. But the next time the client and server need to talk, there's a hello message in both ways. Then direct on to change cypher spec. We don't need to send the certificate again and we can keep using the keys that we've established from the previous step. So it saves time for doing the data transfer. So that's the idea of the session in SSL. Once we've established a session we can reuse information related to that session. And subsequent requests you only see really hollows in both directions and then directly change cypher spec. So there are optimizations to try to cut down the round trip time between client and server. Let's try and finish on SSL and just recap on what we've gone through. We said that for every TCP connection we have an SSL connection but we can group a set of SSL connections into a session. And the performance optimization is you don't need to exchange new keys for every connection. You can keep using them within a session. So that's one concept. We've spoke that for the application data we will break it into fragments, optionally compress. A MAC is attached. So we calculated a MAC and attached that and then encrypt all of that and send that with a header across the network. There are different algorithms that we can select from for each of those steps and we've seen one example of those algorithms. Not just the structure of those messages which is a bit too much detail. And we've gone through a specific example of the handshake protocol. There are different variations of that. We've just seen one case. You can use different algorithms and you may see slightly different messages in those cases. These are the list of messages but in the recent versions of TLS there's new messages. We've seen new session ticket as another one that's not listed here. This one's a bit old. We've gone through that procedure but a subset of those steps and let's just recap now on how that fits into HTTP which I think we've said already but repeat again. HTTPS is simply HTTP over SSL or TLS. So it just uses SSL as we've gone through. One of the practical things that we already know, the URL uses HTTPS as the scheme as opposed to HTTP. That tells your browser before you send the HTTP get request set up a SSL connection. The web server listens on a different port than the normal unsecured web server, port 443. It encrypts when we encrypt our request. The URL is encrypted. When we get a response, the entire response, the web page is encrypted. Any forms that we submit, you type in your username and password on a form in HTML and press submit all of that information is encrypted because that's part of the HTTP request. Cookies which are used to maintain state between different requests are included in the HTTP messages so they are encrypted and all the header fields are encrypted. So someone who intercepts when HTTP S is used cannot see any of that information. The browser confirms it's the correct server it's talking to using certificates. The server sends its certificate to the browser using SSL. We saw there was a message where it was sent and the browser reads that certificate and tries to verify it. Just returning to our capture, that message in our exchange was if we go up in here and the certificate is actually included inside here. So 1,134 bytes and the values of the X509 certificate are included there. It's signed by the issuer. We may get to see what type of certificate. In this example, the certificate is issued to a subject by the issuer. The issuer is the authority who signed it, who issued it. It's self-signed in this case. So this is a self-signed so the first time you visit that website you do get a warning. So that comes up there. Your homework task will be to generate a certificate. A real certificate which will not be self-signed but the authority will be me. So what you'll do is you'll get me to sign it. I will sign it as the authority and we'll see how that works with web browsing. You'll see it in the assignment but the way that that works is what you do is you generate your own key pair, public-private key pair, which you already have, don't you? I hope you kept your private key. You generate them and then you generate what's called a certificate signing request. A special file that you send the authority, me, and I check that. It includes your public key and then I sign it if I trust it. It's the right one. So you send me a request, then I sign it and that generates your certificate. So I create your certificate and return it to you. So that's how we'll see the certificates are issued through an authority. So we'll see that in the next and final homework. How does the server know that the client is the right person? Usually using passwords as part of HTTP. That is, how does the server know it's Steve logging into it? Well, if they submit the correct username and password that was registered on that web server, the server assumes it's the correct person. So the authentication of the client is done not using SSL normally, but using, say, the login, the username and password in a form, which is just sent in the HTTP request from browser to server. You can authenticate clients using certificates, but it's not very common. Not in web browsing, at least, because it requires the user to generate a certificate, and to be associated usually with that computer or browser. So we know the basics of HTTPS and, more generally, secure sockets layer and transport layer security. Let's finish with one final example about a different protocol and one that you've used, I know, Secure Shell. Just remind ourselves of what Secure Shell is used for. Remote login is the general name of the application. In the past, in the old days, there was what's called Telnet. Telnet was a protocol and an application that allowed us to connect from one computer or login from one computer into another remote computer. Telnet had no security features. Everything that we sent using Telnet was not encrypted, it was sent as plain text, and when we logged in, so when you log in, you must type in your username and password, you type it in on your local computer, they are sent to the remote computer which verifies or checks that you can log in, that information is sent unencrypted with Telnet. So Telnet allowed you to access a shell on another computer, so Secure Shell does effectively the same thing, was intended to do the same thing, but all in a secure manner. It used encryption and forms of authentication. Secure Shell also supports file transfer and tunneling, that is, what's the command to copy securely between computers? SCP, Secure Copy, which is just built on top of Secure Shell. So it actually uses Secure Shell to do that copy. So Secure Shell allows you to log into another computer or to issue commands on another computer, so we can do that to do copy a file also between two computers, Secure Copy. What number does the Secure Shell use? The port number of Secure Shell server is 22. So a Secure Shell server uses port 22. And in this case Secure Copy is also using port 22, it's actually just built on top of Secure Shell. And the secure file transfer is referred to as SFTP. It's still built on top of Secure Shell, it's just think of a file transfer protocol but on top of Secure Shell. And that makes it easy because you still just need a Secure Shell server for it to work. Secure Shell was originally created by some company but became a standard developed by the Internet Engineering Task Force and there are multiple protocols involved. We will not see the details as much as SSL. There's a general transport layer that does all the encryption and authentication like the SSL record protocol. There's an authentication protocol. So we can authenticate the different sites and some ways to manage the connections. Once we establish a connection to reuse those connections for different purposes. We'll show an example of tunneling. And it all operates over TCP. How is authentication performed in Secure Shell? There are different ways to do it, but one approach is that the server has its own key pair, public-private key pair. And we assume that the client knows the server's public key. Somehow it's obtained the public key. So when there's an initial key exchange with Secure Shell, similar to SSL, there's a key exchange up front, then the server, to prevent a man-in-the-middle attack, the server signs the message for that key exchange that it sends to the client. A man-in-the-middle attack happens when we exchange those messages for public key cryptography like Diffie Hellman, but we've got no way to verify that one we received is from the correct person or not. Maybe it's from some man-in-the-middle. So the idea of signing the message is such that the receiver can verify it did come from you, not from someone else. So what happens? The server signs a message in the key exchange with its... What's wrong here? Private key. I seem to always make the mistake. The server signs the message with its private key and the client, assuming it knows the public key of the server, can verify. But a common problem is how does the client know the public key of the server? And when you first log into a computer using Secure Shell, you'll often be presented with this warning and you may see a message, do you really want to trust this connection? You have to type in yes or no. That is because you as the client don't have the public key of the server. So you can't verify that signed message. So it's asking you, do you really want to trust this? Maybe a man-in-the-middle attack is occurring and if you say yes, then you accept the public key of the server and verify it when it could be actually an attack. So to avoid that problem, you actually have to have the public key of the server on your client before you do that connection. So when you type yes in that warning message, maybe it's an attack taking place. There are two main ways in which the server knows it's the correct client, too far, key-based and password-based. Password-based is what you've used a lot in the computer labs. You secure Shell into a server and then it prompts you for the password for that account on that server and you type in the password. If it matches the correct one, then you're logged in. So that is the server authenticating the client using the password. But there's another approach where you can also use public-private keys. The client has its own key pair and if the server knows the client's public key, then the client, when it initially logs in it, authenticates by signing a message and then the server knows it's the client because only the person with the correct private key could have signed that. So that allows basically password less log-ins to a server using keys. And in the lab, you use secure Shell. Client authentication was password-based. When you need to log into another computer, you type in username, student, password, student. So the server verified based upon that. You know, when I rebooted your computers all through the lab, that required me to log into every computer and run a command. I didn't type the username and password every time. I used key-based login. I'd set up in advance a key on the client, my computer, and I loaded the client's public key on each destination computer so I could run a command with secure shell without typing a password because it does a key exchange and the client verifies itself by using its private key. That can be more secure in that there's no exchange of passwords and no one can log in by guessing your password. This is a general diagram of the secure shell exchange. We first established a TCP connection, SIN-SINAC-AC. There is an exchange of two initial messages from client to server and server to client saying something about what protocol they're using, what version of secure shell. Then there's some key exchange messages between both sides to negotiate the algorithms to use. Similar to SSL, you can select from the algorithms available. You perform a key exchange. We'll see an example where we again use Diffie-Hellman to key exchange. Once you exchange a secret, you say, let's move on and start using that secret to encrypt our data and then it moves on to the data encryption finally. The general procedure is similar to SSL in that we say hello to each other. We negotiate algorithms to use. We do a key exchange and then we encrypt data using that secret or something derived from that secret. We will not draw it, but I'll open a capture for secure shell just to illustrate some of those concepts. Let's directly filter for SSH. This was done before. It was between the... In this case, this is the address of the server. There's 203 address and 192 is the address of the client. The first two messages are saying, what version of SSH do we support? Because they both should accept... They may have some minimum version which they know is secure, so they need to know that they're both using the acceptable version. Then there's some initialization of the key exchange. This is not doing the key exchange. This is saying what algorithms will we use for key exchange? And here's the client, for example, saying some combination of algorithms that we use. So similar to SSL, we say these are my preferred algorithms. And it lists the algorithms for key exchange, Giffy-Hellman variations, the algorithms for encryption, AES, and others. And we encrypt with different algorithms in both directions, and the algorithms for the MAC, HMAC with MD5, SHA1, and so on. So this is the negotiation of algorithms. The server does the same, and they agree upon some algorithm to use. In this case, they chose our favorite, Giffy-Hellman for key exchange. And what it starts is that the client sends to the server a request for the Giffy-Hellman parameters to get started. Then the server replies, and in the reply, there's the modulus and the base. Remember, Giffy-Hellman alpha, the base to the power of some private value x mod q. Alpha is the base, q is the modulus. Here they're labeled, instead of alpha is G, and instead of q, it's P. So it's just the notation of the protocol in this case. So this is the modulus, this is the value of alpha. And these are public values, and alpha is often quite small or fixed, whereas the modulus may be quite large, usually 1,024 bits, I think. That's the alpha and q for Giffy-Hellman, and the client responds, what does it send? It's public value, y of the client. Remember, Giffy-Hellman, we have alpha and q, we choose x, calculate y, send y to the other side. Well, the value of y here is this one. It's called e in the protocol here. The public value of the client and the server sends back its public value. Here the server f, we called it ys, when we did calculations with Giffy-Hellman. So now they have exchanged their values of y, they calculate their secrets k, and now can encrypt things with the secret k. And in this message from the server, it's calculated the secret k and actually has encrypted some keys that it's going to use. The encrypted value is shown here. The structure and the actually, if you go along, you'll see this is all encrypted. So it's a key encrypted by the server. What key did it use to encrypt the Giffy-Hellman secret? Use Giffy-Hellman to establish a secret, use that secret to encrypt some other secret. And the result, the ciphertext is shown here. And there's also some signatures for authentication, which are shown in this field. So it's again another application of this concept. Use a public key algorithm to exchange a secret, Giffy-Hellman in this case. Then we'll generate secrets from that and use those to encrypt our data. And then finally, we say, okay, let's start encrypting our data with a new set of keys, the ones we've just exchanged or based upon them. And everything from then on is just encrypted packets. Someone who intercepts cannot see the contents. We can see the ciphertext and the MAC. The MAC is not encrypted in this case, but we cannot see the contents. So we cannot see what commands you type when you're using secure shell. We cannot see you type in the password or what the password value was when you sent it to the server. It's all encrypted. Port 22 is used by the server here. So there was some identification string to say who we are, what version of the protocol do we support. We negotiate algorithms. We do a key exchange, for example, with Giffy-Hellman. And then at the end of that key exchange, we generate new keys from the shared secret. Here's the algorithm in general to do it. You generate a new key using the shared Giffy-Hellman key and some other parameters. We don't need to go through that algorithm. And then they can start to encrypt data using that new key that's generated. There are many different algorithms supported. So this is a list of some of those algorithms supported by secure shell. And I think that's a good place to stop because we still have a little bit left to go, but we need to go through some more complex examples just to finish this. We'll do that next lecture on Friday. So we'll just recap on this, give an example of using secure shell, say for tunneling, and explain the concept of tunneling. And that will finish us for the course. So we'll continue that on Friday.