TLS Everywhere, not https: URIs (2015) • Hacker News Board

Re: TLS Everywhere, not https: URIs (2015)

#61

Post by billpg » Mon, Aug 08, 2016, 8:39 AM UTC

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.

Re: TLS Everywhere, not https: URIs (2015)

#62

Post by icebraining » Mon, Aug 08, 2016, 9:05 AM UTC

niftich wrote: post #29

strcat wrote: post #15

Earlier quoted context omitted.

It's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.

[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/... [2] https://dxr.mozilla.org/comm-central/source/mozilla/security...

The page linked above has instructions for removal.

Re: TLS Everywhere, not https: URIs (2015)

#63

Post by jstanley » Mon, Aug 08, 2016, 9:05 AM UTC

billpg wrote: post #61

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…

Delivering a TLS certificate over HTTP is useless as a MITM can simply substitute his own certificate.

Re: TLS Everywhere, not https: URIs (2015)

#64

Post by XorNot » Mon, Aug 08, 2016, 9:10 AM UTC

continuational wrote: post #56

pcl wrote: post #43

Earlier quoted context omitted.

One way would be to re-direct cacheable assets to HTTPS, thus foiling edge caching and increasing load on the origin server. In general, caching is a big problem with the naive approach to "HTTPS everywhere." A mechanism to deliver signed cacheable payloads would be great, so that static assets etc. can continue to be edge-cached.

It would still need to be encrypted, or I could tell a lot about what you're doing on the site by looking at what cacheable resources you fetch.

Not everything is about privacy, and arguably privacy advocates have done a lot to harm our ability to have a trusted internet by conflating verification, encryption and anonymity.

The most annoying thing about HTTPS everywhere is that it ruins cacheability. This is a problem the distros solved ages ago by signing their content but acknowledging it's mostly pointless hiding it in transit.

But its absurd that in HTTP2 we have out of the box encryption, but we don't have a mechanism for doing authenticated caching.

Re: TLS Everywhere, not https: URIs (2015)

#65

Post by billpg » Mon, Aug 08, 2016, 9:11 AM UTC

jstanley wrote: post #63

billpg wrote: post #61

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…

Delivering a TLS certificate over HTTP is useless as a MITM can simply substitute his own certificate.

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.

Re: TLS Everywhere, not https: URIs (2015)

#66

Post by ckastner » Mon, Aug 08, 2016, 9:24 AM UTC

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

Re: TLS Everywhere, not https: URIs (2015)

#67

Post by billpg » Mon, Aug 08, 2016, 9:27 AM UTC

billpg wrote: post #61

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

Re: TLS Everywhere, not https: URIs (2015)

#68

Post by michaelt » Mon, Aug 08, 2016, 9:34 AM UTC

AstralStorm wrote: post #52

markild wrote: post #42

Earlier quoted context omitted.

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.

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.

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

Re: TLS Everywhere, not https: URIs (2015)

#69

Post by z3t4 » Mon, Aug 08, 2016, 9:54 AM UTC

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

Re: TLS Everywhere, not https: URIs (2015)

#70

Post by amluto » Mon, Aug 08, 2016, 10:08 AM UTC

What exactly is he proposing? Without some additional change, if I make a link to 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.