 And here we have Christian Heimes, who is the most senior core developer we have in the building, actually. Hello. Hello. Okay, perfect. Welcome to the afternoon of day one of Parlandinium. Thanks all for attending, and thanks for extra paying your tickets, because you're going to pay, actually, the travel of the core developers. In September, we're doing a sprint here, a meeting with the core developers at Lumberg, and you're funding us. Thank you. So, hi. I'm Christian. I'm from Hamburg, being Python for all... Oh, yeah. I usually use the white screen because no contrast, but these displays are amazing. So, core developer, actually, okay, the date's around since 2007, actually, October, and maintaining mostly security stuff at Python. I'm also employed by Red Hat. I'm working on a software site called FreeIPA, which is identity management, a bit like Active Directory. So, and this talk is going to be about TLS-SSL, and the agenda and takeaway for this talk is I want to give you, like, a high-level view of what's going on if you do, like, HTTPS or open your browser code website. Quick introduction to the SSL model, a bit like Three Minutes Crypto 101, TLS handshake, how certificates and public key infrastructure work, a peak preview at TLS 1.3, and finally some books and resources at the end. So, this is actually three hours of material condensed into a 45-minute talk and then shrink down to 20, hopefully 25 minutes, so I need to rush that a bit, sorry for that. I will upload the slides after my talk at that address. So, this talk is under a CCD license, and I have some assumptions. So, only assuming Python 3.6 or newer, and some things only work in 3.8. New version of SSL, new version of TLS, because the old versions are really bad, and also modern cryptos, so I don't get on the pitfalls of bad old cryptos which you can use in old versions of SSL. At first, should we use TLS-SSL? So, the short answer is actually yes. The slightly longer answer is yes, really should, and there are a couple of reasons for that, and most people think, oh, it's very complicated, it's also slow, but there's actually only one performance issue. It's not yet widely used enough, and the rest can be optimized, and these stays, in most cases, are equally faster to use TLS-SSL, which try a hunch out with a nice animation, so that's loading a web page with lots of resources over HTTP. It takes like eight and a half seconds, oh, almost six seconds, but if you go to HTTPS, you do like bam. So, it's much faster because that can use HTTP2 with some tricks and tunneling, which you can't do over plain HTTP, and that's usually much faster, and setting up TLS-SSL these stays is also easy because thanks to free search with Let's Encrypt, so there's actually no good excuses to do that. On the other hand, lots of benefits, so both privacy and security, so nobody can inject like malware if you're using like public Wi-Fi. It's faster, Google and other search machines bump sites with HTTPS higher. You get browser-warning these days if you use like password fields, and browser-inconsidering to remove support for plain HTTP soonish probably next year or the after. So, but what is HTTPS or TLS-SSL actually? So, it's this green, small, funny, wow, my laser doesn't work very well on display. So, this green icon is what most people consider as secure connection. I'll have Wikipedia definitions because they're much better than me to condense something in short sentence. So, transport layer security, and SSL, the old name, are cryptographic protocol that provide communication security over a computer network. The TLS protocol aims primarily to provide privacy or privacy and data integrity between two communicating computer applications. So, lots of things. Let's pull that apart. The core features are encrypted transport. So, nobody can read what you're doing if you do it right. You can run multiple applications over that, not only like HTTP, but also email, VPNs, and whatever. Here's what integrity checks. So, nobody can mess with your data. You can see if somebody messes with your data. It's spreading in replay attacks. So, if you send money to your bank, do a transaction on your online banking applications, take account replay that over and over again to get, like, all your money up account. It also authenticates the server in very strong ways. You know you're talking to your actual bank and not some mental middle attack. And it can also do what most of you don't do that for browsers, authenticate the client, the client certificates. And it's very extensible. So, HTTP2 and HTTP3 build on several properties they can extend the protocol. It's actually not one. It's a whole suite of different things. Well, ITF has some standard for that. There are a couple of numbers assigned. And the IANA, there's different standards. I only talked about actual TLS. There's also TLS over UDP, and there's something new coming up called QUICK, which is HTTP3. There's ASIN1. That's the standard for, like, encoding data, like JSON 30 years ago. And there's this notorious public key infrastructure with X5 and 9 certificates, which is a bit complicated, but again. So, the SSL model, that's the thing most people use, if you use, like, PIP, install your packages, is a very thin wrapper around OpenSSL, which shows through multiple parts. The most important bits and pieces are this SSL context thing, which maps to SSL CTX pointer and OpenSSL, which is your configuration space. You can figure how you do the actual connections. Then you have the SSL socket, which looks like a normal socket, wrapped in something that does all the encryption and protection for you. There's also another bit and pieces. You don't use the socket directly. You use the memory IO, bio, SSL objects. And there's something you should never use anymore, the very, very old legacy API SSL wrap socket. Hope you can see that in the background. It's a bit low here. The connection with the Python SSL model looks a bit like that. So, you import socket SSL, you create a context, then you create a connection, and you wrap the connection in something that's actually the SSL socket. You need a hostname in two places, explain why a bit later. So, this thing here under the hood does a bit more. If you pull that apart, then it creates a context. And since I'm ignoring the old versions, I also set the minimal version to at least TLS12. I don't want to show the first part of the talk what CL-103 is doing of the maximum version. We require certificate verification. We require hostname verification, and since we want to verify the certificates, we also need to load, like, the trust store, the root of the trust for all the certificates. And then we need to do a connection. So, this socket create connection is just a wrapper that takes here IP for four, IP for six, and just creates a socket connection with DNS lookups. And that's actually the endpoint then for communication. Then wrapped into a SSL socket. So, that takes ownership of the socket and returns a instead of SSL socket. And, yeah, now you can just do most of the things you can do for a socket over the SSL socket. And if you look what we're going to do next, if you look what the socket can do, there's some properties like you can get the ciphers, which is this mumbo-jumbo of letters and numbers that I would explain in a minute. The three different versions you can have, you have version one, two, or the last one is for one, three. So, crypto thingies, how does crypto work? So, the very, very quick intro into crypto, very fast, what you need for SSL TLS. It's a bit like LEGO blocks. You build stuff of smaller blocks and create a protocol of that. The first thing we need in a couple of places is we need to have, like, a fingerprint of data. So, most operations can't be done on large amount of data, but you need to shrink the data down, make, like, a checksum. That's hash algorithms. You also need something to encrypt your data. It's called bulk encryption. A bulk means you can encrypt lots of data very, very efficiently, very, very fast, which these days always symmetric key algorithms. So, you have the same key for encrypting and decrypting. But you have to do the right way. You do the wrong way. You need to see through what the encryption does. So, that's an encrypted image of a logo you may recognize. So, you need also a mode or you operate your encryption. And, yeah, all modes are beautiful except ECB. Not you. You're bad. That's the one where you can see the pinging of a logo. So, there are different ways to chain them together. And also, encryption does not secure your communication. So, you can still modify the data. So, you need something that's called authenticated encryption. In the United States, we use AAAD algorithm that called authenticated encryption with associated or additional data where you do something like a checksum and the encrypted output. Or if you decrypt, you verify that the output is the correct output. We also need a couple of asymmetric crypto algorithm. It means you have like a public and a private key part, three major subparts of that asymmetric encryption, signatures where you sign something and something where you agree on a mutual secret. As a symmetric encryption, we don't do anymore because it's bad. Signatures, we do a lot. We need to sign data both for certificates and for the actual connection to verify that you talk to the right server. So, the server has the private key or the CA who has the private key and signs something else. And with a public key, you can then verify that the peer or the private peer owns the private key. And key agreement protocols are... Wikipedia claims a bit of color mixing. So, you have private parts and public keys and you send your public key to the other part. And magically through math and funny stuff, you both agree on the same result without actually exchanging the results. And an attacker can't do the same. So, we have these building blocks. We have key agreement or key exchange. We have authentication. With the cipher modes. And we used a one-way hashing function. One-way function for some parts like Macs. And these build up this lovely acronym. So, that's TLS with elliptic key, Divi-Hallman key exchange with RSA certs. A is 128 for block encryption in Galos counter mode with SHA-256 as Mac algorithm. Yeah, and the other one, that's very old one. We don't do anymore like no encryption at all and MD5 is also bad. But these don't look like the things I printed out like five minutes ago because, well, OpenSSL has a different naming standard. So, the first one is the same as that one and that also maps to that one and this is a new one for TLS 1.3. So, oh, I'm in time almost. A handshake. If you do a connection to a server, you have forced to shake hands and agree on multiple things. So, if you do a connection like that, wrap the socket and during that operation, you do a handshake. So, you agree on multiple parameters. Parameters are amongst others, which version you talk, which ciphers you can talk and then a way to identify the server with the signature and certificates. And then, if you verify the server, you agree on a pre-master secret, that's the secret we use to derive more secrets for bulk encryption verification. And finally, once you have done all the handshakes, you need to verify that both sides have agreed on the same thing and no attacker has modified your ciphers to something badly. That's what you do in the handshake and again, we don't do like the old RSA-KE handshake with the bad one that's insecure. There are multiple blog posts where that's bad. We do the actual modern one using Diffie-Hellman. It looks like that. So, the client says, hey, hello server. Send me, okay, I can talk to the ciphers. I support this version. Here's a random number you need later and I want to talk actually to Palandinium, server name indicator. The server replies to, sure, hello. I selected that cipher. That's the version to talk to you. Here's another random number. Here's a chain of certificates you have to verify and here is a part of the secret. It's the Diffie-Hellman server parameters and also I used my private key to sign these parameters. The public key for that is in the chain and please do something with that. The client says, okay, sure. I generate my own Diffie-Hellman parameters. Verify that and then I tell the, okay, I change in my specs and now that box here, the first part that's encrypted, the rest is all in public. And the client sends the information back and now they have both agreed on the same Diffie-Hellman parameters, have a pre-master secret, encryption secret, verify the MAC, so the method authentication code of this whole handshake and we are done. And now you have done the handshake and the client can start to send actual parameters like HTTP request. If you use Python 3.8, I added something for debugging so it's actually a private method because we have no good IPA for that. You get the same information, so you see, okay, the client writes, client hello, server replies. So you can, a bit of debugging with that. So certificates, what we exchange, sorry, exchange here. So the server sends this four-and-a-half-kilobyte block of certificates. So what's the certificate and how do public key infrastructure actually work? So for that, I'm going to again do verification, verify the server, allow some stuff, verify the host name. And the host name is needed in two parts. The first is you need to send it in the beginning so the server knows with virtual hosting you do and also to verify the identity of the server. And a certificate is a, one certificate is a block of different information. So you have encoding, usually as in one, the different ones, most people know this big block of base 64 with begin and certificates. That's this PEM, there's also Pete's valve which is rather nasty, or you can have just a binary format that's either called server or dur. They come in pairs, so the server has a public and a private key and the client only gets to see the public part and the signature made by the private one and it contains in the payload the public key of the server, some metadata, some extensions and these certs are always signed by somebody who issues the certificates. You have like a notary chain, you have somebody you trust that signs something else and again and again. There are lots of different fields just to, there's also serial number, there's the subject, oops, the subject of the server, there's the issue of the issue of the server, there's how long the certificate valid, usually for, let's encrypt it three months and subject public key information is the public key of the certificate and a bunch of extensions which can be constraints, key usage, a subject alternative name, something with OCSP, and yeah, it's a lot. But the certificates also have different types depending on which parameters you set like the key usage and the extended key usage. We start always for trusting and verifying servers at the root CA or the so-called trust anchor and the root CA signs itself, so it trusts itself and that one you have installed in your browser or operating system or if you use, it requires ship with certify. And that one also signs intermediate cert because the private key of the root CA is very, very sensitive. You store in a way that nobody can get to the private key anymore and for data operations you sign other certs, you sign an intermediate cert, usually there are two of them in most cases and they actually sign at the end your entity or your server cert. So you have your entity cert that's mostly for this case for servers, you can also have certs for clients, you can have certs for email or to sign code and special cases, it's this chain. So the root CA signs the first intermediate, the other one signs the second one and then you have the server cert and in this handshake, you send the whole chain except the root and the client can then look up this chain, verify the chain and verify the trust anchor of that. So trust anchors, where are they stored? So on Linux and BSD, it's usually in the PKC11 model that is then dumped to a file and there are distributions and don't agree on the actual location, there's some of the locations where different distributions have them stored. On Windows and on MacOS it's a bit more complicated because you should not actually directly use the certificate itself but you should just ask the operating system to verify something for you which is something we can't use in Python yet. And how does the certificate look like? So I just dumped the one for palandinium.org three days ago. It's interesting because it's a certificate from a company called Wizard. So it's a domain subject issuer. So that's the issuer. So that's the issuer of, let's say, the great Manchester sales for some company and it's an iVolton Cloudflare. Ah, here we go. So it's from Cloudflare. We have the subject and it's had lots of subterranean alternative names. So we share for palandinium our certificates with some Casino websites from, yeah, Cloud Volcan Casino, Residents, lots. So, Cloudflare hosts websites a lot so they share the same IP address and the same server with a whole bunch of other ones. And, remember at BarupSocket, I always do supply the host name because it's not only important to validate that the chain is correct, you also have to validate that the end certificate actually supplies to your host name. If you don't verify the host name, then I can send you just any certificates and, yeah, you may not be sure that it's also made with the host and that's very complicated and Python we had like, now seven bugs, while updating the talk we had a new bug coming in which is not very critical but still so verifying that yourself is hard and since three, seven, I switched to OpenSSL, OpenSSL does this the right way and if there's a bug, it's not my fault. So, TEALS 103 were very, very quick. So, TEALS 103 is a new standard that came out last year. It killed lots of bad crypto. Horror story, this list is a whole list of horrible old crypto things. Used lots of shiny new crypto things. For example, it only uses this authenticated encryption algorithms anymore. Only them. It improved the protocol in lots of different ways. They learned a lot from past mistakes and past attacks on TEALS SSL. It's also much faster because what the client does, it does a one round trip handshake. So, the client makes an educated guess and says, well, you probably use that kind of Diffie-Hellman parameter, so I send you a key share. The server says, okay, I like that key share. And we're done. It's a whole handshake and important to know is the certificates you get from the server are encrypted. The certificate chain here is already encrypted. So, another one listening to your traffic can't see which sorts you're getting. There's still the server name indicator. The host name is still not encrypted. That's work in progress. And that's, if you use Python 3 with modern OpenSL 111, looks like that. So, if the guess is wrong, then the server can solve a client, okay, you guess wrong, please try again. And it's still two round trip handshake, but in most cases it's much faster than even TS1.2. And in special cases, you can also do something like a zero round trip. So, if you have already a ticket from the server, you can send a HTTP get request and the same time you do a handshake and it's like done. So, it's the whole request takes like one ping back and forth and that's it. So, quick summary. Most importantly, please, please, please use HTTPS everywhere. We have. Our thing is there are some plans to improve how we're working with OpenSL and TSL and Python. We're soon going to move everybody to OpenSL 111 even for 3.7 raises and you get TS1.3 for free because the other versions are reaching that time soon. I'm working again on the already started by Corey Benfield and we're working with Paul Kara from Python Cryptography and also have plans to replace Certified Package with something more sensible to close this talk with a quote from a famous Roman . So, it means should be destroyed. By the way, I'm concerning where I actually don't know how to translate that in English. Any Latin speakers here? Okay, I had Latin in school. Also, this work on HTTP3, UDP, quick is not actually TLS, it's something more interesting which builds on top of paths of TLS. I think Tom is in the audience. Tom is working on fun stuff, so soon to be announced. You want to learn more, I highly recommend especially the book on the right side of the screen. It's now in like three years old but still the best book doesn't cover TLS 103 but explains the whole public infrastructure very, very well. For general crypto things, that book is easy to understand and pretty modern. And several resources. SSL Labs is really good. If you want to optimize your TLS stack, it's TLSfastyet.com. It's from the same guy who makes heifer bean pond. Dig deeper into the handshake. There's Wolfheim made a interactive website where you can explore each bit and byte in the handshake and explain what it does. This talk is a bit older, like three years now from Filipino, Filippo, explains TLS 103 and lots of obstacles that took because they wanted to actually release 103 like four, five, six years ago. I think 2014 was the first try and they're running lots of issues and that's great. If you don't want to have public CA, it also has a public infrastructure server. And that's it right on time. Wow. Sorry for rushing that a bit but again, it's lots of materials and I already removed the horrible parts. If you have any questions, feel free to talk to me. I will be at the conference until Sunday. Thank you.