11–20 of 94 posts
Earlier quoted context omitted.
If 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:// URLs to https:// , accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.
Only after you visit a domain.
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. This works fine if you use anchors without protocols in your html: a href="//site.com/resource"
It only takes 1 server to serve differing content through each protocol to break things for the user
Earlier quoted context omitted.
Only after you visit a domain.
Or if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.
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.
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. This works fine if you use anchors without protocols in your html: a href="//site.com/resource"
Some websites break if you try to access 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…
Users/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 nee…
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).
Earlier quoted context omitted.
Some websites break if you try to access 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…
There'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)?