5 ms·

> If someone nefarious wanted to MITM my web site, the easiest would be to spoof DNS so it went to some other host, and do the MITM that way. Your ISP could do

> If someone nefarious wanted to MITM my web site, the easiest would be to spoof DNS so it went to some other host, and do the MITM that way. Your ISP could do that to you, no? That's what certificates are for. While certificate authorities can also be compromised, most ISPs don't run their own so they'd have to get a separate organization to cooperate with them to do this. > They aren't injecting ads into my blog. They are injecting ads into your transfer of files from my site. Why are you using an ISP which does that? This seems like a very strange semantic argument. From the customer's point of view they are injecting ads into your blog. Many people are not technically-savvy enough to understand that it's the ISP that's putting the ads in and not you. And for many people in the US and I'm sure also around the world they may not have a choice in ISP for a given level of service (would you choose dial-up or satellite over broadband if the only broadband provider that serves your area injects ads on non-secured pages?). > Again, what's the threat model? I'm pretty sure simple traffic analysis would be enough to figure out, based on download size and number of additional requests made, which pages are downloaded. The threat model is pervasive passive surveillance. The IETF recognizes this: https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258 HTTPS greatly increases the costs of such surveillance (you can no longer just look at the bytes on the wire, you need to closely examine the site the user is connecting to to correlate the amount of data transferred with specific pages on the site; for dynamic sites or sites using HTTP/2 this can be much harder). > Does it make a difference? Not to my argument, but I was genuinely curious what 10-year old phone anyone can consider usable today and the use-cases they have that still accommodate such old hardware. (I could see a basic non-smart phone still being useful, as long as the networks it supports are still active (which in the US will probably not be for more than another year or two)).

