HTTPS: Beware the False Sense of Security

HTTPS is the protocol that is getting a lot of attention these days. As more browsers migrate toward supporting it in meaningful ways — like by not connecting to sites that do not offer it — it would be easy for a user to think that once HTTPS has been implemented, everything security-related is taken care of.

That is not the case.

In fact, one of the major problems affecting HTTPS right now is that users think that it does more than it actually does, than it was designed to do.

A simple example of this would be when some page connects with HTTPS to a browser but has a link to an image on another server embedded in it. The page is sent to the user HTTPS encrypted and all. Yet on the page served to the browser, it also serves up the link to the image – an image file may or may not contain malicious code.

The user would have no idea of what’s going on with the image itself because in most cases the client browser doesn’t provide any warning.

This is also how malvertising schemes work. Online advertising networks serve infected media files up on news or entertainment sites. The perpetrators behind the scheme can be confident that the malicious content will get transported to the victim just as they intended – even if HTTPS protocol is in effect.

HTTPS Alone Won’t Protect You

The following incidents, only three out of many more over the past years, show the limited powers of HTTPS. Even where it’s supposedly implemented, it often isn’t, or only insufficiently. Users are lulled into a false sense of security:

• Certificate Spoofing: HTTPS depends on the integrity of the SSL certificate. But certificates can be false ones, or pretend to be from another source. Such widespread spoofing was reported by Netcraft as affecting major internet entities like Google, Facebook, GoDaddy, YouTube and iTunes. A lack of certificate checks within the popular Steam gaming platform also allowed consumer PayPal payments to be undetectably intercepted for at least three months before eventually being fixed.

• Consumer Cellular HTTPS failure: Minnesota users of the phone service were reporting HTTPS service was failing them on over-the-air transactions in late 2017. Many apps would not work because of this lack of service. Mitigation required changing the network service away from Consumer.

• Facebook fudges HTTPS: Facebook announced in March 2018 that it would send users to HTTPS enabled links, even if an HTTP link is given in the content. But the method used for this (“HSTS preloading”) does not guarantee that such a link will exist. Users are led to believe their security has been enhanced, even if it is not.

Confused yet? Consider this, too: The HTTPS protocol deals with preserving the integrity of information in transit, not with the validity or legitimacy of that information. Put differently, HTTPS cannot stop malware. It was never designed to do that job.

One Hop Encryption

HTTPS works for only one hop – another feature that is not well-understood by most users. Let’s say you connect to a site, and the browser says HTTPS or shows the padlock icon in the status bar. You think you are connected to the site in this manner.

You may not be.

The site may have some outward facing service (such as Cloudflare) that it uses to deal with the “raw’ internet. What is actually happening is that the user is HTTPS connected with that outward facing service for the one —and only that one— first hop. The web service the browser is connecting to may be using unsecured HTTP connections for communications with the target site after that. The user would not know.

Someone on the service’s network might be able to impersonate the desired site (because of the HTTP use from the first stop to the actual site) and carry out a Man-in-The-Middle attack. Users are snookered into complacency by the HTTPS indicator that they see in their status bar.

Because they believe what their browser presents to them, users may think they are in the clear now.

Privacy Leaks

HTTPS use doesn’t prevent privacy violations either, as Eric Claw points out on his blog, though they may not be the ones you would think of first.

Requested server URLs will be encrypted in HTTPS, as one might expect. But IP addresses are not, and can be discovered by a monitoring tool with network access. Not only that, but the hostname requested at the IP can also be found without breaking the protocol. Once a monitor has captured the IP address, a reverse lookup of the site name is trivial.

While data that is sent with HTTPS is encrypted, the length of that data (whether sent or received) is not. This can be a very useful item for monitoring tools that derive what you have connected with by analysis of the length of the traffic exchanged by two servers. While no primary data is leaked, this approach will bear fruit in targeted attacks, where the attackers attempt to break the privacy of particular transactions.

Other non-obvious cases of vulnerability would include truncation detection, a way of telling if the data stream that is sent has been stopped too soon during the transmission and ends up throwing away some of the information in the transmission.

Truncation detection (while allowed by the specification of TLS, the enabling protocol of HTTPS) is almost never implemented in a client. As a result, a truncated data stream will usually be accepted without any user notification.

That means that the full amount of data is not transferred between the server and the client, and the lack of implementation in the software doesn’t alert any of the involved parties to this situation.

Browsers that are attempting to establish a secure connection to a server should authenticate that they are who they claim to be by presenting their own certificates during the HTTPS handshake process. In practice, it is not used in any significant way in HTTPS, which opens the door to client spoofing.

Compromised Certificates

The certificates used in HTTPS can be directly compromised, too. When Trustico sent out 23,000 HTTPS certificates along with their private keys in an unprotected email, it was one more example of how a certificate can be misused. How Trustico came to have those secret keys in the first place was also a concern because that information should belong only to the certificate recipient, not the issuer.

US-CERT has already warned that badly implemented HTTPS poses a hazard to overall security. In a paper titled The Security Impact of HTTPS Interception, experts from Google, Mozilla, Cloudflare and the University of Michigan showed that around 62% of the HTTPS connections they’ve studied featured "reduced security," while 58% contained "severe vulnerabilities."

Consideration by Mozilla not to trust HTTPS certificates issued by the State of the Netherlands Certificate Authority highlight one more reason for caution: the potential for intentional abuse by issuing authorities.

Background: The Netherlands is a major transit point for internet traffic, but a new law could give Dutch authorities the powers to monitor internet traffic, using “false keys” to unlock HTTPS certificates. Mozilla, after considering the implications, left the Netherlands alone as far as trust goes for the immediate, but announced that it will still take governmental policy into account when evaluating whom it trusts implicitly.

In the light of such loopholes, the push to HTTPS isn’t as big of a deal for data protection and privacy as Google would have you think.

Is it a big step forward, given the shaky underpinnings of the web? Absolutely – as long as users keep in mind that like most protocols the web is based on, this technology has soft spots that can be attacked or badly implemented.

One thing it is not when you browse the web: an impenetrable suit of armor.

*

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for IBM’s SecurityIntelligence as well as Security Now.