9 ms·

> 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 to

by 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
A lot of ISPs, some huge like the "XfinityWifi" SSID, routinely inject their own javascript in HTTP pages. Some even take no care to namespace their javascript and wreck a party on your window globals, too.
- peterwwillis 9y ago
  This could be solved without HTTPS. People choose not to for ideological reasons.
  - Liquid_Fire 9y ago
    How would you solve it without HTTPS?
    - peterwwillis 9y ago
      By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser would verify the checksum before rendering the page. However, if you can modify the payload, you could also modify this header. The next method is to use a cryptographic signature. By signing the checksum, you can use a public key to verify the checksum was created by the origin. However, if the first transfer of the public key is not secure, an attacker can replace it with their own public key, making it impossible to tell if this is the origin's content. One way to solve this is with PKI. If a client maintains a list of trusted certificate authorities, it can verify signed messages in a way that an attacker cannot circumvent by injection. Now we can verify not only that the payload has not changed, but also who signed it (which key, or certificate). Note that this does not require a secure transport tunnel. Your payload is in the clear, and thus can be easily cached and proxied by any intermediary, but they can not change your data. So why don't we do this? Simple: the people who have the most influence over these technologies do not want plaintext data on the network, even if its authenticity and integrity are assured. They value privacy over all else, to the point of detriment to users and organizations who would otherwise benefit from such capability.
orf 9y ago
It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up. Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.
- vbezhenar 9y ago
  It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.
  - niij 9y ago
    >wosign Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...
    - vbezhenar 9y ago
      I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.
      - niij 9y ago
        There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy. [0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhstan_wants_citizens_to_download_a_mandatory_national_security_certificate.html http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...
Karunamon 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? Absolutely yes. Without that layer of security, anyone looking at your resume could either be served something that's not your resume (to your professional detriment) or more likely, the malware-of-the-week. (Also to your professional detriment). Do you care for the general safety of web users? Secure your shit. If not for them, for your own career.
- mynameisvlad 9y ago
  So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described. But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely for most people. The second case I can see happening more in theory as it's less discriminating, but does it actually happen often enough in real life to the point where it's a real concern? FWIW, I have HTTPS on all my websites (because, as everyone mentioned already, it's dead simple to add) including personal and internal, but I still question the probability of an attack on any of them actually happening.
  - EtDybNuvCu 9y ago
    I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.
    - mynameisvlad 9y ago
      Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause the user to actually notice because then their ass is going to be on the line when it's exposed that Comcast installed viruses on millions of computers or stole everyone's data. - Or you can be MitMed specifically, which will cause professional detriment, but would require someone to specifically target you and your users. And I don't see this as that likely for the average Joe. Really, what I would like to know is: How realistic is it that I, as a site owner, will be adversely affected by the MitM that could theoretically happen to my users on HTTP?
sydli 9y ago
> Care to link a few? From Friday, in which Turkey takes advantage of HTTP downloads to install spyware on YPG computers: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlo... From a couple months ago, where Comcast injects JavaScript into HTTP connections: http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/td-p/3009551 http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/...

by eric_b 9y ago

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

A lot of ISPs, some huge like the "XfinityWifi" SSID, routinely inject their own javascript in HTTP pages. Some even take no care to namespace their javascript and wreck a party on your window globals, too.

peterwwillis 9y ago
This could be solved without HTTPS. People choose not to for ideological reasons.
- Liquid_Fire 9y ago
  How would you solve it without HTTPS?
  - peterwwillis 9y ago
    By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser would verify the checksum before rendering the page. However, if you can modify the payload, you could also modify this header. The next method is to use a cryptographic signature. By signing the checksum, you can use a public key to verify the checksum was created by the origin. However, if the first transfer of the public key is not secure, an attacker can replace it with their own public key, making it impossible to tell if this is the origin's content. One way to solve this is with PKI. If a client maintains a list of trusted certificate authorities, it can verify signed messages in a way that an attacker cannot circumvent by injection. Now we can verify not only that the payload has not changed, but also who signed it (which key, or certificate). Note that this does not require a secure transport tunnel. Your payload is in the clear, and thus can be easily cached and proxied by any intermediary, but they can not change your data. So why don't we do this? Simple: the people who have the most influence over these technologies do not want plaintext data on the network, even if its authenticity and integrity are assured. They value privacy over all else, to the point of detriment to users and organizations who would otherwise benefit from such capability.

orf 9y ago

It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up. Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.

vbezhenar 9y ago
It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.
- niij 9y ago
  >wosign Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...
  - vbezhenar 9y ago
    I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.
    - niij 9y ago
      There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy. [0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhstan_wants_citizens_to_download_a_mandatory_national_security_certificate.html http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...

Karunamon 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? Absolutely yes. Without that layer of security, anyone looking at your resume could either be served something that's not your resume (to your professional detriment) or more likely, the malware-of-the-week. (Also to your professional detriment). Do you care for the general safety of web users? Secure your shit. If not for them, for your own career.

mynameisvlad 9y ago
So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described. But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely for most people. The second case I can see happening more in theory as it's less discriminating, but does it actually happen often enough in real life to the point where it's a real concern? FWIW, I have HTTPS on all my websites (because, as everyone mentioned already, it's dead simple to add) including personal and internal, but I still question the probability of an attack on any of them actually happening.
- EtDybNuvCu 9y ago
  I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.
  - mynameisvlad 9y ago
    Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause the user to actually notice because then their ass is going to be on the line when it's exposed that Comcast installed viruses on millions of computers or stole everyone's data. - Or you can be MitMed specifically, which will cause professional detriment, but would require someone to specifically target you and your users. And I don't see this as that likely for the average Joe. Really, what I would like to know is: How realistic is it that I, as a site owner, will be adversely affected by the MitM that could theoretically happen to my users on HTTP?

sydli 9y ago

> Care to link a few? From Friday, in which Turkey takes advantage of HTTP downloads to install spyware on YPG computers: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlo... From a couple months ago, where Comcast injects JavaScript into HTTP connections: http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/td-p/3009551 http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/...