4 ms·

> The domain is not the same as the content. Far from it. Aside from that, a site being 'static' is not a meaningful data point here. For a lot of web pages th

by jkire 11y ago

> The domain is not the same as the content. Far from it. Aside from that, a site being 'static' is not a meaningful data point here. For a lot of web pages this is true, but what about sites like restaurant webpages? They have very few actual pages on their site, and they don't change depending on who is making the request. If I request the site over HTTPS, anybody that is sniffing my traffic will know that I'm visiting that domain and thus can request the content themselves. The encryption here is not providing anything. If you are sending/receiving personalized data, e.g. logins, search requests, etc., then you should be encrypting the requests. You would still be encrypting huge amounts of data for no reason, the CSS and static images used on the site are not being transmitted with or based on any personalized data, so any sniffer will already know that these resources would have been downloaded by you anyway (and I don't care if an attacker sees the CSS of a page I'm looking at anyway). Requesting these static resources over plain HTTP, but authenticated via hashes or signatures, doesn't provide an attacker with any information they wouldn't already have. > No, I do not. Tor is yet another dependency that needs to be available, and there are significant usability (and privacy!) concerns with routing all traffic over Tor. And yet Tor is the only way to actually protect against sniffers tracking which domains you visit. If we really care about encrypting all the content - including non-personalized, static content - then I don't see why we wouldn't also care about protecting the domains we visit. > "Everything should be encrypted" does not come at any cost. There are real-world problems that need solving before this can be made a reality. Just disabling non-TLS connections does not cut it. I totally agree with this. However I think I come to a different conclusion. TLS is usable precisely because of its insecurity that we have to trust so many CAs. The key problem with any encryption architecture is key distribution, more often than not the more secure the key distribution the less usable the end product is. Its (relatively) easy to get a TLS certificate for your domain that everyone else will trust, but precisely because its so easy makes TLS very vulnerable to malicious certificates. For the most part TLS is fine, it offers a certain level of security, but is still vulnerable. I'm happy to rely on TLS when browsing google search, online shopping etc, however I'm not particularly comfortable with using it for online banking, and I certainly wouldn't trust it for secure person-person communication. So instead of trying to fix TLS, I think we should have more choice for the different levels of security I desire: 1. No personalised data is being transmitted either way => I only need to authenticate the remote content, not encrypt it. 2. Personalized, but not particularly confidential information being transmitted, e.g. google search, shopping, logins for sites where its not the end of the world if they get stolen => TLS, there's a chance stuff will get intercepted, but it is convenient. 3. Highly confidential information is being transmitted => Some other protocol or cert distribution mechanism, e.g. for online banking I might only trust a certificate given to me directly by my bank IRL.

joepie91_ 11y ago
> For a lot of web pages this is true, but what about sites like restaurant webpages? They have very few actual pages on their site, and they don't change depending on who is making the request. If I request the site over HTTPS, anybody that is sniffing my traffic will know that I'm visiting that domain and thus can request the content themselves. The encryption here is not providing anything. The value of encryption as a whole increases when everything is encrypted, because it is harder for an adversary to distinguish "important" traffic from "unimportant traffic". It may not matter for that domain alone, but it certainly matters in the bigger picture. It significantly increases adversary cost. > If you are sending/receiving personalized data, e.g. logins, search requests, etc., then you should be encrypting the requests. You would still be encrypting huge amounts of data for no reason, the CSS and static images used on the site are not being transmitted with or based on any personalized data, so any sniffer will already know that these resources would have been downloaded by you anyway (and I don't care if an attacker sees the CSS of a page I'm looking at anyway). Requesting these static resources over plain HTTP, but authenticated via hashes or signatures, doesn't provide an attacker with any information they wouldn't already have. False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on every page. > And yet Tor is the only way to actually protect against sniffers tracking which domains you visit. If we really care about encrypting all the content - including non-personalized, static content - then I don't see why we wouldn't also care about protecting the domains we visit. It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity. > I totally agree with this. However I think I come to a different conclusion. [...] Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better. The "different levels" you suggest are pretty much already implemented as such, except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have.
- jkire 11y ago
  > The value of encryption as a whole increases when everything is encrypted, because it is harder for an adversary to distinguish "important" traffic from "unimportant traffic". Except you can classify a lot of traffic as unimportant by domain. If someone is trying to steal my bank account information encrypting all my other traffic isn't going to help. The easiest attack against TLS is to get a valid cert and then MitM, at which point it doesn't matter how much traffic you're sending to that domain. I would also be interested in knowing if sending more encrypted data down a TLS channel actually makes it harder to brute force; considering the tendencies for browsers to connection pool there will probably be (relatively) few actual distinct TLS connections. > False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on every page. Assets are cached by the browser, making it impossible to know if a newly downloaded page included those assets or not. Only downloading assets in plain that are on the root page or on the majority of pages mitigates this attack. (Also irrespective of if you used TLS, if you requested the HTML over TLS and it included hashes for all its static content you would have a much stronger guarantee over authenticity of downloaded assets if they came from CDNs. Hashing also makes caching much nicer and friendlier.) This feels more like an argument along the lines of "its not really worth having a separate method for doing authentication without encryption, it complicates things and probably won't be able to be used very often", which is perfectly valid and an argument I'm sympathetic to. It just doesn't support the notion that all data is important. > It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity. But you can tunnel TLS through Tor(?) The idea behind using Tor here is to stop attackers from being able to trivially tell which domains you're looking at. > Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better. My, probably badly worded, point is that its not as easy as saying "lets make it better". Making TLS more secure means coming up with a way of issuing certificates in a more trusted fashion; I don't see how you do that without making it harder to get a cert. The only other tech I'm aware of that is trying to address this is Perspective, but even that is not perfect. > The "different levels" you suggest are pretty much already implemented as such... Browsers are getting better at supporting pinning, but I don't think any allow you to manually add domains? Its not something that has been advertised and encouraged. My bank certainly doesn't advertise its certs fingerprints in their branches. > ...except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have. And I disagree with you, obviously. Unless there are actual, provable, benefits to enforcing encryption everywhere, I don't like the idea of anyone removing the ability for me to make the choice. If you think all data should be encrypted, by all means encrypt all your data. Personally, I don't care if an attacker knows what BBC articles I read. Yes, I know all the dangers that might befall me, but I've made an informed choice based on a risk analysis of my current situation and, well, I just really don't care one way or the other.

