 first presenter has been in the European Python community for a very long time. He's also a Django core developer, who I believe these days is responsible for migrations. He seems completely worried about that. Today he's going to be telling us how to SSL all the things. Please welcome Marcus Holterman. Thanks everybody for coming. Thanks for PyCon, for having me. SSL all the things. Good introduction to me. I'm from Germany, living in Berlin these days. My regular contributions to Django started in about 2014 when I picked up every other bug in the migration framework, and then the core team back then got tired of merging my pull requests, so I merged them myself at some point, or had to do that myself. And well, yeah, these days I work at a senior software engineer at LATAPay in Germany, and we do micro payments for online content providers, and should be easy as going out for dinner, you buy or you purchase articles online and at some point you pay your tab. SSL all the things. Ever since Snowden proved that the NSA is spying on all of us, which is a pretty bad thing or pretty serious thing over in Germany for the privacy laws and regulations we have there, we want to make sure we have something to protect ourselves against that. There's also the risk of public unencrypted Wi-Fi's. You don't want the owner of a café, you're constantly going to be able to wire tap your communications with other people. Maybe you're doing your, well, you work from the café and have your business communication over this Wi-Fi. And online content providers sometimes or some ISP inject advertisements in unencrypted websites, which is a pretty insane thing to do in the first place, but also comes with a bunch of security concerns, cross-excripting to name one. So everything or one way or the best way to probably protect you from this is to, well, have an encryption on the communication channel you have and make sure nobody can inject or wire tap anything of that. But before I go into any details, I need to tell you something else. I'm not a cryptographer, all examples here are either to the best of my knowledge or to the best of the knowledge of people I trust. And if there's anything in here where you feel you know that this is wrong, please talk to me afterwards before I publish the slides. I'm not telling people the wrong thing. I'm not going to cover everything in this talk about SSL or cryptography because that would be too much and probably enough for an entire conference. SSL 2 and 3 are broken, just don't use that. TLS 1.0, 1.1 are discouraged and superseded by 1.2. If there's a reason to use 1.0 or 1.1 for distribution reasons, then okay, if you can avoid that, then why have that at all? And future looking cryptographers at Google started implementing a thing, a post quantum cryptography algorithm called New Hope called after the Star Wars movie. SSL, what is it or what's TLS? Well, first of all SSL stands for Secure Socket Layer and TSL for Transport Layer Security. But well, these are two words. They are both cryptographic protocols for communication systems and most notably networks. IZARONE provides two out of three parts in information security. The first of that is confidentiality, which is ensured by encrypting the content. That means nobody can read what is transmitted or the underlying thing that's being transmitted. The other thing is integrity. All the messages you send SSL or TLS encrypted are signed. That means nobody can modify them and you ensure that what you send is what the other person receives. The third thing in information security is availability, which is something you cannot cover on a protocol level, that easily at least. This is something you probably do with auto scaling on AWS or something. Now, how do we actually get to TLS? How do we get SSL working? And this is something where a couple of years ago, let's encrypt came up. It's an organization that provides free SSL or TLS certificates. In order to understand how that works, we need to figure out or need to understand how SSL, this entire certificate thing, works in general. And this is a slightly complex graph, but it's the way how the entire trust system, the trust behavior of certificates works. You have your browsers or email clients and they have a bundled so-called trust store. This is a collection of certificates, your browser and trust. This is the thing that you rely on or your distribution or your browser relies on when validating any of the SSL communications you have. For example, you see root CA there. This is whatever is included in the trust store. And CA can then have so-called intermediate certificates, which are certificates signed by their own probably root certificate. That means you include the root CA in the trust store and have intermediate certificates that are signed by that that you can more easily use to distribute and to sign other certificates. The certificates you see at the bottom are the leaf certificates. So these are the certificates you use for all the sites out there or all the services you have out there. That means once you have a certificate in the trust store and you have a trust chain down to a leaf certificate, the leaf certificate is trusted. Now you see root CA3 on the right side. This is not included in the trust store. And this, for example, is let's encrypt as of now. They are not in the current trust stores of all modern browsers. These are Chrome, Firefox, what's out there, Safari, Edge. They are going to be included in, I think, Firefox 50, which is a major step for let's encrypt. Right now they are so-called cross signed by another certificate authority. And because let's encrypt has control over their own intermediate certificate, which is signed by somebody else who is trusted, they can use their intermediate certificate to sign all your certificates. And since we have a certificate chain from root CA2 to the intermediate here to all your leaf certificates, you have a trusted certificate chain. Now let's talk about let's encrypt a bit more. As I said, it's root certificate authority. That's not in the global trust store. Mozilla is going to edit in Firefox 50. Let's encrypt has control over their intermediate set and they can sign everything they want. And sign everything they want is essentially the thing where let's encrypt started to do something that's slightly revolutionized the way certificates are issued these days. Let's encrypt offers and JSON API that you can use to ask them please sign a certificate for these domains for me. And this process is called ACME. What you need for that is an account key, which is probably our A key you use all the other way you use that for in SSL encryption. You would need a certificate key, which is another one and should be different to the account key having the same their possessive security risk. And you need a certificate signing request, which essentially is a thing that you send to let's encrypt and ask them, can you please sign a certificate for these domains? And when you have these three parts, you can go through the process. This might look a bit intimidating right now this diagram, but it's fairly straightforward. You have yourself or your server on the one hand side, you have let's encrypt on the other. This authentication, the first step is that you use your authentication key or your account key to authenticate yourself or your server against let's encrypt. Hey, this is me. You send the account key's public key signed with a private key, which then authenticates that this key belongs to the one who signed it. And let's encrypt starts knowing you. You can include email addresses or pager numbers or something in there to at later points be able to be notified for what expiring certificates. Now, when you've authenticated yourself or registered yourself, it was pretty much the same process in this step. You send let's encrypt this signing request signed with your private key. So let's encrypt now that it's you and you get a so-called challenge back. This is a specially craft string or file you're supposed to put in a specifically defined directory on your web on the web server. So you make this file available to via HTTP because you don't have HTTP as yet. And that's encrypt is going to request this file for each and every domain you ask them to sign, which is this step here. You send them. Okay, I brought this challenge to the file system. It's able to be served. Please do the validation of the challenges. And this is what happens here in the third step. Once this is done, you can ask let's encrypt for the certificate and this is a bit of a polling option because let's encrypt doesn't notify you when they validated all the challenges. But anyway, you ask for the certificates and you get either I'm not sure what kind of response if it's not there yet, but when it's there you get the certificate that you can use. You write this certificate to whatever file system you have, wherever your web service is able to use it or whatever service you wanted to use on. And well, you have SSL. You have an SSL certificate. So far so good. How do we actually use that? Well, you got multiple options. There's an official client that does all the magic. They have implemented an Apache to configuration system demon, whatever thing that rewrites your Apache config files and does all the magic with them. So you don't need to worry about that. I believe they are working on engine x implementation as well. I'm not the biggest fan of that. This is something that should not be done by some service that is that hasn't a will on its own. This is something that from my perspective is something a configuration management system should do. Why if you want to know why watch my talk from last year's pike on Australia on configuration and system management. There's also a script called ACME Tiny by Daniel Rössler. That's about 200 lines and implements exactly the process I shared before. It's really easy to understand 200 lines of Python code. When you want to use that script, have a look at it, how it works. It's really good to understand how the entire process works. If you are in a system that uses system D, maybe use my fork that has system D integrations for that. There are a bunch of other tools. There's a let's encrypt aws by Alex Gaynor. I haven't used that myself, but seems legit as in, I know him and he's on the, for example, on the Django security team and does a lot of security related things in the Python world. There's our proxy by Amber Brown, which provides a reverse proxy, kind of auto-configuration to a reverse proxy that you tell, okay, I want to have these domains. They are proxy there and it does all the SSL magic for you. I believe it's written and twisted and a couple of other things. There are a couple of tools out there that you can use. I mentioned before you need to make these challenges available to let's encrypt. You need to do that via HTTP. HTTP is pretty much web server, so let's have a look at an nginx configuration file. I hope you can read that. Essentially, you say I have this file called 80example.com and in .wellnownacme challenges, you point to a directory where you write these challenges to and serve all the files that are existing. Otherwise, you serve a 400. For every other file or every other request, you serve a 400 as well. This makes all the challenges available to let's encrypt and when they validate them, you get their certificate. Great. Now, how do we actually use the tools? Well, considering that we use ACME Tiny, or I use that for my own websites and we use that DjangoProject.com, yeah, it's like 60 lines. You put this in a Chrome job and run this every month and you're done. You probably need to restart nginx as well or whatever web server you have, but it's straightforward from there, I guess. It boils down to the same. You need an account key. You need the certificate signing request. You need a directory where you write the challenges, where you write the certificate and the way SSL works or how you're supposed to implement it is that when you look, I think back about the diagram with the root certificates and the intermediate ones, you include the intermediate certificate in your, in the certificate file you're serving on your, through your browser and essentially this combine adds this intermediate certificate for less encrypt. All right. Now, regarding SSL certificate, how do we actually use that in Python? Let's start with the client side. This is a bunch of code. I do understand that, but it's, I think it's fairly straightforward. We have a main function and in there we open a socket and we set a, we create an SSL default context with a purpose for server auth, which means we authenticate against a server. Then we also don't want to use TLS version one and TLS version one dot one. I mean, this is something you can do or you cannot do depending on what your requirements are and you wrap the socket that we opened before and pass in a host name that you want to validate against. This is essential, something essential you got to do. If you don't put in the host name, any valid certificate there would be valid even though it's a different host name. So Google.com with some other certificate would suddenly be starting to be valid. You don't want to have that. You connect and then handle a connection, whatever that means. This is no magic from our perspective. The server side looks more complicated and there's more things you can do wrong on the server side. It's also a lot more code, but well, it's a server application. Nobody meant to, nobody thinks that writing those are easy anyway. Again, you create a socket and bind it to an address in port. So that's these lines here and you again create an SSL default context. So this default context is you can create it with Python built-ins. Whatever your current Python version thinks is the best practice at this point of time when it was compiled. There's another way to create a context. If you feel really paranoid and want to do it yourself, have a look at the Python docs, but I believe you all run up to date system environments. So you have all the latest Python versions, security updates and all the things there. They should be fine. You can again exclude a couple of protocols. For example, TLS 1.0 or you can't or you don't. So if you exclude it on the server side, you don't have TLS 1.2 on your client side, then they won't be able to connect. Because, well, you have a set of protocols or versions on the one side and a set of versions on the other side that don't overlap. So this is not going to work. Then the next thing is this Cypher string. This is some cryptic, well, what looks like cryptic string and I'm not going to explain what all these different parts in there mean because I have not the best knowledge about that either. This is something that I looked at other websites that do a really good job at telling you this is what you currently should do. I give you a couple of links to where you want to look up those details later. Well, and then everything from there is, again, I guess fairly straightforward. You accept connections and for every connection you wrap the socket, handle the connection and once it's terminated or when you got an SLR, well, you deal with it. What I didn't cover, but at least want to mention because it's a white topic and there's a lot of things you can or could talk about, but yeah, I want to mention a couple of things to you because I feel there you should have heard about them and then have a couple of points where you might want to follow up on. There's a certificate revocation, which is something when you want to do SSL in any form at work, this is something you should be aware of and you should know how to do that because when you need to do that and you don't know how to do it, it's already too late kind of. So certificate revocation means that when you have a certificate which is in production use and is compromised because the key for that is being compromised, you want to have a way to make sure that you in no time change the certificate with something that is not being compromised and if you don't have a plan in place that you hopefully tried out as well, then you waste time there in which your users can be subject to attacks. This is the revocation process is part of the SME protocol or SME process, which is not covered in the slides before, but it's covered for the Let's Encrypt API. Same applies for the account key. If your account key was compromised where you kind of have lost unless you figured out and now how to replace your account key and tell Let's Encrypt, oh, by the way, please don't accept this account key anymore. I'm now known as this one. Again, this is probably something you want to try out before you actually use everything. Then for HTTP and HTTPS, HSTS, HPKP, so HTTP for Transport Security and Public Keypinning are two things you might want to look into when you do HTTPS. But be aware of that when you turn them on and are not aware of the risks, you render your website inaccessible for people who have visited the website during the time you turned it on when you turned it off again. So look into what it entails and what it means and what problems you may run into if you turn it off again or if you turn off SSL. Public Keypinning, so that applies to both of them. Public Keypinning is something not necessarily too important for all of us. It's something if you have a high profile company with lots of attacks on DNS or on lots of, yeah, generally a lot of attacks. This is something you might want to look into. But at least on Django Project, I think we don't use it because it's not worth the effort there. As mentioned before, you have SSL as a protocol and protocol generally means whatever kind of communication you have there. And as you've seen in the code examples there, you don't necessarily need HTTPS or HTTP as a protocol. You can use it for whatever you want to use. What this requirement let's encrypt has is that you serve the challenges via HTTP. So if you are able to have an HTTP server listening on the same domain on port 80, then your other service on port 1234, then you can use a let's encrypt certificate for this other service. Well, things that could go wrong as, again, HTTP, this is something you want to look into. Leaked keys, as briefly mentioned before, you want to have a process in place that you can just follow when some of your keys are leaked, because this is a serious thing and a serious issue that you need to take care of urgently. People claim or claimed, I'm not sure, that the resource usage for SSL communications is unreasonably high compared to plain communication channels. Yes, of course, we do some cryptography. We need more resources there. But when you have fairly recent servers, couple of years old, they all do all that just fine. AAS and I, as in the Intel extensions for their CPUs, is something that can be used by OpenSSL. This is something that your hardware is doing the encryption and not anything software implemented. This is something which is ridiculously fast. And this is nothing that you really need to worry about these days anymore. Alright, as mentioned, a couple of resources you want to look into. CypherList is this magic string I showed you before. I guess they always have the up-to-date version of just look up your string and compare it with those. If they differ, then figure out if you can use the new one or if you have other requirements or backwards requirements or requirements for older browsers that are not supported with the new Cypher string anymore. If you can, just use whatever they suggest. SSL apps is probably the go-to place to figure out all the things you messed up with your SSL config. I believe everything that's not an A these days is something you can change. There's a legitimate reason to be able to change that. Not sure if you need a plus on the rating, but if you've got an F, you seriously messed up. Hinnix Lava gave a couple of talks and wrote a couple of blog posts on TLS and how all this entire thing is just complicated complex and everybody does it wrong anyway. This is the ACME protocol. So if you want to have a deep read on how it works and why it works, the way it works and everything, it's an interesting document. This is the link to the experimental SSL Cypher the cryptographic algorithm Google worked on and the gist for the code snippets I showed you before. Alright. Thanks very much Marcus. Questions? Thank you for that. This seems like a great idea when you've got production or web-facing servers. Quite often I'm going to want to test my changes before I push it out and one of the things I want to make sure I test is SSL. Is there any way, for example, if I'm just doing a local Django deployment and to say containers on my machine that I can get a certificate from Let's Encrypt that's not public-facing? No. You need to have as long as you're able to so you can of course set your production domain in your ETC hosts and then point it to your container as long as you also have a ready to Let's Encrypt talk to that domain as in the DSS lookup Let's Encrypt needs to do does is just public DNS. So you need the public-facing server that answers Let's Encrypt requests and get the certificates or challenges like exchange. I think that Let's Encrypt now allows DNS challenges rather than just HTTP. Let's Encrypt does allow DNS challenges as opposed to or additionally to HTTP. I have not heard about this. I don't know. I'm going to have a look. Thank you. Can you share with us any case studies or any examples of public websites we might know about that it's using Let's Encrypt for their SSL encryption. DjangoProject.com my websites I think I believe all the WordPress sites are now so they are I think 5 million active like not expired and not revoked Let's Encrypt certificates which is a really big number and active for 18 months to use Anyone else got a question for Marcus? Sure thing. So previously when I wanted to use SSL certificates that span multiple domains there's been a there's been a recommendation not to do that because some devices don't support the SNI server name indication feature and we passed that point where most browsers actually support that so we can actually just get on with it and put these on the same IP address. Look into what SSL get your browser requirements figured out and then look at what SSL apps tells you if there's any browser who does not support that that you need. Otherwise you need to serve them on different IP addresses which does not mean so it's about different IP addresses not different domains. So the SNI server name identification which means that each domain within a certificate needs to resolve to its own IP address. So you can still have the same certificate for multiple domains I believe but all those domains have to resolve to different IP addresses. Well thank you very much for that Marcus. Please thank again Marcus Haldeman.