Users/user agents need to know whether to <i>expect</i> a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably tell you. If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic. If I can get you to use HTTPS when you should've used HTTP, it might be a DoS.<p>Incidentally, this is the same problem as public key distribution. You need a trusted channel to receive public keys, and a trusted channel to know whether to use a public key. Why can't these be the same channel? Right now we have HSTS preloading[1] for the latter, but in that case why not preload certificates (or hashes thereof) too?<p>Then we can finally cut out the middle-men and realize the truth: that the browser is the ultimate certificate authority.<p>[1] <a href="https://hstspreload.appspot.com/" rel="nofollow">https://hstspreload.appspot.com/</a>
<i>The problem is of course that moving things from http: space into https space, whether or not you keep the rest of the URI the same, breaks any links to. Put simply, the HTTPS Everywhere campaign taken at face value completely breaks the web.</i><p>Tim Berners-Lee is certainly an authority in the area, but I (an amateur) fail to see any major problem here, let alone one that "completely breaks the web".<p>Can someone illustrate a use case where either this fatal link-breaking cannot be solved by a simple HTTP->HTTPS redirect, or any other scenario where the user is so much worse off?<p><i>In a way it is arguably a greater threat to the integrity for the web than anything else in its history. The underlying speeds of connection of increased from 300bps to 300Gbps, IPv4 has being moved to IpV6, but none of this breaks the web of links in so doing.</i><p>I'd venture to say that IPv6 probably wishes it had the traction that HTTPS Everywhere has...
The problem with opportunistic TLS is that while it protects from wide-scale DPI it doesn't protect against MITM. Personally I think that the effort that would be put to implementing opportunistic TLS in all web servers and browsers would be better put to migrating all web applications to HTTPS only.
It only breaks the web if you cut everything over from http to https. If you can serve both you don't have a problem.<p>This works fine if you use anchors without protocols in your html:<p>a href="//site.com/resource"
TBL's points here are well-made. In particular, there's the issue that security is a multidimensional probability field, not a binary state.<p>The questions of secure document transfer and/or interchanges are:<p>1. Am I talking to the party I intended to?<p>2. Is the communication free from third-party interception?<p>3. Is the message itself originated by the party I intended?<p>4. Are the <i>contents</i> of that message as originally intended by the author?<p>(Possibly more, but those strike me as the Big Four.)<p>There are various ways for this to fail, and there are different <i>and independent</i> assurances which can be afforded. I remeber the first time I heard phrases to the effect of "you can trust our secure webserver" in the context of commercial transactions, and cringed.<p>The present HTTP / HTTPS split addresses only a subset of these concerns, and few of them well, whilst breaking multiple elements of functionality.<p>I will note that TBL seems to be concerned over the expiration of old, previously-valid URLs. To that I can only say that this appears to be a lost battle. The duration of a contemporary URL is on the order of 40-45 days, I think from the Internet Archive. That's scarcely longer than an old-school Usenet post might be relied on to persist online, and suggests to me that perhaps the successor to Usenet <i>is</i> the Web, with origins and various archival services (archive.org, archive.is, the NSA, ...) providing robust storage needs to various audiences.
I find the HTTP/HTTPS "ring-fence" or "oil/water boundary", as he describes it, to be the most frustrating aspect of HTTPS, and recently wrote about it in some more detail (and how it might be fixed): <a href="https://alexcbecker.net/blog.html#towards-universal-https-adoption" rel="nofollow">https://alexcbecker.net/blog.html#towards-universal-https-ad...</a>
What exactly is he proposing? Without some additional change, if I make a link to <a href="http://bank.com" rel="nofollow">http://bank.com</a>, any MITM can trivially force an unencrypted connection and somehow the user needs to notice (or be lucky enough to have HSTS know about bank.com).<p>I can see an argument for having DANE-like records include an HSTS instruction, but nothing like that is mentioned in the article.
5-10 years and <a href="http://" rel="nofollow">http://</a> will be as rare as having a lottery jackpot. our kids kids will ask - what is this http? like our kids did with floppy disks...
if there was just one scheme for both and some kind of protocol upgrade needs to take place wouldn't it be easy to manipulate the connection and just doesn't let it take place?
I used to think HTTPS everywhere was overkill, then I discovered HTTP2/ H2. H2 has some massive performance improvements and I believe we have barely scratched the surface of what is possible e.g. once the connection is established there's no need for additional HTTP handshakes, massively reducing latency.<p>I'm also a big fan of Let's encrypt, democratizing SSL certificates is only a good thing.
Off topic, but I'm a native english speaker, and have never heard this construction before:<p>"There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west."<p>What does "and points west" mean here?
If we're designing in hindsight...<p>Browsers should connect to port 80 and perform a GET for /tls-cert with an Accept: header listing all the certificate formats it knows and the applicable Host: header.<p>The server would respond with the certificate for that host-name and the browser would validate it. After that, the HTTP connection would switch into TLS mode using the key in that certificate.<p>If the server responds to this initial request with 404 or some other error, the browser either shows an error or continues in insecure mode.
as an ignorant user, I would just like to have a browser setting such as 'only talk to sites using TLS'. I would be happy to deal with the fallout. does chrome or other browser have that?
Just in case, note that it is <i>not</i> against "TLS Everywhere", just against the separation of http: and https: schemes in the URI. TBL essentially argues that http: <i>should</i> upgrade to TLS without any change in the URI (I think that this also implies that, when TLS deployment is finally universal, http: <i>should</i> equal to today's https:).