MESSAGE
| DATE | 2015-11-09 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [Hangout-NYLXS] Browser security and EFF
|
https://www.eff.org/deeplinks/2014/02/websites-hsts
April 4, 2014 | By Jeremy Gillula
Websites Must Use HSTS in Order to Be Secure
You would think that by now the Internet would have grown up enough that
things like online banking, email, or government websites would rely on
thoroughly engineered security to make sure your data isn't intercepted
by attackers. Unfortunately when it comes to the vast majority of
websites on the Internet, that assumption would be dead wrong. That's
because most websites don't yet support a standard called HSTS—HTTPS
Strict Transport Security.1
Why is lack of HSTS even an issue? To see what could go wrong, imagine
the following common scenario. You're in a coffee shop and you want to
check your bank account. You pop open your laptop, connect to the free
wifi, load up your web browser, and type in your bank's URL. No security
alerts pop up when you load the page, and there's even a padlock icon
next to the address, so you go ahead and login. Unfortunately, you could
very well have just sent your login information to a potential attacker.
The way the attack worked is as follows. When your browser first tried
to contact the bank's server and load its homepage via HTTP, the
attacker intercepted the request to connect and prevented it from
getting there (perhaps by having his laptop pretend to be that free wifi
hot-spot). He then sent your request to the bank's server himself. When
he got the response back (i.e. the webpage to load, the images to
display, etc.) he stripped out any links that would initiate a secure
HTTPS connection, modified the page so that it would show the padlock
icon next to the address (by setting a padlock as the favicon), and sent
it back to your laptop. Of course these kinds of attacks have been
automated. The result is a page that looks identical in your web
browser—the only difference is that it's not secured, and the attacker
can read everything you send to the server and everything that gets sent
back.
A secure and an insecure connection in IE 11. Can you tell the difference?
But why couldn't your browser detect the attack? The problem is that
modern browsers display prominent security alerts only when a website's
security credentials appear suspicious—if a website connects over a
secure channel and everything appears OK nothing much happens, and the
same is true if the website connects over a normal, insecure channel.
Without HSTS, browsers have no way of knowing that a website should be
delivered securely, and so cannot alert you when a website that ought to
be loaded securely (e.g. your bank's website) is instead loaded via a
normal connection (i.e. the unencrypted version the attacker sends to
you instead). HSTS fixes that by allowing servers to send a message to
the browser saying "Hey! Connections to me should be encrypted!" and
allowing browsers to understand and act on that message.
So why haven't more websites enabled HSTS? The biggest reason, we fear,
is that web developers just don't know about it.2 Another problem is
that support for HSTS in browsers has been incomplete: only Chrome,
Firefox, and Opera have had HSTS support for a significant period. This
is changing though: we noticed that Apple quietly added HSTS support to
Safari in OS X 10.9. For now, Internet Explorer doesn't support
HSTS—which means that there's basically no such thing as a secure
website in IE.
In response to questions from EFF about this situation, a Microsoft
spokesperson told EFF that the company would now commit to supporting
HSTS in the next major release of Internet Explorer (we aren't sure
whether we have persuaded Microsoft to implement HSTS sooner, though
that seems quite likely, and is great news). This means that with the
next major release of IE, every major browser will support properly
secured websites.
In the mean time, what can users do to make sure their connections are
secure? One option would be to use EFF's HTTPS Everywhere browser
extension. HTTPS Everywhere automatically tells your browser to use
secured connections on many (but not all) websites that support them; on
many domains it functions like a client-initiated equivalent of the
serverside HSTS mechanism.
But what if you're stuck using a browser that doesn't support HSTS or
HTTPS Everywhere, or a website that doesn't support HSTS? For now all a
savvy user can do is to always carefully examine the address of the site
you've loaded, and verify that it's secure by checking to make sure it
has "https" in the front and is the precise address you want to visit.
Unfortunately this assumes that you know ahead of time (and remember)
whether or not a site should be secure, and are meticulous with every
website you visit. This is obviously a huge burden to place on users—it
makes a lot more sense to automate the process via HSTS, and it's about
time website operators the world over picked up the slack and did so.
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/ |
|
