Secure Digital Life #78
Recorded on September 4, 2018 at G-Unit Studios in Rhode Island!
- Check out our On-Demand material! Some of our previously recorded webcasts are now available On-Demand at: securityweekly.com/ondemand.
- DerbyCon is holding its first-ever Mental Health & Wellness Workshop - to help support their efforts, please go to https://www.derbycon.com/wellness
Topic: Understanding SSL and HTTPS
Ok, so, let's talk about crypto a bit. Crypto is one of those topics everyone can't wait to get to until they get to it and then they run like hell because, you know, maths.
But that's ok, we don't have to do a lot of math to understand some basics of crypto. So, if you think about crypto, there have been weird crypto things going on for thousands of years. I mean the romans used all sorts of tricky things to create cipher keys (like rods and alphabetic shifts) and in the time when a lot of soldiers were probably illiterate or at least not skilled enough with writing to figure out a cipher, this was probably sufficient.
In the old days, most focus was on what are called symmetric keys. These are basically the idea that if I tell you, "a == 7; b == 10; c == 45" and we share that information, then you can decrypt what I encrypt and vice versa. A classic symmetric key schema was to use a book so say Moby Dick 4th edition or something. If we use additional schemes like start on page 40 and turn a page every day. The first 26 letters of the first paragraph are the alphabet and duplicates skip to the next paragraph. That would let people who knew the code, decrypt and encipher things to each other. This type of thing leads to what are called one time pad ciphers. They used to make large sheets of ciphers that were handed out to spies and such and you only used each cipher page one time. Those are hard to break since the code keeps changing.
The problem with symmetric keys. If the key scheme becomes known, the whole thing is worthless. Truthfully, there is nothing wrong with symmetric keys in computing but the problem starts with how do you share the key. Now, in the old days (not that old) we had symmetric session keys that were on a plastic card. That key was use once and burn (so a symmetric one time pad). Works, fine, the key is used to encipher the communications and Bob's your Uncle. Those keys were all shipped "out of band" between the users and as such were pretty safe. They were one time pads, so they didn't get reused. The problem starts because, what if you have a large number of users? Well, that gets expensive. Still, there are a lot of these algorithms in use. AES, 3DES, etc. are symmetric key encryption schemes.
Enter the asymmetric key. This is pretty trick and is based on math. A one way algorithm is used with two different keys, a public key, and a private key. If something is enciphered using the public key, ONLY the private key can decipher it and it works in reverse too so if you encipher with the private key, only the public key can decipher (this is called non repudiation or a digital signature). Basically, you can then give the public key to anyone and they can use it to send you things that are encrypted. So, if you and I wanted to exchange emails and we each have the others public key, I encrypted with your public and you encrypt with my public and we each have a private key only we know. RSA, ElGamal, etc. are asymmetric keying schemes.
But there is still a problem. This kind of thing is kind of slow if we have to encrypt a lot of stuff. Symmetric keys are faster to use but harder to manage. Thus, what is called a hybrid key is established. Basically, in these hybrid keys, an asymmetric key pair is used to send a private key to the other end for that session. The private key is then used to encrypt the symmetric session between the two parties.
How is all this implemented? Well, this leads around to the idea of digital certificates. Understand this is a whole course in most programs, so we are just giving you the basics. A certificate is typically a public key that is signed by a private key. So, when you connect using something like HTTPS or SSL, the server sends you the certificate which is digitally signed using that private key. You can then "trust" the certificate (if you do). This public key can then be used to exchange private key information (symmetric) between the user and the server and as such a session that is encrypted begins.
Certificates are create by "trust authorities". So, if you want one, you have to buy it or get it issued from someone who is a the high level trust authority that people would trust. The Certificate Authority (CA) is supposedly trusted by everyone so let's say Microsoft. So, if you see certificate that is validated by Microsoft, that is trusted? Well, it's up to you. There are a lot of CAs out there. You can also just sign your own. If you sign your own certificate, then you basically are saying that you trust it. Will anyone else trust it? I don't know. But for internal use, that works pretty well and it's cheaper. But if you have unknown users, they may not be too happy when the browser says "don't trust this site" and go away. Modern browsers all assess sites now and if you don't have a "valid" certificate you get a warning. This doesn't mean the site is bad, but it means you better know who you are talking with. Likewise a "safe" site may not be valid either. Google decides which CAs are valid and which are not. Typically, that means that certificate are issued with some sort of validation in place to ensure that the site is what it says it is. For the most part, this is pretty reasonable.
So, an example: If I own the domain edgeofforever.com, I can buy a certificate from some CA that says that edgeofforever.com is legitimate and they will ask me for id and such. Understand, that is the end of the legitimacy right there. All that means is that the CA says that edgeofforever.com has a certificate, that doesn't mean that edgeofforever.com is safe from malware, etc. just that the certificate is valid. That certificate will be used to create the hybrid session for you so that all your traffic on that site will be encrypted between you and the other end.
Again, once your data is there, what happens to it is just like what happens on your end. Anything goes. But in between, the valid cert will be used.
So, how does HTTPS work then? Originally, all the web stuff was in HTTP. That's a layer 7 protocol which is sent in the clear. So, anyone between you and the other end that is listening (sniffing) could just grab the packets and look at them. So, let's say you are uploading photos of yourself to your manager's server. If I was sitting somewhere in between you and the server, I could just sniff for packets going to 188.8.131.52 port 80 and then sort them out by their sequence numbers and reassemble the picture. Voila' I just "hacked" your data and stole your photo.
If we use HTTPS instead, what happens is this regular old HTTP clear data is encrypted instead. First, the server sends its certificate to you and your browser validates that the name on the cert is the same as the domain on the site. Then that public/private asymmetric key pair is used to exchange a one time private key that will be used to encipher all the data on the stream. Now, the sniffer gets an encrypted set of packets. Can they broken, well sure, but now it takes a major effort to get to the data.
Today, most all webservers use HTTPS and certificates to validate themselves from trusted CAs.
- If you don't see the padlock in the browser, that's big warning.
- If you don't see https, I wouldn't use the site if you are sending anything to them.
- You can use sites with self signed certs but only if you know them. Otherwise I would avoid.
- I would avoid sites with invalid or broken certificates (view only with something safe ioisearch.com or tor and even then maybe on a vm.)