Why isn't the Web using it HTTPS always?

You wouldn’t write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to any service that uses a plain HTTP connection that’s essentially what you’re doing.

There is a better way, the secure version of HTTPHTTPS. HTTPS has been around nearly as long as the Web, but it’s primarily used by sites that handle money. HTTPS is the combination of HTTP and TLS. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet.


Web security got a shot in the arm last year when the FireSheep network sniffing tool made it easy for anyone to capture your current session’s log-in cookie insecure networks. That prompted a number of large sites to begin offering encrypted versions of their services via HTTPS connections. So the Web is clearly moving toward more HTTPS connections; why not just make everything HTTPS?

HTTPS is more secure, so why isn’t the Web using it? gives some interesting background on HTTPS. There are some practical issues most Web developers are probably aware of.

The real problem is that with HTTPS you lose the ability to cache. For sites that don’t have any reason to encrypt anything (you never log in and just see public information) the overhead and loss of caching that comes with HTTPS just doesn’t make sense. The most content on this site for example don’t have any reason to encrypt anything.

HTTPS SSL initial key exchange also adds to the latency, so HTTPS-only Web would, with today’s technology, be slower. The fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.

The cost of operations for HTTPS site is higher than normal HTTP: you need certificated that cost money and more server resource. There is cost of secure certificates, but obviously that’s not as much of an issue with large Web services that have millions of dollars. The certificate cost can be a showstopper for some smaller low budget sites.

Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work well with virtual hosts. There is a way to make virtual hosting and HTTPS work together (the TLS Extensions protocol Server Name Indication (SNI)) but so far, it’s only partially implemented.

In the end there is no real technical reason the whole Web couldn’t use HTTPS. There are practical reasons why it isn’t just yet happening today.


  1. Tomi Engdahl says:
    In-depth: How CloudFlare promises SSL security—without the key
    CEO shares technical details about changing the way encrypted sessions operate.

    Content delivery network and Web security company CloudFlare has made a name for itself by fending off denial-of-service attacks against its customers large and small. Today, it’s launching a new service aimed at winning over the most paranoid of corporate customers. The service is a first step toward doing for network security what Amazon Web Services and other public cloud services have done for application services—replacing on-premises hardware with virtualized services spread across the Internet.

    Called Keyless SSL, the new service allows organizations to use CloudFlare’s network of 28 data centers around the world to defend against distributed denial of service attacks on their websites without having to turn over private encryption keys. Keyless SSL breaks the encryption “handshake” at the beginning of a Transport Layer Security (TLS) Web session, passing part of the data back to the organization’s data center for encryption. It then negotiates the session with the returned data and acts as a gateway for authenticated sessions—while still being able to screen out malicious traffic such as denial of service attacks.

    In an interview with Ars, CloudFlare CEO Matthew Prince said that the technology behind Keyless SSL could help security-minded organizations embrace other cloud services while keeping a tighter rein on them. “If you decide you’re going to use cloud services today, how you set policy across all of these is impossible,” he said. “Now that we can do this, fast forward a year, and we can do things like data loss prevention, intrusion detection… all these things are just bytes in the stream, and we’re already looking at them.”

    The development of Keyless SSL began about two years ago, on the heels of a series of massive denial of service attacks against major financial institutions alleged to have been launched from Iran.

    the banks weren’t able to use existing content delivery networks and other cloud technology to protect themselves either because of the regulatory environment. “They said, ‘We can’t trust our SSL keys with a third party, because if they lose one of those keys, it’s an event we have to report to the Federal Reserve,’”

    Prince and his team had nothing to offer the banks at the time. “These guys need us, but there’s no vault we can ever build that they’ll trust us with their SSL keys,” he said. So CloudFlare system engineers Piotr Sikora and Nick Sullivan started working on ways to allow the banks to hold onto their private keys. The answer was to change what happens with the SSL handshake itself.

    Once that’s complete, the CloudFlare data center is able to manage the session with the client, caching the session key and using it to encrypt cached, static content from the organization’s website back to the client. Requests for dynamic data are passed through to the back-end servers on the organization’s server, and responses are passed through (encrypted) to the client Web browser.

    The client, Cloudflare’s service, and the backend server all then have the same session key.

    CloudFlare’s data centers can spread out requests for a single session across all the servers in each data center through CloudFlare’s key store, an in-memory database of hashed session IDs and tickets.

    Prince said that CloudFlare already has a “handful of beta customers, which include some of the top 10 financial institutions,” up and running on Keyless SSL.

  2. Tomi Engdahl says:
    The Cost of the “S” In HTTPS

    Researchers from CMU, Telefonica, and Politecnico di Torino have presented a paper at ACM CoNEXT that quantifies the cost of the “S” in HTTPS. The study shows that today major players are embracing end-to-end encryption, so that about 50% of web traffic is carried by HTTPS. This is a nice testament to the feasibility of having a fully encrypted web.

    The Cost of the “S” in HTTPS

    Increased user concern over security and privacy on the Internet has led to widespread adoption of HTTPS, the secure version of HTTP. HTTPS authenticates the communicating end points and provides confidentiality for the ensuing communication. However, as with any security solution, it does not come for free. HTTPS may introduce overhead in terms of infrastructure costs, communication latency, data usage,
    and energy consumption.

    Motivated by increased awareness of online privacy, the use of HTTPS has increased in recent years. Our measurements reveal a striking ongoing technology shift, indirectly suggesting that the infrastructural cost of HTTPS is decreasing. However, HTTPS can add direct and noticeable protocol-related performance costs, e.g., significantly increasing latency, critical in mobile networks.More interesting, though more difficult to fully under stand, are the indirect consequences of the HTTPS: most in-network services simply cannot function on encrypted data.

    For example, we see that the loss of caching could cost providers an extra 2 TB of upstream data per day and could mean increases in energy consumption upwards of 30% for end users in certain cases. Moreover, many other value-added services, like parental controls or virus scanning, are similarly affected, though the extent of the impact of these \lost opportunities” is not clear.

    What is clear is this: the S” is here to stay, and the network community needs to work to mitigate the negative repercussions of ubiquitous encryption. To this end, we see two parallel avenues of future work:

    first, low-level protocol enhancements to shrink the performance gap, like Google’s ongoing efforts to achieve -RTT” handshakes.

    Second, to restore in-network middlebox functionality to HTTPS sessions, we expect to see trusted proxies become an important part of the Internet ecosystem.


Leave a Comment

Your email address will not be published. Required fields are marked *