 So as I said, my name is Eric Hitter. I work at Automatic. Today, I'm going to go through a pretty high level introduction to SSL. We're not going to get into a lot of implementation specifics, but I'm going to go over a lot of terminology, try and clarify a lot of the process involved with this because it's not terribly straightforward. If you were here yesterday and saw Zach's talk, he really did lead into this well with a lot of what he talked about. And don't worry about taking a lot of notes during this, the slides and all of this will publish in about 15 minutes. So everything will be by the end of the, by the time I'm done, they'll be open and available. So first, why bother? Why are we even talking about this? I'm not going to spend a lot of time on this because Zach did a far better job yesterday than I could. There are security reasons as this became a popular topic after Edward Snowden started leaking the documents that he'd taken, but it really goes beyond that. It's not just if you're dealing with something, something sensitive like that. It's even if you have a form on your website where you're accepting any sort of input, including just the WordPress login. If this is the site that is important to your business, you want to make sure that somebody can't snoop your username and password as you're logging in. So you want to ensure that that form is submitted over a secure connection. Again, it makes it much more difficult for third parties, the NSA, or just hackers in general. It really doesn't necessarily need to be a government entity. It could be your internet provider even. If you're connecting and delivering the traffic over SSL, it's much more difficult for people to intercept that traffic and do anything with that. Google has mentioned that they're going to start including this in their search rankings ever so slightly and it will probably become a bigger thing because Google is pushing their ad network as well towards SSL. Mozilla has also said that this is something they would like to see as eventually us going to a web that is entirely encrypted, that is entirely delivered over SSL. And one of the nice things now is with some recent technology advances, one of the long-standing concerns beyond the complexity is performance. And that is much less of an issue now, but it used to be that you would hear and see a lot of articles about how if you enable SSL on your site, it's going to be slower for this reason than that reason. That's much less the case now. Why not? There's two big reasons right now. Ad providers have been notoriously slow to update, so it is entirely possible that if you're running ads on your site, whoever is providing those won't be able to serve those over SSL, so that can be a blocker for a lot of folks. That's becoming less and less of an issue. Again, Google is using their influence. Large media organizations like The Washington Post has made a big push to serve their traffic over SSL, so that's becoming less of an issue. Right now, also because we're in the middle of this transition from traffic being just available encrypted over to SSL, there are a lot of sites that don't support SSL at the moment, so if you're embedding content from one notorious one right now is Hulu. They may have fixed this by now, but as recently, when I looked last, you couldn't embed a Hulu video over SSL. They just don't have a certificate for that. In that case, you end up with mixed content warnings and your embeds don't load and it's just a poor user experience. That is hopefully going to become less and less of an issue, especially as it's easier to secure traffic with some of the things that we're going to talk about today. With that, we're going to move on to terminology. There's a fair amount of it. A lot of it is very similar, very repetitive in some ways, and I'm going to do my best to try and alleviate some of this confusion. Feel free throughout this at any point to interrupt me with questions. Again, this is a lot of very similar terminology and things we're going to get into. First, I've mentioned this a little bit already, talking about encrypted versus unencrypted traffic. When you're connecting to a site just over a plain HTTP connection, so your browser doesn't have the little green lock icon or whatever it shows, that connection is unencrypted. It just means that the request going to the server, the information it's sending back, if there was someone monitoring that connection, they'd be able to read that information without any special abilities. It's just there. It's going to be garbled and strange looking, but it is something that is human readable. It's very plain. Conversely, if you're connecting to a site over a secure connection, that text using some things we're not going to get into today, that text is garbled in a way that doesn't look anything meaningful to you and I or anyone who's intercepting it, but because of how that is garbled, how that is encrypted, the server and the browser can decrypt it and read those two things. Even though anybody jumping in between that, to them it just looks like a meaningless string of text. So encrypted, again, this is where the security comes in. We're transmitting things as ciphertext instead of as plain text. Next up, there are three terms that come up a lot that are effectively the same thing and I will unfortunately end up using them interchangeably very frequently and it happens a lot in documentation and tutorials because they are, for most people's needs, these three terms are synonymous. First is HTTPS and that's just the, happens to be the protocol, it's what you see in your browser when you're connecting to a site securely. It stands for any of these number of different things. It doesn't seem to be a lot of agreement upon how that would translate back, but it just means that in some way your web traffic is being delivered securely over an encrypted connection. SSL stands for secure sockets layer. This is, it was the first version of encrypted web traffic was introduced by Netscape. So they use the term SSL. The technology itself is actually generally no longer used. There are a number of security vulnerabilities in the different versions of SSL. So even though the term is very common, you're almost never actually connecting to anything over SSL. But again, because the terms have been around from the very beginning and it was the original term used for secure web traffic, it persists even though you really shouldn't be using the protocols themselves. And the last term and this one is going to start to become more widely used, but is also still not as common as SSL is at TLS or Transport Layer Security. This is the modern version of delivering encrypted traffic. It came about when Microsoft wanted to introduce secure traffic, secure connections into their browsers. And because they were competing with Netscape, they had to come up with their own thing. The first version of TLS was really just the fourth release of SSL. But again, for naming and fun things like that, it is, we came up with a new term. Again, the three of these really do mean basically the same thing. It gets into the technology used to make those connections, which we're not going to talk much about today. But you'll see these in tutorials and I will end up using these interchangeably throughout. And yeah, as I noted, there are versions of the different protocols. What's important as you start to implement SSL in your sites is this last piece here. The only two that are really considered secure at this point are TLS 1.1 and 1.2. Okay, so now that we've covered those terms, any questions on that? We're going to talk next about the first piece or really the central piece to how all of this secure connection and secure traffic happens. And that's through certificates. And we'll get into the different types of certificates later on. But what it basically comes down to, this is an agreed upon convention for confirming that you have some sort of ownership control of the domain, which should be representing that domain securely. So not trying to spoof Google.com, for example. And it plays a role in how the traffic ends up being encrypted going back and forth. So again, the central part of the certificate is that you have to work with a third party in order to obtain one of these. You can't do this entirely on your own. And that is how secure traffic can be trusted because you have to go to this third party who, as we'll talk about, does some sort of confirmation that you are allowed to be doing something with this domain and then issues you the certificate, which is used to encrypt the traffic. There is a way of creating what's called a self-signed certificate, but it throws an error in the browser. There's no way that you yourself can create a certificate that will be valid without going through what's called a certificate authority. So certificate authority, these are big companies like I've listed down at the bottom there you've probably heard of. This is where you actually go when you need a certificate. You need to buy one of these certificates. It's the Komodo's and it's now semantic. It used to be called Verisign. They rebranded their SSL stuff. GoDaddy also does SSL. StartSSL. And then the big one that we're going to talk about a bit more today is Let's Encrypt. But all these are, these are organizations that the web is basically agreed are trusted to perform this vetting and issue certificates. And I say that they're trusted because the way that this works, these authorities provide a type of certificate to browser manufacturers, so Google and so on. And that is included in the browser, which allows your browser to say, okay, the certificate issued by this certificate authority looks like it's valid. My browser trusts it. And it's because of that inclusion in the browser. That's why the self-signed certificates will never work. It again is enforcing that need for a third party to have that trust mechanism. You can't go this on your own. It's again where the certificate authority comes in. So there's not really, there's no rule that's saying that they can't do one and the other. They got away with it because they've been around for a long time. It's incredibly expensive to become a certificate authority and get the browsers to trust your certificate. So they made a substantial financial investment. All of these organizations have. And it really, because of the verifications, the way that that's done is agreed upon by the web in general, the way that those verifications are done. There's not a lot of conflict of interest there. They're your host and your certificate authority. They're still, even if it's a site they host versus a site hosted with someone else. If you go to GoDaddy to get a certificate, you still go through the same validation process that you would otherwise. They don't get to skirt around that just because they own both. Yep. There are some that will do it for things like the control panels. I've noticed that in some cases. They shouldn't be really, and especially now with let's encrypt, as we'll talk about, there's not a lot of reason to use them. If you're in a situation where you're not expecting third party traffic to visit the site, it's only for you to ever connect. You can get away with a self-signed certificate if it's something that you think you can trust. But it's going to interfere with a lot of things. The browsers throw up warnings. You have to go through, you have to accept those warnings before you can connect to the site. If you're trying to use command line tools with that, in a lot of cases they'll also throw up errors unless you specify that you should trust any self-signed certificate. Yep. I don't know why a hosting company would do that other than certificates are expensive and for a long time until let's encrypt came along, the process was not terribly straightforward. So simplicity perhaps, cost savings. If it's something where you're connecting to a control panel and there's some expectation that you trust that whatever you're connecting to is a valid place that you should be going, then they may just assume, they may have decided that it was worth that compromise. I honestly don't know. It's strange. And again, with let's encrypt out there now, there's really not a lot of reason for it. Okay. So with a certificate authority, in order to get the certificate, there's a what's called a certificate signing request. And this gets us into the three pieces of actually receiving a certificate, certificate issuance. So traditionally when you were getting ready to request a certificate, you would generate a CSR and a private key, and then you go to the certificate authority and go through their process and they give you back the LEAF certificate. So again, that starts to get into how this trust process works. You provide them with the certificate signing request, they do their confirmations and give you back a LEAF certificate. So a certificate signing request is a, again, it's another one of these agreed upon formats. It includes basic information about the entity. So its name, its location, most importantly lists the domains that the certificate should cover. And again, because there's this verification that you have some sort of authority to use this domain, this is where it starts to come in. In this certificate signing request, you say, I am this organization or this individual, whatever, I'm located in this place and I'd like to secure this set of domains. That information all gets rolled up into this CSR and that it provided to the certificate authority. It has the information that they need to then be able to verify your ownership, give you back that LEAF certificate. Again, getting back into the security aspect of this, when you produce that CSR or if you had one before, there's a private key. And this is used to both sign the certificate signing request. So in that certificate signing request, there's a representation of this private key. The certificate that you get back from the authority uses that as well. Which means that if you don't have this private key, that certificate from the authority is useless. You can't unlock it, you can't do anything. So it's as if they send you back the lock but now you've lost the key. It's not going to do you any good. This is never shared, it really should probably just never leave your server in general. You don't submit this to the certificate signing authority. You want to have backups of these somewhere, but this is otherwise is secure. Keep this as private as say your social security number, something like that. Because if this leaks and somebody also then has your certificate, they can go and set up a website somewhere saying, Hey, I am whatever domain and potentially spoof your traffic, things like that. And lastly, there is the LEAF certificate. This is what the certificate authority is going to provide back to you after they've done their process. These expire generally every year, every two years with some sort of frequency. So you have to renew these, you have to re-verify that you still control the domain, that you still have the authority to use that. Any questions at this point? Not for securing the submission now. The question was, does a CAPTCHA on a form offer any sort of security? It doesn't offer any sort of security for the data when it's being transmitted back to the server. CAPTCHAs really are just for protecting against spam submissions and things like that. Okay, any other? Yep, so there are, you can cover more than one domain. How many depends on the certificate authority? And there is a way of also covering every sub-domain for a domain instead of having to list them out. I will mention that a bit when we get into this. So there are three certificate trust types, which I've talked a couple of times now about how the certificate authority verifies that you have some control and some ownership of the domain that you'd like to secure. And this comes into the type of certificate that they'll issue you as a result of it. We're going to talk about three different types. Really the second and third types are only needed if you're a large organization or if you think there's a strong potential that someone might want to spoof your domains. So a Google or WordPress.com uses it. In a lot of cases they're expensive, they're more complicated to get and really are not generally necessary, but we'll talk about them just nonetheless. So the first type of validation, the first type of trust is domain validation. So this just confirms that in some way, in one of these three ways, you have some sort of ownership of the domain. You can server, you can receive the email that's listed in the who is contacts or you have the ability to update the DNS. One of these three, which is used depends entirely on your circumstances, which you have control over, which of these might be easiest. In some cases adding the file to the server is the simplest way. In other cases you may just want to do this through DNS. That really is not important which of the three methods is used. It's just someone affirming that you do indeed have the authority to use that domain. The next type is organization validation. And this is specific to the different certificate authorities, how they do this. But in addition to the domain control validation, there's some checking done to see that the organization submitted in the CSR, if you're saying you're Google that you actually somebody from Google, for example. How this is done, how they do the verification varies by the certificate authority. They have their own rules around this. The last type is an extension of organization validation. It's called extended validation. If you've ever visited a site and in Chrome, your address bar turns up with the company name in the green lock icon, like I've shown down here. Firefox does something similar. That's an extended validation certificate. And what this does in addition to all of the domain validation and the organization validation, they go through and do confirmations that the organization name matches its legal registration wherever the company happens to exist. It confirms with the organization that you have the exclusive right to use that domain and that the organization authorized for an extended validation certificate to be issued. So there's a lot more thorough checking with the organization. To caveat with this, it does not support wild card certificates, which means that if you want to use one of these, you have to list every single sub-domain that the certificate should cover. And the last thing, if you ever did want your company's name to show up in the browser address bar like that, the only way to do it is with an extended validation certificate. Basically, the only thing it does is show that green bit in the address bar. The certificate authorities can really decide to charge whatever they'd like for these. And yeah, it is, in a lot of cases, it's more of a marketing thing, I think, than anything else. But there are some companies that like the confirmation. In a lot of cases, organization validation is sufficient, because if you use one of the big companies like GoDaddy and you say you're from Microsoft, they know that they need to confirm with somebody of Microsoft. Yep, yep, yep. There is, it's much more thorough when you write, because if you're, like in this case, I've screenshotted WordPress.com, the company is automatic. That's what we're registered as. So that's why it shows automatic ink in there. When we did this, they would have done some confirmation that we are allowed to do business as WordPress.com, that we have the authority to use the WordPress name in a .com domain, various things like that. So there is a lot more checking that goes into this. Yep, yep, there's definitely some, it does come with some greater level of trust, because the company name is there and it is more involved. The one thing I will say, Chrome keeps changing how they display SSL information. So if the green bar disappeared or went in some other direction sometime soon, I wouldn't be surprised. I believe in Firefox, they condense it down to the lock icon and you've got to click to expand. Yep, yeah, yeah. And I think it is fairly misleading, because as you said, the traffic is encrypted either way. This doesn't change the security level of the traffic. This just limits someone else's ability to incorporate you in an SSL certificate. This makes sure that the site, that looks a lot like Google.com. The traffic is still as encrypted either way. Now, so that's one of the things extended validation is not covered by Let's Encrypt. They only do control validation. And we will get to that. So I'm running short of time. I have three minutes, okay. So I guess, yes. There are about 15 more slides, so obviously we're not going to get through all of those. Are there any remaining questions at this point? Yes. So I can't think of a circumstance where you wouldn't want to have the certificate. What I would do if you have a case where you need to be able to serve both encrypted and unencrypted traffic, you can configure the web server to do both. Wordpress specifically, if you want just to secure the admin, there's a way to do that, so that the login screen and all of WP admin is only accessible over SSL. But the front end of the site remains available over both connections. So that's not specific to the certificate, but rather how the server and WordPress are configured. Yep. So, yeah, with a lot of the managed hosts now they're offering integrations because Let's Encrypt, and I can actually jump ahead because I do have a slide on that. Here we go. So the way Let's Encrypt works, it does have this client that runs on the server, and all that is really doing is simplifying the process of interacting with the API that Let's Encrypt runs. So if you don't have access to the server but you can run code, you could run a script on the server, you could write something to communicate with the API. The biggest thing with Let's Encrypt, the biggest requirement is that their servers need to be able to make a request to your server at the domain you're trying to secure. So if your DNS isn't pointing there yet, that needs to be fixed, but that's the biggest thing. The server needs to be able to communicate back. You can trigger all of that communication using, you don't have to use the client. You could write your own script that interacts with the Let's Encrypt API, gets back the certificate. They just need to be able to ping a file that gets created on the server. Again, because Let's Encrypt is only using domain control validation. So it's creating a file on the server, they're checking to confirm against that. Okay, I've got time for one more question. Yep. Yep. Nope. Correct. So this is one other big difference with Let's Encrypt. The certificates are valid for three months, but because of how the renewal works with this, they've made it very simple to automate it. So with a lot of the hosting providers, they are going to cover this for you. Otherwise, if you install the command line tool and use that, it retains the configuration and then there's a renewal option. So you could set that up and run that on a cron job. You could just set yourself a calendar reminder that every two months go in and do that. But what's nice is if you set it up on a cron, they have an option to not renew it if it's not expiring. So we'll just check. And I use Let's Encrypt for a few of my domains. It checks every Sunday and just runs once a week. If anything is going to expire in the next two months, it will renew it. And I don't even think about it. I get an email at the end. Yeah, there are a bunch of solutions out there for that. The slides are... Let's see here. There we go. So the slides are up on EtHitter.com now. They should be published. And included in the post are a bunch of links to some other stuff that I've written and some other resources around this. And I do have a post that has some links on automatically renewing Let's Encrypt. Again, slides are up as well. So I will... I'll be around if you have any more questions.