TLS Everywhere, not https: URIs (2015)
1–10 of 94 posts
Re: TLS Everywhere, not https: URIs (2015)
#2Just 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:).
Re: TLS Everywhere, not https: URIs (2015)
#3It 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"
Re: TLS Everywhere, not https: URIs (2015)
#4This is from early 2015. Should be noted in the title, since it more than 18 months old.
Re: TLS Everywhere, not https: URIs (2015)
#5[deleted]
Re: TLS Everywhere, not https: URIs (2015)
#6Just 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:).
Indeed. Perhaps a better title for this would be "'https://' considered harmful".
Re: TLS Everywhere, not https: URIs (2015)
#7Just 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:).
Indeed. Perhaps a better title for this would be "' https://' considered harmful".
We changed the title to that of the HTML doc, which is clearer.
Re: TLS Everywhere, not https: URIs (2015)
#8It 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 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:// should fix their site)
Re: TLS Everywhere, not https: URIs (2015)
#9Just 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:).
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.
Re: TLS Everywhere, not https: URIs (2015)
#10Just 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:).
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.