 If you have never sat in a session with Zach and listened to all the smartness, then you are in for a treat. Zach is an incredibly intelligent guy, but more importantly, he's super approachable and takes very technical concepts and makes them super approachable. So you're going to love hearing from him. We're talking about security here at HTTPS and you may think because you bought the cert that you're secure, but he's going to help you really get your stuff on lockdown. So would you welcome Zach with me? Thank you, Chris. You kind of did half my talk for me. So just remember what he said. I'll try to say the same thing, but I'm going to take about 10 minutes to say it. So thank you all for coming. I always am inspired by people showing up for a talk on HTTPS, something that may not be the most thrilling and exciting thing, but it's extremely important and we really need to make sure we get it right. So my goal today is to give you a better understanding of what HTTPS is and TLS, the protocol that really powers it. If you're a web developer, you've been involved in just anything having to do the web, you probably understand the fact that, you know, HTTPS is just sort of like the big thing these days. Everyone's talking about it. Everyone says you've got to get your site moved over to HTTPS as fast as possible. And if we want to track where this comes from, I would probably say it starts with this quote. I've got some stuff you might be interested in. Does anyone know where this comes from? This is a Snowden quote. Yes. This is the first line that Snowden communicated to Glenn Greenwald when he was thinking about and eventually did release a treasure trove of documents from the NSA. This was in December 2012, right? What followed was some of the biggest revelations about mass surveillance in the U.S., Britain, all over the world. What people started to realize is that every move we make, everything we do is tracked to some degree. And this kind of invades our privacy. So the next really big statement that I thought was really important on this was one that came from the Internet Engineering Task Force. This is a standards body that tries to create standards around what they call anything internet related. They came out and they said that we should treat pervasive monitoring or surveillance as a technical attack. Monitoring isn't like going into someone's server and injecting some code and stealing credit cards, but it's just sort of monitoring everything, listening to everything. Not targeting one individual or two individuals or people that are involved with certain criminal activities, but just everybody. So what they said is that we should consider this as an attack. And when we are considering new protocols for internet related things, we need to think about this as a first class problem that we try to protect against. This was in 2014 that they came out with an RFC just around this concept. Just saying that pervasive monitoring is an attack. Another statement on this came about a year later, about a year ago now, was from Richard Barnes, who is a Firefox security lead. And what he said is that Firefox intends to deprecate non-secure HTTP in the Firefox browser. What that means is any fancy new APIs that Firefox will deliver in the future, you can only use it on sites that are over HTTPS. A great example of this is service workers, if people have heard about that. It's a fantastic new JavaScript API that allows your websites to take on a lot of app-like capabilities. So sending notifications, doing offline modes, those sorts of things. Only HTTPS. Recently Chrome 50 came out, they deprecated geolocation over HTTP. You now need to have HTTPS for geolocation API to work. So we see the trend, right? Browser vendors are saying, hey, if you're not over HTTPS, the cool new features, they actually call this in the standards language, powerful features, are not going to be supported, move to HTTPS. Now one of my favorite sort of stances on this was last year we got an update to HTTP, the protocol that powers the web. HTTP2 came out, and the big headline here is, HTTP2, everything's faster, right? We really want this, everyone likes to have fast website, makes it really faster. So through the standards process of HTTP2, it's very controversial. A lot of people were pushing, we should make HTTP2 only work over HTTPS. Unfortunately they didn't win, so in the standard itself, there's no mention of HTTPS. However, something amazing happened, like absolutely amazing. After that, all of the major browser vendors came out and agreed on something and did it. They all said, okay, we're going to support HTTP2, but it will only be over HTTPS. And seriously, like within the same timeframe, within the same year, all major browser vendors, probably about a seven month period, all of them had support for HTTP2 all over HTTPS. Seriously, and like Flexbox, we can't even get that standard across all browsers. Like this stuff doesn't happen, this is unheard of, but that's how important it is. All browser vendors are like, sure, we're going to do this. So the point here is that we're trending towards HTTPS. I have some data on this, some real science here. I put it in a graph. I also have a laser pointer which makes it more scientific. Can you see it here? We're right here right now, we have less HTTPS, dramatic walk across to emphasize going over time here. We're going to be up here, way up here. We're going to have more HTTPS over time. Point is, we need to understand HTTPS as a web developer. If you are doing work in the WordPress space, there will come a time where you have to implement HTTPS. This isn't going to be for e-commerce, this is just going to be for your standard website. You need to know how to do this. And I would argue that HTTPS knowledge is now essential. You need to understand this. If you see yourself maybe as someone who only wants to do some HTML, CSS, maybe do a little templating with some PHP, but you've had to set up WordPress before, maybe you've tweaked the HTTPS file. You never thought of yourself as a server admin, but you've had to do that to make WordPress work. I would argue that this is the same thing with HTTPS. You're going to have to understand this well enough so that you can make it work. There's a huge, huge problem here, though. We are really, really bad at HTTPS. As an industry, when we implement HTTPS, more often than not, we tend to screw it up. We just screw it up. One way or another, we can't help ourselves, we trip over our foot, we screw it up. There's a website that actually tracks this, SSL Pulse. It looks at the top 300,000 Alexa ranked websites on a monthly basis, waits their HTTPS implementation, and tries to decide how many are secure or how many are not secure. Current statistics from this month suggest that 58% of the top 300,000 Alexa websites that allow an HTTPS connection are, in fact, not secure. They rate this on an A through F scale. If you're not an A, then you are considered to be insecure. Their logic follows that if you don't have an A, you've messed up one key area of HTTPS implementation, meaning that you are vulnerable to a known attack, therefore you are not secure. These are the top 300,000 Alexa websites, right? Like, these are the big sites out there in the world. 58% of them are considered not secure right now. In an academic study by Croncha Beno, they looked at sites that were implementing some of the newer, cooler, like, even more secure features of HTTPS. And what they generally found is that people tried, like it was a nice college effort that you tried to get this right, but they screwed it up, and their conclusion was misconfiguration error. Just undermine the potential security. Echoing that, a study in 2014 by Wong et al that looked at, again, top Alexa websites, looked at how they implemented a key exchange, something we're going to talk about a little bit, and found that there was an industry-wide configuration problem with the deployment of DHE key exchange. Do you hear that refrain? We're just configuring it incorrectly. We just don't know how to do that correctly. And I would ask the question, why is this? Like, why are we getting this wrong? And I have, like, the stupidest explanation in the world. It's hard. It's just hard, right? Like, stuff's hard. This stuff is hard. Unless you're a cryptographer and you study these things, it's easy to screw it up. It really is. However, I'm not going to leave you hanging with stuff as hard. There's something that's actually really easy, and it's called copying and pasting. This is something that computer science has devoted a lot of time to studying. They've solved the problem. This one's free. This one's on the house. If you want to copy and paste, it's Apple C, Apple V. Windows users have got you covered. It's Control C. You've got to use the pinky, Control V, right? It's easy. It's really easy to do that. So what happens? We want to implement HTTPS. We, you know, Google some fancy terms. You find a configuration, copy and paste that sucker. The problem is that maybe we kind of made it work, but we don't know what we're doing, and that's really the hard part. We don't know what we're doing. So that was a long introduction to what I want to talk about here today. I want you to know what you're doing when you're implementing HTTPS. So today I'm not going to give you a walkthrough of this is how you implement HTTPS. We're going to focus on what you're actually doing when you put HTTPS on your website. Why it's so important that we're doing this. Eric Kidder is going to have a talk tomorrow where he's going to focus, I believe, on the implementation pieces, right? Yes, good. Okay. If he said no, sorry. Didn't know what to tell you at that point. So let's start off by talking about TLS. So basics of TLS. TLS stands for Transport Layer Security. You might know it as its other name, SSL or Secure Socket Slayer. So to kind of give you an idea of where this comes from, in 1995 Netscape Navigator introduced SSL. This is the term that most people will call this. The term changed its name in 1999 to TLS, yet we still call it SSL. Go figure, right? That's what we do. So the whole issue there was that in the late 90s there was the big browser wars, Netscape, Internet Explorer, Internet Explorer wanted to get in on this secure connection and they also wanted to push it towards a standards, to a standards track, but they didn't like the idea of the standard being Netscape's product called SSL. So instead it went through a name change which made it much better, but for all intents and purposes, TLS version one was essentially SSL version four. It was the next line, the next product in the line of this protocol. So TLS is a sort of security layer that sits in between TCP and HTTP. So when you take your web browser and you type in a URL to connect to a server, you first establish a TCP connection. A TCP connection can be thought of as like when you pick up your phone to call someone, you type in the number and it starts ringing. You're establishing a connection with that person so then you can start passing messages back and forth on that connection. That's the TCP part of this. You establish a connection between the browser and the server so you can transmit data back and forth between the two. Then you would normally just start sending the messages which are HTTP. When you are doing HTTPS, you have an extra part of this and that is TLS, the transport layer security. So you open up the connection, then you negotiate a bunch of security parameters around that connection so you have a secured connection between the browser and the server. So then HTTPS, it's HTTP over a TLS connection. Does that make sense? Okay. Now the four things that HTTPS gives you, and this is what I really want you to focus in on today, it gives you authentication, encryption, integrity, and key exchange. So we're going to break all four of those subjects down but I really want you to focus on those. That explains to you what the security benefits of HTTPS really are. So the first is authentication. When we think of HTTPS, authentication is one of the things I think a lot of people just sort of naturally grasp and authentication is concerned with is the server that we're connecting to the server we intended to connect to? So when I go on my browser and I type in Google.com I really hope that the data I'm getting back and the site that I'm passing data to is actually Google.com and it's not like some forgery website that's run by a malicious attacker that's trying to steal information from me. What I really hope is that I'm connecting to the website that is owned and operated by a tech giant located just north of here, right? So I want that to be the case. So HTTPS can give us guarantees around that using SSL certificates through a whole transferring of chain of trust. We know that when we connect to that website our browser will only allow us to connect to it if a number of validations have occurred that authenticate that server as belonging to Google.com. That's really important with HTTPS. If you want to ensure that when people are talking to that specific site that it's actually that site. Someone hasn't performed a man in the middle attack and directed you to another site that's actually a forgery. HTTPS can give you that guarantee. Properly configured HTTPS that is. We also get an integrity guarantee with HTTPS. An integrity is concerned with is the message that was received actually the message that was sent? When the server passes information back to the browser sends that HTML. Has that HTML been tampered with in one way or another? If it is it could change the meaning of that content. All sorts of problems it could be used to trick someone into some behavior that could cause them to give up more information they wanted to. We want to ensure that that data that is being transferred has not been altered tampered with, not played with at all. We want to make sure it's the actual data that's been sent. HTTPS that is properly configured gives us guarantees around integrity of data. That's really, really important. The third thing probably the one that everyone kind of grasps naturally because this is in the news daily now is encryption. HTTPS gives us encrypted data transfer. And this is really concerned with taking some intelligible plain text and converting it into unintelligible cipher text. So you garble up all that content so that if someone gets their hands on that content it's no good to them. For instance like with pervasive monitoring where people are listening in on this content that's being transferred all the time. If it's encrypted and it can't be decrypted then that data is essentially useless to people. So let's talk a little bit about encryption. I've encrypted a word here extremely securely. Can anyone guess what this word might be? Wordpress? Yeah, you think so, huh? Okay, yeah, you're right. Okay, good. So that was not a very good encryption scheme but it should hopefully get the point across. Does anyone know what encryption scheme I was using? A Caesarshift. I rarely hear that but that is absolutely right. Anyone know another name for it? Rule 13, yeah, all the same thing or a substitution cipher. All we're doing is we're taking a letter, we move a certain number of letters down the alphabet and we get a new letter. So we take a plain text letter and we change it into a cipher letter. The important thing here and the reason I like to show this one is because the algorithm is extremely easy to grasp. We just take a letter, we shift the X number of letters down the alphabet and then we have a new letter. I have 13 highlighted there because that stands for the key. I'm just going to skip this slide since you have a very well informed audience that already knows what this thing is called. It's a substitution cipher, a Caesar cipher. And in this case, our key is 13, right? We have an algorithm, a known algorithm, really good cryptography, relies on the algorithms being really well known. It's the same kind of concept of open source software sometimes can be a lot more secure than proprietary software because it's out there in the world, everyone's studying it, attackers are studying it, all of the security vulnerabilities tend to bubble up to the top whereas if you have proprietary software, fewer people see it, less vulnerabilities are discovered. That doesn't mean they're not there, just they're not discovered. The cryptography community has valued those same principles. We want where they want, I'm not part of that community, they want really, really good algorithms that have been studied. Mathematicians have tried to break them so we all know the algorithm but what we don't know when we're engaging in encrypting and decrypting content is the key. The key needs to be extremely secretive. The idea is if we have a good strong algorithm and a good key, we can have good encryption. So people who have the key are able to take plain text, apply it to an algorithm with a key, and get cipher text. And if someone else has that same key, they can reverse that, they can take the cipher text, apply the algorithm and the key to it, and get plain text. So both parties that exchange this information must have the key. And this leads us to the last part of HTTPS and that is key exchange. So we just established that if two parties have the same key and they're using the same algorithm, they're able to encrypt content that the other person can decrypt. And then both of them can encrypt, both of them can decrypt. But how do we get to this point where both parties have the same key? We have to get to some sort of point where I have the same key that you have so that I can encrypt data that you can decrypt. And isn't the whole point of this that we're trying to do this so that we can encrypt data to send it back and forth? But before we can encrypt data to send it back and forth, how do we send a key to each other before we have encryption? Like this is a problem. How in the world do we do this? And this has been a problem for a long, long time. Back in World War II, German soldiers used an enigma machine to be able to encrypt data at the time it was thought to be completely unbreakable. To be able to do this, they had keys. And keys in this case essentially specified the settings for these little cords here. There were some rotors that they had to change. These keys dialed in exactly what all those settings would be. If you have those settings exactly right, you can encrypt content just by typing it in. And then the other person with the same settings would be able to type that in and be able to change the ciphertext back into plaintext. But to be able to do that, you had to agree on those different keys. So what did they do? They actually had books that had all the keys for like a month worth of keys, and they would distribute them all throughout Europe. So if anyone who needed to have those keys, they would just have couriers, you know, go over here, here's your book, over here, here's your book. Everybody had keys, and then they can engage in that kind of communication. So the other day, I ordered something on Amazon. I was over an HTTPS connection. I gave them my credit card. I felt that it was safe, but never did I have Jeff Bezos come to my house, give me a key to use to encrypt my credit card. That didn't happen. This happens automatically over a good HTTPS connection using something that is known as the Diffie-Helman-Merkel Key Exchange. All right? So rather than go through all the math of this, we're just going to do this live. How does that sound? Okay, great. So let's do a demo. Demo time, everyone. So I need two volunteers. I need an Alice, and I need a Bob. Come on up. Way in the back. That never happens. That's awesome. Alice or Bob? That was not a yes or no question. Bob, okay, we got a Bob. We need an Alice. Alice, right there. Come on up. All right, Bob, I'm going to give you this, and you can just stand right there. Alice, how are you doing? Thank you for volunteering. I'm just going to give you this. Hold on for a second. Okay, so before we get started, we want to make sure that we can all see this, and we all know this data. So can you all read with me what's up there? P equals 23, G equals 5. We all see that. We all hear all that information is available to everybody. Can we agree on that? Okay, good, because if we couldn't, then I would just have to walk off the stage here. That would be weird. Okay, so Alice and Bob, what I need you to do, I want you guys to both complete step one on your sheets. Actually, step one and two. Can you have any questions? Let me know. What they're doing are complex computations up here in front of a crowd, so very good. Much respect to them. Yep, so you can still read it. Perfect. All right, so Alice, what I would like you to do is complete step number three. Bob, be listening, and you'll do steps four and five. Yep, and I'm going to have you say it out loud. Two. We heard Alice say two. Did everyone hear Alice say two? Perfect. Bob, I'm going to have you do step number three. Alice, you're going to do four and five. 16. 16, Bob said. 16. I really have. I want to do bingo right now. Okay, perfect. Alice and Bob, can you please complete steps six and seven at this time? Okay, does anyone know the key that the two of them arrived at? No one knows. Alice and Bob, can you show your numbers, please? We have a three and we have a three. This has been successful. Thank you, Alice and Bob. Thank you so much. All right, so what we missed, what we witnessed right now was not magic. I don't feel like it, but it was just a key exchange. What we were able to do is publicly broadcast some information while keeping some information secret. And in doing so, they were able to arrive at the same number. So I want to show you how this math works out. And let me get the numbers that they picked. Please don't look ahead. That's cheating. Find the mouse. There we go, okay, perfect. All right, so what happened was that we had these two numbers public. We had P equals 23 and G equals 5. What I asked Alice and Bob to do was pick a number and keep it secret to themselves. We had Alice pick two and Bob picked eight. The numbers that you heard weren't these numbers. They picked two numbers and they kept them to themselves. The only people in the room that knew them were Alice and Bob. They then broadcast a couple different numbers. Alice said two. Bob said 16. The way this works is they apply their secret number to a formula. G raised to A, mod P and Alice got two. It just happens to work out that the number Alice put in was the number Alice got out there. In real crypto, it doesn't work out that way. We just have to use small, easy numbers for the demo. Bob put in A and got 16. Now here's what's really interesting. We broadcast those numbers out. We all heard them and then they could arrive at the same number three. So all you would do is that Alice sorry, Bob here would take the number that Alice said out loud, raise it to the secret number that Bob had, mod P and would get three. What's so fascinating about this is that Alice would do the same thing. Take the number that Bob read out loud, raise it to her secret number A, mod P and get three. The math behind this is pretty complicated. I honestly don't understand it myself a whole lot, but the whole point is we all heard four different numbers out loud. An attacker would hear those numbers when a TLS connection is being established but unless they have those secret numbers, they can also arrive at the secret key. So this is an important principle of us being able to do any type of encryption between two unknown parties that don't have a shared key. This is exactly how it works. And if I can figure out how to do this, I will start my slideshow again. There's a big play button there, wasn't there? I was going for the higher degree of difficulty here, just to get some props from you all. As a good engineer, I was prepared for failure here. I was going to make a hilarious look about the Wi-Fi being bad if we didn't arrive at the same number. Everyone was going to laugh, it was going to be awesome. But I'm glad we didn't have to do that. So the important thing here is that any of these four systems, the authentication mechanism, the integrity mechanism, encryption, key exchange, if any four of those is flawed, your communications are not private. They are susceptible to some sort of attack that can compromise the whole entire system. So you have to get all four of them absolutely correct. So I'm going to go through this last part a little bit quickly because we're running short on time. The way that you configure this, and I'll actually go back to the last slide, is through a thing called cipher suites. Now when you go to configure HTTPS, you have to confront cipher suites. I apologize but you're going to have to deal with this term. Now this is really intimidating. It's very, very scary. But if you understand those four concepts that we just talked about, which those are too scary, right? Those are pretty easy to understand. Cipher suites will make a lot more sense because cipher suites are just a combination of algorithms for authentication, integrity, encryption, and key exchange. We know what those four things are now, right? So we can configure them. We can do that. Well, a HTTPS configuration in Nginx might look something like this. See that big chunk in the middle that says cipher suites? Like that kind of makes your eyes cross and you're like, what am I doing now? It's not that bad. Let's break it down a little bit. An individual cipher suite might look something like this. All these blocks mean, or sorry, all these blocks apply to one of these four key areas. It's just configuring the algorithms that you're going to use for one of those areas. So we start off with ECDHE, which stands for an ephemeral elliptic curve, Diffie-Hellman key exchange. That's all that's configuring is the key exchange, that demo we just did. There's different types of key exchange. This is a really good one. This is what we want to do. RSA, in this case, is an algorithm for certificate signing. This relates to authentication. That's all this means here. RSA, algorithm for certificate signing. We then have AES 128GCM. This is our encryption. We're not using a cipher here. We're not using rot13. We're using AES, which is a good, strong standard. That's all we're saying is that, okay, we want to use this level of encryption for this communication. And then we finally have a message authentication code, which specifies the algorithm we use for checking our integrity. That was really fast, explaining all those individual algorithms is like a whole day's worth of work in and of itself. The point is a cipher suite will just specify those four different areas that we covered before. When you actually configure your cipher suites, it's going to be a big block of mumbo jumbo like this. It's basically like who's encryption to configure your encryption. It just looks like complete nonsense. But again, it's just we have one cipher suite. This is one combination of those four key areas. And then they're separated. Different combinations are separated by a colon. Think of it as like progressive enhancement for like doing CSS or JavaScript. What you want to do is you want to configure different sets of cipher suites so different browsers can be able to connect to your server. Different browsers have different abilities. We can also do things like never let us use RC4, which is a terrible form of encryption. If you see a website that has the green icon like in Chrome, you can click that icon and you're going to get some information about it. So if we zoom in a little bit, you'll see something along these lines. I think this actually just recently changed though. But hopefully this makes a little bit more sense to you now. You know, say that the site is encrypted with modern cryptography. You're using TLS version 1.2. The connection is encrypted and authenticated using AES128 GCM. So this has to do with the encryption piece. It uses the ECDHE RSA as the key exchange mechanism. I think the wording here is a little confusing, but the whole point here is that this relates to those cipher suites and those four main concepts, authentication, integrity, encryption and key exchange. That's what it's telling you about. So what have we talked about today? What have we actually done? This is really confusing stuff. It's really heavy. If you understood authentication, encryption, integrity and key exchange, you're well on your way to understanding and evaluating whether you have a sufficient HTTPS setup or not. So now we're going to fall back on the easy stuff, copying and pasting. I'm going to refer you to this website if you're going to copy and paste because this is a good website to copy and paste from. Mozilla maintains a list of cipher suites that you absolutely want to use when configuring your website. One of the things I really like about them is that they break it down into three different configurations. One is like here is the best TLS configuration you can get. Yeah, you're only going to be able to serve your site to Chrome and Firefox, but if you want really good encryption, there you go. The next one is like compatible. So like reasonably modern browsers will be able to handle it. I think IE down to IE 10 will be able to work. And then it has like super compatibility mode. If you need IE 6 and HTTPS, here you go. It's really insecure, but there you go. So it's a really great guide. I would highly recommend it. So last thing I want to leave you with, if you're interested in this subject, I have sort of a reading list for you and this is an order of kind of your gateway drugs down into like the really hardcore stuff here. So starting at the top you have the code book. The code book is just a really fantastic sort of story about the history of encryption not written towards like academics or anything like that, but it's really a great story starting with the Caesar Cyper explaining how that was used, how that was cracked, and then that led to other advancements in encryption. Really, really good stuff, highly recommend it. Next one is by Ilya Grigorek, high performance browser network. This is my subversive way to get you to read this book. They have a great section on TLS, but this is like probably the number one book that I recommend. Anybody doing anything with the web reads just explains how browsers work essentially, how your CSS becomes pixels on a screen. Really important. Next one is Bulletproof SSL and TLS. This is where things are going to get a little heavy. This is kind of the modern go-to book for TLS and SSL. It's constantly updated via the e-book. This is by Ivan Ristik who runs SSL Labs which has become the gold standard for evaluating your TLS connections. And then finally, SSL and TLS and Oli Bakudi, Eric Rescorla who is part of the team who put together the TLS standard wrote a very dense textbook like an academic textbook on this. So if you're interested, read from top to bottom. Very, very good stuff. So that's all I have for now. Here's my link to my slides. You can get everything on those slides. So yeah, anybody have any questions? I think I have a few minutes for it. What are my thoughts on Let's Encrypt? Let's Encrypt is awesome. So Let's Encrypt is a new certificate authority. Certificate authority is an authority that can issue certificates. Let's Encrypt came out, it just came out of beta and technically people were able to get certificates end of November last year. It gives free certificates to everyone. So one of the big hurdles for HTTPS, a lot of people would say, well, it costs money. So what am I going to be able to do? It was just a lame excuse to not do this because it really was like 10 bucks a year. It's not that much. But now, if that was a problem for you, you have Let's Encrypt. Even better than free certificates worked with the IETF to come up with a new standard, a protocol for certificate management called ACME, which is Automated Certificate Management Environment. There we go. So the ACME protocol, it's basically a protocol around a RESTful API interface for being able to issue certificates. The beauty of this is that any system that wants to could develop an integration with Let's Encrypt so you can automatically integrate certificates into things. So there's new servers. One fun one written in Go is called Caddy server. And it's... Well, when you start up the server, it automatically issues a certificate for your site. You can run WordPress with it. I have never done it myself, but those sorts of integrations are possible. So what's my thoughts on Let's Encrypt? Let's Encrypt. Are there questions? Yes, sir? The question was, is there any way to test a site to see if everything's running right? There absolutely is. If I was doing more of an implementation talk, we would go over that. The site is called ssllabs.com. It looks a little weird because there's two L's, but it's ssllabs.com. This is the gold standard. So you configure your site for HTTPS. You go run it through there. If it's not at an A, go fix it. No excuses. I don't want to hear them. Go fix it. It's really good, really well tuned. It's the product that sslpulse uses to assess security. The author of the third book there is the one who built this. They have a lot of details about how you can fix things. If you are hosting with somebody else and they provide the HTTPS for you, run your site through that. If it is not perfect, talk to them. It needs to be an A. You can only get an A plus if you do something extra. Don't worry about that too much. If it's not an A, talk to your host and don't accept no for an answer. They need to do better. If you need someone to help with the technical things about explain, email me. I will help fight that battle for you because there's no excuse for them not doing that well. Absolutely no excuse. Do I have any recommendations for plugins that relate to TLS and HTTPS in WordPress? So there's a lot of work going on in WordPress core to make these HTTPS transitions easier so automatically updating links from HTTP to HTTPS. We didn't go into this but when you are serving your site via HTTPS you need to make sure that all the assets that you serve with your site are also HTTPS otherwise you're going to get mixed content errors. There's a lot of work going on in WordPress right now to fix that. There's a few plugins that work with that. I don't actually know the names of them offhand because I usually do this work manually through a lot of search and replace or filters on the content to be able to switch HTTPS to HTTPS. I have a plugin myself that helps raise those mixed content errors. It's called HTTPS mixed content detector. Very good SEO on that one. Yes. That's all. One last question. One last question. What's the difference between a $10 SSL certificate and $100 certificate or $0. $10 and $100 and $0. That really is the difference. If it's from a good CA and a good CA is basically one that you just have to sort of trust that they're good, that they haven't had any sort of break-ins that people are able to issue a certificate as you from that certificate authority really what it comes down to quite honestly is marketing. There's a lot of kind of fun around this trying to scare people into thinking you need, if you buy the $150 certificate it's going to be $150 better. Let's Encrypt is here. It's going to make it really hard to sell those tickets so we get over that cost barrier. It's okay though like if a host is trying to charge you some money to implement it initially that's a different thing. There's labor, there's work there, but the certificate itself should be free at this point. That's it.