9 ms·

> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampe

by mholt 9y ago

> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countless research papers. And real-world attacks that are reported over and over again. The fact is that the global Web has become hostile, regardless of your prejudice against Google's Web security teams. > In many cases the cost of the security is not worth it. The problem is that it's not YOUR security, it's other people's. If websites don't implement HTTPS, it's the users of the Web who pay the price. It's their privacy being deprived. And the website becomes easy to impersonate and manipulate, increasing the liability of having a website. HTTP is bad news all around.

pwnna 9y ago
What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.
- vertex-four 9y ago
  Clients for this aren’t web browsers. Making browsers warn about them doesn’t break anything.
- geofft 9y ago
  HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to deb https://deb.debian.org/debian stable main HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security. And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain. (Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)
  - pwnna 9y ago
    I'm not talking about a mirror, which has a different domain name. I'm talking about a transparent cache like squid. This will mean I don't have to change the OS images that I might not even control in order to get traffic savings, whereas under your model I would have to, which again, may not even be feasible.
- madeofpalk 9y ago
  > What about hosting HTTP content because you verify GPG signatures upon download If you're doing this, then you've made your own HTTP client so you can do whatever you want. "HTTPS Everywhere" is a web browser thing.
  - pwnna 9y ago
    So it's just bad naming. Everywhere to me implies everywhere, not just everywhere in the browser. Regardless, it looks like there are still people confused about it like me discussing in this thread, tho.
- jen20 9y ago
  There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
  - jwilk 9y ago
    On HN: https://news.ycombinator.com/item?id=16432435 https://news.ycombinator.com/item?id=16432435
- jopsen 9y ago
  I'm actually surprised debian repos are still HTTP. Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror. But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win. Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago. There will always be bugs, we can only hope they aren't exposed concurrently :)
  - zenhack 9y ago
    That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.
    - asdbffg 9y ago
      Indeed. The same is also true for repositories, served via SSL. Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size. Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?! As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right? SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.
      - jopsen 9y ago
        TLS is getting better and there is a LOT of momentum to this. I bet the SNI issues will eventually be fixed too. And yes, with momentum behind certificate transparency, it could definitely hold CAs to the fire :) TLS is no silver bullet, but it's a good base layer to always add.
- staticassertion 9y ago
  > What about hosting HTTP content because you verify GPG signatures upon download? Because the rest of the content is not verified?????? That's the whole point of HTTPS????????
  - pwnna 9y ago
    I didn't downvote this and this is a valid misunderstanding. The whole point of having GPG is that you (as the distributor/debian repo/whatever) have already somehow distributed the public key to your clients (customers/debian installations/whatever). Having HTTPS is redundant as it is presumed that initial key distribution was done securely.
eric_b 9y ago
> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What happens when Let's Encrypt is down for an extended period? What happens when someone compromises them? > And real-world attacks that are reported over and over again. Care to link to a few? > The problem is that it's not YOUR security, it's other people's. Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?
- mjmasn 9y ago
  > Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users? Without TLS how do YOU know that the user is receiving your static resume. Any MitM can tamper with the connection and replace your content with something malicious. With properly configured TLS that's simply not possible (with the exception you describe in corporate settings where BlueCoat's cert has to be added to the machine's trust store in order for that sniffing to be possible). Hopefully in the future even that wont be possible.
  - mholt 9y ago
    And web servers can even detect TLS MITM: https://caddyserver.com/docs/mitm-detection https://caddyserver.com/docs/mitm-detection
- CaptSpify 9y ago
  > Oh, so you know better than me what kind of content is on my site? The content of your site is irrelevant. We do know that your lack of concern for your user's safety is a problem though. I also wish that managing certs was better, but until then, passing negative externalities to your users is pretty sleazy.
- 0x0 9y ago
aplorbust 9y ago
"It's their privacy being deprived." I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. Will these "advances" benefit users more than they benefit the companies serving ads, collecting user data and "overseeing the www" generally? Is there a trade-off? To users, will protecting traffic from manipulation be viewed as a step forward if as a result they only see an increase in ads and data collection? Even more, perhaps they will have limited ability to "see" the increase in data collection if they have effectively no control over the encryption process. (e.g., too complex, inability to monitor the data being sent, etc.)
- icebraining 9y ago
  I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. We're talking only by HTTPS. Adding HTTP/2 is just mudding the conversation. Care to give any argument on how does adding a TLS layer over the exact same protocol (HTTP/1.1) will be used to do that?
  - aplorbust 9y ago
    /I wonder/s/HTTPS/TLS/
