We have all heard over and over again that secure web pages are safe. They are encrypted using SSL and HTTPS such that the contents of the pages are confidential. But, just because data is encrypted, that doesn't mean that it can't be spied on.
Needless to say, malicious software, typically on a Windows computer, can see passwords before they get encrypted by the web browser. A newer approach - infecting the web browser itself - is far worse. The browser sees everything coming and going, making it the perfect spy. Read a few articles about man in the browser attacks and you may never do online banking again (here's one story and another).
But even without malicious software (yes iPad users, you should pay attention too), HTTPS encrypted web pages can be spied on, without breaking the encryption. Using a man-in-the-middle (MITM) attack, spies place themselves between the victim and the secure website.
The victim thinks they are talking to the secure website but they are actually talking to a spy computer/device that is intercepting their transmissions. Encrypted data leaves the victims computer, but the intercepting spy machine gets to decrypt it just as the real website would have.
What does the intercepting spy computer do with the victim's web pages and data? Whatever it wants to. For the attack to succeed, however, it will send the data, unchanged, to the target website. Most likely, everything coming and going gets logged for later review. That is the whole idea, after all.
Both sides of the secure SSL/HTTPS connection get lied to. The website thinks it is talking directly to the victim, but it is actually communicating with the intercepting spy machine pretending to be the victim. All the encryption in the world doesn't help if you are not communicating with the entity you think you are.
Seth Shoen of the EFF describes the situation:
For an effective defense, users cannot rely on their intuitions derived from a site’s appearance, content, or behavior; during a successful attack, a user is communicating indirectly with the genuine site and so its contents and behavior typically appear completely genuine. Since the man-in-the-middle can forward all communications back and forth, the web site appears authentic to the Internet user, and vice versa.
In other words, secure web pages are a scam.
Man in the middle attacks succeed, in large part, because you can lie to people that don't fully understand the technology. But, even those that understand it had no easy way to detect it. Now, thanks to Steve Gibson, we have a new service that should expose man-in-the-middle attacks.
Sometimes this type of spying is done with full disclosure. A large corporation, for example, may set rules for behavior on their network using their computers by their employees. They disclose these rules and the fact that data traffic is monitored to enforce the rules. Fair enough.
But the spying can also be done without disclosure. In that case, the spy computer is likely to be installed on the network of victims Internet Service Provider. If you are, for example, a Comcast customer, anything leaving your house/office first goes through Comcasts internal network before going out onto the Internet.
Recently there was a troubling story about Comcast modifying web pages in transit to warn customers approaching bandwidth limits. The point being, an ISP is already in the middle.
This wasn't supposed to happen. The original design of SSL included provisions for insuring that you were actually connected to the website you think you are connected to. Most of the time, this authentication scheme works. But because it is not well understood and not all that well designed, it can be subverted.
In describing his new Fingerprinting service, Gibson refers to the intercepting spy devices as "HTTPS Proxy Appliances". I have also seen them referred to as "SSL/TLS interception proxies" (TLS is a newer version of the SSL protocol).*
Gibson offers two examples of SSL/HTTPS interception. One company, Blue Coat Systems sells a "secure web gateway" that offers "inspection and validation of SSL traffic". He also cites Microsoft's "Forefront Threat Management Gateway" which offers "HTTPS Inspection."
Another company offering SSL interception is Packet Forensics. As of 2011, they were selling a four square inch device they claimed could be configured and installed in under five minutes. After some undesirable publicity, their website now says
"If you are a governmental or defense organization, please contact us to learn more about our defense and intelligence applications and hardware platforms. Information about these products is not made available to the public."
During their bad publicity, a company spokesman for Packet Forensics said there was nothing special or unique about their product. Scary.
To understand exactly what Gibson's Fingerprinting service does, we have to start at the beginning.
IP ADDRESSES AND DNS
How does any computing device (tablet, smartphone, desktop computer) find a website?
Computers on the Internet are assigned unique numbers. When two computers communicate over the Internet they recognize each other by these unique numbers, called IP addresses. When a computer is looking for somebank.com, for example, the first thing it has to do is find the number (IP address) of the server computer running the website that is somebank.com. Only after it has this number can it open a channel to the remote websites server.
The system that translates from names (somebank.com) to numbers (IP addresses) is called the Domain Name System (DNS).
DNS is an amazing system that has endured well for many years. But, like the Internet itself, it was not designed with security in mind and that leaves it vulnerable to multiple types of attack. If something goes wrong with DNS, your web browser might say you are at the somebank.com website when you are really looking at a copy of the site constructed by an organized crime gang.
If DNS were rock-solid and resistant to attack, then there would be no need for an external authentication system. But DNS can be attacked both in your computer or in your router, either from the local area network (LAN) side or from the wide area network (WAN), that is the Internet, side. Alternatively, the DNS server run by your ISP can also be attacked or mis-configured.
DNS attacks aim to either change the DNS server computer you reference for translation services, or, they try to poison a DNS server into providing wrong answers. A malicious DNS server might say something akin to "That somebank.com website that was in Virginia yesterday on computer number 1234, well it moved. Now it is in Latvia on computer number 5678. That's my story and I'm sticking to it".
On top of this, there was another system before DNS for translating computer names into IP addresses. Some operating systems still look at this ancient (hosts file) system before making DNS queries. That system too, can be compromised to cough up malicious name to number translations.
Since DNS and the hosts file are under-the-hood plumbing, tampering can easily go undetected. What to do?
*For whatever reason, the older SSL and the newer TLS are both referred to as SSL. This is just as inaccurate as calling copiers from other companies Xerox machines.
Back in 1994, the now-defunct Netscape came up with a scheme called SSL that provided both encryption for web pages and an assurance that you are really at the website you think you are. SSL was, and is, a really big deal. It's what underlies the HTTPS protocol that sends us encrypted web pages.
The trust in the identity of the website does not come from its IP address, it comes from a file called a digital certificate. Anyone who wants to offer authenticated and encrypted web pages needs to pay for a digital certificate file.
The file gets installed on the server computer running the website, and, thereafter when people make HTTPS requests for pages on the site, the certificate file is sent to the web browser along with the web page.
Basically, the certificate file vouches for the website's identity. A "valid" certificate is what results in the lock icon (shown below) indicating an encrypted HTTPS page.
But who vouches for the certificate file?
A bunch of companies most people have never heard of, that's who. Companies like Cybertrust, GeoTrust, A-Trust, S-TRUST, AffirmTrust, SecureTrust, USERTrust, AddTrust, Entrust, TURKTRUST, Trustwave, Chunghwa Telecom, Deutsche Telekom, Government Root Certification Authority (Taiwan), Hongkong Post Office, Comodo, VeriSign, GlobalSign, DigiCert and Thawte, among others.
Companies that sell digital certificate files are referred to as Certificate Authorities, or CA for short. Basically, they sell trust. Your web browser believes that you are really at the somebank.com website because it trusts a group of Certificate Authorities and one of them vouched for the site.
How many Certificate Authorities do our computers trust?
Back in 2010, freelance writer Ms. Smith (not her real name) reported that Microsoft trusted 264 different Certificate Authorities, while Apple trusted 166 and Firefox trusted 144. The Electronic Frontier Foundation's SSL Observatory project found roughly 650 organizations functioning as Certificate Authorities.
The counting is complicated because CAs are often associated with resellers (a.k.a. secondary authorities or subCAs) that act in their behalf. You can see Mozilla's list of trusted CAs here. Below is a screen shot from a Windows 7 machine showing some of the Certificate Authorities Microsoft has chosen to trust.
Who vouches for the Certificate Authorities? Where does the buck stop?
Ultimately it is the web browser that decides whether or not to trust identity assertions made by a Certificate Authority. Thus, the ultimate arbiters are the software companies that make browsers: Microsoft, Mozilla, Google, Opera and Apple.
Back in February 2012, Mozilla was none too happy with something Trustwave did and was considering removing them from all Mozilla software. Note that Mozilla's decision is theirs alone. Apple, Microsoft, Opera and Google make their own trust decisions.
Earlier this year Microsoft, Mozilla, Opera and Chrome took steps to revoke trust from an unauthorized digital certificate. Apple? Not so much.
Devices such as routers often use SSL and HTTPS for the encryption they provide, but skimp on the authentication. That is, they vouch for their own digital certificates. This is known as "self-signing" and always raises a browser warning.
Should Chrome run across a web page tied to an untrusted Certificate Authority, it displays the following error surrounded by a sea of red.
In the same situation, this is the Firefox warning.
Most web browsers make it fairly easy to see which Certificate Authority has vouched for a secure web page. For example, with Firefox running on Windows, just clicking on the lock icon can reveal that VeriSign vouches for the Bank of America.
Seeing the same data in Chrome requires two clicks, first on the lock icon, then on the word "Connection". Doing so while logging in to Barnes and Noble shows that "Akamai Subordinate CA 3" vouches for the bookseller.
But, is this right? That is, has Barnes and Noble contracted with Akamai for their digital certificates?
None of your business.
A huge (in my opinion) flaw with the architecture surrounding digital certificates is that it is impossible to know which Certificate Authority any given organization has contracted with for their certificates. Making this worse, is that any Certificate Authority can issue digital certificates to anyone. Nothing prevents 22 different Certificate Authorities from all issuing certificates for somebank.com.
So, unless your sister works in the IT department at the Bank of America, there is no way to know whether their digital certificates are supposed to come from VeriSign or not.
In another wrinkle, suppose you visited somebank.com hundreds of times and each time you were given a digital certificate file certified by Comodo, a relatively large Certificate Authority. Then, one day, you go to a coffee shop and use their compromised Wi-Fi network and end up with a somebank.com certificate from the Hongkong Post Office. No problem. Your web browser will happily and silently trust it, if the Hongkong Post Office is on the list of trusted Certificate Authorities (it is for Firefox, I'm not sure of other browsers).
Why is there no intelligence built into the system that looks out for this sort of thing? I use a secure FTP program for maintaining web sites and the program issues huge warnings when the certificate vouching for the remote server changes. According to Seth Schoen of the Electronic Frontier Foundation (EFF)
" ... a major priority for web browser developers since this infrastructure was introduced by the Netscape Corporation in 1994 was to reassure users that it was safe to use their credit cards to shop online -- and, correspondingly, to hide the complexity of the cryptography from the user. Thus, browsers chose to accept digital certificates absolutely and unquestioningly ..."