[BreachExchange] HTTPS is not a magic bullet for Web security

[Audrey McNeil]

http://arstechnica.com/security/2016/07/https-is-not-a-magic-bullet-for-web-security/

We're in the midst of a major change sweeping the Web: the familiar HTTP
prefix is rapidly being replaced by HTTPS. That extra "S" in an HTTPS URL
means your connection is secure and that it's much harder for anyone else
to see what you're doing. And on today's Web, everyone wants to see what
you're doing.

HTTPS has been around nearly as long as the Web, but it has been primarily
used by sites that handle money—your bank's website, shopping carts, social
networks, and webmail services like Gmail. But these days Google, Mozilla,
the EFF, and others want every website to adopt HTTPS. The push for HTTPS
everywhere is about to get a big boost from Mozilla and Google when both
companies' Web browsers begin to actively call out sites that still use
HTTP.

The plan is for browsers to start labeling HTTP connections as insecure. In
other words, instead of the green lock icon that indicates a connection is
secure today, there will be a red icon to indicate when a connection is
insecure. Eventually secure connections would not be labeled at all, they
would be the assumed default.

Google has also been pushing HTTPS connections by "using HTTPS as a ranking
signal," meaning Google takes the security of a connection (or lack
thereof) into consideration when ranking sites in search results. For the
time being, Google says that HTTPS is "a very lightweight signal...
carrying less weight than other signals such as high-quality content."
However, the company says that it "may decide to strengthen" this indicator
as a means to encourage more sites to adopt HTTPS.

Through efforts like these, HTTPS has already moved beyond the obvious
realms like banking and webmail. Popular sites like Facebook, Twitter,
YouTube, as well as major online retailers like Target, Home Depot, and
Adobe, are all served over HTTPS.

Target, Home Depot, and Adobe were not examples chosen at random, though.
In recent years, all three have had major data breaches that exposed
identifying information about users. HTTPS does not mean your data is
secure, it just means your connection is secure.

This is not semantics. It's critical for users to understand, and
unfortunately HTTPS advocates sometimes present HTTPS as synonymous with
"security." The phrase "secure Web" gets used a lot in discussions, but as
those three retailers illustrate, using HTTPS does not mean a website is
necessarily secure. In fact, HTTPS says nothing about the website, the
server it resides on, or what happens to whatever data you might give it.

And therein ultimately lies the biggest challenge for HTTPS—people need to
understand what it means.

What's so great about encryption, TLS, and authenticity?

If HTTPS is no guarantee of security, what exactly does it do? In short,
HTTPS offers three things: secrecy, integrity, and authenticity.

The simplest of these is secrecy. HTTPS uses encryption to make sure that
no one can see the data that's transmitted over the wire. When your browser
connects to a website over HTTPS, the connection from your browser to the
page you want to view is encrypted. That means any data exchanged is not
visible to anyone else snooping the network.

The EFF's Jacob Hoffman-Andrews, lead developer on Let's Encrypt (a new
tool that offers free HTTPS certificates similar to what Symantec offers)
tells Ars encryption is a "necessary minimum bar" for today's Web. "If we
were designing the Internet from scratch today, we would say encryption is
cheap and easy, there's no export restrictions anymore, so it will be
default and you won't have to worry about it."

Without the encryption, it's easy for people with the ability to monitor
the connection--say a person on the same unsecured WiFi network or a rogue
ISP employee—to see everything you ask for and everything the site sends
back. That allows attackers to perform what's known as a Man in the Middle
attack.

With an unencrypted connection, both your browser's request and the
server's response are just plain text bits of data. All a Man in the Middle
attack does is step into that stream of data and start reading and
manipulating it. If your ISP wanted to add an advertisement to this page
that requires you to click on it before reading the story, it could do that
by just injecting a few packets of its own. You would have no way of
knowing whether that ad came from Ars or some other source. Anyone could in
fact do just about anything to the data traveling between the Ars server
and your browser, including serving up an entirely different page or not
showing the page at all.

Man in the Middle code injection is not a theoretical problem; It is an
active, widely used attack. In the case of Verizon Wireless' so-called
"Perma-Cookie," it's even a business model.

Using a Man in the Middle attack, Verizon Wireless modifies traffic on its
network to inject a tracker (it added an HTTP header called X-UIDH) that is
then sent to all unencrypted sites that Verizon customers visit. This
allows Verizon to, in the words of the EFF, "assemble a deep, permanent
profile of visitors' Web browsing habits without their consent."

Verizon is not alone. It's a safe bet that your ISP is doing something
similar. Comcast's Wi-Fi service already does this, as does AT&T's Wi-Fi
(you can opt out, for a fee). What your ISP does with this data is less
well known, but it's a big part of why Google wants the Web to move to
HTTPS.

When you communicate in plain text over the network, you have to assume
that someone is at the very least watching and very probably injecting some
tracking code to record your requests. With the encrypted connection you
get when a site uses HTTPS, the transmitted data is very difficult to read.
There is no way to read or manipulate cypher text without the encryption
keys. Score one for HTTPS, which can guarantee that you are getting the
content your browser requested.

HTTPS also prevents the kind of censorship that happens at the state or ISP
level. For example, Russia wanted to ban a Wikipedia article (about charas
hashish), but because Wikipedia is served over HTTPS there's no way to see
which page visitors are requesting. Russia was faced with the choice: ban
all of Wikipedia or none. It opted for none.

Score another one for HTTPS. As it turns out, unencrypted networks do not,
as early Web enthusiasts liked to say, "see censorship as damage and route
around it." In fact, unencrypted networks make censorship very easy—just
reach in and block what you want, change what you want.

Put all this together and you discover that the Web, the network on which
your data travels, is not just insecure but actively hostile. As developer
and HTTPS proponent Eric Mill writes, "I see companies and government
asserting themselves over their network. I see a network that is not just
overseen, but actively hostile. I see an Internet being steadily drained of
its promise to 'interpret censorship as damage'... In short, I see power
moving away from the leafs and devolving back into the center, where power
has been used to living for thousands of years."

It's getting worse, too. A considerably more alarming network attack has
come to light in the last year that exploits the lack of HTTPS on the Web
to create distributed DDoS attacks using unsuspecting users who never know
they're part of an attack.

Great Cannon, as this attack has been dubbed, is a very sophisticated
attack. In a nutshell, someone hijacked a bit of JavaScript served up by
Chinese search giant Baidu and added a payload to it that made frequent
requests to two websites that challenge Chinese government censorship.
Everyone visiting Baidu who loaded that script became part of the attack.

This is what Mill means when he says the network is actively hostile. With
Great Cannon it becomes so hostile it turns you, unknowingly, into a DDoS
attacker. The only way to stop attacks like Great Cannon, or network
tampering like what Verizon and others are doing, is to encrypt your
traffic.

The last thing HTTPS provides is authentication. The site you're visiting
is verified by the browser as actually being that site and not some
imposter. To authenticate your connection, Web browsers maintain a list of
known, trusted certificate authorities. When your browser requests a page,
it gets the page's security certificate, which contains a chain that leads
back to a certificate authority. If that authority matches an authority
known to your browser, then your browser will trust that the site you're
connecting to is who it claims to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160711/52346388/attachment.html>