 Let's move now to the second protocol, SSH. SSH is a completely different kind of protocol. It has nothing to do with SSL-TLS, except maybe if you compile it yourself on a system, you will see that it will use some of the cryptographic libraries on your system that also TLS-SSL is using. But it's something completely different. Where does it come from? Well, originally, on the internet, we had all kind of remote login protocols, telnet, remote login, remote shell. They did transfer your password in plain text. Everyone here is able to work with wire shark, so you know what you can do then. Just capture the password. There have been a couple of versions of SSH. They started also same time when the internet became public. It was by a Fin, I forgot his name, who basically started with it. Then they created a company. But at a certain moment, the technology was held privately. So there was a split up of, I think, version 1 that went to open SSH. And I think nowadays everyone is using open SSH. That was also the basis for work that was done in the IETF, which led to, say, SSH standards. So how does it look like, this protocol architecture? You have applications on top of this. So usually you have kind of, say, telnet or remote terminal application on top of it. But you can run many other things on top of that. So in that sense, you could say SSH is a bit more flexible than SSL-TLS, although you can use SSL-TLS also in other environments than the web. But this was designed to support multiple applications. We have there an SSH connection protocol. And the connection protocol basically multiplexes the different applications that you have on top, via single SSH connection. Then you have a user authentication protocol, which takes care of the user, so the client. And OK, I should have told it in a slightly different order. And you have the SSH transport protocol, which takes care of authentication of the server, but also, say, the confidentiality, so the encryption integrity that you can't modify bits and compression, which is, again, an option. OK, what is important, what I wanted to say. Server authentication is done here. Client authentication is done there. There are completely different ways how you can do that. I already said, connection protocol runs logical channels on top of that to support different applications. OK, let's start now from the bottom transport protocol. How does it look like? Basically, you, again, start with an initial key exchange. Diffie-Hellman, say, public key stuff. Not sure if I'm saying this well. Encryption, there are a couple of things which, in the RFCs, are, say, recommended, required, et cetera. They are outdated. There are a couple of, say, optional ones. This kind, AES-256, these are the kind of things that you should use and not say the things that you are supposed to implement, but you better not use. So AES-128 is the recommended one. Uh, server authentication, you also have there something recommended and something optional. MD5 is also not very secure anymore. I think this is still OK. And compression, you don't have to do it. You can do it, and then you use ZLIP for that. OK, let's look at how this over time the various phases look like. So first, you have the TCP connection setup, so transport layer, SYNAC, blah, blah, blah. Then here, the SSH start with an SSH version string exchange. This is something if you capture on Wireshark, you can still hear, say, read everything. Oh, yeah, it's this version of SSH, blah, blah, blah, blah. And then here you have, say, the negotiation about algorithms, and then in time, after that, you start the data exchange. And if you're ready, you release the connection. What is interesting is what I said is you can run multiple applications on top of SSH. So you do this for your first application, but then you can add other applications, and you can even stop your first application. But then this still keeps on running. So your multiplex applications, that is different from a TLS, where you can't do multiplexing. However, with TLS, you do have this caching in the beginning. So setting up something that was closed before is relatively fast. You don't have this caching mechanism with SSH. What can happen is that at a certain moment you have exchanged so much data that you have to change your key, so you rotate keys. How does packets look like for SSH? You start with packet lengths as padding field. This is the payload. And then you have padding at the end, and matches authentication code at the end. How does this stuff that you can analyze with, say, Wireshark? What is probably interesting is how do you do, say, authentication? Basically, you usually authenticate first the server. I showed you this layout stack below you had server authentication. So how do you authenticate the server? Well, you use for that a server host key. So in general, you don't use, say, anything complex. It's just a string of octets. And the client must check this key. So every time that you connect, you have to check, hey, is this still correct? And there are multiple ways how you can do that. Well, first you have, in the client, you have a local database which stores the keys. So as soon as you enter or you create a new SSH connection, you look in your local database, hey, do I know this one? It has this key. OK, it's OK. I've seen that one before. But how do I know if a host key is correct? If I get it first time, how do I know that? So there are a couple of ways how you can do that. Of course, you can use a trusted third party, a certificate authority. But I'm not aware that many. In fact, I don't know anything that is using this. There will be people who are using it, but I think it's quite uncommon. What you can do is the first time the host sends the key via an external channel. So phone is probably not the easiest, but something that you can trust. But what most people do is best effort. So I assume all of you have used SSH in the past. What do you do? The first time you connect to a machine, you see that, hey, this is new. I don't have this machine already in my local database, and your operating says, hey, this is a new key. Should I trust it? And you usually do that. Remember, this is SSH. You usually lock in into remote machines which are nearby. So machines which are under your control or in your house or you don't log in on, say, with SSH on the surface of Google or of the ING Bank. So if you look at TLS SSL that we discussed earlier, there the surface are things that you don't trust at all. Here you usually have systems that are nearby which you do somehow trust. So first time you see, hey, new key, never connected with it, OK, except yes, and then you save it in your local database. If the key changes, your operating system will say, oh, yeah, you have a problem, and usually you have to manually remove it from your local database. And so every time that you connect again, it's checked against this, and if it changes, you get an error message. So that's basically simple. So this is the server to whom you SSH. Now the client, so the user, how does that work? Again, you have multiple options, and you can do it via public key. You can do it via password. That's what most people do. So you just have a password and you log in. Host-based, but also keyboard-interactive. So that is something where you get a challenge. So many banks still have these kind of things. You get a challenge. You have to type in the challenge, and then you get something, and then you say, again, that's this keyboard-interactive. Clicked on the wrong button. Then there's a time-out period. If you don't do anything, it will automatically close the connection. Often 10 minutes is standard. So you have to keep alive messages regularly to keep the connection open. What happens if you try too many times to log in? Servers detect that and will say too many attempts and ban you for a short period. If you look at SSL-TLS, they usually don't do this banning stuff. So you can easily do brute-force attempts. And here you're punished, fail to ban. You have these kind of systems. OK, so 20 attempts. The multiplexing protocol, that is, say, the thing that makes SSH different from TLS-SSL. You use it since you can have multiple applications. And this multiplexing protocol opens and closes channels. So every application has its own channel. So over SSH connection, you can have multiple channels. Every channel uniquely relates to one application. If the application stops, but there are other applications still running, then the channel stops, but the connections keep running till the last channel stops. So that's what I just said. Have multiple channels on one transport connection. And what can you do with it? You can run multiple applications, of course. But you can also have some out-of-bent controls. So there have been a couple of protocols, I think, X11 kind of stuff, where if you want to change the size of terminal window. So you had one channel for everything you typed into the window, but another for controlling the size of the window or whatever. Application flow control, you can run exit codes of processes that you remotely start. What do you have? Every channel has a unique identifier. And what are the things that you run? Well, usually you run the shell on top of that. You have a couple of other things. But I guess that probably most people know SSH for the fact that you know. Who has another nice application for SSH? Yeah, why would you use a proxy? Yeah, so you can use it to secure other applications. Yeah, you have to? Yeah, so file transfer, of course, it's there. You can also reverse the tunnel thing where you can connect to some machine which is able to access another machine. So you can use it to make sure that only one machine keeps so that it acts like a sort of firewall and only people with SSH access to the intermediate machine can access. Yeah, that's also what we do with the group with a couple of machines which contain more sensitive data. You have one system where you can only go with SSH. And if you can't manage that, you can't connect to anything that's behind it. Yeah, it's a kind of gateway. Well, it's used for many things. But people already said tunneling proxy the firewall. So this is the standard way how you use it. You have SSH. It runs on port 22. The server side, you have an application client. That's easy, but what happens if you have a firewall pity that the picture doesn't really fit? If the firewall is not allowing you to pass through, so if you look at Samba, for example, and you want to use Samba from outside the university port, the Samba port is closed. Why is it closed on the university? Yeah, that is. And well, I'm not. It was said that locally it was allowed to share files. Yeah, I don't think that there has ever been any court case where university specific was mentioned. I think there are two rules, or there are two reasons why it is blocked. The first one is that there is lots of, say, material that is copyrighted that people have on their shares. And if you make it available to the entire world, that would certainly be a real problem. The other thing is that attackers often use these open, say, Samba shares to put all kind of malicious stuff there. So it's not just protecting students against copyrighted material, which they have, but it's also to protect the network against malicious activities. Because many people open these things but have no clue what they actually do. So I think it's also a security thing. So OK, if you want to do Samba from outside the university to the university, the firewall blocks it. However, if you have a machine on the university, you can have here an SSH server running. You just connect it via port 22, which goes through the firewall. And your application here connects to this local SSH client. Everything here, port 22 encrypted. Very nice. Here it's decrypted, and then you send it to the original port x again. And so something which was not reachable because of the firewall, you can still reach it. Yeah? If you want to know more about SSH, here are some, say, references. I would like this last slide for today. I would like to summarize the difference between SSH and SSL TLS. SSH is used in an environment where you look into machines which you usually know, which you trust, which you probably have configured yourself, or you know the people behind. SSL TLS is used on the web to have a secure connection with web servers. I don't know where. Completely different kind of, say, environment. If you look at SSH, the server has to authenticate. That was this service string. If you look at the specification of SSL TLS, server authentication is optional, but it is always chosen. So you can still run SSL TLS without server authentication. So you just do encryption, but no one does it. If you look at client authentication, then here you see you have many options, but password is often used, but you can also have a challenge response kind of systems. If you look at SSL TLS, client authentication is usually not done. If you do it, the only way how you can do it is using public keys. Still, you may say, oh, yeah, but if I connect to my bank, I have to type in a password. But that's not, say, an SSL TLS password. It's an application password. So don't confuse that. Here you type your SSH password, your machine password. Here you type your bank application password, which has nothing to do with SSL TLS protocol. So server authentication is based on these, say, SSH keys, which I just mentioned. And here the service authentication is based on X509 certificates. And here you have to make it more efficient that you can run multiple applications over one SSH connections by using multiplexing. Whereas here you don't have this multiplexing, but you have this caching. So if you connect later to the same machine, you can use, say, the keys and outcome of the negotiation that you had before.