 I'm going to present to you a few things about SSH and TNS SSL and more particulars of her at the SSH. So you have a way to access the SSH protocol. So a few words about myself. I'm a security and cryptography engineer. I came into SSH as well. I work for the lead SSH project. I work at BellNet which is a research and education internet provider. So we provide internet connectivity to research network and in particular for them this year. There is a job booth so if you have a minute just go there. That's for my application. Okay, I'm very good and I like you. Just tell me where you want to next slide. Yes, but my rule slides are interactive so I'm really good. Okay, so I'll start by speaking a little about the differences between SSL and SSH because I'm not sure it's clear for everyone and it's a good start to decide if you are going to use SSL or SSH for your next cryptographic application. And then I will talk a little about our project, how it works, how to use it in start. So you can start coding your own SSH client when going outside of this field. So you know SSL, you know TLS. How many people know the difference between SSL and TLS? In fact, there is almost no difference because starting from 3.1 SSL is the same as TLS 1.1 but I think it's about the same as that. Okay, there is SSH1 which is almost legacy. It has plenty of hold inside it so nobody uses it anymore. Maybe in some hold Cisco routers. And SSH2, I imagine most of you already use SSH. What's SSL and TLS? The name is Secure Circuit Layer, Transport Layer Security. The idea is really that it's a secure transport. The goal is to transport data from A to B in a secure version. So it was developed by Netscape. I think the version 1 was broken during the presentation. They came with the version 2 but it's very useful for HTTPS and TLS. I think you know it. Something that's interesting is that the security model of SSL and TLS is based on Netscape online certificates. So that certificates you buy had some CD providers for a lot of money generally. And they say you are to be trusted because you gave them money and a proof that you are who you are. Sometimes, yes. There are a lot of implementations so they're the best known. Our pen SSL, new TLS. If you are using Firefox, you are using NSS. There will be talk about the BI SSL as well. And I think Windows has its own version. I think a complete list will include 30 or 40 writers. So it's very valuable. Okay, what about SSH is a secure shell. So the primary use of SSH was to provide an interactive shell to a server. The goal was to replace Telnet in fact. That wasn't a good idea. Okay, the first version was SSH1 which was almost free software. The OpenSSH team took the code when it was still free and they've made the great OpenSSH project. So it's defined in RFCs. It's not, it's recent, quite recent. I think it's just been done one or two years ago. So some of the features of SSH that help grow the general scope of SSL are that, quite a secret, but you have that with SSL as well. But we have several channels for communication. So it's possible to have parallel channels of communication in the same SSH stream. It's important. Authentication is omitted inside the protocol. So it's very interesting. I will tell you about it later. Okay, so it was done for shell handling. So everything that goes around terminals, terminal size, X11 for routing. So that's embedded into the protocol. And there is also dedicated a five-transfer protocol that is a lot different from FTP because it's based in a binary protocol. I won't go into the detail because it's a little out of the point. Okay. What are you looking into, a security protocol or a security transport protocol? Of course you are looking for integrity. You do not want that someone with SSL can change something in your data stream and convert your files or inject commands into your shell. So a good thing for a transport protocol is that any tampering is detected and if possible is avoided. You look also at the availability. Availability is a resistance against the denial of service attacks and the fact that you have the most time as possible. So it's not possible to shut down your connection to make it look slow to stop you from connecting to your server. Something you want as well, and I think it's the best known functionality of SSH and TLS, it's confidentiality. You don't want anyone to know what you've done on your interaction on your channel. So nobody can interrupt you. And that increase that you are sure who you are speaking to is very important because if you are sure you are talking into a private and secure channel without anyone interrupting but you are not actually speaking to the good person, it has no interest. So it must be embedded into the security of your protocol. Most of the implementation of SSH do the same, apply the same solution for all of these programs. So integrity is verified through strong hash marks, so it's a cryptographic mechanism that makes possible to verify that a packet is not really tampered with. Another problem is that if somebody changes a byte or flips a bit into your screen, SSH or TLS will detect it and shut down the communication. So so much for the availability. It's still based on TCP which is an insecure protocol. Anybody can send an RST, anybody can send packets containing garbage and the application running SSH or TLS will not be able to recover from such a situation. So if you are looking for availability, SSH or TLS is not your solution. Maybe you should look at something around top of IP like IP sake. Okay, confidentiality, it's actually a well-known problem. So SWAMC first, a key exchange and of course the dedication on the key exchange. The key exchange is the way by which the server and the client agree on a common symmetric key to use for the communication and by a way or another the servers might stay. I am that server and my proof is that I signed the key exchange first. Okay, so the main goal of server authentication is to avoid the man-in-the-middle attack. Man-in-the-middle attack is when someone runs right between your server and the client and they fix the server. So in TLS, well, I won't go a lot in the details because I think it's not really the topic right now. But there are a lot of differences between SSH and TLS. For instance, TLS is using X509 certificates where SSH only use your key pages. So you comment for the first time on your server and you get a hash. Do you trust the server to have that hash with a cryptic MD5 or a section 1 hash of the public key? And you say yes or no and then you store it on a computer and you add it. And you store it on an old OS file which is a big difference between SSH and TLS which use a twist chain to verify that the host is legitimate. In addition, their open SSH started using certificates that are not X509 certificates but their own certificates. Yes, that's right. They started implementing their own certificate at first because they felt the need for certificates because people having huge farms with hundreds of servers don't take time to exchange and learn those files. But they have added the X509 thing because they thought a lot of vulnerabilities could come from just parsing F509. So X509 is maintained by Ruben Petrov as the server's patch out of the tree. And the certificate support that it's added in open SSH since a few versions back now is really much, much simpler. It's just the keys and just signatures on keys. And they intentionally did not use X509 because it's complicated. Yes, it's really complicated. It's easy to make errors. But it's new still. Okay, now something that is important as well is that the server must sometimes know the identity of the client, the guy who is typing files in and out of the keyboard. So with TLS, you don't have so much else. Heather, you must use a certificate as well. Of course, you can use a smart card with a PKC as well. But if you wish to use passwords, OTP, two-factors and CISO, you are left to use the application layer. So HTTP or FTP or something like that. There is nothing integrated right into TLS from right. And that's a big difference between SSH and TLS. With that in SSH, everything is done inside the protocol to just to... Can you use QSK now? QSK? Yeah, QSK. That's interesting too. I'm not sure you can do it with SSH right now. Okay. Okay, so I'm sorry if the diagram is not really nice. I made it in the memory. So that's a little genome of the difference between SSH and TLS. In SSH, you have several channels that can be used to communicate with the server. And each channel is dedicated to a service. So for channels, something like that. And all of the channels are protected. Because the authentication layer is particularly used to communicate with the user. So if you wish to use OTP authentication, just use a keyboard to direct it. So it's possible to ask for it to send a challenge to the client. The client replies using the host key. So GSS-CTI, which can be used for cable routes and integrations. So what are you going to choose? I'd say it depends on your trust model. For you, a CA model is easier if a lot of people are going to use your service. And there is no problem that China can forge a certificate for you. Then TLS is probably the best protocol layer. So that's one use case. You'd use SSH if you have clear views of an asymmetrical protocol. So there are the servers and the clients. They are mostly the same, but they are different in implementation. The host authentication model is very simple. So most users will just have to accept the first time. And that's okay. Yes, in SSH you can find it mostly everywhere. And it would be a good idea to actually implement SSH for the access to some widely deployed system services like IMAP. Why couldn't a user have access to IMAP using all the advantages of the authentication feature of SSH? So it's time to start again. I will have to hurry a little. So that's a list of existing SSH libraries. You can see the SSH is not the only one. Actually, I did not test all of them and I can guarantee the whole one. But it's interesting to look at it. Okay. Now I will speak in detail of SSH. So it's just started like a simple SSH program concept in 2003. And I started putting some code around to make a library for SSH. And then it became a little more serious. Some people were contributing. Andreas, who came in 2008 and made a lot of work on the code. So now the SSH is around 33,000 lines of code. So it's one sort of SSH. And it's used by some free software like Qtp. Okay. So interesting feature of SSH is that it's client-side and server-side as well. So you can implement both sides of the communication. There is support for SSH2 and SSH1. You can authenticate using passwords that's the most used for SSH. But also keyboard interactive. For instance, if you pan on your system, it will rely on keyboard interactive. Public key. So if you have public key on your system, it will try to authenticate using it. It will also try to authenticate using the SSH agent. And the good thing is that if your SSH agent is already compatible with PKCS11, you can also authenticate using this contract. Okay. Open SSH. Just click. Okay. A lot of basic features for SSH is there. Okay. We also wrote a lot of documentation for SSH because we felt it was really important for the library to be correctly documented. So if you want to have the API documentation and the oxygen documentation, it's available on that URL. There is also a tutorial that explains all the basic steps to get things done that I will show you a few steps of course. Okay. There are also a lot of examples. It's not intended to be revealed. That's a look on the main page of the tutorial. So there is a lot of information on how to connect, how to authenticate, how to open a remote shell, SFTP, SCP, providing connections or to see if they're running, how to handle trades. And you are currently writing a tutorial on the server application. Okay. So we are developing SSH on our own hardware, on our own infrastructure. So we are using kits with mine. And what's interesting is we have a test panel with night servers. So every night there is a build that is done on several targets. We test our RAM using Valgrinds too. And so we get an A each time someone broke something. So we can have a preview. That's all it looks like. So all the problems used, 3DSD, centralized. Now we have Windows as well. And we get a lot of bugs fixed just by using this and getting the most reported variant. So it's very, very interesting. Another thing that is interesting is the coverage of the test. So all of the tests cover some part of the code. Right now we can see it's still orange because we only have 30% of the code that is correctly tested. But we only started one or two years ago to do some systematic testing. So we see not that bad. Okay. So now the details of the coverage. Okay. That's the sample of how to connect to SSH. Actually, it's pretty straightforward. So you just create an object for the decision. Just then I want to connect to localhost. I want to use the login Paris icon. And then I check the return code to see if the connection was successful. Okay. Then I need to check the server is now. So just like on the SSH when we connect to your host you get a neural message. If you are going to connect to a server, use KSChange. That's the same. You just get a neural code that tells what the status of the host and the known host file. So server known. Okay. Everything is good. The host is known. Server known changed. That means that the key changed. That's very nice. The server from there, that means the server advertised the DSLK for instance, that you only know the RSEK. Find out phone and server not known. That's the first time you connect to the server or that you are using SSH. In that case, you just have to update the file. So a question? Yes. Is it using the open SSH? Yes. Same format. Same file. Parsing it the same way. We parsed the configuration file from SSH. It's not complete, but we are, I say, 70 persons. No. No? Maybe 30. 30 persons. I am optimistic. Okay. You need to authenticate. Well, there is an interesting code that does everything for you. It's a user order type of key, which simply try all the public keys in the repository and will try to connect to you. If you still need to connect using the password, there is a straightforward password authentication code. But of course, there are a lot of other codes that can be made for lower level authentication. Okay. Now you want to just execute something on a channel, but you have to create a channel to open it. So you have to pass the server if you can access it. Normally, you should look at the error codes each time you do SSH code, of course, but it was stripped down for the example. So you just request an execution of a comment and then you read the response. And when you are done, you close the channel. So it's pretty straightforward. Now, what we are looking for the future, we are planning to become 100% SSH library. So we want to implement 100% of the entity protocol, the front end of the case or dynamic. We want to be fully in sequence and code like this. Right now, a lot of work has been made in that direction, but it's not really that. So we want a low-locking API. It will probably be really in the amount actually. Okay. I would like to go into other minutes, but still some work to do. Pkcs11 is a hot topic because we are here just to speak on Pkcs11. Right now, you can use SSH and Pkcs11 for using the SSH agent, but the support will be ready in one month or two after that. Okay. And of course, we have some work to do on the SSH part, server part of SSH. Okay. I'm just in time. I don't know if there are some questions. So what are the questions? Both. So the client-side API is more evolved than the server part API, but as far as I know, the SSH is the only SSH variant that does the server part. Why did you implement it as a separate project from SSH? In the library now, the SSH? Probably not invented here, single. Sorry. Our comment to that is that the OpenSSH code base is not really... Well, you could make a library out of it, I guess, but it's not made as a library. It's not the same concept. The concept in a library is that you must have an external API to access to the whole elements while in OpenSSH, the same is done to work inside the OpenSSH. So it's not really the same. Maybe we could share 50% of the code, not that much. I have a question. Which is the most widespread user of the SSH? The KDA project. So if you are using a KDA partner's use and access using Dolphin, SFTP further somewhere on the server, you are using the SSH as a backend. It was a trick question, because I think I once shared with you a document that said that the SSH is the most used client for some portnet. That's right. We have the market leader there. We won't have to start somewhere. No hanging fruit. Okay, time is up. Thank you.