Should new web features be HTTPS only?

I doubt anyone who reads this will disagree with the proposition that the Web needs to move toward all traffic being encrypted always. Yet there is constant back pressure in the standards groups, people trying to propose network-level innovations that provide only some of the fundamental three guarantees of a secure channel—maybe you can have integrity but not confidentiality or authenticity, for instance. I can personally see a case for an authentic channel that provides integrity and authenticity but not confidentiality, but I don’t think it’s useful enough to back off on the principle that everything should be encrypted always.

So here’s a way browser vendors could signal that we will not stand for erosion of secure channels: starting with a particular, documented and well-announced, version, all new content features are only usable for fully HTTPS pages. Everything that worked prior to that point continues to work, of course. I am informed that there is at least some support for this within the Chrome team. It might be hard to sell Microsoft on it. What does the fox think?

Responses to “Should new web features be HTTPS only?”

  1. Jesse Ruderman

    IMO, only features with a clear connection to security and privacy should be restricted to HTTPS. For example, getUserMedia. There’s a clear hit to security when a user selects always allow this site to access my camera on an HTTP site.

    Requiring HTTPS for all new features would hinder adoption of new features more than it would speed up HTTPS adoption. Many of the new features are better for security than the things they replace.

    I’d also drop the fully HTTPS requirement. Mixed content is often dynamic or page-specific, so things would seem to break at random (unless you also required an STS/CSP header to forbid mixed display content).

    1. Zack Weinberg

      I can see where you’re coming from, but I think that limiting the restriction to features with a clear connection to security and privacy does not provide enough encouragement. The idea is to couple adoption of HTTPS to adoption of the new shiny things that designers actively want, whatever those happen to be in release cycle N.

      Re mixed content, I suppose I might back down to the HTML document and the specific JS or CSS file that requested the new feature, if any and leave discouragement of mixed content in general as a separate ratchet.

  2. Anders

    Of course everybody would like secrecy, integrity and authenticity. But nobody wants to be any more beholden to Certificate Authorities than they already are (since the CA system is basically a monopolistic protection racket that does not protect you and have no incentive to). Since authenticity normally are equated with CAs, I can understand why some might ask the question if there isn’t some way around it. But it isn’t authenticity we should try to get around, it is the CA system. I would hate if Mozilla would force us into the arms of the CAs.

    Maybe something like http://convergence.io/ (presentation: http://www.youtube.com/watch?v=Z7Wl2FW2TcA ) could start us down the road of making CAs optional. Mozilla is in the position of being able to do it since it would only require a change to the browser and a web service (no changes to the sites). And of course some lobbying to get other browser vendors and notaries on board.

    Then you can start requiring certs for all communication.

  3. DaveG

    Once HTTP 2.0 starts rolling out, we need to start treating it as the new normal. If it is the case that an insecure mode will exist within the spec, but certain browsers refuse to support it, that doesn’t change anything. HTTP 2.0 + TLS 1.2 will be the expected platform and HTTP 1.1 will exist only for legacy support. It is irrelevant how long that will be. I personally think that every feature that can be served over HTTP 1.1 at that time should be effectively frozen. It will unarguably exist for backwards compatibility reasons only and should be treated as such. Halting the release of new features on old known-to-be-flawed protocols is a very good idea.

    Not only would it force everyone to adopt new standards, but it would provide a simple cut-off point for backwards compatibility. Nobody ever wants to break the web, but with HTTP 2 we’ve got a sort of clean slate. There will be the legacy pages sent out to old browsers and the full version sent over HTTP 2. It will be a very clear point that can be used to decide what features to use that doesn’t involve UA sniffing. More complex fixes and changes to HTML and TLS could be done without having to worry about interoperability with ancient browsers. A package of HTTP 2 + TLS 3 + HTML 6 could be put together with whatever web breaking changes need to be done without having to worry about old browsers at all. We could then just say this is the new stack of what we use, but the old is still supported with no changes. It’s much cleaner than phasing in bits and pieces at a time like is being done now. It’s also a hell of a lot simpler to just have an old and a new mode, and much easier to explain to people.

  4. squib

    This seems like a backwards way to go about things, and in many cases, would just make life harder for developers (I’d need to set up localhost to use HTTPS if I wanted new content features for my test environment).

    If the goal is to force websites to switch to HTTPS, I think it would make more sense to craft actual, legal regulations requiring it where it makes sense (which is most places).

  5. Anonymous

    I’d very much like to see this systematically applied to new features.

  6. voracity

    HTTPS is an utter pain in the arse. How many one-line HTTPS servers are you aware of? If you want to put a massive and debilitating innovation tax on the web, then by all means make HTTPS a requirement for everyone. For far too long, the web has been just too darn small-creator-friendly.

    The focus for security experts shouldn’t be to yoke the web’s developers because of ideology about the how the world should be. It should be to make good security so simple that it costs next to nothing (and that includes avoiding the hyper-centralised CA system). And if you can’t achieve that, let us continue the way we have been for the past 20-ish years.