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

21–30 of 94 posts

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

#21

Post by CydeWeys »

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

Because no one ever prohibited it (ignoring issues of whether that is a good idea), and it's way too late to change it now.

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

#22

Post by btrask »

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…

I said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.

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

#23

Post by michael_storm »

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…

> 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 associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained.

That's a possible alternative to btrask's proposal, though you're equating "assurance that the key belongs to whom you think it does" with "web of trust". btrask's proposal is a special case of that, in which the web of trust is simply the sender.

> The first problem you point out, that any encrypted channel is not necessarily a secure channel

Correct, but not what btrask said. The first problem he pointed out was the fact that clients need to know whether a host expects secure communication before ever connecting to it.

> though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion

That's not very nice.

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

#24

Post by iancarroll »

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.

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

#25

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

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

#26

Post by dredmorbius »

btrask wrote: post #22
dredmorbius wrote: post #19

Earlier quoted context omitted.

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…

I said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.

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?

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

#27

Post by dredmorbius »

michael_storm wrote: post #23
dredmorbius wrote: post #19

Earlier quoted context omitted.

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…

> 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 keys (I'm thinking PGP protocol here) of keys of interest. Either piece of information would reduce search space for an Eve.

I'm not equating trust of keys to web of trust, I'm stating that in existing (PKI/PGP) protocols, that is the assurance mechanism. And it is independent of either trust OR encryption of the key delivery channel itself.

There seems to be a rather profound difficulty in distinguishing what I've said with what I've said btrask said. I'm not sure how I could be clearer, but I'm open to pointers.

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

#28

Post by seandougall »

RubyPinch wrote: post #14
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"

I think its safe to say "it breaks the web" is from the user perspective, not the server. It only takes 1 server to serve differing content through each protocol to break things for the user

Yeah, but that's a subset of "misbehaving servers break the web" as far as I can tell. HTTPS doesn't inherently cause this problem, it just provides one theoretical nucleation point for it.

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

#29

Post by niftich »

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.

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

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

#30

Post by btrask »

dredmorbius wrote: post #26
btrask wrote: post #22

Earlier quoted context omitted.

I said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.

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.

Post reply on HN