NGINX + https 101 The Basics & Getting Started

as an overview this is what I'm going to cover in this talk so the basics of what is HTTP everybody might recognize HTTP from the browser and and have a good sense of what it is but you know I'll go over the basics again and go into a little bit more detail about what protocol versions there are what cipher Suites there are and and the whole point of this talk is how to configure nginx to set your site up or service up with HTTPS beyond that there's the question of using HTTPS in as a proxy so if your engine X is in front of another application how do you set nginx up to act as an HTTP client and from there I'll I'll go into some ways that you can check your configuration to see that it is the most secure in the most up-to-date as well as some bonus topics that help you get the A+ that you need in security so as you might guess HTTP is HTTP + s and S stands for security and in the case of in the case of the web this is two protocols called SSL or TLS they're kind of used interchangeably I'll go into that a little bit later but it's it's a security layer that sits on top of your communication if you think in the OSI light so the OSI stratum it sits below layer 7 in something called layer 6 the presentation layer and what it provides to you is between a client of the server is confidentiality of data so everything that's sent from from the client to the server and back is fully encrypted so that the only two people then know how to read it are the client and the server it also provides a form of authentication where the client can know that the server is who exactly who it says it is and these are all intertwined in the concept of the handshake and the this is your SSL TLS handshake it's it's a little it's a little complicated there's a lot of moving parts but essentially if you if you look stick take a step back it's an extra one or two round-trips between the client and the server that send cryptographic information in this case you have a several options right here there's their server randoms there's client randoms this is all kind of deep stuff you don't really need to know all you need to know is that the server itself sends a public key and the client and server establish a shared secret that they can use to encrypt the communication so all the communication between the visitor and the server is encrypted with a symmetric key meaning both parties have the same key and it's also has there's an integrity key so in this case an H Mac but I'll skip over this this diagram for now and go to the more saline question of why set up HTTPS well the main reason is user privacy and in the case of service the service communication its privacy of information how much do you trust the networks that you're using to transit this information do you trust these networks to be injecting thing to not inject things into your traffic into it to be able to read what gets transmitted over also recently this is if you're using this for a public website it provides an SEO advantage so Google will more highly rank sites that support HTTPS than those that do not and another thing you can do for HTTPS and this is this is one of the main use cases for nginx is to put it in front of services that don't necessarily support HTTPS natively or don't support the most modern up-to-date version of SSL and TLS so what you get with nginx is the best state of the art implementations of all the crypto algorithms that you don't really need to think about and in general it's good practice so if someone's going to a site they like to see that little happy lock icon and in this case this is nginx comm which has HTTPS enabled as well as HSTs a feature I'll talk about later which means that you can you can't really go to the regular HTTP version the site anymore the browser knows to always go to the HTTPS another thing you see here is there's a nice nginx Inc with the US there that that just shows that this is a extended validation sir assert the certificate that says nginx is who it says it is they paid a little bit extra for that and did some vetting but um it's not all roses there are some downsides specifically there is a little bit of operational complexity you have to manage certificates and you have to make sure that these are continued to be up to date and you need to have administrators who are trusted to hold on to the private key material when you connect to a site over HTTPS the first time it can be a little bit slower there if you're not necessarily physically close then on top of the TCP handshake there's the SSL handshake which I mentioned which adds at least two round-trips so there is a slight heart to two latency there but this can be mitigated by several more advanced features of SSL such as speedy which I won't go into but in the end HTTPS can be as fast as HTTP but sometimes it isn't there's also the cost on your servers to actually do the crypto this was brought up as kind of an excuse or a reason to not do HTTPS a long time but it's less and less applicable as the latest generation of Intel servers can do the type of crypto you need for HTTPS very very very quickly with almost no cost so actually encrypting data in transit is basically free in in modern hardware so if you want to set up HTTPS for your service or your website you need to make a couple choices and obtain a couple things so the first is which protocols you want to support the second is which ciphers you want to support and I'll go into what that means and also a certificate that a certificate and a corresponding private key that is and this is an important part trusted by a third party certificate authority that your clients trust so I'll go into that a little bit later but first let's talk about protocol versions so a bit of history HTTP is HTTP plus the s and the S has been changing it's something that's evolved over time originally SSL v1 was a protocol invented at Netscape and there's a famous anecdote where Marc Andreessen was presenting it at MIT and someone in the audience broke it with a like a pencil description of how you break the crypto cryptographic algorithm so that one didn't last very long and eventually they released SSL 2 in 1995 and this was essentially the start of the encrypted web this is what enabled ecommerce and people to be able to submit passwords and credit cards online and be at least reasonably comfortable with doing so SSL 3 followed very soon and this was a complete rewrite by Paul Coker and others and this was a pretty solid protocol in fact the IETF took SSL 3 and kind of mulled it over and worked it into what what was not a Netscape specific algorithm but something for the wider audience called TLS transport layer security oh yeah an SSL stands for a secure socket layer and that's kind of the concept that people had at the time but transport layer security is what they call it now it's a little bit confusing TLS 1.1 1.0 is essentially exactly the same as SSL v3 it's just one or two little tweaks that the IAF took to standardize it and if you actually deeply look into the protocol itself the version number in TLS 1.1 point O is actually SSL 3.1 so you can kind of think of this as a continuum but eventually IETF came up with new versions 1.1 which was just a few minor tweaks and then 1.2 which introduced some new cryptographic topics but looking at this you think okay well some clients support these some clients for more modern ones depending on where they come out you can you can kind of compare with the years but in terms of a security sense most of these have been broken in a significant way or another so SSL v2 is really not recommended it was it was broken a long time ago it's not cryptographically safe SSL v3 people had been using it all the way up until just just over a year ago just under a year ago actually when a cryptographic attack that was essentially 10 years old got rediscovered and was found to break all of SSL v3 TLS 1.0 and 1.1 are generally safe and the latest one 1.2 is the only one that doesn't have any known attacks against it TLS has kind of a model history not really the best security record but it's the best that we have when it comes to interoperability with browsers and with services and it's built into almost everything so TLS 1.2 is the way to go if you look on the web right now in terms of percentage of visitors there's only certain versions that introduced 1.2 and these are these are actually pretty recent versions and it works out to about 75% of traffic so if you're going to set up your server and you choose to go 1.2 only you're really eliminating a lot of your audience so it's it's not necessarily the best move unless you are a super security conscious and okay with letting wide swaths of people who aren't using say Internet Explorer 11 or later to use it on the plus side a lot of or not on the plus side but on the other side of the coin certain certain operating systems platforms are starting to prefer to LS 1.2 so iOS 9 just came out with something called app transport security and in it it requires the server to support TLS 1.2 so we're actually it's that the industry is moving forward towards this standard in any case TLS 1.0 that's the last one that's really secure basically works with everything except for Windows XP sp2 and it yeah there's not much you can say about this it's but it's end of life but it's it's still used in different parts of the world you might want to consider using SSL 3 if you really really need to reach this audience or corporate environments that have this very old version of Windows and there's a missing s in the slide so there's this a site called SSL labs I'll kind of go more deep in detail to that that can rate your site and if you're configuring SSL if you choose SSL TLS 1.2 only you can a if you have only TLS you get an A if you go back to supporting SSL 3 this is it's risky so you get a C so this is this is what you have to consider when choosing your protocols now let's go into cipher suites now what is this what is a cipher suite well there's various cryptographic algorithms that SSL TLS HTTPS uses to establish connections and and it's it's really an alphabet soup you can see there's all these different acronyms what do they mean I can break it down essentially the first one is the key exchange there's a algorithm that the two parties use to exchange keys in this case it's based on the diffie-hellman algorithm the second term here is what type of keys in your certificate so every certificate has a public key of a certain type in this case it's RSA the third piece is your transport cipher so what is the encryption algorithm used to encrypt all the data there's a lot of different pieces that go into this but AES GCM as I meant mentioned this is the this is the most secure cipher and this is actually something that Intel processors do at almost zero cost so this is a pretty cheap and solid cipher to use and the last one is integrity so as I mentioned messages have a hash that goes along with them to make sure they haven't been tampered but if it's encrypted and with integrity you can go from there now not all browsers and servers have the same list of ciphers they support and this this is called protocol flexibility and essentially what you want to do as a server or what a server does is the client says hey this is all I support server says okay of those I know about five of them I'll pick my favorite and so for example if the client says these are the ones I support in this order the server only supports two and then it'll just pick its favorite this is this is this is really it not a really big matter of debate but there's there's a lot of options that you have out there CloudFlare uses this cipher suite list and you can find it on github comm slash CloudFlare slash ssl config and we have it in an engine x configuration format and these are the ones we recommend these are the ones that all sites that are on CloudFlare end up using so there's a cool new cipher called ChaCha 20 that's not supported in mainline nginx yet but we're pushing to do it everything else here you can use Mozilla also has their own recommendations on this and you can go to their site which is the server-side TLS site and they will generate an SSL configuration for you for nginx or for whatever web browser or so whatever web server you might you might be using so that's that's the cipher suites so we have a protocol set cipher suites set now certificates this is the most important part of HTTPS this is what identifies you as a site to your customer and what's in a certificate well there's your name who you are what domain names your site is valid for when the certificate is valid for itself the public key for which the customer can use to to validate anything that you sign with it and then there is a digital signature kind of a stamp from a public certificate authority that is someone who says yes this is a this is a real certificate this is the person actually owns this DNS name and it's valid from these part these points so what makes this certificate trusted well it's the this is this is a breakdown of all the certificates on the internet right now who the mote most of them are signed by so there's some common names in here Symantec has owned has bought several of these certificate authorities including GeoTrust Verisign and others GoDaddy has won Komodo Global sign digi sir these are all kind of big companies that are trusted and most importantly their certificates are trusted by browsers so if Symantec says this certificate is good via the process of someone buying a certificate from them and then browsers will present the green lock and saying yes okay I believe you this is really who you say you are and how you get a certificate is well you have to create a private key or a pair of keys and then send off your public key to the certificate authority to rubber-stamp and turn into a certificate now this usually costs a bit of money there are free ways to do it but essentially the private key you have to keep private and the only person that or the only entity that should have a hold of this is your administrator and your web server itself will need this there are several ways to create these key pairs we have we built a tool at CloudFlare called CF SSL which is a way to generate these keys and what's called a CSR which is a certificate signing request and this is this is essentially the way that you package your public key to the certificate authority to create a cert from and yeah there's open SSL CF SSL several ways to do this and if you want a free one the current most well-known site is start SSL calm so they will give a free site for your certificate valid for a year the UI is a little bit less than nice so good luck trying to get through this there's other talks later today about you know the future of certificate authorities and it's it's looking that getting a certificate will be something that is less and less costly as time goes forward there are proposals for free certificate authorities so right now you're kind of you can pay for a nice experience with comodo or digi cert or come out or global sign or whoever or you can go the free route and go to start SSL now certificates don't get signed directly by the certificate authority there's this kind of chain of trust that gets built up so if you have a certificate it's usually signed by an intermediate certificate authority and that intermediate certificate authority is signed by the real certificate authority so in this case you can kind of think of it as this says CloudFlare but imagine this is a certificate authority is you get a certificate and you have this whole chain of certificates that you present and not all browsers necessarily know what the next one in the chain is and browsers are really only bundled with the top the real offline root certificates so when you can when you're creating when you get a certificate you also need to have the whole chain of trust along with it there's a tool we both called CFS to sell bundle that allows you to create this if your CA doesn't give it to you typically your CA will give you this this chain so now in the good part now that all the kind of theories aside how do you take these options and configure nginx well there are some basic primitives here that you can use and they are SSL certificate SSL certificate key ssl protocols and ciphers they correspond to exactly what we were talking about before you start nginx the way it does TLS is with open SSL which is a tool I'm sure you've a library actually that you've heard about in the news it was famous for heartbleed and several other vulnerabilities that came out it really is the most widely used crypto library built in but and this is what nginx uses for crypto for better or for worse so one thing to do on your server is to check which version of open SSL you're using and you probably want to not use one that's say 0 9 8 and something in the 101 P or 102 range is where you want to be because they've fixed a lot of bugs over the years and the most recent versions are I would say less full of bugs never know when the next SSL OpenSSL bug drops but at least right now it's pretty solid the 101 P and it also has all the modern crypto so when you set up your server section and nginx it's it's really this SSL certificate is your chain of certificates this is your certificate plus all of the chain of trust all the way up to the root and then you also provide your private key and these are these are paths and there are some extra options you can add having to do with session resumption and as I mentioned before when you first establish a TLS connection there is an extra two round-trips because you have to do an entire handshake and exchange certificates and all these sort of things if you've previously connected with the client and they've cashed the the key that is used for the session transport you can just resume that session and this is a feature called session resumption and if you if you look right here it really you just need a timeout to say how long you want to keep sessions for on your side and then how big of a cache for these sessions you can have in this case the default is is 50 Meg's that should last you for a long time and a shared cache is preferred because then you can share them between all your nginx workers so that if one of your workers was the one that originally made the connection and a second connection gets made to a different nginx worker you can still resume the connection and this really speeds things up there's there's a nice talk tomorrow by one of my co-workers Zeeland about session resumption and all the work that we've done to make session resumption safe there's also another option called session tickets this is less widely used it's only used in Chrome and Firefox but essentially does the same thing there's instructions on on how to do this you have to generate a random 48 byte file but um I would recommend sticking just with session caching for now as a pretty obvious next step is you have to list of protocols you want to support and the ciphers so in this case these are the ones that CloudFlare supported ciphers clough are recommended and the TLS protocols starting with 1 all the way up to 2 I mentioned the how you negotiate which cipher you choose there's prutte you can prefer the clients choice of the service choice it's always better to prefer the service choice so there's a directive here SSL preferred server ciphers always turn this on now if you have multiple sites and you have them using the same certificate you can actually break up your HTTP definition to have your SSL Certificates on the top level and then different servers on the bottom levels and it'll work appropriately so the one thing that you have to keep in mind here is if you have example.com and example org you have to have one certificate that contains both of those names that's valid for both those names for this to work and that's that's basically it that's the basics of setting up nginx for HTTPS now the more advanced topics are how do you use nginx as a proxy behind other HTTP services and what we'd like to call this is in backend encryption so your visitor comes to comes to your nginx server and this is fully encrypted what happens behind behind nginx while in genetics has to kind of act in this case as the browser to whatever your back-end service is now this is this can be configured in nginx in a very similar way there's similar directives to SSL protocols SSL ciphers in this case it's just you put it under proxy so proxy SSL protocols proxy SSL ciphers these are the ones that you're going to use as a client to nginx to whatever it could be another nginx it could be another service behind but this is this is how you configure this to work and you I would recommend using exact same set of ciphers and same set of protocols the main difference here is that as a client as I mentioned the client authenticates the server so in the case of a browser you have a bundle of certificate authorities that you trust and as nginx the client you need to have the set of certificate authorities that you trust and there are there are two different ways or two different philosophies that you can use to approach this and one is to create your own internal certificate authority and manage it in-house this is a little bit trickier but it is cheaper and it's more easy to manage because you can issue a certificate for any one of your services whatever they're named and have them issue to a certificate authority that you own and have full control over in that case this proxy SSL trusted certificate would be set to your certificate authority alternatively you can do the same technique that you that I described for nginx which is you can buy certs just buy a certificate for all of your services and and then if your nginx needs to trust them then it can trust the same set of certificate authorities that the browser's trust and so for Ubuntu there's a list on disk and there's there's a place on disk that holds all these certificates for basically every platform but um if you are building a large sort of a large set of services that are going to need to talk to each other it is hard to get certificates issued for these domains um you have to prove ownership to the certificate authority to actually get this get the certificate so if you can I reckon in the internal CA mechanism the the tough part about this is really how do you keep this certificate authority safe how do you keep the private key of that certificate authority safe and you can you can do it by having an offline computer and a special administrator to do that but um in either case there are some challenges okay so you have nginx setup with HTTPS how do you check that it's configured correctly well one of the favorite tools for people checking websites is SSL labs now SSL labs this is a site run by Qualis and you just type in your domain and it will run a full suite of every type of browser every type of SSL connection and it'll it'll tell you what what you have set up correctly and what you have not so in this case we checked as a site I think it was um yeah there's a site called bad SSL comm which essentially enumerates all the different ways that you can mess up your HTTP communication and you can scan each one of those with SSL labs and it'll tell you what's wrong with each one so in this case the grade was given C because it supports SSL 3 which I mentioned is a protocol that is broken but um you do need for backwards compatibility with Windows XP too but you don't really need that there's also several other things that it mentions here that that you can you can kind of fix up but in the description of how I set up nginx in my talk you're not you're basically going to get an A if you set it up that way and that means the certificate protocol support key exchange cipher strength these are all kind of top-notch we also built so if this this works great for public websites if you have services that are behind a firewall or behind an engine X we built this tool called CF SSL scam which will you can use it inside the internal infrastructure it's open source you can build it it's on github and it will do essentially the same thing that SSL labs does but inside your infrastructure and it'll tell you what's right what's wrong with your configuration so this is how you can a but what about a + turns out that SSL labs does give an A+ every once in a while and that's which when you have a feature called a chest eh sorry HSTs which is a hypertext strict Transport Security essentially what this is is an HTTP header you can add on your requests that tells the browser to always reach this site over HTTPS even if they originally reached it over HTTP whenever you go to HTTP always redirect to HTTPS don't ever read their HTTP site and this is this is this is something that you can you can use but it's actually a little bit dangerous because if your SSL configuration breaks then well or say a certificate expires then there's no way for visitors to go to your plain HTTP version of the site there's also some more advanced things you can do here and that's adding your site to a preload list so both Chrome and Firefox yeah you can check the header to see if something should be always HTTPS but they also have a list baked into the browser so if you sign up for this then you can say chrome will never ever access my site over HTTP and this will give you the nice a plus on if everything else is correct on SSL labs if you have HSTs set correctly with include subdomains which means it applies to all subdomains and and it has an at least a six month expiration period which you know this is what makes it very risky because if you change your configuration browsers are going to remember this for six months so you really have to keep your HTTPS configuration working but um the reason that this is a good thing is that every once in a while HTTP as I mentioned is slightly is less secure so someone in the middle can say modify whether it's your ISP or or anybody if you're in a coffee shop can kind of modify things and inject cookies or do anything to your site and with HSTs the browser will never have a chance to even go to your HTTP site so people can't mess with your site in that from that regard so HSTs is a pretty solid thing to do as I mentioned there are several risks but I'm to set it up this is this is just an example but in your server config and edge neck's just add a header that says strict Transport Security and give it a max age and in this case this is in second so this is six months in seconds that's the minimum you need for the preload list and you can add other directives here such as include subdomains or and preload which means that it's acceptable to take this and add it to a preload list so that's how you get the A+ here's just another bonus feature that some people like to use and it can help actually speed up the connection as I mentioned before there's quite a few back and force that you need to set up a TLS connection what I didn't mention was that these certificates not only can they expire to go bad they can be revoked so if you lose track of your private key or there's a breach or someone hasn't managed to own your private key then you have to go to your certificate authority and revoke this key now there are several mechanisms for telling a browser that a certificate is revoked they're all a little sketchy but um the most popular one is OCSP which is the online certificates certificate status protocol and what happens is the when the browser receives a certificate it also has to check to see if it's been revoked or not so it contacts the certificate authority and says hey is this certificate still good and they'll say yes or no and this in itself is another set of connections so you have to look up the DNS of the CA you have to connect to the CA and it's it's it's really kind of an additional slow down for your site so not only is it three round-trips to do HTTPS you have to get the OCSP so what OCSP stapling is is it allows the server to grab this proof that the certificate is not expired for tea and in the background it'll fetch this OCSP response that says yes this certificate is good and then put it inside the handshake so then the client doesn't have to actually reach out to the CA and get it and this makes connections around if you if you do the math on this this is this is obviously back-of-the-envelope type of stuff but it can save around 30% in terms of connecting to a site 30% a time and this is a pretty easy to set up with nginx as well there's a directive called OCSP stapling stapling verify means that you verify the certificate after you staple it and as I mentioned before with the proxy you have to trust the CA so you can just get a file from your CA to add into this trusted certificates section so that brings us basically to the end of this session this is how you configure nginx and OCSP stapling HSTs and a SSL proxying so any questions yeah so the question is do I have a link to my slides and I will add the slides online and provide a link you can go to my Twitter handle here I'll post it within within a few days I'll put these slides up yeah I realize there's a bunch of directives on the slides that you probably want to copy down that taking a photo is not the most accurate most efficient way of doing so okay any other questions so the question is is this how it's going to be or is it going to be changing over time which is a really good question because as I mentioned TLS 1.2 is the latest and greatest this is 2008 they're coming out with a new version TLS 1.3 so this is this is probably going to be coming out within the next year so this applies to right now and HTTPS is a changing landscape so threats that we didn't know about two years ago have completely changed the way that you would configure something now then you would have two years ago so I would I would expect this to change going forward and for people setting up HTTPS to be aware of the changes in the industry if there are big attacks then learn within the new best practices are so it's constantly changing but for now this is the way to go anybody else okay well thank you very much

Channel: NGINX, Inc

Views: 47,266

Keywords: nginx, https, tls, cloudflare, ssl, reverse proxy

Id: dsTub1_4Upg

Length: 36min 6sec (2166 seconds)

Published: Thu Feb 04 2016