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.

  3. Tomi Engdahl says:
    Why “Let’s Encrypt” Won’t Make the Internet More Trustworthy

    Internet users have been shaming Lenovo for shipping the SuperFish adware on their flagship ThinkPad laptops. SuperFish was inserting itself into the end-users’ SSL sessions with a certificate whose key has since been discovered (fascinating write-up by @ErrataRob here).

    Clearly the certificate used by SuperFish is untrustworthy now. Browsers and defensive systems like Microsoft Windows Defender are marking it as bad. But for most certificates the status isn’t entirely as clear.

    Observable Internet encryption is largely made up of SSL servers listening on port 443. On the Internet, approximately 40% of these servers have so-called “self-signed” certificates. A “real” certificate (trusted by your browser) is signed by a trusted third party called a certificate authority: VeriSign, Comodo, GlobalSign, GoDaddy are a few of the tier 1 providers. But a server whose certificate is signed with its own key is called self-signed and is considered untrustworthy. It is sort of strange, isn’t it, that there’s all this software that can perform sophisticated encryption on the Internet, yet much of it is junk.

    In mid-2015, the Electronic Frontier Foundation (EFF) will be launching a free, open Certificate Authority called “Let’s Encrypt” with an aim to reducing the stumbling blocks that prevent us from “encrypting the web.”

    If Let’s Encrypt succeeds, will self-signed certificates go extinct?

    I’m guessing no. I’ll explain why, and why I think that’s not necessarily a bad thing.

    There are three reasons certificates are self-signed.


    The first and most quantitative reason for self-signing is because real certificates cost real money. A world-class “extended validation” certificate, perhaps used by a global financial institution and trusted by every browser, might cost $1,000 per year. So it’s no wonder that there are over 10 million sites with self-signed certificates, right? These sites would represent $10 billion in subscriptions per year if they all had real certificates.

    there are already bargain certificate vendors who provide no frills, no-questions-asked certificates for $5 per year or even less.


    One of the most common scenarios resulting in a self-signed certificate is when a new device like a router or webcam gets deployed in a small network. The software in the device supports HTTPS (and not HTTP, otherwise it would set off all kinds of compliance alerts) but it is up to the user to get a real certificate (from a certificate authority) and stick it on there. Unless the user is a security professional of some kind, they probably aren’t going to get a certificate for their device, regardless of the price.


    Ask a penetration tester or DAST vendor, and they’ll tell you that a huge number of devices on the Internet were never meant to be there in the first place.
    To see how often this really happens, you don’t have to look any further than the infamous SHODAN search engine, which can find weird devices on the Internet based on their HTTP headers.
    Will Let’s Encrypt fix all these routers and webcams? No

    I predict that Let’s Encrypt probably won’t make a huge impact on the number of self-signed certificates out there, and maybe that’s not a bad thing.

    Will Let’s Encrypt Succeed?

    Even though Let’s Encrypt has no apparent business model, let’s suppose for a minute that it gets some market share. Over time, vendors might trust its longevity enough to build support into their routers, webcams, and other devices. When their end-user customers set up the device, it would automatically certificate-fetch from Let’s Encrypt. That’s the only world in which self-signed certificates might become a thing of the past. But that world is years away. So like the junk DNA within all of us, I predict that self-signed certificates will live on for at least a few more generations.

  4. Tomi Engdahl says:
    ‘All browsing activity should be considered private and sensitive’ says US CIO
    Stop laughing about the NSA and read this plan to make HTTPS the .gov standard

    The CIO of the United States has floated a plan to make HTTPS the standard for all .gov websites.

    “The majority of Federal websites use HTTP as the primary protocol to communicate over the public internet,” says the plan, which also states that HTTP “create a privacy vulnerability and expose potentially sensitive information about users of unencrypted Federal websites and services.”

    “All browsing activity should be considered private and sensitive,” the proposal continues (cough – NSA – cough) before suggesting “An HTTPS-Only standard will eliminate inconsistent, subjective decision-making regarding which content or browsing activity is sensitive in nature, and create a stronger privacy standard government-wide.”

    The proposal acknowledges that “The administrative and financial burden of universal HTTPS adoption on all Federal websites includes development time, the financial cost of procuring a certificate and the administrative burden of maintenance over time” and notes that HTTPS can slow servers and sometimes complicate the browsing experience.

    The HTTPS-Only Standard

    The American people expect government websites to be secure and their interactions with those websites to be private. Hypertext Transfer Protocol Secure (HTTPS) offers the strongest privacy protection available for public web connections with today’s internet technology. The use of HTTPS reduces the risk of interception or modification of user interactions with government online services.

    This proposed initiative, “The HTTPS-Only Standard,” would require the use of HTTPS on all publicly accessible Federal websites and web services.


Leave a Comment

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