Https
From Computer Tyme Support Wiki
(→How Encryption Works) |
(→How Authentication Works) |
||
| Line 35: | Line 35: | ||
=== How Authentication Works === | === How Authentication Works === | ||
| + | |||
| + | Authentication is the other leg of the HTTPS security protocol. Authentication helps ensure that when you connect to a site using HTTPS that it is really the site you are connected to. Using certificates and certificate chains your web browser (is supposed to) verify that you are actually connected to the web site you think you are connecting to. This makes it much harder for someone to impersonate your bank to steal your passwords. A detailed explanation of this process is complicated so I will try to make the important concepts as easy as possible. | ||
| + | |||
| + | When you connect through HTTPS it established an encrypted connection. It sends the sites certificate which was generated in unison with your '''certificate authority''' who validates your certificate. The web server not only sends your certificate, but also the chain of certificates leading back to the '''root certificates''' which are highly trusted certs that came with your browser. Using these certificates one can verify that the cert is authentic and can be trusted. You then see the green padlock and all is good. | ||
| + | |||
| + | ==== The down side of Authentication ==== | ||
| + | |||
| + | There is one step however that exposes your privacy. In order to fully verify the cert the web browser has to check to see if your certificate has been revoked. To check if the cert was revoked your browser has to ask the certificate authority through a "revocation request" if the cert is still valid. The reason for this is, if I'm running a web site and my private keys make it into the wild, hacker or government can decrypt your connection and steal your data. So if I'm a bank and I fire the head admin, I might want to change my keys by revoking my cert and getting a new one. | ||
Revision as of 03:35, 28 February 2018
Contents |
Why HTTPS everywhere is a really really bad idea
Introduction
HTTPS Everywhere sounds like a good idea, but as they say, the devil is in the details. The idea, supported primarily by the Electronic Frontier Foundation (eff.org) is to get all traffic on the internet to be encrypted. If everything is encrypted, as promoted, then no one can tap in and spy on your communication. This includes NSA spying and other government spying that is both illegal and immoral where third parties and government track you to create a digital profile of who you are that can be used against you, profile you, steal your passwords, invade your privacy, blackmail you, and round you up to put you and your freinds and family in concentration camps. Imaging if you will what would have happened if Adolf Hitler had today's technology. There would be no Jews left hiding in attics!
And as we know from the revelation of Edward Snowden, my second favorite person in the world after Elon Musk, we know the government is actually doing a lot of the things that the EFF is paranoid about. Snowden confirmed what all paranoid schizophrenics new was true all along, the government(s) is spying on them. The nightmare, as it turns out, is actually real.
So on it's face it would seem as if making it harder for these problems to occur would be a great idea. And - quite frankly, if it were done right it would be a great idea that I would support. However, the way it is being implemented through "Let's Encrypt" (letsencrypt.org) and Google strong arming the public to force everyone into it. By doing it wrong EFF's good intentions are actually making the problem worse. Forcing encryption on everyone, as it is being implemented, creates more problems than it solves and will inhibit freedom and privacy, not enhance it. Rather than making it harder for the NSA to track you, it makes it easier. Rather than enhancing free speech, it inhibits free speech, and rather that making the internet safer from criminals, it actually reduces internet security making it easier for the bad guys to take advantage of you.
As someone who used to work for EFF as their first full time system administrator you would think I would be on EFF's side on this. And over the years there have been a number of issues EFF has got wrong. But this is a very serious issue that will negatively affect the entire internet and have a huge negative impact on EFF if they are successful in what they are trying to do. EFF sometimes has a habit of latching onto an idea like a bulldog without carefully thinking things through and is sometimes cult like in their opinion in spite of evidence that their position fails to make objective sense. I still support EFF as no organization is perfect and they get it right most of the time. But this time is not one of them.
Encryption / Authentication - Understanding the Basics
HTTPS has 2 separate function, not one, that are artificially bound together into the HTTPS standards. These 2 functions are:
- Encryption - making the data unreadable to 3rd parties
- Authentication - making sure that the website you connect to is actually the real web site.
And it is because of the binding together of there to unrelated functions that cause the problem. If these two protocols were unbundled, where you could have encryption without authentication, then my objections to encrypting everything goes away. The encrypting side is the easy part, the authenticating side is the part that is hard and expensive and causes all the problems. All this could be easily solved by allowing encryption without authentication. But modern browsers do not allow self signed certificates without dire warnings that would scare the average person to back away immediately. If they changed that it would solve the issues that I'm about to describe.
How Encryption Works
The actual process is long and complicated so I'm going to limit my explanation to the simple stuff you need to know. Encryption relies on a pair of keys, both keys are very large numbers. If you encrypt a message with one key you can only decrypt it with the other key. It doesn't matter which key you encrypt with as long as you use the other one to decrypt.
One of the keys is know as the public key, and the other is know as the private key. As the names imply, one key you make public, the other key you keep private. When someone wants to establish a secure connection with you they download your public key which is furnished by opening a connection. When you get the public key you can then encrypt a message that can only be read by the server which is usually a set of new keys to establish a secure connection. Because only the other end can read it you then have the keys to establish a secure connection that no person in the middle can break into.
Vulnerabilities
The encryption used in HTTPS is pretty good. It isn't easily broken. One of the main vulnerabilities is what's called a "man in the middle" attack. The attack isn't generally easy to do and usually requires hardware access to be in the middle of that connection which very few people have. However, when I used to fly more often I used to provide a free wifi access point using my cell phone to allow other travelers around me to access the internet without paying high fees. But if a were nefarious and evil I could create a fake certificate pretending to be their bank and steal their passwords. And I would need a fake cert for every domain I wanted to steal. Someone smarter than me could accomplish this.
To make sure this doesn't happen we use authentication so that only the real certificate works. the real certificate is varified by the certificate authority issuing the certificate as real so if you are connecting to your bank, you can be (somewhat) confident there's no one in the middle stealing your information.
There are other ways you're vulnerable. You could have someone looking over your shoulder when typing your username and password. You could have spyware on your computer that is logging your keystrokes and grabbing the display text on your web pages. Or the site you are logging into has been hacked. Remember Equifax? It was an encrypted site. And while your data was being stolen it was sent to the hackers over an encrypted connection.
How Authentication Works
Authentication is the other leg of the HTTPS security protocol. Authentication helps ensure that when you connect to a site using HTTPS that it is really the site you are connected to. Using certificates and certificate chains your web browser (is supposed to) verify that you are actually connected to the web site you think you are connecting to. This makes it much harder for someone to impersonate your bank to steal your passwords. A detailed explanation of this process is complicated so I will try to make the important concepts as easy as possible.
When you connect through HTTPS it established an encrypted connection. It sends the sites certificate which was generated in unison with your certificate authority who validates your certificate. The web server not only sends your certificate, but also the chain of certificates leading back to the root certificates which are highly trusted certs that came with your browser. Using these certificates one can verify that the cert is authentic and can be trusted. You then see the green padlock and all is good.
The down side of Authentication
There is one step however that exposes your privacy. In order to fully verify the cert the web browser has to check to see if your certificate has been revoked. To check if the cert was revoked your browser has to ask the certificate authority through a "revocation request" if the cert is still valid. The reason for this is, if I'm running a web site and my private keys make it into the wild, hacker or government can decrypt your connection and steal your data. So if I'm a bank and I fire the head admin, I might want to change my keys by revoking my cert and getting a new one.
