As per an honourable mention in an answer for « Why self-signed https is less trustworthy than unencrypted http? », it appears that there are already two post-Snowden drafts that have to do with the exact topic of opportunistic encryption of http traffic:

They are a bit tense on the details; also, being reference documents, they obviously don't talk about implementation details and product support.

But I'm really excited that someone's finally working on making opportunistic encryption of HTTP possible just like we have had STARTTLS in SMTP for years. Is any of this implemented yet? I'd really like to enable all of it for all of my non-profit web-sites, any way to be an early adopter?


2 Answers 2


None of the mainstream user-agents (IE, FF, Chrome, etc.) support either of those proposals, so there's currently no way to do opportunistic HTTPS. Why not just serve all of your content over HTTPS to everyone? Seems like that's the best way to offer your users confidentiality and integrity.

  • 2
    Because certificates are controlled by the CA cartels with prohibitive pricing for multi-domain certs; because self-signed certs would create too many nuisance warnings all over (whereas http is warning-free); because the https certs have to be renewed every X months; because not everyone supports SNI, and people linking to my site through the https:// address scheme would be making my site unavailable for lots of users (e.g. Android 2.3) and bots. As my non-profit sites don't require authentication, I will never implement https:// due to the shortcomings as above.
    – cnst
    Jul 21, 2014 at 0:56

I think you mix up opportunistic encryption as described by these drafts and STARTTLS.

STARTTLS has clearly defined semantics how certificates should be verified (see RFC6125) and most Mail User Agents (MUA) implement these validations when connecting to an Mail Transport Agent (MTA). Thus you need to explicitly accept a specific fingerprint of a server if the certificate is signed by an unknown CA. Most MTAs instead offer ways to disable these validation checks, with the argumentation that non-validated TLS helps against passive monitoring in thus is at least better than no TLS at all.

But, the security model of mail (SMTP) is totally different from HTTP. SMTP is a hop-by-hop protocol with at least on MTA between source and target MUA. There is no end-to-end encryption (i.e. MUA-to-MUA), but only hop-by-hop. This means any MTA in between can see and modify the mails in plain text, even if the connection to this MTA is protected by TLS. So if you need privacy with SMTP you need to encrypt the body of the mail yourself - that's what PGP and S/MIME are for.

HTTP instead provides an end-to-end connection between the parties and HTTPS thus offers end-to-end encryption. There is no additional security layer defined (e.g. similar to PGP or S/MIME) so your privacy solely depends on the proper implementation of TLS.

Have a look at the section about security considerations in the RFCs you referenced. They both clearly state, that they only protect against passive monitoring, that they are vulnerable to man-in-the-middle attacks, and that browser creators should not provide a user interface which might suggest a protection comparable to HTTPS.

And about your complains about the "cartel" associated with HTTPS: There is nothing inherent with TLS/HTTPS which needs such a "cartel". But, what it needs is a way to validate the identification (certificate) presented by the peer, because otherwise it would be vulnerable to man-in-the-middle (active) attacks. Historically this validation has been implemented by having a fixed set of trust anchors in the browsers and start from there to validate the certificate. If you have another trusted way to verify the servers certificate you can use it, but at the end it does not remove the need for some kind of trust anchors, but it only replaces it with other trust anchors. Like with DANE, where you need DNSSec which again needs trusted CAs for signing the DNS root entries and build a trust chain from there to verify the DNS entries which include the certificate.

I would not suggest, that the current way with 100s of fully trusted root-CAs inside the browser is the way we should continue. But at least it provides the expected security in most cases. So I would not recommend to replace it with something far worse, i.e. one of these drafts which provides encryption without identification of the peer. I would not even recommend to implement this as an option inside the browser, because the average user will not be able to understand the differences between the various levels of security.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .