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

31–40 of 94 posts

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

#31

Post by mintplant »

iancarroll wrote: post #24
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…

Chrome does preload public key pins for large sites, not that it's the ultimate solution to what you describe.

Firefox also does this.

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

#32

Post by dredmorbius »

btrask wrote: post #30
dredmorbius wrote: post #26

Earlier quoted context omitted.

And I still disagree on that point. Maybe I misunderstand (though I also think I understand teh issues involved pretty well), or maybe one or the other or both of us are communicating poorly. How would you distinguish a trusted, encrypted, and untrusted channels, say?

In the context of sharing public keys, I'd say you merely need authentication. Web of Trust being one possible mechanism. This isn't a particularly advanced topic. Relevant to my original post, information about whether the connection should be encrypted also merely needs to be authenticated, not encrypted itself. Of course, the HSTS preloading site uses HTTPS (with encryption) because it's easy and why not.

Thanks. So re keysharing, authentication is a form of secure channel.

I'm reading the auth and channel as independent. Auth is something of a metachannel, perhaps.

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

#33

Post by btrask »

dredmorbius wrote: post #32
btrask wrote: post #30

Earlier quoted context omitted.

In the context of sharing public keys, I'd say you merely need authentication. Web of Trust being one possible mechanism. This isn't a particularly advanced topic. Relevant to my original post, information about whether the connection should be encrypted also merely needs to be authenticated, not encrypted itself. Of course, the HSTS preloading site uses HTTPS (with encryption) because it's easy and why not.

Thanks. So re keysharing, authentication is a form of secure channel. I'm reading the auth and channel as independent. Auth is something of a metachannel, perhaps.

Fair enough. :)

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

#34

Post by michael_storm »

dredmorbius wrote: post #27
michael_storm wrote: post #23

Earlier quoted context omitted.

> 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. btrask wasn't saying that encryption is necessary for key distribution; he/she was saying that HTTPS guarantees identity and integrity, both of which are necessary to trust a key. > What matters is that the web of trust a…

Clarifying my own post: I'm insisting that neither a trusted or an ecrypted channel are necessary. I said that an encrypted channel could be used, and that it might not be , but that if used encryption would largely serve as a protection to the requestor , who might otherwise be subject to traffic and/or interest analysis based on the specific keys they requested, which could be presumed to be of interest, or signing…

You're both right. I only replied because you responded to points that btrask hadn't made, then claimed he/she misunderstood the topic.

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

#36

Post by jessaustin »

colejohnson66 wrote: post #18
Nadya wrote: post #8

Earlier quoted context omitted.

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…

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

Servers can really do whatever they want, based on whatever they want. They can serve a different page to clients based on e.g. "Accept-Language": "en" might be a completely different page than "fr", rather than just a translation.

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

#37

Post by yardstick »

colejohnson66 wrote: post #18
Nadya wrote: post #8

Earlier quoted context omitted.

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…

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

Technical reason: Multiple ports = multiple apps.

HTTP and HTTPS use different ports (TCP 80 and 443). You can run one web server application on the HTTP port serving content A, and a completely different web server application on the HTTPS port serving content B. With firewalls doing NAT port translation this could even result in HTTP requests going to a completely different machine than the HTTPS requests.

From a non-tech reason, there are some types of sites that the HTTPS content should never be available on a HTTP site. For example an online payment form. In such cases a sensible website will either disable HTTP entirely (and use a subdomain for secure content, rather than the top leve/ www. domain), or have a basic HTTP site that transparently redirects to the HTTPS version.

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

#38

Post by winteriscoming »

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?

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

#39

Post by marvy »

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?

the only way I can think of is if the site doesn't support https

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

#40

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