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

81–90 of 94 posts

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

#81

Post by ukblewis »

nathanaldensr wrote: post #80
dmd wrote: post #79

Off topic, but I'm a native english speaker, and have never heard this construction before: "There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west." What does "and points west" mean here?

It's okay; I'm a native English speaker and I had trouble following much of Berners-Lee's grammar and writing style. He should consider editing the piece. I have no idea what "and points west" means in this context.

Yeah... His English is extremely hard to decipher (Native Brit here). I thought that the man that invented World Wide Web would write more eloquently...

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

#82

Post by moskie »

dmd wrote: post #79

Off topic, but I'm a native english speaker, and have never heard this construction before: "There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west." What does "and points west" mean here?

I think you can interpret "and points west" as "and beyond."

I think it's based on the expression "all points west." Can't find a good source at the moment. "Points" is used as a plural noun there, not a verb. So, I think the expression "all points west" means "all locations to the west," and used metaphorically here to mean "all things beyond."

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

#83

Post by ukblewis »

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.

That isn't really viable yet. Browser vendors could decide that they will introduce this functionality in a few years though.

IMHO, the feature would need to be implemented as some have suggested, by enabling any website to transmit securely or insecurely, but for the web browser to request a secure TLS connection first (trying HTTP and HTTPS to reduce incompatibilities) and if a website appeared to have issues, then try insecure connections. If an insecure page were to be served, the browser should indicate this with a broken padlock.

Furthermore, I believe that browsers should warn when any data is input, e.g. clicking items that cause JS calls or text is typed - this strict implementation is important. Single page JS applications have made it possible to send any input data via JSON, we cannot only warn the user on a form submission, since it would be very possible to capture details via AJAX. E.g. If I were impersonating an e-commerce solution, I could hope the user would not notice the padlock and use AJAX to send the data preventing any form submission warnings. This would be annoying for users when they were using such websites regularly, but this would be a good thing - pressuring websites that handle user inputs to act responsibly and use encryption via TLS.

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

#84

Post by pcl »

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.

Agreed that unencrypted signed static assets provide a vehicle for activity monitoring.

Your statement can be misinterpreted to imply that merely by encrypting all traffic, such analysis can be prevented. There's plenty of metadata in a typical encrypted page load that can be used to do so.

For example, the view-discussion page might download three static assets, a js file, and two CSS files, one small and one large, whereas the post-comment page might load zero assets and js files, and one small CSS file.

Point being, making a privacy-protecting website takes careful planning even when fully encrypted. As such, it'd be great to have tools (such as signed content) available for performance optimization. Sure, naive usage might lead to attack vectors, but naive usage of HTTPS already leafs to many such attack vectors anyways.

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

#85

Post by rspeer »

moskie wrote: post #82
dmd wrote: post #79

Off topic, but I'm a native english speaker, and have never heard this construction before: "There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west." What does "and points west" mean here?

I think you can interpret "and points west" as "and beyond." I think it's based on the expression "all points west." Can't find a good source at the moment. "Points" is used as a plural noun there, not a verb. So, I think the expression "all points west" means "all locations to the west," and used metaphorically here to mean "all things beyond."

I have heard the phrase "points west" used when listing the places where a train is going. After listing the next several stops, they say "...and points west" to sum up all the stops the train will make that are too far away to be worth listing.

So I guess it's a metaphor for the indefinite beyond that makes sense to people who live on the east coast of the US and ever take the train.

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

#86

Post by niftich »

icebraining wrote: post #62
niftich wrote: post #29

Earlier quoted context omitted.

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

Yes, the submission site talks about removal, and how it takes until the next major release of the browser for the changes to appear in the codebase, and every user will have to upgrade to pick up the changes.

If it were a HSTS preload registry service and API, that'd be different, but it's not.

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

#87

Post by dredmorbius »

nicky0 wrote: post #55
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…

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

Then the signatures don't match, or the fingerprint is wrong. If you're relying on long-term data access, messages encrypted against or signed by the true key don't match. This is an area in which PGP and SSH differ markedly. PGP is used to encrypt and authenticate data which tends to persist, SSH data used only in session. While both can use long-lived keypairs, it's the PGP keys you're more likely to notice changing (though SSH cclients tend to report this happening).

Yes, that means verifying your keys, and probably through an out-of-band method.

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

#88

Post by deadowl »

ckastner wrote: post #66

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 illustr…

The URL that's supposed to redirect to HTTPS is still vulnerable to MitM. It can be modified in transit to serve up the same data as the HTTPS URL, but in plaintext, and potentially with a different form action attribute, etc. There are different things that can help with that, but none of them universally protect privacy.

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

#89

Post by ckastner »

deadowl wrote: post #88
ckastner wrote: post #66

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 illustr…

The URL that's supposed to redirect to HTTPS is still vulnerable to MitM. It can be modified in transit to serve up the same data as the HTTPS URL, but in plaintext, and potentially with a different form action attribute, etc. There are different things that can help with that, but none of them universally protect privacy.

That would mean HTTPS is not necessarily an improvement security-wise, but that does not explain how it "completely breaks the web" by "breaking links to".

To be more specific, I'm referring to the "Don't break the Web" section in the article.

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

#90

Post by velox_io »

I used to think HTTPS everywhere was overkill, then I discovered HTTP2/ H2. H2 has some massive performance improvements and I believe we have barely scratched the surface of what is possible e.g. once the connection is established there's no need for additional HTTP handshakes, massively reducing latency.

I'm also a big fan of Let's encrypt, democratizing SSL certificates is only a good thing.

Post reply on HN