Transcript from the "HTTPS" Lesson
>> Jem Young: HTTPS, we had a long session on security, but what is HTTPS? Why do we need it? We touched on it a little bit. Sam?
>> Speaker 2: It's SSL over, or secure sockets layer, over HTTPS.
>> Jem Young: Exactly.
>> Speaker 2: Over HTTP.
>> Jem Young: And why we need it though?
>> Speaker 2: So that anybody and their dog can't inspect the traffic between you and the server?
>> Jem Young: That's exactly right. It's kind of wild to think that in the olden days of not that long ago I literally could just set up a fake router or I could just tap into your phone line and intercept all of the data that's coming and going and it was totally unencrypted.
[00:00:44] It's the equivalent of me yelling across the room, what my data is. And if someone just happens to be in earshot of that, they know exactly what I'm doing. And this is the way the Internet used to work. Fortunately now, thanks to persistence of a lot of the tech companies and mainly browsers, we all use HTTPS now.
[00:01:03] And that's one of the things that, again, it's fascinating that the Internet keeps working the way it does. And we keep pushing these new protocols and standards forward, even though there's no one entity that saying how we should operate. But HTTPS, what it does is it encrypts all the data in transit.
[00:01:18] In the old days and current days with HTTP, if I was going to frontendmasters.com put in my credit card information, it'd be in plain text. I could just intercept that packet and read it. And I can even pass it along back to frontendmasters, so that they wouldn't even know or you wouldn't even know that your data is being sniffed and stolen.
[00:01:36] In fact, they can keep doing that for years and people did that. And people were like, why is it when I use this website, about a month later my credit card gets stolen mysteriously? And it's because people were sitting in the middle and intercepting requests. And those are probably the most nefarious kinds of attackers, the ones that don't let you know that they're doing anything.
[00:01:54] You just sort of start the seeing things go wrong here in there. But now so what it use to be another benefit of HTTP was, or a down side of HTTP was you couldn't guarantee who you were talking to. For instance, we talked earlier about if I let my domain expire and someone picks it up really quickly which they tend to do.
[00:02:16] I can now create jemyoung.com or frontendmasters.com if let it drop and you have no proof that this isn't the person you were talking to before. Because most people don't, you're not checking IP addresses. Most people are never gonna check out IP addresses. You're just gonna check that domain name.
[00:02:31] And I think it's really interesting that the Internet used to be like this. You used to be able to do all these things. If Google let its domain expire, I can just be, like, I'm now Google. Yeah, go ahead and log in. You can't log in? Wow, just keep trying.
[00:02:45] Keep entering all your credentials. And we'd just say, the Internet's broken or something like that. Because I'm clearly on google.com and there's no way of verifying that. But HTTPS not only encrypts things in transport, it says, hey, the person you're talking to is guaranteed that you're talking to them and we guarantee it.
[00:03:05] Now who guarantees that? It's something called certificate authorities. Again, the Internet is built on trust and certificate authorities are trusted authorities that validate you are who you say you are. Does that any questions on that so far? Cuz we're gonna keep going on HTTPS. Is anybody shocked that the Internet used to be this way and now it's getting better?
[00:03:26] And I think if the next generation will say, wait, the Internet was like this. That was, wow, it was just like the wild west of people shooting guns left and right. And I'll be like, yeah, pretty much. It was anything goes back in the day. Fortunately now, with HTTPS, you can't sniff that traffic.
[00:03:42] It's encrypted on the clients and decrypted on the server. So it's that public key authentication again. It's not SSH, but think of it similarly where the client has a key and a certificate that it gets from the server. So the first time I connect the frontendmasters.com, they say, okay, you've never been here before.
[00:04:01] Here's my public certificate verifying who I am. And here's how to encrypt all that data. So I use that public certificate to encrypt all the data, and then I send it down the frontendmasters.com or your server, and anything between is just jibberish. It's just encrypted data. The only one who can decrypt it is Frontend Masters because they hold that private key.
[00:04:19] And your server holds a private key. So no one in between can encrypt it. Funny enough, and this makes me really suspicious of the government, they were not against HTTPS. Generally, when it comes to encryption, the government is against all of it, because they can't read your data anymore, but they don't really have beef with HTTPS.
[00:04:35] Which makes me really suspicious, that's totally a tangent and not related to this course. But, what happens is now, if you're like I have HTTPS everything's secure everything's hunky dory. We're good, we're never have to worry about security again. This all depends on those certificate authorities. So if when I registered my domain, I say, hey Mrs. security certificate authority, I'm Jem Young and I'm going to register jemyoung.com.
[00:05:01] They're like, how do we know you are who you say you are? And you go through a series of authentication steps and you're like, okay, yeah, this this person is trustworthy. We're gonna put our stamp on it that verifies it. And if we go to our browser, we can actually check out the certificate authorities.
[00:05:17] Let's try, what's a random website, let's say Google, it's an easy one, Google.com. And I can look here, I say connection is secure, I can look at the certificate. We can dig in that certificate a bit more.
>> Jem Young: And it has a bunch of information about who the authority is, like how do we know these people are who they say they are.
[00:05:41] There are different levels of certificates. The more expensive ones where you see the full, this site is verified by that it's actually google.com, are the more expensive ones. That's not the kind we're gonna implement today. Those tend to cost a bit more money, we're gonna implement a free one in a second, which should be pretty fun.
[00:05:58] But it tells you all about the algorithm that's encrypting that data. Some are more secure than others. So here's a, yes?
>> Speaker 2: It's elliptic curve public key, and that's the NSA has known vulnerabilities.
>> Jem Young: As far as we know. And if they did, would they tell us?
>> Speaker 2: No, they've already-
>> Jem Young: They've proven it?
>> Speaker 2: It's known, that's why the government hunky dory with SSL.
>> Jem Young: Yeah, well, yeah, man I should do a section on cryptography. Now I to be honest, I am not qualified to talk about cryptography, most people are not unless you're a mathematician. But the rule on cryptography and things like that, don't roll your own, you're not smart enough.
[00:06:39] [LAUGH] I don't mean that to be mean. If you roll your own crypto, you're gonna be in trouble. That's why we have these known algorithms that you can only use for HTTPS. You can't just, I'm gonna create Jem's hashing algorithm and then serve that out. That doesn't work.
[00:06:54] You have to use a known standard that everybody agrees on. But speaking of cryptography and encrypting things, what's the downside of using like, instead of 256 bits for the key, say using 1024 or 248? Yes, here?
>> Speaker 3: More bytes, more data, it's slower.
>> Jem Young: Yeah, it's slower. You're theoretically more secure.
[00:07:16] But there's a point of diminishing returns where you're like my data is ultra secure, but it now takes longer and all these things add up over time. These are microseconds, nanoseconds, but if you use a giant key and it hashes, the client has to decrypt that, the server has to decrypt that too.
[00:07:31] Weird facts, when we converted Netflix over to HTTPS, it costs us a few million dollars in compute time, because all that cryptography of decrypting and encrypting, decrypting and encrypting, that cost CPU time. And when you're talking about trillions of requests, that adds up really quickly. So that's why HTTPS was really slow to roll it out.
[00:07:53] The reason why it has rolled out successfully today is because browsers made us. They started shaming people now where if it's not encrypted there's like a big like slash or the lock sign or something like that because they want to encourage people to use HTTPS because it's just a better way of doing things.
[00:08:09] In fact you can't use a service workers web bluetooth, web secure payments things like that without HTTPS. And that's just like a little nudge by the browsers, hey if you want to use the latest features, you better upgrade your system.