I'm going to present to you a few things about SSH and TNS-SSL and particular over the SSH, so you have ready to access the SSH protocol.

So, a few words about myself, okay, I'm a security and crypto-graphy enthusiast, I came to just as well, I work for the leaders of the SSH projects, I work at BellNet, which

is a research and education internet provider, so we provide internet connectivity to research network and particular for them this year. There is a job booth, so if you have a minute, just go there, that's for my address item,

okay, and I like it. Just tell me where you want the next slide. Sorry? Just tell me where you want the next slide. Okay. Yes, but my whole slides are interactive, so I'm going to do it. 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 crypto-graphy application. And then I will talk a little about our project, how it works, how to use it in

the start, so you can start coding your own SSH clients when going outside of this room. So, you know SSL, you know TLS, how many people here 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 evolved since then. Okay, there is SSH 1, which is almost legacy. It has plenty of holes inside it, so nobody uses it anymore, maybe in some old Cisco

routers. And SSH 2, I imagine most of you already use SSH. So, 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 version 1 was broken during the presentation.

Yes, they came with the version 2 quite easily. Okay, it's very useful, HTTPS, I think you know it. Something that's interesting is that the security number of SSL and TLS is based on

a certificate. So, that certificate, you buy, see the providers for a lot of money, generally, and they

say you are to be trusted because you gave them money and approved that you are who you are. Sometimes. There are a lot of implementations. The best known are penSSL, NewTLS. If you are using Firefox, you are using NSS.

There will be a talk about EDR-SSL as well. And I think Windows has its own and built its own implementation. I think a complete list will include 30 or 40 libraries. So, it's very widely used.

Okay, what about SSH? It's a secure shell. So, the primary use of SSH was to provide an authority shell to a server. The goal was to replace a telnet, in fact.

The first version was SSH 1, which was almost free software. The OpenSSH team took the code when it was still free and made the great OpenSSH product.

So, it's defined in RFCs. It's quite recent. I think it has been done one or two years ago. So, some of the features of SSH that help grow the general scope of SSL are that,

well, a secret transport you have done with SSL as well, but with several channels for communication. So, it's possible to make parallel channels of communication in the same SSH stream.

It's important. Authentication is submitted inside the protocol. So, it's very interesting. I will tell about it later. Okay, so it was done for the shell handling.

So, everything that goes around terminals, terminal size, X11 for wiring, and so that's embedded into the protocol. And there is also a dedicated file transfer protocol that is a lot different from FTP

because it's based on a binary protocol. I won't go into the details because it's a little out of time. Okay, what are you looking into a security protocol or a secure transport protocol? Of course, you are looking for integrity.

You do not want that someone with this laptop can change something in your data stream and coverage 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 availability. Availability is a resistance against Daniel-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 and so on. 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 integration on your channel. So, nobody can interrupt you. And that increase that you are sure who you are speaking to.

That's 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 masks.

So, it's a cryptographic mechanism that makes it possible to verify that a packet has not been tampered with. Another problem is that if somebody change a byte or a bit, flips a bit into your stream,

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. So, anybody can send an RST, anybody can send a packet 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 socket. Okay, confidentiality. It's actually a well-known problem. So, SWAN suffers a key exchange and of course the authentication 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 server is not there. I am that server and my proof is that I signed the key exchange request.

Okay. So, the main goal of server authentication is to avoid a 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, 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 difference between SSH and TLS. For instance, TLS is using X.509 certificate 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 one hash of the public key?

And you say yes or no. And then you store it on your computer and you are done with it. And you store it on a null OS file which is a big difference between the TLS which use a trust chain to verify that the host is legitimate.

In addition, their openness started using certificates. They are not X.509 certificates but their own certificates. Yes, that's right. They start 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 X.509 thing because they thought a lot of vulnerabilities could come from just parsing X.509.

So, X.509 is maintained by Ruben Petrov as a separate patch out of the tree. And the certificate support that is added in OpenSSH 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 X.509 because it's complicated.

Yes, it's really complicated. It's easy to make errors. But it's new still so let's see how it goes. Yes, that's right. Okay. Now, something that is important as well is that the server must sometimes know the identity of the clients.

The guy was tapping something on the keyboard. So, with TLS, you don't have so much choice. After, you must use a certificate as well. Of course, you can use a smart contract with the PQC 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 else. There is nothing integrated right into TLS.

And that's a big difference between SSH and TLS. In SSH, everything is done inside the protocol just to… Can you use KSC? Yes. KSC? Yes. That's interesting too.

I'm not sure you can do it with SSH right now. Okay. So, interesting. Okay. So, I'm sorry if the diagram is not really nice. I made it in a memory. So, that's a little chin up 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 example, the channel is protected using an authentication layer. You can use OTP authentication.

Just use keyboard directly. So, it's possible to send a challenge to the client. The client replies using the host. So, GSS API, which can be used for Kerberos integration as well.

So, what are you going to choose? I'd say it depends on your trust model. If 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. So, that's one use case.

You'd use SSH if you have a clear use of an asymmetrical protocol. So, there are the servers and the clients that are mostly the same, but there are differences in the implementation.

