UNITED STATES 
DEFENSIVE COMPUTING
By Michael Horowitz, Computerworld
APR 14, 2013 12:35 PM PST
About 
Defensive Computing is for people who
use computing devices for work, not play.
Rather than focus on the latest news or
devices, this blog aims to be educational.
Heavy on facts, light on opinions.
OPINION
Steve Gibson's Fingerprint service detects SSL man in the middle spying
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.
[ Related: Online privacy: Best browsers, settings, and tips ]
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 manin-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.
ACTUAL DEVICES
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.
How much vetting do CAs do when someone applies for a digital certificate? Not much
necessarily, (see here and here) but that's another topic.
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 ..."
FINGERPRINTING
Page 1 of 2
▻
Bing’s AI chatbot came to work for me. I had to fire it.
SHOP TECH PRODUCTS AT AMAZON
SPONSORED LINKS
dtSearch® - INSTANTLY SEARCH TERABYTES of files, emails, databases, web data. 25+ search
types; Win/Lin/Mac SDK; hundreds of reviews; full evaluations
There's a new hybrid cloud agenda. HPE has the playbook for success. Learn more here.
Copyright © 2023 IDG Communications, Inc.