by jkire 11y ago

joepie91_ 11y ago

> For a lot of web pages this is true, but what about sites like restaurant webpages? They have very few actual pages on their site, and they don't change depending on who is making the request. If I request the site over HTTPS, anybody that is sniffing my traffic will know that I'm visiting that domain and thus can request the content themselves. The encryption here is not providing anything. The value of encryption as a whole increases when everything is encrypted, because it is harder for an adversary to distinguish "important" traffic from "unimportant traffic". It may not matter for that domain alone, but it certainly matters in the bigger picture. It significantly increases adversary cost. > If you are sending/receiving personalized data, e.g. logins, search requests, etc., then you should be encrypting the requests. You would still be encrypting huge amounts of data for no reason, the CSS and static images used on the site are not being transmitted with or based on any personalized data, so any sniffer will already know that these resources would have been downloaded by you anyway (and I don't care if an attacker sees the CSS of a page I'm looking at anyway). Requesting these static resources over plain HTTP, but authenticated via hashes or signatures, doesn't provide an attacker with any information they wouldn't already have. False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on every page. > And yet Tor is the only way to actually protect against sniffers tracking which domains you visit. If we really care about encrypting all the content - including non-personalized, static content - then I don't see why we wouldn't also care about protecting the domains we visit. It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity. > I totally agree with this. However I think I come to a different conclusion. [...] Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better. The "different levels" you suggest are pretty much already implemented as such, except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have.

jkire 11y ago
> The value of encryption as a whole increases when everything is encrypted, because it is harder for an adversary to distinguish "important" traffic from "unimportant traffic". Except you can classify a lot of traffic as unimportant by domain. If someone is trying to steal my bank account information encrypting all my other traffic isn't going to help. The easiest attack against TLS is to get a valid cert and then MitM, at which point it doesn't matter how much traffic you're sending to that domain. I would also be interested in knowing if sending more encrypted data down a TLS channel actually makes it harder to brute force; considering the tendencies for browsers to connection pool there will probably be (relatively) few actual distinct TLS connections. > False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on every page. Assets are cached by the browser, making it impossible to know if a newly downloaded page included those assets or not. Only downloading assets in plain that are on the root page or on the majority of pages mitigates this attack. (Also irrespective of if you used TLS, if you requested the HTML over TLS and it included hashes for all its static content you would have a much stronger guarantee over authenticity of downloaded assets if they came from CDNs. Hashing also makes caching much nicer and friendlier.) This feels more like an argument along the lines of "its not really worth having a separate method for doing authentication without encryption, it complicates things and probably won't be able to be used very often", which is perfectly valid and an argument I'm sympathetic to. It just doesn't support the notion that all data is important. > It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity. But you can tunnel TLS through Tor(?) The idea behind using Tor here is to stop attackers from being able to trivially tell which domains you're looking at. > Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better. My, probably badly worded, point is that its not as easy as saying "lets make it better". Making TLS more secure means coming up with a way of issuing certificates in a more trusted fashion; I don't see how you do that without making it harder to get a cert. The only other tech I'm aware of that is trying to address this is Perspective, but even that is not perfect. > The "different levels" you suggest are pretty much already implemented as such... Browsers are getting better at supporting pinning, but I don't think any allow you to manually add domains? Its not something that has been advertised and encouraged. My bank certainly doesn't advertise its certs fingerprints in their branches. > ...except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have. And I disagree with you, obviously. Unless there are actual, provable, benefits to enforcing encryption everywhere, I don't like the idea of anyone removing the ability for me to make the choice. If you think all data should be encrypted, by all means encrypt all your data. Personally, I don't care if an attacker knows what BBC articles I read. Yes, I know all the dangers that might befall me, but I've made an informed choice based on a risk analysis of my current situation and, well, I just really don't care one way or the other.