10 ms·
TLS Everywhere, not https: URIs (2015)
- lifthrasiir 10y agoJust in case, note that it is not against "TLS Everywhere", just against the separation of http: and https: schemes in the URI. TBL essentially argues that http: should upgrade to TLS without any change in the URI (I think that this also implies that, when TLS deployment is finally universal, http: should equal to today's https:).
- nandhp 10y agoIndeed. Perhaps a better title for this would be "'https://' https://' considered harmful".
- dang 10y agoWe changed the title to that of the HTML doc, which is clearer.
- geofft 10y agoIf you set HTTP Strict Transport Security (which any site that believes it will continue to competently run SSL can and should do), it will implicitly upgrade all http:// http:// URLs to https:// https://, accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.
- dietrichepp 10y agoOnly after you visit a domain.
- niftich 10y agoOr if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.
- strcat 10y agoIt's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.
- niftich 10y ago[a] If the ownership for the site's domain changes, how does the new owner undo the previous owner's preload? [b] Is the only way to obtain the full preload list to extract it out of Chromium or Firefox source code? [1][2] [1] https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/+/master/net/... [2] https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc https://dxr.mozilla.org/comm-central/source/mozilla/security...
- icebraining 10y agoThe page linked above has instructions for removal.
- niftich 10y agoYes, the submission site talks about removal, and how it takes until the next major release of the browser for the changes to appear in the codebase, and every user will have to upgrade to pick up the changes. If it were a HSTS preload registry service and API, that'd be different, but it's not.
- Matt3o12_ 10y agoNo it doesn't. You cannot preload every of the Internet, i event doubt you could load 5% of al domain names. With this approach we can have it for big sites, or important sites but we want it everywhere.
- geofft 10y ago
- dcw303 10y agoIt only breaks the web if you cut everything over from http to https. If you can serve both you don't have a problem. This works fine if you use anchors without protocols in your html: a href="//site.com/resource"
- Nadya 10y agoSome websites break if you try to access https:// https:// - from my experience of using Https Everywhere. It's a simple fix to whitelist the one website though. It doesn't break the Internet. It breaks sometimes, for some users, and is trivially fixable when it does break. "Fundamentally breaking the internet", to me, is something that actually breaks the usability of the internet in a non-trivial-to-fix way for the end user where the end user isn't even in control of the fix. That's breaking the web. Failing to support IE5 is "breaking the web" in the same way Https Everywhere breaks the web. In a way that is to be fixed on the user-end. (Although sites that fail to serve over https:// https:// should fix their site)
- colejohnson66 10y agoThere's probably a technical reason I'm unaware of, but why are you allowed to have HTTP and HTTPS handled differently (besides then encryption portion)?
- zAy0LfpBZLC8mAC 10y agoThat's just how it happened. And historically, it was common to put only the "important things" behind TLS. That never really made sense from a security perspective, but it certainly saved CPU cycles.
- c3833174 10y agoI don't really like when I'm not able to read the news because HTTPS didn't want to collaborate with an unreliable connection.
- CydeWeys 10y ago
- heimatau 10y agoThis is from early 2015. Should be noted in the title, since it more than 18 months old.
- deleted 10y ago[deleted]
- schallertd 10y ago5-10 years and http:// http:// 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...
- breakingcups 10y agoI'm guessing in 10 years Chrome will refuse to connect to http hosts, given Google's track record of aggressively unilaterally deprecating and disabling web features they consider harmful.
- noenpnqnoen 10y agoThat would break all Tor hidden services web servers (except Facebook).
- drdaeman 10y ago5 years? Don't see any chance for extinction. There are tons of non-HTTPS websites out there. A myriad of forsaken ones that are still running because no one had remembered to do anything to them, and a myriad of ones whose sysadmins just don't care about TLS at all. A non-obtrusive "insecure connection" warning is probably going to happen quite soon, but I just don't see any chance of mass HTTPS migration besides the high-profile sites, newborn sites and geeks that would stand for the cause. Otherwise, a pretty large fraction of the WWW is going to be lost.
- alexbecker 10y agoI 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): https://alexcbecker.net/blog.html#towards-universal-https-adoption https://alexcbecker.net/blog.html#towards-universal-https-ad...
- btrask 10y agoUsers/user agents need to know whether to expect 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. 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? Then we can finally cut out the middle-men and realize the truth: that the browser is the ultimate certificate authority. [1] https://hstspreload.appspot.com/ https://hstspreload.appspot.com/
- dredmorbius 10y agoIncorrect on public keys. You do not need a trusted channel to receive a key. You could receive one via smoke signal, carrier pigeon, or billboard. Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself. That last is independent of the key distribution channel. What matters is that the web of trust associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained. The first of those problems is difficult, but not intractable. The second problem is rather difficult, especially in the case of persistent data, though the core requirement is that the key was valid when a message was generated, if you're looking at the sender of information. For your own information, you are relying on the recipient to maintain integrity over their private (decryption) key going forward, such that the data you'd transmitted remains encrypted against all others. The first problem you point out, that any encrypted channel is not necessarily a secure channel, is valid, though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion (I still need to RTFA).
- btrask 10y agoI said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.
- mercora 10y agoif 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?
- dredmorbius 10y agoTBL's points here are well-made. In particular, there's the issue that security is a multidimensional probability field, not a binary state. The questions of secure document transfer and/or interchanges are: 1. Am I talking to the party I intended to? 2. Is the communication free from third-party interception? 3. Is the message itself originated by the party I intended? 4. Are the contents of that message as originally intended by the author? (Possibly more, but those strike me as the Big Four.) There are various ways for this to fail, and there are different and independent 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. The present HTTP / HTTPS split addresses only a subset of these concerns, and few of them well, whilst breaking multiple elements of functionality. 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 is the Web, with origins and various archival services (archive.org, archive.is, the NSA, ...) providing robust storage needs to various audiences.
- steve371 10y agoLooks like ppl didn't listen. I saw more https movement this days. and surely enough, it breaks...lots of stuff.
- vtsingaras 10y agoThe 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.
- IshKebab 10y agoAgreed, and MitM is arguably a bigger threat than DPI to most people, especially if you use coffee shop wifi, etc.
- billpg 10y agoIf we're designing in hindsight... 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. 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. 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.
- jstanley 10y agoDelivering a TLS certificate over HTTP is useless as a MITM can simply substitute his own certificate.
- billpg 10y agoJust like real-world TLS, the browser would validate the certificate before using it. TLS can be MITM'd too - if you can find a way around browser validation of the certificate.
- billpg 10y ago(To complete my above comment...) This would have the benefit of bringing that initial certificate negotiation outside of the TLS black-box. For years, TLS deployment was held back because you couldn't have multiple domains on a single IP, long after the problem had been solved for HTTP. Later, SNI was added to TLS, but the change wouldn't be rolled out to Windows XP users (except Firefox which used its own TLS implementation). By using HTTP, you'd have the Host: header right away and could even introduce new certificate formats by looking at the Accept: header. This sort of thing is built into HTTP but had to be retrofitted with much pain and anguish into TLS.
- ckastner 10y agoThe 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. 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". 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? 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'd venture to say that IPv6 probably wishes it had the traction that HTTPS Everywhere has...
- deadowl 10y agoThe URL that's supposed to redirect to HTTPS is still vulnerable to MitM. It can be modified in transit to serve up the same data as the HTTPS URL, but in plaintext, and potentially with a different form action attribute, etc. There are different things that can help with that, but none of them universally protect privacy.
- ckastner 10y agoThat would mean HTTPS is not necessarily an improvement security-wise, but that does not explain how it "completely breaks the web" by "breaking links to". To be more specific, I'm referring to the "Don't break the Web" section in the article.
- z3t4 10y agoSince most browsers now a days support SSL/TSL it's safe to redirect all traffic from http to the same url on httpS.
- amluto 10y agoWhat exactly is he proposing? Without some additional change, if I make a link to http://bank.com http://bank.com, 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). I can see an argument for having DANE-like records include an HSTS instruction, but nothing like that is mentioned in the article.
- dmd 10y agoOff topic, but I'm a native english speaker, and have never heard this construction before: "There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west." What does "and points west" mean here?
- nathanaldensr 10y agoIt's okay; I'm a native English speaker and I had trouble following much of Berners-Lee's grammar and writing style. He should consider editing the piece. I have no idea what "and points west" means in this context.
- ukblewis 10y agoYeah... His English is extremely hard to decipher (Native Brit here). I thought that the man that invented World Wide Web would write more eloquently...
- moskie 10y agoI think you can interpret "and points west" as "and beyond." I think it's based on the expression "all points west." Can't find a good source at the moment. "Points" is used as a plural noun there, not a verb. So, I think the expression "all points west" means "all locations to the west," and used metaphorically here to mean "all things beyond."
- rspeer 10y agoI have heard the phrase "points west" used when listing the places where a train is going. After listing the next several stops, they say "...and points west" to sum up all the stops the train will make that are too far away to be worth listing. So I guess it's a metaphor for the indefinite beyond that makes sense to people who live on the east coast of the US and ever take the train.
- velox_io 10y agoI 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. I'm also a big fan of Let's encrypt, democratizing SSL certificates is only a good thing.
- dmh2000 10y agoas 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?
- niftich 10y agoThe EFF's 'HTTPS Everywhere' Firefox addon [1] has a setting to block all HTTP requests. This is not enabled by default [2], but when turned on, will exhibit the behavior you want. [1] https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/ https://addons.mozilla.org/en-US/firefox/addon/https-everywh... [2] https://www.eff.org/https-everywhere/faq#faq-When-does-HTTPS-Everywhere-protect-me?-When-does-it-not-protect-me https://www.eff.org/https-everywhere/faq#faq-When-does-HTTPS...?
- dmh2000 10y agothanks