5 ms·

I’ll agree to disagree, because otherwise the conversation would be moot. I just disagree that we should “HTTPS” everything and that’s partly because of the ov

I’ll agree to disagree, because otherwise the conversation would be moot. I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. A medical site is different to a static html site like listed in the post. ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application. “run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.

MaxBarraclough 7y ago
> the overhead The computational overhead is negligible. This simply isn't a credible argument against HTTPS. Netflix send petabytes of data over HTTPS. There's no excuse for anyone else. > A medical site is different to a static html site like listed in the post. Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you. > ISP regardless of SSL know which sites I’m visiting They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal. > It’s there in the HTTP host header regardless of SSL or not. That's not the case. HTTPS encrypts all headers. > transit security can easily be encrypted without SSL The easy solution is HTTPS. > people are too lazy to encrypt their content within the application. A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0]. When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app. Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript. > When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages. > I don’t dismiss that HTTPS is important but I feel platform is flawed. You've not presented a single good argument against the technical merits of HTTPS. > Owned by corporate greed. It’s security based upon pay us money or else model. You can get certs for free. This isn't new. [1] [0] https://justi.cz/security/2019/01/22/apt-rce.html https://justi.cz/security/2019/01/22/apt-rce.html [1] https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt
- bityard 7y ago
  > Netflix send petabytes of data over HTTPS. There's no excuse for anyone else. Uhh, yes, indeed... manufacturing cars is so cheap these days, even General Motors can do it... > That's not the case. HTTPS encrypts all headers. That's not the case. HTTP uses SNI (for now): https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
  - MaxBarraclough 7y ago
    > manufacturing cars is so cheap these days, even General Motors can do it... Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. Long answer: that's disanalogous. Manufacturing works with economy of scale. Netflix have it worse than the rest of us. They have to deliver tens of gigabytes per month per customer, using roughly the same hardware as the rest of us. According to that Ars Technica article, they did their usual Netflix-ey software optimisations with FreeBSD, but their hardware isn't customised for the job. Their scale doesn't much help them. If HTTPS overheads would put anyone out of business, it would be Netflix, but here we are: they voluntarily added HTTPS for their streams. Again, as I think it bears stressing: these guys are transmitting about 15% of all data-flow across the Internet. Out of all the HTTPS traffic in the entire world (measured by gigabytes, admittedly discounting number of connections established), Netflix handles at least 15% of it. They do so voluntarily. Same goes for YouTube. If you can think of a business model where HTTPS overheads would cause more trouble than they do for Netflix and YouTube, I'd like to hear it. > That's not the case. HTTP uses SNI (for now) Thanks, I wasn't aware of SNI. I don't think it gives much more away though, does it? Someone spying on my line can already see the IP address I'm connecting to. They already know I'm connecting to Wikipedia. They still can't see the specific page I'm requesting. SNI only leaks information where multiple sites are hosted on the same public IP, right? [0] https://www.keycdn.com/blog/https-performance-overhead https://www.keycdn.com/blog/https-performance-overhead
    - bencollier49 7y ago
      > Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. That's incorrect. Plenty of people browse the net on Z80 based machines. HTTPS borks that, the computers aren't fast enough to run the decryption. There are a lot of assumptions being made in this conversation which may be quite inaccurate.
RKearney 7y ago
You are grossly misinformed on this subject. > I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. The overhead in any modern CPU is negligible. If you're worried about negligible overhead then why are you using an entire operating system to serve up web pages? > ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. The host header is encrypted over HTTPS. Furthermore, SSL isn't used in 2019 as it's insecure and was replaced with TLS. That might be pedantic but it seems to align with what this post is about so I'll mention it. You're confusing the host header with the server name indication sent in the client hello. There is a huge difference between my ISP knowing I went to example.com (with TLS) or example.com/medical/how_to_deal_with_cancer.html (without HTTPS) > And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application. I'm not sure what you're suggesting here. The industry standard transport security for HTTP is TLS. Trying to re-invent the wheel is counterproductive and dangerous. > “run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. Then don't. The specification for the acme protocol is open and available to you. You could automate the entire process and even choose a DNS based challenge. Typical use of cerbot, should you choose to use it, does not "mess with your configuration". > I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model. It literally isn't because Let's Encrypt gives out certs for free. Additionally, so does AWS, Azure, and GCP. If you're paying for a certificate you're doing it wrong. You have always been free to use self-signed certificates, but then the challenge of convincing your visitors that your certificate really is from you and not someone else who created a self-signed certificate becomes your problem to manage.
- MaxBarraclough 7y ago
  I made all these points 2 hours ago.

