 Thanks to the patients for setting this stuff up. I'm going to talk today about OpenSSL, so from all those wonderful, beautiful UI features that Haris is talking about, I'm going to sadly go back to something really basic and common line and plain. And this is going to be focused on this OpenSSL C library, so I will try and keep it at a high enough level. So those of you who normally work in scripting languages can actually understand me. So a little about myself. I'm a network programmer at Microsec. Max, who is one of the organizers, is one of my colleagues. And I do socket programming and protocols, mostly work in C, C++, some Python. And I work with Linux. And I spend most of my time fighting with OpenSSL, so that's going to be the focus of my talk chat today. And I'm going to cover the history of the OpenSSL library and talk about how to program with it in an ubuntu slash devian environment and how to install the things that you need to start programming with it, some things to keep in mind when you start, especially if you're a newcomer to C and C++ and some basic networking backgrounds so that you can actually follow the example I'm going to talk about. And I'm going to talk about how you move from a TCP handshake to include the TLS handshake. So what is OpenSSL? It's a hugely influential library. It's widely used while being open source. And it implements cryptographic algorithms. And it also provides a complete TLS and PKI stack, a public key infrastructure stack. And it's a command line toolkit. So those of you who are system administrators will be more familiar with the command line toolkit. SSL is the old name. It stands for Secure Sockets Layer. These days, it's known as transport layer security. And TLS is used to secure TCP connections. These days, we've moved on to TCP 1.2. TLS 1.3 is new. It's not very widely deployed yet. And for those of you who don't know too much about networking, you most often come into contact with TLS when you're browsing and a warning pops up on your browser saying that the website certificate has expired. And the purpose of this is to let you know that something, there is a chance that something may have gone wrong. And you think you're visiting Google.com, but really you've been visiting another website. So you might be sharing stuff with them that you really shouldn't be. And another thing that TLS does is to manage encryption between your browser and the website. Now, you can buy a certificate for your website if you have your own website. Or you can get it from free using services such as Let's Encrypt. So very quickly talking about the early days of OpenSSL, it started in 1995. It was the work of two guys, Eric Eh Young and Tim Hudson. It was known as the SSLEAY Library. And eventually, because there was just the two of them working for it, without any pay, they got a job offer from RSA Security and left the project. And in 1998, a new team took over, a bunch of volunteers. And by this time, the code base had grown to this humongous amount. And still, it was used on 66% of web servers. And at the same time, people are still overworked, underfunded. And you can see how little support they were getting. And things finally hit the news in 2014 when you all heard the news about the hard need bug. And even though it was patched a week later, that led to a whole shift in the approach that the world took towards OpenSource projects. And just a very quick overview of the hard need bug. The vulnerability was in an extension to TLS. It wasn't in one of the features you actually need to implement. The vulnerability arises from the fact that the attacker on the left can basically ask the server to return any amount of data up to 64 kilobytes. And if the attacker does this enough times, they can eventually read all sorts of sensitive information from the server's memory. So on the aftermath, OpenSSL received lots of media attention. It dawned on people that these projects are really, really important to the way that the internet works. And OpenSSL became the first project to receive support through the Linux Foundation's core infrastructure initiative with corporate donations from tech giants like Google and Microsoft. The project was restructured for better management, for auditing and security. And from a tiny number of contributors who moved on to GitHub, so now we've got, yay, anyone could contribute to OpenSSL. And we're now at long-term support vision 1.1.1.1. And despite the attention, it's still very much used on the internet. And even if you're a Python programmer and you're using the SSL module, which I've included screenshot off on the right, you are actually using OpenSSL on your machine. Next, I'm going to talk about how to get the source code and get started with developing it. If you're running Ubuntu or Debian, it's as easy as installing the headers for the library. But I really recommend that you get the source code, because chances are something will go around and you'll need to debug, so it really helps for you to search for things in the source code. And if you want the latest and greatest features, I recommend that you download the LTS version. You can play with things such as AdWords 255.1.9 curves and TLS 1.3. I highly recommend you set this flag as well when you're building it, because you will want to know what goes wrong. And there are just a few changes you have to do if you're building projects with OpenSSL. If you're just installing the headers at the minimum, this is what you will need. And if you download the demo projects that I've uploaded onto GitHub, this I use CMake, so this all happens in the background. Next, some gotchas. It is C and C++, so you will get this very useless error message. And there are pointers everywhere, and there are a whole bunch of appropriate free functions, depending on the function that you're calling. And I highly recommend when you're building your OpenSSL projects to include these flags, because when you build your binary and you run it, it dies. Instead of emitting this very useful error message, it will tell you the line of the code that it's actually the source of the problem. The other thing you should do is, good practice, use Well-Grind. The problem with OpenSSL is because it relies on uninitialized library. Well-Grind tools have a fit in throughout thousands of warning statues. So initialize the values in your code as much as possible, and run this with a wrist flag when you run it through Well-Grind. The other thing about OpenSSL is it uses two main file formats, D, E, R, and PEM. They're related to one another. They're basically the same thing. D, E, R is just a binary encoding. It's highly nested, and I'll show you how that works in a second. P, M is the same as D, E, R, just a base64 encoder, so you can email things to one another. And because it's so highly nested, and because it's meant to operate on the Internet, they contain lots more information than what you actually need for the cryptography to work. For instance, an x.509 certificate on the Internet consists of three main things. The certificate to be signed, the algorithm and the signature. Within the certificate to be signed, you've got these further bits as well. And the public key that's needed for the cryptography to work is within here, just these bits and just these bits. So that's why your certificates get up to several kilobytes in size. So to better pass the certificate, I use this tool by adopting myself. It shows you through the various segments of an x.509 certificate as well as other things you might be working with in OpenSSL. And the other thing to keep in mind if you're doing crazy stuff for blockchain and whatnot, OpenSSL assumes, because it's part of the, it uses, it's raised on debt, it's a TLS stack, everything is DR encoded. So you will have to keep in mind that the signature that outputs contains the type of the data, the length of the data, and then the plain bytes that you will actually be interested in. This just shows you what happens when you unzip the folder, the ones that you will need for your programs. Apps is where examples live, crypto and SSL, crypto is where the algorithms live. SSL is where the TLS stuff lives. And for your header files, you will need to pay attention to them because OpenSSL uses many, many data struts. If you work with the cryptography, you will be using the EVP interface. And you should use the EVP interface as much as possible because if you want to switch between algorithms, it's as simple as just calling a different function. So there are two struts and pointers types that you'll be working with in the EVP interface, EVP Piki to hold public and private keys. And you'll be setting up this context pointer before you sign or verify any sort of message. And when you sign a message, everything takes place in stages. You'll be calling an init function, and an update function, a final function, and OpenSSL specific mallet function that you call final twice the second time. And this is to deal with the fact that the structures in DER and PM are nested. So the amounts that you call first time is not exactly the size of the signature that you will get at the end. Verifying also takes place in stages, as you can see. And there's this very cool thing that you will usually not have to worry about. It's an input-up-foot stream abstraction. You can use it to deal with files and socket descriptors and other sorts of things, but that's like really crazy voodoo stuff. And don't panic, read the manual. If your connection fails, fire up Wireshark. You can see what the issue is. And there's the Python library, which is a wrapper around this, but I haven't used it myself, so I can't just say and think about it. And I need to talk about network programming. And I know it's super scary, but really what happens is sockets, you work in a socket API, and the application data just goes to the socket's API and your operating system does the rest of the work. So the kernel of your operating system just adds the headers, the UDP headers, to your application data once you call the socket's API. And because sockets, everything in Unix is a file, you can just treat the socket like you would a normal file. So that's more network programming stuff, but really I want to talk about this. So this is the basic TCP handshake, and you'll be relieved to know that this happens the same way with a TLS connection, and how TLS secures it. You really just have the same three steps and then it performs all the crazy stuff after the same three steps. And what we have to do is handle all these things through OpenSSL, and I'll show you in a second that the Python API is really similar to this. And you can see that TCP is transport, and TLS is kind of logically at a session layer, because the fact that the cryptography consumes computing power and takes time, you really don't want to start a new TLS handshake every time your browser client calls out the server. So I'm not going to show you the source code in detail, just talk you through the steps. The example that I have on GitHub has two pairs of client server programs, one with plain TCP and one pair secured with TLS. The client sends a listening server a string, the server reverses it and sends it back, the client disconnects. So this is how you set up a TLS connection in OpenSSL. These are the things you do normally with a plain TCP connection, and where you will be spending the most time debugging is probably here, setting up the context, because that's where you have to worry about the cryptography and the Cypher suite on either end of the connection. And four and six are actually really easy, and so seven as well. So this structure is also used in Python. When you use the SSL module, you spend a lot of time worrying about the context that is going to control the connection on each endpoint. So when you create a context to worry about which protocol version, I say use TLS 1.2, the Cypher list, go for a strong Cypher list, please don't use MD5 because that's terrible. Normally, if you're surfing on the internet, the client will only need to verify the server, but in some applications, you might want to also verify that the client is who they say they are. And you create a TCP socket in the usual way, it's a bit more involved on the server side, and then you create the SSL pointer from the context. It's literally that one line. You do it on both the client and the server. And then you set the file descriptor from your client. Once you have a working TCP connection, once accept has been called successfully and connect has been called successful, you just set the file descriptor on both sides. And then you perform the handshake so there are several ways of doing this. When you call SSL accept, you're actually telling OpenSSL that you want it to act as a server, likewise with SSL connect, you're telling OpenSSL that you want it to be the client. Or you can do it in two stages, set the accept state, and then you do the handshake, and then you transfer data. Now, those of you who are experienced with TCP will know that you will need to call the read or write function in a loop because TCP just knows of things as a stream of bytes. You don't need to do that with OpenSSL in most cases because it has a default record size of at least 16,704 bytes. So your TLS record should fit within that one TCP packet. And there's a link to that if you want to read more. And that's the GitHub repo. How much time do I have? Five minutes, all right? So list of resources. If you're super new to network programming, I recommend the Bible, the just guide. They got me through uni. And I think we have time for showing this. I mean, I could show you the program, but it's really, it's not as pretty as what Harris showed. So look at the code. Any questions? I've got one question. Yeah. Why not, why not for 1.3? I haven't played 1.3, so I couldn't show the example. But yeah, it's next on the to-do list. Does it address an important thing then? Yeah, it addresses perfect forward secrecy. So perfect forward secrecy is, so every time you set up a new session, there's a new shared key to either side. So even if someone manages to crack the keys on either endpoint, the communications previously are still protected, because they were encrypted using a different key. Yeah, so thank you for your time. Oh, okay. So on the right, you've got the TCP server that's plain text. Just waits for a connection. And on the left, you have the client sending the string. And I'm running this all in local host. So yeah, you can see that I'm calling receive and bytes. That's when I call TCP read in the loop. And then I'll just repeat the exercise with TLS. So you can see that the software descriptor for the client was this. And then it forms the handshake and it was all right. And I had equivalent functions just to send and receive data over TLS. That's it. Anyone have any questions for Anil? This is a, I haven't mentioned this, but you can do this in UDP as well, DTLS. The issue with it is that trying to get it to work with a multi-threaded DTLS server is highly complicated. The problem is that with UDP, you just have one file descriptor. It's the connectionless file descriptor. And so you don't get the, unlike TCP and TLS, you can't link a different file descriptor to an SSL pointer. So you need to use BIOS to make a multi-threaded DTLS server that handles UDP. Have you done anything with quick yet? No, haven't yet. All right. Thank you for your time. Thank you.