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

51–60 of 94 posts

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

#51

Post by nateguchi »

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.

A good solution for HTTP sites is to load the https version after first loading over http. If they have similar content, show a bar at the top of the browser with a message along the lines of "A secure connection is possible, click here to go to use the secure version of this page".

Then it would be good to remember this setting and always pull the HTTPS.

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

#52

Post by AstralStorm »

markild wrote: post #42
noja wrote: post #41

Earlier quoted context omitted.

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

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.

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

#53

Post by AstralStorm »

anewhnaccount wrote: post #49
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.

Which is good. With TLS variant you would have to ensure that anyway for security reasons or you open doors to injection attacks. Mitigated by keep alive with pipelining and socket reuse, but there.

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

#54

Post by anewhnaccount »

AstralStorm wrote: post #53
anewhnaccount wrote: post #49

Earlier quoted context omitted.

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

Which is good. With TLS variant you would have to ensure that anyway for security reasons or you open doors to injection attacks. Mitigated by keep alive with pipelining and socket reuse, but there.

It has nothing to do with the points made in TFA.

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

#55

Post by nicky0 »

dredmorbius wrote: post #19
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…

Incorrect on public keys. You do not need a trusted channel to receive a key. You could receive one via smoke signal, carrier pigeon, or billboard. Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself . That last is independent of the key distribution channel. What matters is…

What if someone intercepts the carrier pigeon and swaps in a different public key of their own?

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

#56

Post by continuational »

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.

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.

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

#57

Post by noenpnqnoen »

breakingcups wrote: post #50
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.

That would break all Tor hidden services web servers (except Facebook).

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

#58

Post by voyou »

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 are usually a bad idea. They mean "use http or https depending on whatever the current page is", but there are very few situations where that is a useful way of making that decision. What you should do is specify https in the link, unless you know that the target site doesn't support https, in which case of course you have to specify http.

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

#59

Post by hello_there »

markild wrote: post #42
noja wrote: post #41

Earlier quoted context omitted.

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

They could display that same "this page is not secure"-page that they display on broken certificates.

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

#60

Post by belorn »

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 HTTP when you should've used HTTPS, I might be able to sniff your traffic

That is not worst case scenario. If someone can force http, they can also inject malicious code into the stream and do anything from bank transfers to create botnets. With the worst case scenario of always https being DoS, and worst case scenario of allowing http is code injection, I would prefer deprecating http in favor of https.

Post reply on HN