The host authentication model is very simple. So, most users will just have to click on accept the first time. And that's okay. Yes, open SSH, you can find it most 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. I will have to worry 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't guarantee the whole world. But it's interesting to look at it. Okay, now I will speak in detail about the SSH.

So, it just started like a simple SSH profile 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, which is there, came in 2008 and made a lot of work on the code but also on the infrastructure. So, now the SSH is around 33,000 lines of code.

So, it's one sort of open SSH. And it's used by some free software. Okay, so interesting feature of the SSH is that it's client side and server side as well.

So, you can come on both sides of the communication. There are support for SSH2 and SSH1. You can authenticate using a password. That's the most used of the SSH.

But also, keyboard iterative. For instance, if you pan on your system, it will rely on keyboard iterative. 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 PKCS level, you can also authenticate using this card card. Okay, open SSH. Just click. Okay, a lot of basic features from SSH.

Okay, we also wrote a lot of documentation for the SSH because we felt it was really important for our library to be correctly documented. So, if you want to have a look at the API documentation

and Doxygen documentation is available on that URL. There is also a tutorial that explains all the basic steps to get things done. But I will show you a few steps of that. Okay, there are also a lot of examples.

It's not intended to be real. Let's look on the main page of the tutorial. So, there is an explanation of how to connect, how to authenticate, how to open a remote shell, SFB, SCB, providing connections or TCP providing,

how to handle threads, and you are currently writing a tutorial on the server. Okay. We are developing a new SSH on our own hardware, our own infrastructure.

So, we are using Git with MIME. And what's interesting, we have a test panel with 90 rows. So, every night there is a build that is done on several targets. Test our RAM using Valgrind 2.

And so, we get a name each time someone broke something. So, we can give a preview. That's how it looks. So, I'm hoping to use FreeBSD centralized. Now we have Windows as well.

And we get a lot of bugs fixed just by using this and getting the most important value. So, it's very, very interesting. Another thing that is interesting is the coverage of the test. So, all the tests cover some part of the code.

Right now, we can see it's still arranged because we only have 13% of the code that is correctly tested. But we only started one or two years ago to do some systematic testing. So, it's not that bad.

Okay. So, now the details of the coverage. Okay. That's an example of how to connect to SSH. Actually, it's pretty straightforward. So, you just create an object for the decision.

You just tell, 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 or not. Okay. Then, I need to check if the server is now. So, just like in SSH, when you connect to your host,

you get a narrow message if you are going to connect to a server whose key has changed. That's the same. You just get a narrow code that tells what the status of the host and the known host file is.

So, server known, okay, everything is good. The host is known. Server known changed. That means that the key changed. That's very bad. Server front-order, that means the server advertised a DSC key, for instance, but you only know the RSC key.

File not found and server not known means 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, question. Yes. Is this using the open SSH known host file, the same format?

Yes, same format. The same file. Parsing it the same way. We parse through the configuration file from SSH. It's not complete, but we are, what I say, 70%. No. No? Maybe 30%. 30%? I'm optimistic.

No. You need to authenticate. Well, there is an interesting code that does everything for you. User goes with the key, which is simply try all the public keys in repository and will try to connect to you.

If you still need to connect using a password, there is a straightforward password authentication code. But, of course, there are a lot of other codes

that can be made for lower legal 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 ask the server if you can access it.

Normally, you should look at the error code each time you do an SSH code, of course, but here it was stripped down for the example. So you just request an execution of the code, and then you redo the response, and when you are done, you close the channel.

So it's pretty straightforward. Now, what we are looking for in the future, we are planning to become a 100% SSH server. So we want to implement 100% of the SSH protocol,

but not 100% by now. We want to be fully asynchronous, a code like this. Right now, a lot of focus has been made in that direction, but it's not really that. So we want a low-looking API,

which will probably be written in a month or two. Okay, I would like to go into other members, but still some work to do. PKCS 11 is a hot topic because we are here just to speak on PKCS 11. Right now, you can use the SSH

with PKCS 11 for using the SSH agent, but the support will be ready in one month or two after. Okay, and of course, we have some work to do on the SSH server part of the SSH.

Okay, I'm just in time. I don't know if there are some questions. Yes? Is it a solo or a client-side API? 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 barrier that does the server part. Why did you implement it as a separate project from the SSH taking the library out of the SSH slowly?

Probably the not-invented-here syndrome. No, sorry. Our comment to that is that the open SSH code base is not really... Well, you could make a library out of it, I guess, but it's not named as a library.

It's not the same concept. The concept in a library is that you must have an external API to access the whole elements, while in open SSH, everything is down to work inside the open SSH, so it's not really the same.

Maybe we could share 50% of the code, but not that much. I have a question. Which is the most widespread user of the SSH? The KDA project. So if you are using KDA,

wireless shoes, or so, a window, and access using Dolphin SFTP folder somewhere on the server, you are using the SSH as a backend. Okay, that's actually... It was a trick question, because I think I once shared with you that there was a document that said that the SSH is the most used client for some botnet.

That's right. We have the market leader there. You won't have to start somewhere. That's right. No hanging fruit. Okay, my time is up. Thank you.