 SecureShell is our final example of a protocol that uses some different cryptographic mechanisms that we've covered through the semester. We had a quick look at last lecture. The SecureShell protocol is broken into different layers. There's what's called the transport layer part of it, which is about doing all the encryption of data once we've set our upper secure connection authentication and integrity. So the data that's sent is encrypted using that part. But before we can encrypt data, we need to authenticate the client and server. They need to authenticate each other. So we need to check that we're communicating with the right entity. And the connection protocol supports some other features like maintaining a session and setting up tunnels. So we'll show an example of a tunnel today to finish off. The protocol, we will not go into detail, but just see some example that we established a TCP connection. The two sides exchange some identity strings saying what protocol version they support, what software version they support. Then they negotiate the algorithms to use. And we need algorithms for key exchange to encrypt our data. We're going to need a secret key known by both sides. So we need a key exchange protocol to do that. We also need to authenticate each other, make sure we're communicating with the right side so they negotiate the algorithms. Then they perform the key exchange. So at the end of that, they both should have a shared secret key. And then there's some special message to say, okay, we've done the key exchange. Now let's start using that new key to encrypt our data. And there's a couple of messages to do that. After that, the data sent between client and server is encrypted using the algorithms that were negotiated and using the key that was exchanged in that key exchange. Just to recap, we saw a capture of secure shell from a client. This 192.1681.5 computer to the server, the other computer, and some of the messages. The two identification messages, the negotiation of algorithms in this key exchange initialization messages saying what algorithms will we use. And then these four are the key exchange step and using Diffie-Hellman as the algorithm to exchange a key. There are other algorithms possible, but Diffie-Hellman is common and used in this case. And we've seen Diffie-Hellman in a number of cases, so it's a good algorithm to be aware of. Just as a reminder, the Diffie-Hellman key exchange that we studied, User A, which will be the server in the case that we see. The server starts the key exchange. User A, we have some public values, alpha and q. So, in fact, the user A can choose those values and simply tell user B what values to use. And user A generates a random x, their private value. We refer to that as their private key. And they from the alpha, the x and q calculate a public y, a public value y. They send their public value to the other user. And we'll see in Diffie-Hellman, they don't just send that. They also send the value of alpha and q because they are also public. And then the other user, user B, given that alpha and q chooses some x of their own, their private x, calculates their public y and sends back that y to A. And when each user knows their x value and the other person's y value, they apply this algorithm to calculate the key k. And we showed that both sides will end up with the same value of k. That is their shared secret. So, we've studied Diffie-Hellman. In the secure shell protocol, the terminology is slightly different. If we look at these messages, this is, I think, the message we want to start with. This is from the server to the client. See if we can find the values. The base, g, is denoted in the secure shell. The base is alpha. Remember that alpha raised the power of some value. So, the base is alpha here. So, it's called g in the secure shell. Five is the value here. And the modulus is q. We have alpha raised to the power of something, mod q. So, the values of alpha and q are given here in this message. g and p. What else do we see? This is from the client to the server. So, this value denoted as e is the public value of the client. It is the value of y that the client calculated. It received alpha and q. The client shows its x value. He doesn't tell anyone its x value. It's private. Calculates its y and sends it back. And this is the value of y being sent back. It's just called e in this case. And the last one, f, is the value of y for the server. Remember, there are four public values. Alpha and q, y of the client and y of the server. So, the procedure was this message from the server contained alpha and q. It told the client what alpha and q to use. The client sends back its value of y. And then finally, in this one, the server sends its value of y. And once they have each other's y value, they can calculate k. So, the notation change, given between what we studied and what we see in the capture, q and p are the same in the capture. E is the public value of the client, and f is the public value of the server. So, that's just Diffie-Helman working. There are also some, if we talk about the IDs, if we look in those messages, there's some strings identifying those client and server. What else do we see? In this third message, the server sends its public value here. But since the server has the public value of the client, the server can calculate k. So, the server knows the secret k. And similar, when the client receives this, it can calculate the same secret k. So, they both have a shared secret. And also included in this message is some other information. So, what the server does is it calculates the secret k, and then it can use that secret to encrypt information or to sign information. So, the secret is then used in other steps in the signature, for example. So, here, the secret obtained from Diffie-Helman is then used to encrypt information that is sent for the subsequent steps for the client needs to learn the key that they'll use. The signature component, this is a signature from the server. So, this involves the server using its private key to sign some values. So, when the client receives this message, how does it verify it? How does it verify that this message came from the server? This is the signature is coming from the server. It's therefore using the server's private key. The client will receive this message, and it wants to verify, did this message come from the server, or did it come from someone pretending to be the server? That would be bad. How does it verify? If it's signed with the private key of the server, we verify with the public key of the server. So, the client, when it receives this message, which is signed by the server, to avoid men in the middle attacks, we need to verify it. A man in the middle attack may be someone sending us to the client a message that is pretending to be from the server, but it's not, and that's a problem. So, signed by the server, when the client receives it, it verifies using the public key of the server. How does the client know the public key of the server? How does the client get the public key of the server? Often it does not. In the way that we have used, or you've seen SecureShell used, when you first secure shell into a server, SSH into a server, you get a warning message saying, here's, you've connected to this server, and what's happened, the client has received this message to verify it needs the public key of the server. But if it doesn't know the public key of the server in advance, it cannot verify, and you will see on the screen usually some warning message saying, are you sure you want to proceed, yes or no? And that's because the client is not sure if this is a man in the middle attack, or if it's actually from the real server. So, to avoid such warning messages, you need to, some other way, obtain the public key of the server in advance. Maybe manually copy the file from the server to your client in advance, and then you can be sure. But you'll commonly see with SecureShell, if you haven't set it up to obtain the public key of the server, then you'll get this warning message, and you really have no protection against men in the middle attacks in that case. So, the client receives this, and in theory it should verify, in practice sometimes it cannot verify without the public key. And then they say, okay, let's, because I've exchanged the secret, let's see what we've got. Once they exchange a secret, they then use that key, that secret value, plus some other values. And the details are not so important here, but they use values of some session ID, some hash value as an output of some hash of some input values. And they combine all that to create another key. So they use the key obtained from Diffie-Hellman, K, and then generate another key from that. The hash, H is a hash of the IDs, the message, the first message, and some other values, those Ys and so on. And then this key, KC2S, think of the master key for the client of the server, is then used for the next steps for encryption. The server does it in a similar manner. The idea of taking some key, K, so K comes from the Diffie-Hellman exchange. All these other values, the ID, M is the messages, some of the messages sent, YA and YB are the Diffie-Hellman public values, the public key of the server, and we hash all them, and we combine and we hash it again. The idea is that it's a way to generate another random key. We start with the master key, K in this case, and we combine it in such a way to produce a different key, KC2S. Similar concept was used in SSL. We generate a pre-master key that is used to generate a master key that's used to generate different sub-keys. Effectively, using the hash is like a random number generator. It takes as an input the key and some other values and generates a random output, which is used for a subsequent key for encryption. So this new keys message says, let's start using this new key that we've generated, K, C2S, and so on. And from now on, all the secure shell packets are encrypted. We will not be able to see the internals from Wireshark today encrypted with the keys. We would need the keys to decrypt. The client is supposed to authenticate the server by using the server's public key. How does the server authenticate the client? How does the server know it's actually the correct client logging in? Username and password. So one of these encrypted messages, the server prompts the user for their username and password. One of these encrypted messages will contain the username and password encrypted, sent to the server. The server checks them against the registered values, and if they match, then the server believes this is the correct client. It's someone who has access to the server. So we use username and password to authenticate the client, but we use public keys to authenticate the server. It's the same used in secure web browsing. For your browser to authenticate the web server, we use certificates, public keys. For the server to authenticate the client, they use usually logins from the website, from the form you enter your username and password, and the server checks are you the correct person to be accessing this website. Everything else is encrypted, so we cannot see any more there. Before I show you an example of tunneling, and using secure shell for tunneling, the last thing, so this authentication aspect, the server has its key pair. It assumes the client knows the server's public key in advance, but in many cases it doesn't, and that's why you see that warning message when you first log in. You don't have the public key. You're not sure if it's the correct server. And client authentication, the common way we've seen is using password base. The client sends a password, an encrypted password to the server, and the server checks that. But you can use key-based authentication. Let me show you an example of that. First, an example of password-based authentication. We know with secure shell we can secure shell to some destination address, and then we don't have to have an interactive terminal when we log in. We can issue a command and then exit. So if I type the command here, the idea is that this command will run on the server, and then it will return the result, and then it's done. Who am I? Secure shell is going to work there. It's doing that exchange, and eventually it asked me for my password. So this is the server trying to authenticate the client. Let's make sure it doesn't show. I can remember it. Okay, so I typed in the password, I pressed Enter, and then that command, who am I, executed on the server, and it simply prints my name. So that was password-based authentication. The server asked the client for the correct password, for the password. Let's do or see an example of key-based authentication. So I'm going to log into the ICT server, another server I have an account on, and I'll just log in in this case and do an interactive session. I'm logged in. No username or password. Okay. The message is just the warning from SIT. So that was key-based authentication. I didn't have to submit a username and password. So let's just explain how that works. What I've done in the past is the client, my laptop, has its own key pair. And the public key is put onto the server. So let's write that down. Normally the server must have its key pair and one of the steps for the key exchange, the server signs with its private key and the client, to verify, should have the public key of the server. If it has the public key of the server, when the server sends a message, the client can verify that it came from the server, not someone pretending to be the server. So that's needed for the client to authenticate the server. But in addition, if we want key-based login, we can have a public key pair of the client. The client has its own key pair. And if the server knows the public key of the client, then in the same way, when the client sends a message to the server, if it's signed in the authentication step, if the client sends a signed message, signed with its private key, of some message, the server can verify it's the correct client because it has the public key of the client. And that's how we do effectively password less logins or key-based logins. We configure the client to have its own key pair and you run a command to create your key pair. You copy the public key of the client to the server in advance. That must be done in advance. And securely, so the server must trust it's the correct public key. And then once they log in as part of the secure shell steps, one of the messages, the client sends signing with its private key and the server can verify that because it has the public key. And when it verifies and it passes successfully, it knows this message came from the client. The only person who could have come from as a client that's signed by the client, therefore, I'm communicating with the client, therefore, this client can log in because I've previously allowed them to log in if they provide me the correct key. So the step to set that up is that to allow key-based log in or password less logins with secure shell, the server must be configured to have the public key of the client. And in this case, in secure shell, let me bring up a new terminal and we'll show you the client. This is the client, my laptop, in Linux, inside the .ssh directory. There are some special files for secure shell. I have my own key pair here, idrsa and idrsa.pub are my private key and public key respectively for my client. So this is my private key. I will not show you that. It's private. This is my public key. They were generated in the past. I can show you my public key. It's an rsa public key but stored in a text format so it's easy to copy. So it's just encoded using some encoding techniques. So it's an rsa key that's all encoded in here, not encrypted, encoded, meaning the key, remember a public key is the modulus n and the public value e. Those values are encoded in a form that we can represent in ASCII characters, so shell on the screen and for this username and computer. So that's the public key of the client and in the past, I've copied that to the server. Remember, everyone remember this because we're going to look at it in a moment or at least the last few characters, five ls, jd. If we look now at the server, in the authorised keys file, it's this one. This is the server has already been configured to have the public key of the client. It's here. You can check. It's the same one. So this server has the public key of the client, so when that client logs into the server, the server checks when it's signed by the client using the client's private key. The server has the corresponding public key. It's stored in this special authorised keys file and simply verifies and then allows automatic login without passwords. So it can be set up to be password-based logins in this case. And that, yep. Yes, it has to be the computer that has the correct private key. So anyone who has my private key, it doesn't have to be this computer, it has to have the private key. So that id underscore rsa file contained my private key, I can put that file on another computer, on any computer, and it will allow me to login automatically to the server. So it's important to keep your private key private. If someone else gets it, that means that they can use it to log in. So it's verified by the client that sends one of the messages to the server. The client uses its private key. Whoever has that private key can then login because the server will automatically accept anyone who has a signed message that is verified with this public key. So to get the public key on the server, I had to copy it in advance. That was a manual step. So if I move to this other desktop computer and log into the ICT server, I'll have to enter my username and password because this computer doesn't have the private key that matches this public key. I can still log in if it accepts usernames of passwords. So the server may be set up to accept both forms of authentication. Key-based authentication can be more secure if it's used correctly The problem with password-based authentication is that malicious people will try and guess people's passwords. So with password-based authentication, if you want to log in as me on the ICT server, you could try and attack where you try and guess my password. And if I didn't choose a good password, maybe you'll guess it and you're logged in as me. But with key-based authentication, we don't use passwords. So trying to guess my password doesn't help if we disable that on the server. So if we set up a server that doesn't support password authentication, just key authentication, then to log in, you must have the key on your computer. And then it's just a matter of not letting someone access my computer when it's logged in. You can, in fact, password protect the file on your computer on the client. So it's even harder for someone to log in as you. Using keys means that password attacks become less effective. Any last questions on this form of client authentication? Right, the key may... So the public key may not just be the exact value of the modulus and the E in RSA. There may be some other information to determine the data structure and so on. So there may be... This is just an encoding of the public key. How the public key is stored, I don't remember. It's not just the value of N and E. It's maybe some other data structure information. So there may be similarities between different public keys. You need to decode this and find the what it converts back to. But I says most of these values are the... Indicating the value of N, the modulus N, which will be different for different public keys. Any final questions on client authentication for SSH? Then the last thing, one final example. We've talked about that. We've seen the capture. Okay, this is not so important, but just the structure of the packets, that once we do an encryption, we have the data we want to send, the payload. We may optionally compress that and attach some headers, some padding to make it the right size, a sequence number. Encrypt that and calculate a MAC. The MAC is used for authentication, data integrity. So authentication of the data and the encrypted packet, which is the ciphertext plus the MAC. The last thing to demonstrate is that secure shell can be used in what's called tunneling mode, which allows you to send the data of other applications via the secure shell connection. And we'll show one example of that. So a normal TCP connection, an unsecured TCP connection, say from a web browser, a client application, a web server. What happens is the client, does anyone see port numbers A and B on this picture? It should be X and Y, application port numbers here. X and Y are port numbers. So this says, let's say for web browsing, just normal web browsing. My web browser uses a port number X to communicate with TCP on my computer, and we create a TCP connection to the server computer on port number Y equals 80 with HTTP and communicates with the server. So that's just normal TCP based communications. We can... Because that's an unsecured connection, one way we can secure it is what? If we're using web browsing, we can use HTTPS. But what if the web server doesn't support HTTPS? We're trying to access a website. The web server only supports HTTP. Can we still make the packets that go across the internet between your browser and website secure? That is encrypted. Well, you can do what's called tunneling and send the HTTP packets inside a secure connection using secure shell. And we'll demonstrate an example of that. So the idea is that now the port numbers are correct. Normally, your client connects to TCP at port X and at the server at port Y with the secure shell tunnel. You connect at that same X and Y ports to instead of TCP to an instance of the secure shell client and server. And they establish a secure connection. Anything sent via SSH is encrypted. And SSH in turn uses TCP to communicate across the internet. So the idea of a secure shell tunnel is when your client and server application do not use encryption, but you want your data to be encrypted, send it via secure shell. And there are different ways that that can be used. But the one I'll show is to connect from a browser to a secure shell server and have all of that connected and then from the secure shell server to an external web server. And it can be used for different purposes to encrypt your data across a segment of the path and to do things like bypass firewalls. Let's show the example. The scenario that we're dealing with is I have my client and be my browser. We'll use web browsing as the example. I have a web server. I want to access and we'll use in the middle a secure shell server. A third computer. Normally when I connect from the browser to the web server, just using HTTP and TCP, but we'll connect via the secure shell server and see how that can provide some benefits. So we'll have the browser running here, Firefox in our case. There's a web server application running here, Apache, or whatever other web server application. In addition, we'll run a secure shell client here, SSH, and here secure shell server. Also, I'll just denote as SSH, but the server variant of it. What I want to do is from my browser, access that website. But what I'm going to do is access that website, but going via the secure shell server. So when I send my HTTP get request, I'll send it not direct using TCP, I'll send it via secure shell to the server, and then the server will send that to the real web server. And we'll see what comes back. Let's do it first and then show how it works. First, let's do it without the secure shell server. What is my IP address? So here, no secure shell server. From my browser on the laptop, I'm accessing some website, the web server. In this case, what is my IP address? And it tells me my IP address is 203131209.66 and I'm in Bangkok in Thomas Art University. This is illustrating the point that the web server can identify me, or roughly it identifies me as part of Thomas Art. Based upon the IP address, I sent a request to the web server. The source address was this address. So this web server, this website knows roughly who I am. I say roughly because it knows that I'm part of TU. It may not know identify me uniquely because I think if you open your mobile phone and visit that same website, you'll get the same IP address. Try. Visit whatismyipadress.com using the SIT Wi-Fi, I suggest. Anyone get that address? Yep, it's the same. Yep, it's the same. Whatismyipadress.com? If you do it, you get the same address. Why is that? In everything I've taught you about networking, we've said computers have unique IP addresses. But now what's happening is that this website, many people from different computers are accessing it, but this website thinks it's all the same computer, this one particular IP address. What's happening is a concept called a network address translation is used. Inside SIT, all of our devices have private addresses. If you check your IP address, it'll be 10.10.something or 10. Whatever. Assigned inside SIT only. But when your packet leaves SIT, there's a special device that does network address translation that converts your private address into the SIT public address. And there's one public address, this one. So everyone's packet, even though they're coming from different computers, from the perspective of outside people, this website, it looks like it's coming from this IP address. The reason for that is to allow organizations to use easily set up internal IP addresses and have a limited number of public addresses. This is not a security feature, it's a way to assign addresses easier for an organization. But does this website know who is accessing it? Well, it can get down to the level it knows someone from TU is accessing, but maybe it doesn't know it's Steve or someone else. So in theory, we say everyone has a unique IP address and we can identify people based upon that IP address. In practice, because of network address translation, from outside people's perspective there may be a shared IP address and we may not be able to identify individuals, but we can at least identify the organization or the ISP they come from. That's not the point of this example. That's just showing that this example is just showing us that this website knows I'm from TU. There's no secure shell used. I want to access the same website, but I'm going to use a secure shell tunnel. I'll open a terminal and do that. I'm going to use a secure shell tunnel, so I'm going to secure shell into my external server. Normally that logs us in. I don't want to run any commands on that server, so the minus n option says don't run any commands here. I wonder, so this will start the secure shell client. I want to start in a special mode where the secure shell client will act as a special server that will listen to connections from my web browser. So I add to say listen on some port, and I just choose this random port unused port 9999. This logs into my external server, but it sets up secure shell client to start as a tunnel endpoint. Let's do it and then explain how it's working. It logs in, should ask me for the password. I'm sure I've typed it wrong. How do I know? If it's successful, then it does nothing. So it looks like I typed it correct. So it's not going to issue a command. The minus n option says just log in, don't do anything. The minus d option says now listen, if anyone sends to port 9999 then take that and send it to the secure shell server. So what I do now is I set my web browser to use port 9999 in a proxy mode. I'll go to my settings in my web browser, my preferences, my network settings and we'll set a proxy. Normally there's no proxy used and I'll configure a manual proxy configuration. I've already done it. We use a special protocol called socks. We're using it here to what we'll do is my browser normally sends packets out across the internet to the website that I specify in the address. But now I'm telling my browser don't send the packets out to the internet send them to a socks proxy server that's on the local host, that's on my computer and that's listening on port 9999. The secure shell connection I created using that minus D option started a socks proxy server. So what this is going to do is tell my browser send to the secure shell client whatever you have to send. Okay, that. Refresh and now I'm in Japan from the websites perspective because the server the secure shell server is in Japan. And that is the address of my server in Japan 1061874622 What has happened? From the web servers perspective it thinks someone from this IP address contacted it. But we know it's my laptop that did it. What happened was we configured this secure shell client first it connected to the server. When I ran the SSH command the server and set up a secure connection. But the minus D option said to listen on port 9999. So access it own special server it's called a socks proxy server and then I configured my Firefox browser to send via this proxy. So what Firefox does when I visit a website is it sends to here because it was configured to use this port on the local host on my computer and now the secure shell client takes what it receives sends it across to the secure shell server this one when it receives it it takes whatever was received and looks at the destination and sends it to the destination which is of course the real web server. So my browser I typed in the address what is my IP address .com and it creates a packet which will be destined to this web server but my browser doesn't send it across the internet it sends it to the secure shell client running on my computer which then encrypts everything sends it to the secure shell server and what it receives it takes the original message the request to the website and sends it to the website and the response comes back in a similar manner. Here why has this provider sent what benefit has it provided first the web server when it receives the packet the source address is that of the secure shell server it receives a packet from the secure shell server that's why the website reports your IP address is this one because that is the IP address of the secure shell server what's the practical benefit of this this is some form of hiding who you are the web server doesn't think I'm in Tamasa anymore they now think I'm in Japan okay so it's a form of hiding or pretending you're from some other location when web servers use your address to identify which country you're from and then tailor the response based upon the country and here's a way to to fool the web server another benefit of this the data between the browser and the server was encrypted we use secure shell here so the request remember we're only using HTTP there was no HTTPS but still because the request was tunneled using secure shell this segment of the path the data is encrypted the benefit is anyone inside this segment cannot see my data out here it's not encrypted it's still public it's using just HTTP but over this segment it's encrypted and again that can be used for keeping your data confidential against specific targets so no one inside SIT can now see my encrypted data I can see my requests say you're using a Wi-Fi connection I know everyone here can monitor Wi-Fi and intercept my packets so even though you intercept my packets in the local SIT Wi-Fi they are encrypted if I use this meaning you can't see the original contents so that's one benefit or one way that it can be used this tunnel it can potentially be used to bypass firewalls if there is a firewall say inside SIT at this location a firewall blocks traffic usually based upon addresses IP addresses and port numbers if this firewall was blocking access to this website based upon the IP address it would not see the address of the web server in this packet it would see the IP address of the secure shell server so the firewall would not block access to this website it would allow me to send the packet out to the secure shell server the firewall would have no way of knowing that I'm actually contacting this web server so such a connection can be used to bypass firewalls if they block based upon addresses so this is an example of a secure shell tunnel the concept of a tunnel is that we're putting application layer packets web browsing packets inside other application layer packets secure shell packets it provides some form of private network between my browser computer and my secure shell server a private network no one can see what I'm communicating it's a virtual private network a VPN secure shell is not the only technology available to do this thing you can use other technologies so secure shell is just an example that's easy for me to demonstrate but for a virtual private network if you're drifting your data from one computer to a server there are other technologies different specialized VPN technologies and different secure protocols all use the concept of tunneling to create a virtual private network so this was in secure shell notation it's called local forwarding the traffic to a local port to that port 9999 was sent via the secure shell connection to the remote server you can use it in other modes as well any questions to finish on secure shell it is a form of VPN how is it how is it different from the VPN a VPN is a general technology a virtual private network a private network let's say I want to connect from my computer to the secure shell server in a private network then I'd need to build my own network a private network if I own it then it's private for me anything I send across it is just seen by me no one's going to build their own network just to send their traffic to that server a virtual private network provides the same thing but using encryption it's done virtually and that's what we're doing here we're creating a virtual private network between my browser computer and the SSH server because anything that we send between them is encrypted even though it's going across the public internet the data is kept private so this is one example of a VPN a virtual private network but there are other ways to do a VPN different protocols IPsec, different tunneling protocols OpenVPN is one and there are a few others so this is an example of a VPN the result is the same in that for one segment of our path this is the VPN server for this segment everything's encrypted and when I contact some external server that external server thinks it's coming from the VPN server so we have the same effect there and if other questions on secure shell and secure shell tunneling