MaxBarraclough 7y ago

> the overhead The computational overhead is negligible. This simply isn't a credible argument against HTTPS. Netflix send petabytes of data over HTTPS. There's no excuse for anyone else. > A medical site is different to a static html site like listed in the post. Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you. > ISP regardless of SSL know which sites I’m visiting They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal. > It’s there in the HTTP host header regardless of SSL or not. That's not the case. HTTPS encrypts all headers. > transit security can easily be encrypted without SSL The easy solution is HTTPS. > people are too lazy to encrypt their content within the application. A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0]. When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app. Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript. > When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages. > I don’t dismiss that HTTPS is important but I feel platform is flawed. You've not presented a single good argument against the technical merits of HTTPS. > Owned by corporate greed. It’s security based upon pay us money or else model. You can get certs for free. This isn't new. [1] [0] https://justi.cz/security/2019/01/22/apt-rce.html https://justi.cz/security/2019/01/22/apt-rce.html [1] https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt

bityard 7y ago
> Netflix send petabytes of data over HTTPS. There's no excuse for anyone else. Uhh, yes, indeed... manufacturing cars is so cheap these days, even General Motors can do it... > That's not the case. HTTPS encrypts all headers. That's not the case. HTTP uses SNI (for now): https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
- MaxBarraclough 7y ago
  > manufacturing cars is so cheap these days, even General Motors can do it... Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. Long answer: that's disanalogous. Manufacturing works with economy of scale. Netflix have it worse than the rest of us. They have to deliver tens of gigabytes per month per customer, using roughly the same hardware as the rest of us. According to that Ars Technica article, they did their usual Netflix-ey software optimisations with FreeBSD, but their hardware isn't customised for the job. Their scale doesn't much help them. If HTTPS overheads would put anyone out of business, it would be Netflix, but here we are: they voluntarily added HTTPS for their streams. Again, as I think it bears stressing: these guys are transmitting about 15% of all data-flow across the Internet. Out of all the HTTPS traffic in the entire world (measured by gigabytes, admittedly discounting number of connections established), Netflix handles at least 15% of it. They do so voluntarily. Same goes for YouTube. If you can think of a business model where HTTPS overheads would cause more trouble than they do for Netflix and YouTube, I'd like to hear it. > That's not the case. HTTP uses SNI (for now) Thanks, I wasn't aware of SNI. I don't think it gives much more away though, does it? Someone spying on my line can already see the IP address I'm connecting to. They already know I'm connecting to Wikipedia. They still can't see the specific page I'm requesting. SNI only leaks information where multiple sites are hosted on the same public IP, right? [0] https://www.keycdn.com/blog/https-performance-overhead https://www.keycdn.com/blog/https-performance-overhead
  - bencollier49 7y ago
    > Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. That's incorrect. Plenty of people browse the net on Z80 based machines. HTTPS borks that, the computers aren't fast enough to run the decryption. There are a lot of assumptions being made in this conversation which may be quite inaccurate.

RKearney 7y ago

You are grossly misinformed on this subject. > I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. The overhead in any modern CPU is negligible. If you're worried about negligible overhead then why are you using an entire operating system to serve up web pages? > ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. The host header is encrypted over HTTPS. Furthermore, SSL isn't used in 2019 as it's insecure and was replaced with TLS. That might be pedantic but it seems to align with what this post is about so I'll mention it. You're confusing the host header with the server name indication sent in the client hello. There is a huge difference between my ISP knowing I went to example.com (with TLS) or example.com/medical/how_to_deal_with_cancer.html (without HTTPS) > And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application. I'm not sure what you're suggesting here. The industry standard transport security for HTTP is TLS. Trying to re-invent the wheel is counterproductive and dangerous. > “run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. Then don't. The specification for the acme protocol is open and available to you. You could automate the entire process and even choose a DNS based challenge. Typical use of cerbot, should you choose to use it, does not "mess with your configuration". > I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model. It literally isn't because Let's Encrypt gives out certs for free. Additionally, so does AWS, Azure, and GCP. If you're paying for a certificate you're doing it wrong. You have always been free to use self-signed certificates, but then the challenge of convincing your visitors that your certificate really is from you and not someone else who created a self-signed certificate becomes your problem to manage.

MaxBarraclough 7y ago
I made all these points 2 hours ago.