eesmith 6y ago
"That's what certificates are for" Could you explain that? I thought that if DNS were spoofed then people could be redirected anywhere else, no matter what the certificate said. I thought that could be mitigated by CAA records, but that too could be spoofed, eg, by your service provider. How do I prevent the government of China from MITM-ing access to my web site from someone in China, using a Chinese mobile phone with certificates pre-installed and automatically by the local Chinese telco? "This seems like a very strange semantic argument" I think you're making the strange argument. If I get a "free" cell phone which has a modified browser that inserted ads when viewing my web site, then from the customer's view those ads are on my site, right? But of course there's nothing I can do about that. Nor can you. So why place the responsibility on me? "if the only broadband provider that serves your area injects ads on non-secured pages" Have you not seen all of the ads for systems like SecureVPN? "pervasive passive surveillance" One of the pervasive passive surveillance attacks mentioned in the ietf link is traffic analysis, which I mentioned earlier. Can you guarantee that if I simply switch to https then the NSA could not use traffic analysis to figure out what users access from my static-pages, public-facing web site? Do you seriously think the NSA hasn't automated something as simple as remembering download sizes for each page, for a large number of web sites, in order to infer things like this? So do my readers gain any additional security against NSA surveillance by switching to https? Don't forget that my service provider (in the US) can be forced to reveal details and do tracing without telling me, including providing clear-text access to the logs. Since I cannot defend against NSA surveillance on my readers, I have to choose a threat model where I can make a difference. And I can't figure out who I should care to thwart, where https would make a meaningful difference. Clearly there are web providers which can and should use https to protect privacy against non-nation-state actors. Passwords, money, and the ability to insert code without review are three things which change the balance. But I don't see any benefit for my basic blog site that's been around for 20 years, and there appears to be a (small?) negative.
- MrRadar 6y ago
  > "That's what certificates are for" Could you explain that? I thought that if DNS were spoofed then people could be redirected anywhere else, no matter what the certificate said. This suggests you are not very familiar with how HTTPS works. I'll give you the short version, but I'd suggest you do a lot more reading into how TLS, public key cryptography, and certificate authorities work. Every site that wants to use HTTPS (in a way that doesn't trigger massive warnings in the client browser) has to obtain a certificate containing (among other things) the domain names that are authorized to use the certificate, a public cryptographic key, and a cryptographic signature from a certificate authority. The job of the certificate authority is to verify the person they are issuing the certificate for (by signing it) have control over the domains listed in the certificate. (Lets Encrypt's main innovation was to automate this process using the ACME protocol[1].) When you connect to a site over HTTPS the TLS handshake includes the certificate of the site and the handshake messages are signed using the private key corresponding to the public key in the certificate. This means that the client can verify the certificate is valid for the site they are connecting to (by matching they domain they are attempting to connect to against one of the domains in the certificate's list), the server they are talking to has the private key for that certificate (because the public key is embedded in the certificate which can be used to verify the signature produced using the private key), and that the certificate itself is valid because it is authorized by a certificate authority (by using the public key from the CA's root certificate, in the "root store" of the browser/OS, to verify the signature on the certificate). Additionally, once the handshake is completed all further traffic is encrypted and authenticated using an ephemeral key negotiated during the handshake. This means that you can trust the data coming over the wire is always coming from the correct server and has not been tampered with. (And as a side benefit it will detect any bit errors that occur during the connection, even those that are not caught by the TCP checksum, so you can be sure that e.g. large file transfers are not corrupt due to network errors.) In order to carry out a DNS spoofing attack against a site using HTTPS (with a valid certificate issued by a recognized certificate authority), you'd either need to steal the private key associated with the certificate (in which case you've probably compromised the target site deeply enough that you don't need to spoof their DNS) or you'd need to obtain a fraudulent certificate for that site that was nevertheless issued by a recognized certificate authority. Any CA that issued an invalid certificate is supposed to immediately revoke the certificate and if they mess up like that too often they run the risk of being delisted from browser/OS root stores (this has happened in the past). Additionally, Certificate Transparency logs (where a CA maintains a public log of all certificates they have authorized) and DNS CAA records (which restrict which certificate authorities can issue certificates for a given domain name) further make this type of mis-issuance harder to carry out and easier to detect. > How do I prevent the government of China from MITM-ing access to my web site from someone in China, using a Chinese mobile phone with certificates pre-installed and automatically by the local Chinese telco? If the device itself is compromised there's nothing HTTPS can do. However, that scenario is outside of the scope of HTTPS. The threat model for HTTPS is bad actors in between a trusted service and a trusted client wanting to surveil or modify the traffic as it transits their networks. It is extremely effective at that. > If I get a "free" cell phone which has a modified browser that inserted ads when viewing my web site, then from the customer's view those ads are on my site, right? Again, if the user's device is compromised that's outside of your control and is not your fault. However, if you do not use HTTPS then anyone in between your site and the end-user's device can monitor or meddle with the connection and you do have a choice to use HTTPS to avoid that. > Have you not seen all of the ads for systems like SecureVPN? That still means you have to trust the VPN service and their upstream providers not to do these things. With HTTPS you are guaranteed to have protection all the way from your server to the client device. > Can you guarantee that if I simply switch to https then the NSA could not use traffic analysis to figure out what users access from my static-pages, public-facing web site? Obviously the NSA (and other state actors) could almost certainly figure out what any given person was looking at even if they were using HTTPS. The point of HTTPS is to increase the cost of doing such a thing from near 0 to significantly greater than 0. You can no longer just slurp up the bytes as they pass through a middle network, you have to actively catalog the site in question and perform statistical analysis to get that information. What HTTPS will protect you against are ISPs and other middle networks monitoring your web browsing activity to sell that data to advertisers. This is a serious enough concern that the FTC asked the major US ISPs to provide information on what data they do sell about their customers[2]. And that's on top of the ad injection scenario I've already outlined. [1] https://tools.ietf.org/html/rfc8555 https://tools.ietf.org/html/rfc8555 [2] https://arstechnica.com/tech-policy/2019/03/ftc-investigates-whether-isps-sell-your-browsing-history-and-location-data/ https://arstechnica.com/tech-policy/2019/03/ftc-investigates...

eesmith 6y ago

"That's what certificates are for" Could you explain that? I thought that if DNS were spoofed then people could be redirected anywhere else, no matter what the certificate said. I thought that could be mitigated by CAA records, but that too could be spoofed, eg, by your service provider. How do I prevent the government of China from MITM-ing access to my web site from someone in China, using a Chinese mobile phone with certificates pre-installed and automatically by the local Chinese telco? "This seems like a very strange semantic argument" I think you're making the strange argument. If I get a "free" cell phone which has a modified browser that inserted ads when viewing my web site, then from the customer's view those ads are on my site, right? But of course there's nothing I can do about that. Nor can you. So why place the responsibility on me? "if the only broadband provider that serves your area injects ads on non-secured pages" Have you not seen all of the ads for systems like SecureVPN? "pervasive passive surveillance" One of the pervasive passive surveillance attacks mentioned in the ietf link is traffic analysis, which I mentioned earlier. Can you guarantee that if I simply switch to https then the NSA could not use traffic analysis to figure out what users access from my static-pages, public-facing web site? Do you seriously think the NSA hasn't automated something as simple as remembering download sizes for each page, for a large number of web sites, in order to infer things like this? So do my readers gain any additional security against NSA surveillance by switching to https? Don't forget that my service provider (in the US) can be forced to reveal details and do tracing without telling me, including providing clear-text access to the logs. Since I cannot defend against NSA surveillance on my readers, I have to choose a threat model where I can make a difference. And I can't figure out who I should care to thwart, where https would make a meaningful difference. Clearly there are web providers which can and should use https to protect privacy against non-nation-state actors. Passwords, money, and the ability to insert code without review are three things which change the balance. But I don't see any benefit for my basic blog site that's been around for 20 years, and there appears to be a (small?) negative.

