
TLS Everywhere, not https: URIs (2015) - schallertd
https://www.w3.org/DesignIssues/Security-NotTheS.html
======
btrask
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 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/)

~~~
noja
> Users/user agents need to know whether to expect a connection to be secure.

Why not expect it to be secure? Connect to https before http.

~~~
markild
Behavior like that needs to come with a huge warning label.

It would be trivial for any man-in-the-middle to block https and server http.

~~~
AstralStorm
This is exactly why browsers warn about such redirects. That said, this
reminds me of a similar discussion on mail servers. There, STARTTLS sees much
more use.

The main problem is preventing downgrade attacks. With mail it is easy to just
remember the setting for every server. Not so with websites.

~~~
michaelt
I've seen quite a bit of criticism of it for mail servers [1] because an
attacker can simply block the 'STARTTLS' message and (many) clients will
silently accept that.

[1]
[https://www.agwa.name/blog/post/starttls_considered_harmful](https://www.agwa.name/blog/post/starttls_considered_harmful)

------
ckastner
_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._

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
The 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
That 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.

------
vtsingaras
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.

~~~
IshKebab
Agreed, and MitM is arguably a bigger threat than DPI to most people,
especially if you use coffee shop wifi, etc.

------
dcw303
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"

~~~
Nadya
Some 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
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)?

~~~
zAy0LfpBZLC8mAC
That'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
I don't really like when I'm not able to read the news because HTTPS didn't
want to collaborate with an unreliable connection.

------
dredmorbius
TBL'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.

------
alexbecker
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):
[https://alexcbecker.net/blog.html#towards-universal-https-
ad...](https://alexcbecker.net/blog.html#towards-universal-https-adoption)

------
amluto
What 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.

------
schallertd
5-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
I'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.

------
mercora
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?

------
velox_io
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.

I'm also a big fan of Let's encrypt, democratizing SSL certificates is only a
good thing.

------
z3t4
Since most browsers now a days support SSL/TSL it's safe to redirect all
traffic from http to the same url on httpS.

------
dmd
Off 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?

~~~
moskie
I _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
I 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.

------
billpg
If 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
Delivering a TLS certificate over HTTP is useless as a MITM can simply
substitute his own certificate.

~~~
billpg
Just 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.

------
steve371
Looks like ppl didn't listen. I saw more https movement this days. and surely
enough, it breaks...lots of stuff.

------
dmh2000
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?

~~~
niftich
The 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-
everywh...](https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/)

[2] [https://www.eff.org/https-everywhere/faq#faq-When-does-
HTTPS...](https://www.eff.org/https-everywhere/faq#faq-When-does-HTTPS-
Everywhere-protect-me?-When-does-it-not-protect-me)?

~~~
dmh2000
thanks

------
lifthrasiir
Just 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:).

~~~
geofft
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://](http://) URLs to [https://](https://), accomplishing the
goal requested in this article without the security risks of
optional/opportunistic encryption.

~~~
dietrichepp
Only after you visit a domain.

~~~
niftich
Or if you preload with a browser vendor, which in all fairness doesn't scale
in its current incarnation.

~~~
strcat
It'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
[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/...](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json)

[2] [https://dxr.mozilla.org/comm-
central/source/mozilla/security...](https://dxr.mozilla.org/comm-
central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc)

~~~
icebraining
The page linked above has instructions for removal.

~~~
niftich
Yes, 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.

------
heimatau
This is from early 2015. Should be noted in the title, since it more than 18
months old.

