6 ms·

> I do not believe that there is data that is "not important enough to encrypt". I do believe this. When I visit a static web page over SSL people sniffing my

by jkire 11y ago

> I do not believe that there is data that is "not important enough to encrypt". I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. So why encrypt it? The benefit is that we can trust that static content really did come from that domain and wasn't changed by a MitM, but this can be solved by simply including a signature of the content rather than encrypting everything. SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Signing static content is essentially free, since we can pre-compute them. If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :)

azurezyq 11y ago
SSL has became significantly efficient on newer CPU w/ hardware supports. And even the static page itself may be not worth to steal, there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. Moreover, MitM can easily insert ads in the page without a SSL connection. I've ever interviewed some guy from a ISP contractor (not US), their business is to mine search queries from user URLs and inject targeted ads into static pages sent to user.
- jkire 11y ago
  > ...there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. And SSL should be used in those cases. I'm not saying you should never use SSL, I just don't buy the idea that you need to encrypt everything. Due to all the unencrypted bits like the IP address and DNS (and SNI?), sniffers can already guess what domains you're visiting anyway. Encrypting in those gives nothing that signing the plain text wouldn't. > ...MitM can easily insert ads in the page without a SSL connection Not if the response is also signed. (Assuming clients actually checked the signatures of course)
joepie91_ 11y ago
Author here. > I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. 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. > SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Being somebody who runs a HTTPS-only PDF hosting site off such a cheap VPS, I disagree. It does not make a meaningful impact on resource usage. I'm quite sure you could easily run a static site HTTPS-only from even a LowEndSpirit VPS - these are €3 per year. > If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :) 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. "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.
- 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.
vbcr 11y ago
> ...solved by simply including a signature of the content rather than encrypting everything. How do you deliver the signature to the client. If it is through the unencrypted channel, then the signature could also be MitM'd.

by jkire 11y ago

azurezyq 11y ago

SSL has became significantly efficient on newer CPU w/ hardware supports. And even the static page itself may be not worth to steal, there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. Moreover, MitM can easily insert ads in the page without a SSL connection. I've ever interviewed some guy from a ISP contractor (not US), their business is to mine search queries from user URLs and inject targeted ads into static pages sent to user.

jkire 11y ago
> ...there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. And SSL should be used in those cases. I'm not saying you should never use SSL, I just don't buy the idea that you need to encrypt everything. Due to all the unencrypted bits like the IP address and DNS (and SNI?), sniffers can already guess what domains you're visiting anyway. Encrypting in those gives nothing that signing the plain text wouldn't. > ...MitM can easily insert ads in the page without a SSL connection Not if the response is also signed. (Assuming clients actually checked the signatures of course)

joepie91_ 11y ago

Author here. > I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. 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. > SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Being somebody who runs a HTTPS-only PDF hosting site off such a cheap VPS, I disagree. It does not make a meaningful impact on resource usage. I'm quite sure you could easily run a static site HTTPS-only from even a LowEndSpirit VPS - these are €3 per year. > If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :) 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. "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.

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.

vbcr 11y ago

> ...solved by simply including a signature of the content rather than encrypting everything. How do you deliver the signature to the client. If it is through the unencrypted channel, then the signature could also be MitM'd.