SSL All The Things
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Holtermann, Markus
Over the last few years SSL/TLS encryption of not only websites but many other services as well has risen tremendously. The Let’s Encrypt organization and certificate authority (CA) makes that pretty easy. Since September 2015 almost 1.8 million certificates have been issued. And you can use it, too. For free! In this talk I'll demonstrate how to integrate SSL/TLS and point out some common pitfalls. I’ll briefly layout the Let's Encrypt ACME protocol and explain what you need to set up in Django to make SSL/TLS the default and only way to access your site.
 Come on, you all! My more regular contributions to Django started in, I think, 2014, when I picked up every other bug in the Migrations framework that was about to be released. And in 2015, the core team decided they were too lazy to merge my poor request and made me do it myself, which made me become a core developer. That was 2015, since April I'm working as a senior software engineer at LaterPay in Munich. At LaterPay, we tried to make online purchasing and selling of goods more easy. And our entire idea behind the process is that it should be really, really convenient for us as a client of our merchants to buy digital goods. And the idea behind, which is also part of the name, is you are served first and Pay Later, similar to the way when you go into a restaurant and order dinner. Now back to the topic, SSL, all the things. Ever since Snowden revealed that the NSA is spying on all of us and that the security and the urge for security increased pretty much, especially over in Germany, where we have really huge and high data security and privacy standards, and that applies to many other European countries as well. And well, there's a risk of, for example, in public, the unencrypted Wi-Fi that might be able to recognize where people might be able to wiretap on the network communications you have, which might be the email communication you have, and depending on how the email server is set up or your client is set up, this might be the business emails where you reveal the purchase of whatever other company you do. And well, you don't want this, you want the owner of the café next door or any other person who is in the café to be able to wiretap on your communication. And yeah, so there's some need for encryption there. I mean, you also don't want internet service providers to inject advertisements into your website, which is otherwise free. So this is something that happens. We have that in Germany, which is really scary and the bad user experience, and not to mention from a security perspective, that is really awful. But before we go into any details, I need to tell you something more. There's a disclaimer. I'm not a cryptographer. All the examples I give here are to the best of my knowledge. If I don't know something, I talk to people, I'm trusting that no more about the stuff than I do, and ask them, therefore, their opinion, which still means we are all human, and there might be errors in their TLR if there's something, if you spot something in the slides that's clearly wrong, please talk to me after the talk outside, I will update the slides appropriately before I publish them. This talk will not cover everything you need to know about SSL, TLS and stuff. That would be too much for one talk and would probably be enough for an entire conference. Also, if you think of SSL or here SSL and TLS, I probably always mean TLS, SSL being just the common term for both of them. SSL 2 and 3 are broken, do not use them. TLS 1.0 and 1.1 are discouraged and you probably should not use them either, but they are at least better than SSL. And future looking cryptographers at Google came up with the implementation of a post-cruntum cryptographic algorithm a couple of days or weeks ago, which is called New Hope, yes, after the Star Wars film. SSL stands for Secure Socket Layer, TLS for Transport Layer Security, but well, this is just the words, they are both cryptographic protocols for communication system, notably networks. And either of them provides two out of three parts of the topic of information security. The first one being confidentiality, which is provided through encryption, which means nobody else can read what is being transmitted. The other one is integrity, which is provided through signing, and nobody else can change what you send without the receiver noticing. The third part of information security is availability, which is something you need to handle on a different layer, for example, scaling and redundancy in your service, but this is something these two protocols cannot provide. Well, know that we are at DjangoCon, we in all the, or most of the things we do with Django with these days are websites, let's start with talking about what you need to do to get a website running, and this is obviously a web server. And a web server configuration is something you, which is the first step where you want to, where your client, the browser of a user speaks SSL with when talking to your website. So let's look at what you need to define or configure in your web server to make SSL working up on and get it up and running. And well, let's start with Apache here, because it comes first in the alphabet. You need to switch on the SSL engine, which happens with this line. Then you want to define a Cypher Suite, which is something I took from CypherList, one of those websites that provide security standards and recommendations. You want to make sure that also the Cypher's, the connection between the client and your server is going to use the Cypher's you want, not that the client wants, because that would mean the client is able to, or somebody might be able to, reduce security of that connection. And well, you also want to use, not use SSL as I said before, Apache 2.4 already disables SSL2 by default or doesn't even support it anymore. So excluding SSL3 might be just enough. But well, you might also want to exclude TLS 1.0 and 1.1. And well, then you define the server key and the server certificate. And last but not least, there's a thing called Divi-Helman parameter, which is used for the initial key exchange between the browser and your server. And setting a custom one there is also probably a good idea. When you look at the engine X configuration, well, that pretty much looks the same. Now, the question arises, where the hell do we get this certificate from? That I was just talking about. And this is where let's encrypt comes into play. What the heck is let's encrypt, you might ask yourself. And how does this entire SSL thing works anyway? And well, this is a huge complex topic that I tried to break down in this talk. And let's start off with how SSL works, or how does a client, how does your browser now that the communication it does with a server is actually trustworthy? And with, for that, let's start with what CA stands for, Certification, Certificate Authority. And these are trusted entities we or our browsers rely on in order to establish a so-called chain of trust. Browsers or email clients on any other client that has encrypted communication with a server have a so-called pre-installed or have a pre-installed list of so-called root certificates. And this list is curated by the browser email vendors, email client vendors such as Google and Mozilla. And they, this list is trusted by them and is called the so-called trust store. The root certificate authorities then go ahead and normally sign so-called intermediate certificates, which are then used to sign certificate you use for your website, for example. They're not signing your website or your certificate with your root certificate, but with a certificate in between. And we can see the reason for that when we look to the right with root CA2 and 3. Roots, as you can see, root CA3 is not in the trust store. So browsers don't necessarily trust the intermediate certificate that was signed by that CA. However, if the second CA, so-called cross-sign this intermediate certificate, you have a chain of trust from here over there to a certificate you would use on your server, and, well, the connection is trusted. And, well, let's encrypt this one of these certificate authorities that is not trusted, or not in a trust store, at least not yet. And, well, they have some other CA that trusts them, which is called Ident Trust. And since let's encrypt has control over their intermediate certificate, they can still sign whatever website they want, and your browser is going to trust that. This is probably a good idea, not necessarily a good idea, but given some security measures in the background, this is probably a good idea in this context. And, well, let's encrypt offers an API to get pretty much unlimited certificates for the domain you had that is under your control. And under your control means you need to be able to provide something on port 80 via HTTP. By now, let's encrypt provided more than 5 million certificates, and they set up, like, one and a half, two years ago, which is pretty impressive. Now, let's look at the process in which you get one of those certificates. And this process is called ACME, or Automatic Certificate Management Environment. It's a fairly simple JSON API with some crypto magic that I'm not going to explain in detail, but the entire process only has, like, four steps. And there are three things you need for this process. One being an account key, which is something you need to authenticate yourself or your server against the, let's encrypt, a certificate key, which is the one you put in your Apache Engine X configuration, and a certificate signing request, which includes all the domains you want to be signed in your certificate. So the API starts with, well, here I am, this is my key. Please register me and authenticate me if I'm already registered. You can provide an email address, for example, there, or a page number in case your certificate is going to expire, but these are optional parts. Then there's this certificate signing request that you sent over, and as a response, let's encrypt is going to provide you with a bunch of challenges. These challenges, you're writing to a web server directory and a provided name with a specific content, let's encrypt is going to provide you. And in the next step in this that you have here, you're telling the next encrypt, okay, I'm done, I've written all the challenges, and let's encrypt is going to request all those challenges on those domains via port 80, what I just said. So when you have control over a domain, you are able to provide content under a certain domain. If you don't have the content, or if you don't have to control over that domain, you can't provide the content, which means this step is secure. And well, lastly, you request the certificate from let's encrypt once all the let's encrypt checked all the challenges. And that's pretty much all the magic that let's encrypt does. Well, this is the configuration of how you would include the, or how we would define the challenge directory, for example. So there's this, let's encrypt is going to request something on well known ACME challenges. So this is the directory or path in the URL you have to provide. And everything else is pretty much explained in there. And well, just to our completion, the same for engine X. Now that we know how to how let's encrypt is working, how do we actually use it? And well, there's an official client which does all the magic. Literally, it rewrites your Apache config if you wanted to. And well, they are also working as far as I know on the implementation for engine X. And well, while this might be a good idea for people who just start with server management, this is probably a bad idea for enterprises at which point you want to use configuration and system management tools. For the reasoning there, please watch my talk from 2015, Picon Australia. There's a script called ACME Tiny by Daniel Rosler, which is like 200 lines give or take. It's easy to understand and it does exactly those four steps I showed before. It's a really recommended treat if you want to start looking at let's encrypt. This gives you a really good idea of how it's working. I've talked that project and edit system D support and a few other things. And if this exact implementation doesn't work for you, well, go ahead, fork it and adjust it as you want. There's also a bunch of other tools, for example, let's encrypt AWS by Alex Gaynor, which as a name suggests supports or implements AWS support. There's a tool called Rproxy by Amber Brown, which is a reverse proxy, which just does all the magic. You only define the domains and nothing else. And well, this is the script we use at my websites and we use a Django project. You provide the information I said you need to and be done with it. You run this every month or so. The certificates provided by let's encrypt have a maximum lifetime of 90 days, which also means that in case something happens, you're lost for 90 days, but then the certificate is invalid anyway and nobody can use it. Being a Django account, there's actually not much we need to do adjust in Django to make SSL work. That's one thing or two things you might want to adjust or I recommend you want to adjust, which are the secure settings for two cookies, which is the session cookie and the CSRF cookie. And also you probably don't want to run your website on HTTP and HTTPS, only HTTPS. If you want to go into further details on what things you could possibly set, have a look at this list of features Django supports out of the box in terms of SSL. It does a lot of features that you probably, when you use Engine X or Apache, would not do in Django but as part of the reverse proxy in front. And well, let me go through those things in the next couple of minutes. Let's encrypt certificates, as briefly mentioned, are valid for 90 days. If you lose them or if they are compromised, you can revoke them by an API call. Same applies for your account key. If you lose that, you can change that and be safe again. If you lose your certificate key, well, this is the same as if you have, if the certificate is compromised, you should get a new key, get a new signing request, get a new certificate and you're done. Well, you probably want to revoke the key as well, but yeah. Then there's a thing called HTTPS or HTTP strict transport security, which means your browser is, after the first visit to the HTTPS site, is only ever going to request an HTTPS version of this site and not even trying HTTP. Which means if you turn it on and turn it off and disable SSL, then all the browsers that went to this website before cannot access it anymore, because you don't have SSL anymore. So if you enable it, be sure about what you do there. There's a similar thing called HTTP, HTTP public key pinning, which works on a slightly separate level. It's probably not too useful for most people, only ever when you have like a really big organization or company and are subject to DNS attacks or so. It has the same drawbacks as HTTPS, that it's not ever going to be, your clients won't be able to connect if this changes or if you lose the configuration there. You can use, you can use Let's Encrypt or the certificates provided by Let's Encrypt for any kind of other service that uses SSL, by just providing a service that supplies these challenges on port 80 for that domain. That's it. You get the certificate for that domain, put it wherever you use it and be done with it. For example, I use it myself for my IRC banter. Well, speaking of cryptography, things can go wrong, and things can go horribly wrong, and there's no finite list of things that could go wrong. HSTS, HPKP, if you want to use it, please be aware of the downsides and what could possibly happen and how bad you can break your site, but you probably want to use it. So this is kind of a trade-off. Speaking of cryptography, you have keys and, well, occasionally you probably, you will leak a key, hopefully only ever once, well, hopefully never, but it's going to happen to everybody. So you want to be able to, you want to have a process in place to revoke keys. And as I said before, let's encrypt has that implemented and has the feature there. Just be aware of how you handle that. People say SSLH or TLS that uses lots more resources. Yes, of course, it does need more resources and computation power, but honestly, that doesn't really matter if any of them are more or less modern hardware. So let's say it lasts for years, probably you probably don't recognize it. Here's an incomplete list of sources. The first one was briefly mentioned before, CypherList. It's a good recommendation for use these cyphers and use, well, this is a configuration you might want to use. The second one is probably your GoTo page if something with their SSL configuration is broken, or if you want to see how good or bad you configured your web service. Seriously, this is the reference tool from my perspective for is my SSL set up correctly. And then there's a couple of blog posts and other resources of how to use or not to use SSL. Thank you. So we do have time for some questions. If you have a question, please come down to the mic for the recording purposes. We've got about five minutes. Hey, Amigo, how you doing? If you turn on the secure cookies, I had two minor questions. One, how does Run Server handle that? And two, if you have to share your cookies from Django with a legacy code base across your domain, say cold fusion, how does that work as well? One, you don't. So which is the reason why I had the good point? I had the environment variables in here. So this is something you want to set in production, but you don't want to use in development, because development is not going to work unless you set local SSL setup, which is kind of a pain for it. The other one I didn't really get. If I have a domain, say worton.upn.edu with two subdomains, like vagrant.wyrton.upn.edu and coldfusion.wyrton.upn.edu, how do I share a cookie across worton.upn.edu as secure? Does it still work across the entire domain if you set the cookie for worton.upn.edu and not the actual server? I'm not too sure, to be honest. Okay. Read up in the documentation. It should be in here. Otherwise, if it's not, this is probably a topic, something we should add to the good documentation as a possible problem. And the ask prints, please submit a ticket and possibly a patch. Well, dude, somebody should also totally do a lightning talk called, Oh, crap, I just committed my Django secret key. That's also a good idea. All right. Two more questions. Sort of similar to the last one, but different case. Let's say you, you know, so let's say you use a bunch of vendors, possibly ad servers, analytics vendors, and they're not running on HTTPS. Any suggestions on how you can still protect your site, or is it just? There's, if apps, companies or apps networks don't provide SSL, there's not much you can do except for either live with, oh, your swipe users insecure content or not use SSL. I might even err on this side of, well, your site uses insecure content. Or hope for the people to use ad blockers and not load the content. I don't know. Honestly, there's not much you can do. At least the major ad networks as far as I read a couple of weeks ago, they are slowly moving over to HTTPS. Right, slowly. Yes, sorry. Hi. I was wondering if you've used Let's Encrypts built-in cert bot utility, and if there's any advantages or disadvantages to using the Acme Tiny instead. The Let's Encrypts official client does too much magic from my perspective. I only want to get my certificates and deal with the rest myself or with tools that are meant to deal with that. So, no, I haven't used anything else. All right, one more round of applause for Marcus.
 Come on, you all!  My more regular contributions to Django started in, I think, 2014,  when I picked up every other bug in the Migrations framework  that was about to be released.  And in 2015, the core team decided they were too lazy to merge my poor request  and made me do it myself, which made me become a core developer.  That was 2015, since April I'm working as a senior software engineer at LaterPay in Munich.  At LaterPay, we tried to make online purchasing and selling of goods more easy.  And our entire idea behind the process is that it should be really, really convenient for us as a client of our merchants  to buy digital goods.  And the idea behind, which is also part of the name, is you are served first and Pay Later,  similar to the way when you go into a restaurant and order dinner.  Now back to the topic, SSL, all the things.  Ever since Snowden revealed that the NSA is spying on all of us  and that the security and the urge for security increased pretty much,  especially over in Germany, where we have really huge and high data security and privacy standards,  and that applies to many other European countries as well.  And well, there's a risk of, for example, in public, the unencrypted Wi-Fi  that might be able to recognize where people might be able to wiretap on the network communications you have,  which might be the email communication you have, and depending on how the email server is set up  or your client is set up, this might be the business emails where you reveal the purchase of whatever other company you do.  And well, you don't want this, you want the owner of the café next door  or any other person who is in the café to be able to wiretap on your communication.  And yeah, so there's some need for encryption there.  I mean, you also don't want internet service providers to inject advertisements into your website,  which is otherwise free.  So this is something that happens. We have that in Germany, which is really scary  and the bad user experience, and not to mention from a security perspective, that is really awful.  But before we go into any details, I need to tell you something more.  There's a disclaimer. I'm not a cryptographer.  All the examples I give here are to the best of my knowledge.  If I don't know something, I talk to people, I'm trusting that no more about the stuff than I do,  and ask them, therefore, their opinion, which still means we are all human,  and there might be errors in their TLR if there's something, if you spot something in the slides that's clearly wrong,  please talk to me after the talk outside, I will update the slides appropriately before I publish them.  This talk will not cover everything you need to know about SSL, TLS and stuff.  That would be too much for one talk and would probably be enough for an entire conference.  Also, if you think of SSL or here SSL and TLS, I probably always mean TLS,  SSL being just the common term for both of them.  SSL 2 and 3 are broken, do not use them.  TLS 1.0 and 1.1 are discouraged and you probably should not use them either,  but they are at least better than SSL.  And future looking cryptographers at Google came up with the implementation of a post-cruntum cryptographic algorithm  a couple of days or weeks ago, which is called New Hope, yes, after the Star Wars film.  SSL stands for Secure Socket Layer, TLS for Transport Layer Security,  but well, this is just the words, they are both cryptographic protocols for communication system,  notably networks. And either of them provides two out of three parts of the topic of information security.  The first one being confidentiality, which is provided through encryption,  which means nobody else can read what is being transmitted.  The other one is integrity, which is provided through signing,  and nobody else can change what you send without the receiver noticing.  The third part of information security is availability,  which is something you need to handle on a different layer,  for example, scaling and redundancy in your service,  but this is something these two protocols cannot provide.  Well, know that we are at DjangoCon, we in all the,  or most of the things we do with Django with these days are websites,  let's start with talking about what you need to do to get a website running,  and this is obviously a web server.  And a web server configuration is something you, which is the first step where you want to,  where your client, the browser of a user speaks SSL with when talking to your website.  So let's look at what you need to define or configure in your web server  to make SSL working up on and get it up and running.  And well, let's start with Apache here, because it comes first in the alphabet.  You need to switch on the SSL engine, which happens with this line.  Then you want to define a Cypher Suite, which is something I took from CypherList,  one of those websites that provide security standards and recommendations.  You want to make sure that also the Cypher's, the connection between the client and your server  is going to use the Cypher's you want, not that the client wants,  because that would mean the client is able to, or somebody might be able to,  reduce security of that connection.  And well, you also want to use, not use SSL as I said before,  Apache 2.4 already disables SSL2 by default or doesn't even support it anymore.  So excluding SSL3 might be just enough.  But well, you might also want to exclude TLS 1.0 and 1.1.  And well, then you define the server key and the server certificate.  And last but not least, there's a thing called Divi-Helman parameter,  which is used for the initial key exchange between the browser and your server.  And setting a custom one there is also probably a good idea.  When you look at the engine X configuration, well, that pretty much looks the same.  Now, the question arises, where the hell do we get this certificate from?  That I was just talking about.  And this is where let's encrypt comes into play.  What the heck is let's encrypt, you might ask yourself.  And how does this entire SSL thing works anyway?  And well, this is a huge complex topic that I tried to break down in this talk.  And let's start off with how SSL works, or how does a client,  how does your browser now that the communication it does with a server is actually trustworthy?  And with, for that, let's start with what CA stands for, Certification, Certificate Authority.  And these are trusted entities we or our browsers rely on in order to establish a so-called chain of trust.  Browsers or email clients on any other client that has encrypted communication with a server  have a so-called pre-installed or have a pre-installed list of so-called root certificates.  And this list is curated by the browser email vendors, email client vendors such as Google and Mozilla.  And they, this list is trusted by them and is called the so-called trust store.  The root certificate authorities then go ahead and normally sign so-called intermediate certificates,  which are then used to sign certificate you use for your website, for example.  They're not signing your website or your certificate with your root certificate, but with a certificate in between.  And we can see the reason for that when we look to the right with root CA2 and 3.  Roots, as you can see, root CA3 is not in the trust store.  So browsers don't necessarily trust the intermediate certificate that was signed by that CA.  However, if the second CA, so-called cross-sign this intermediate certificate,  you have a chain of trust from here over there to a certificate you would use on your server,  and, well, the connection is trusted.  And, well, let's encrypt this one of these certificate authorities that is not trusted,  or not in a trust store, at least not yet.  And, well, they have some other CA that trusts them, which is called Ident Trust.  And since let's encrypt has control over their intermediate certificate,  they can still sign whatever website they want, and your browser is going to trust that.  This is probably a good idea, not necessarily a good idea, but given some security measures in the background,  this is probably a good idea in this context.  And, well, let's encrypt offers an API to get pretty much unlimited certificates for the domain you had that is under your control.  And under your control means you need to be able to provide something on port 80 via HTTP.  By now, let's encrypt provided more than 5 million certificates, and they set up, like, one and a half, two years ago, which is pretty impressive.  Now, let's look at the process in which you get one of those certificates.  And this process is called ACME, or Automatic Certificate Management Environment.  It's a fairly simple JSON API with some crypto magic that I'm not going to explain in detail,  but the entire process only has, like, four steps.  And there are three things you need for this process.  One being an account key, which is something you need to authenticate yourself or your server against the, let's encrypt,  a certificate key, which is the one you put in your Apache Engine X configuration,  and a certificate signing request, which includes all the domains you want to be signed in your certificate.  So the API starts with, well, here I am, this is my key.  Please register me and authenticate me if I'm already registered.  You can provide an email address, for example, there, or a page number in case your certificate is going to expire,  but these are optional parts.  Then there's this certificate signing request that you sent over,  and as a response, let's encrypt is going to provide you with a bunch of challenges.  These challenges, you're writing to a web server directory and a provided name with a specific content,  let's encrypt is going to provide you.  And in the next step in this that you have here, you're telling the next encrypt,  okay, I'm done, I've written all the challenges, and let's encrypt is going to request all those challenges on those domains via port 80,  what I just said.  So when you have control over a domain, you are able to provide content under a certain domain.  If you don't have the content, or if you don't have to control over that domain, you can't provide the content,  which means this step is secure.  And well, lastly, you request the certificate from let's encrypt once all the let's encrypt checked all the challenges.  And that's pretty much all the magic that let's encrypt does.  Well, this is the configuration of how you would include the, or how we would define the challenge directory, for example.  So there's this, let's encrypt is going to request something on well known ACME challenges.  So this is the directory or path in the URL you have to provide.  And everything else is pretty much explained in there.  And well, just to our completion, the same for engine X.  Now that we know how to how let's encrypt is working, how do we actually use it?  And well, there's an official client which does all the magic.  Literally, it rewrites your Apache config if you wanted to.  And well, they are also working as far as I know on the implementation for engine X.  And well, while this might be a good idea for people who just start with server management,  this is probably a bad idea for enterprises at which point you want to use configuration and system management tools.  For the reasoning there, please watch my talk from 2015, Picon Australia.  There's a script called ACME Tiny by Daniel Rosler, which is like 200 lines give or take.  It's easy to understand and it does exactly those four steps I showed before.  It's a really recommended treat if you want to start looking at let's encrypt.  This gives you a really good idea of how it's working.  I've talked that project and edit system D support and a few other things.  And if this exact implementation doesn't work for you, well, go ahead, fork it and adjust it as you want.  There's also a bunch of other tools, for example, let's encrypt AWS by Alex Gaynor,  which as a name suggests supports or implements AWS support.  There's a tool called Rproxy by Amber Brown, which is a reverse proxy, which just does all the magic.  You only define the domains and nothing else.  And well, this is the script we use at my websites and we use a Django project.  You provide the information I said you need to and be done with it.  You run this every month or so.  The certificates provided by let's encrypt have a maximum lifetime of 90 days,  which also means that in case something happens, you're lost for 90 days,  but then the certificate is invalid anyway and nobody can use it.  Being a Django account, there's actually not much we need to do adjust in Django to make SSL work.  That's one thing or two things you might want to adjust or I recommend you want to adjust,  which are the secure settings for two cookies, which is the session cookie and the CSRF cookie.  And also you probably don't want to run your website on HTTP and HTTPS, only HTTPS.  If you want to go into further details on what things you could possibly set,  have a look at this list of features Django supports out of the box in terms of SSL.  It does a lot of features that you probably, when you use Engine X or Apache,  would not do in Django but as part of the reverse proxy in front.  And well, let me go through those things in the next couple of minutes.  Let's encrypt certificates, as briefly mentioned, are valid for 90 days.  If you lose them or if they are compromised, you can revoke them by an API call.  Same applies for your account key. If you lose that, you can change that and be safe again.  If you lose your certificate key, well, this is the same as if you have,  if the certificate is compromised, you should get a new key, get a new signing request,  get a new certificate and you're done.  Well, you probably want to revoke the key as well, but yeah.  Then there's a thing called HTTPS or HTTP strict transport security,  which means your browser is, after the first visit to the HTTPS site,  is only ever going to request an HTTPS version of this site and not even trying HTTP.  Which means if you turn it on and turn it off and disable SSL,  then all the browsers that went to this website before cannot access it anymore,  because you don't have SSL anymore.  So if you enable it, be sure about what you do there.  There's a similar thing called HTTP, HTTP public key pinning,  which works on a slightly separate level.  It's probably not too useful for most people,  only ever when you have like a really big organization or company and are subject to DNS attacks or so.  It has the same drawbacks as HTTPS, that it's not ever going to be,  your clients won't be able to connect if this changes or if you lose the configuration there.  You can use, you can use Let's Encrypt or the certificates provided by Let's Encrypt  for any kind of other service that uses SSL,  by just providing a service that supplies these challenges on port 80 for that domain.  That's it.  You get the certificate for that domain, put it wherever you use it and be done with it.  For example, I use it myself for my IRC banter.  Well, speaking of cryptography, things can go wrong,  and things can go horribly wrong, and there's no finite list of things that could go wrong.  HSTS, HPKP, if you want to use it, please be aware of the downsides  and what could possibly happen and how bad you can break your site,  but you probably want to use it.  So this is kind of a trade-off.  Speaking of cryptography, you have keys and, well, occasionally you probably,  you will leak a key, hopefully only ever once,  well, hopefully never, but it's going to happen to everybody.  So you want to be able to, you want to have a process in place to revoke keys.  And as I said before, let's encrypt has that implemented and has the feature there.  Just be aware of how you handle that.  People say SSLH or TLS that uses lots more resources.  Yes, of course, it does need more resources and computation power,  but honestly, that doesn't really matter if any of them are more or less modern hardware.  So let's say it lasts for years, probably you probably don't recognize it.  Here's an incomplete list of sources.  The first one was briefly mentioned before, CypherList.  It's a good recommendation for use these cyphers and use, well,  this is a configuration you might want to use.  The second one is probably your GoTo page if something with their SSL configuration is broken,  or if you want to see how good or bad you configured your web service.  Seriously, this is the reference tool from my perspective for is my SSL set up correctly.  And then there's a couple of blog posts and other resources of how to use or not to use SSL.  Thank you.  So we do have time for some questions.  If you have a question, please come down to the mic for the recording purposes.  We've got about five minutes.  Hey, Amigo, how you doing?  If you turn on the secure cookies, I had two minor questions.  One, how does Run Server handle that?  And two, if you have to share your cookies from Django with a legacy code base across your domain,  say cold fusion, how does that work as well?  One, you don't.  So which is the reason why I had the good point?  I had the environment variables in here.  So this is something you want to set in production, but you don't want to use in development,  because development is not going to work unless you set local SSL setup, which is kind of a pain for it.  The other one I didn't really get.  If I have a domain, say worton.upn.edu with two subdomains, like vagrant.wyrton.upn.edu and coldfusion.wyrton.upn.edu,  how do I share a cookie across worton.upn.edu as secure?  Does it still work across the entire domain if you set the cookie for worton.upn.edu and not the actual server?  I'm not too sure, to be honest.  Okay.  Read up in the documentation.  It should be in here.  Otherwise, if it's not, this is probably a topic, something we should add to the good documentation as a possible problem.  And the ask prints, please submit a ticket and possibly a patch.  Well, dude, somebody should also totally do a lightning talk called,  Oh, crap, I just committed my Django secret key.  That's also a good idea.  All right. Two more questions.  Sort of similar to the last one, but different case.  Let's say you, you know, so let's say you use a bunch of vendors,  possibly ad servers, analytics vendors, and they're not running on HTTPS.  Any suggestions on how you can still protect your site, or is it just?  There's, if apps, companies or apps networks don't provide SSL,  there's not much you can do except for either live with, oh, your swipe users insecure content or not use SSL.  I might even err on this side of, well, your site uses insecure content.  Or hope for the people to use ad blockers and not load the content.  I don't know.  Honestly, there's not much you can do.  At least the major ad networks as far as I read a couple of weeks ago,  they are slowly moving over to HTTPS.  Right, slowly.  Yes, sorry.  Hi. I was wondering if you've used Let's Encrypts built-in cert bot utility,  and if there's any advantages or disadvantages to using the Acme Tiny instead.  The Let's Encrypts official client does too much magic from my perspective.  I only want to get my certificates and deal with the rest myself  or with tools that are meant to deal with that.  So, no, I haven't used anything else.  All right, one more round of applause for Marcus.
DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_0_59.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_60_167.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_168_239.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_240_1067.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_1068_1799.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_1800_4103.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_4104_6155.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_6156_8627.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_8628_10859.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_10860_11495.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_11496_14387.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_14388_16067.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_16068_16163.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_16164_16355.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_16356_16931.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_16932_20075.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_20076_22499.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_22500_23363.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_23364_24719.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_24720_30407.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_30408_31439.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_31440_32447.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_32448_33839.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_33840_34343.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_34344_34571.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_34572_36551.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36552_36599.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36600_36659.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36660_36743.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36744_36791.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36792_36923.png DjangoCon_US_2016_-_SSL_All_The_Things_by_Markus_Holtermann_B32-KLL1tHU_36924_36946.png