Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS Everywhere, not https: URIs (2015)

w3.org

Post reply on HN
Print view View original

41–50 of 94 posts

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

#41

Post by noja »

btrask wrote: post #16

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…

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

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

#42

Post by markild »

noja wrote: post #41
btrask wrote: post #16

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…

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

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.

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

#43

Post by pcl »

winteriscoming wrote: post #38
btrask wrote: post #16

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…

>> If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Can you explain what you mean by this? Genuinely curious to know how it can lead to DoS?

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.

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

#44

Post by Matt3o12_ »

strcat wrote: post #15
niftich wrote: post #11

Earlier quoted context omitted.

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

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.

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

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

#45

Post by chrisseaton »

noja wrote: post #41
btrask wrote: post #16

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…

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

I'm not sure you can assume that the same URL with https will be the same content as at http. It could be an entirely different site that you may not have wanted.

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

#46

Post by ATsch »

noja wrote: post #41
btrask wrote: post #16

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…

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

what if you block the https request in some way? You can now force an Insecure connection.

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

#47

Post by breatheoften »

pcl wrote: post #43
winteriscoming wrote: post #38

Earlier quoted context omitted.

>> If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Can you explain what you mean by this? Genuinely curious to know how it can lead to DoS?

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.

That seems like a good idea -- a simple scheme where the browser validates every http response from a particular domain against a key specified in that domain's SSL cert (if the appropriate field is present in the https cert) -- seems like it would work well?

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

#48

Post by anewhnaccount »

breatheoften wrote: post #47
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.

That seems like a good idea -- a simple scheme where the browser validates every http response from a particular domain against a key specified in that domain's SSL cert (if the appropriate field is present in the https cert) -- seems like it would work well?

This is what MEGA does. See: https://github.com/meganz/webclient/blob/master/secureboot.j...

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

#49

Post by anewhnaccount »

dcw303 wrote: post #3

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"

Protocol-less urls use the same protocol as the current page. This resolves nothing.

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

#50

Post by breakingcups »

schallertd wrote: post #12

5-10 years and 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...

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.
Post reply on HN