z3t4 9y ago
Those who you trust with your internet browsing is usually also those who you trust with HTTPS certificates. Eg. Your browser, your operating system, your ISP, et.al are still able to spy on you unless the site uses certificate pinning, which is unfortunately not feasible with Letsencrypt due to certs only lasting 3 months.

by mholt 9y ago

pwnna 9y ago

What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.

vertex-four 9y ago
Clients for this aren’t web browsers. Making browsers warn about them doesn’t break anything.
geofft 9y ago
HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to deb https://deb.debian.org/debian stable main HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security. And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain. (Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)
- pwnna 9y ago
  I'm not talking about a mirror, which has a different domain name. I'm talking about a transparent cache like squid. This will mean I don't have to change the OS images that I might not even control in order to get traffic savings, whereas under your model I would have to, which again, may not even be feasible.
madeofpalk 9y ago
> What about hosting HTTP content because you verify GPG signatures upon download If you're doing this, then you've made your own HTTP client so you can do whatever you want. "HTTPS Everywhere" is a web browser thing.
- pwnna 9y ago
  So it's just bad naming. Everywhere to me implies everywhere, not just everywhere in the browser. Regardless, it looks like there are still people confused about it like me discussing in this thread, tho.
jen20 9y ago
There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
- jwilk 9y ago
  On HN: https://news.ycombinator.com/item?id=16432435 https://news.ycombinator.com/item?id=16432435
jopsen 9y ago
I'm actually surprised debian repos are still HTTP. Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror. But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win. Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago. There will always be bugs, we can only hope they aren't exposed concurrently :)
- zenhack 9y ago
  That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.
  - asdbffg 9y ago
    Indeed. The same is also true for repositories, served via SSL. Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size. Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?! As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right? SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.
    - jopsen 9y ago
      TLS is getting better and there is a LOT of momentum to this. I bet the SNI issues will eventually be fixed too. And yes, with momentum behind certificate transparency, it could definitely hold CAs to the fire :) TLS is no silver bullet, but it's a good base layer to always add.
staticassertion 9y ago
> What about hosting HTTP content because you verify GPG signatures upon download? Because the rest of the content is not verified?????? That's the whole point of HTTPS????????
- pwnna 9y ago
  I didn't downvote this and this is a valid misunderstanding. The whole point of having GPG is that you (as the distributor/debian repo/whatever) have already somehow distributed the public key to your clients (customers/debian installations/whatever). Having HTTPS is redundant as it is presumed that initial key distribution was done securely.

eric_b 9y ago

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What happens when Let's Encrypt is down for an extended period? What happens when someone compromises them? > And real-world attacks that are reported over and over again. Care to link to a few? > The problem is that it's not YOUR security, it's other people's. Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?

mjmasn 9y ago
> Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users? Without TLS how do YOU know that the user is receiving your static resume. Any MitM can tamper with the connection and replace your content with something malicious. With properly configured TLS that's simply not possible (with the exception you describe in corporate settings where BlueCoat's cert has to be added to the machine's trust store in order for that sniffing to be possible). Hopefully in the future even that wont be possible.
- mholt 9y ago
  And web servers can even detect TLS MITM: https://caddyserver.com/docs/mitm-detection https://caddyserver.com/docs/mitm-detection
CaptSpify 9y ago
> Oh, so you know better than me what kind of content is on my site? The content of your site is irrelevant. We do know that your lack of concern for your user's safety is a problem though. I also wish that managing certs was better, but until then, passing negative externalities to your users is pretty sleazy.
0x0 9y ago

aplorbust 9y ago

"It's their privacy being deprived." I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. Will these "advances" benefit users more than they benefit the companies serving ads, collecting user data and "overseeing the www" generally? Is there a trade-off? To users, will protecting traffic from manipulation be viewed as a step forward if as a result they only see an increase in ads and data collection? Even more, perhaps they will have limited ability to "see" the increase in data collection if they have effectively no control over the encryption process. (e.g., too complex, inability to monitor the data being sent, etc.)

icebraining 9y ago
I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. We're talking only by HTTPS. Adding HTTP/2 is just mudding the conversation. Care to give any argument on how does adding a TLS layer over the exact same protocol (HTTP/1.1) will be used to do that?
- aplorbust 9y ago
  /I wonder/s/HTTPS/TLS/

z3t4 9y ago

Those who you trust with your internet browsing is usually also those who you trust with HTTPS certificates. Eg. Your browser, your operating system, your ISP, et.al are still able to spy on you unless the site uses certificate pinning, which is unfortunately not feasible with Letsencrypt due to certs only lasting 3 months.