MrRadar 6y ago
> "That's what certificates are for" Could you explain that? I thought that if DNS were spoofed then people could be redirected anywhere else, no matter what the certificate said. This suggests you are not very familiar with how HTTPS works. I'll give you the short version, but I'd suggest you do a lot more reading into how TLS, public key cryptography, and certificate authorities work. Every site that wants to use HTTPS (in a way that doesn't trigger massive warnings in the client browser) has to obtain a certificate containing (among other things) the domain names that are authorized to use the certificate, a public cryptographic key, and a cryptographic signature from a certificate authority. The job of the certificate authority is to verify the person they are issuing the certificate for (by signing it) have control over the domains listed in the certificate. (Lets Encrypt's main innovation was to automate this process using the ACME protocol[1].) When you connect to a site over HTTPS the TLS handshake includes the certificate of the site and the handshake messages are signed using the private key corresponding to the public key in the certificate. This means that the client can verify the certificate is valid for the site they are connecting to (by matching they domain they are attempting to connect to against one of the domains in the certificate's list), the server they are talking to has the private key for that certificate (because the public key is embedded in the certificate which can be used to verify the signature produced using the private key), and that the certificate itself is valid because it is authorized by a certificate authority (by using the public key from the CA's root certificate, in the "root store" of the browser/OS, to verify the signature on the certificate). Additionally, once the handshake is completed all further traffic is encrypted and authenticated using an ephemeral key negotiated during the handshake. This means that you can trust the data coming over the wire is always coming from the correct server and has not been tampered with. (And as a side benefit it will detect any bit errors that occur during the connection, even those that are not caught by the TCP checksum, so you can be sure that e.g. large file transfers are not corrupt due to network errors.) In order to carry out a DNS spoofing attack against a site using HTTPS (with a valid certificate issued by a recognized certificate authority), you'd either need to steal the private key associated with the certificate (in which case you've probably compromised the target site deeply enough that you don't need to spoof their DNS) or you'd need to obtain a fraudulent certificate for that site that was nevertheless issued by a recognized certificate authority. Any CA that issued an invalid certificate is supposed to immediately revoke the certificate and if they mess up like that too often they run the risk of being delisted from browser/OS root stores (this has happened in the past). Additionally, Certificate Transparency logs (where a CA maintains a public log of all certificates they have authorized) and DNS CAA records (which restrict which certificate authorities can issue certificates for a given domain name) further make this type of mis-issuance harder to carry out and easier to detect. > How do I prevent the government of China from MITM-ing access to my web site from someone in China, using a Chinese mobile phone with certificates pre-installed and automatically by the local Chinese telco? If the device itself is compromised there's nothing HTTPS can do. However, that scenario is outside of the scope of HTTPS. The threat model for HTTPS is bad actors in between a trusted service and a trusted client wanting to surveil or modify the traffic as it transits their networks. It is extremely effective at that. > If I get a "free" cell phone which has a modified browser that inserted ads when viewing my web site, then from the customer's view those ads are on my site, right? Again, if the user's device is compromised that's outside of your control and is not your fault. However, if you do not use HTTPS then anyone in between your site and the end-user's device can monitor or meddle with the connection and you do have a choice to use HTTPS to avoid that. > Have you not seen all of the ads for systems like SecureVPN? That still means you have to trust the VPN service and their upstream providers not to do these things. With HTTPS you are guaranteed to have protection all the way from your server to the client device. > Can you guarantee that if I simply switch to https then the NSA could not use traffic analysis to figure out what users access from my static-pages, public-facing web site? Obviously the NSA (and other state actors) could almost certainly figure out what any given person was looking at even if they were using HTTPS. The point of HTTPS is to increase the cost of doing such a thing from near 0 to significantly greater than 0. You can no longer just slurp up the bytes as they pass through a middle network, you have to actively catalog the site in question and perform statistical analysis to get that information. What HTTPS will protect you against are ISPs and other middle networks monitoring your web browsing activity to sell that data to advertisers. This is a serious enough concern that the FTC asked the major US ISPs to provide information on what data they do sell about their customers[2]. And that's on top of the ad injection scenario I've already outlined. [1] https://tools.ietf.org/html/rfc8555 https://tools.ietf.org/html/rfc8555 [2] https://arstechnica.com/tech-policy/2019/03/ftc-investigates-whether-isps-sell-your-browsing-history-and-location-data/ https://arstechnica.com/tech-policy/2019/03/ftc-investigates...