3 ms·

> When you connect to a site over HTTPS Right, but if DNS is spoofed then you haven't yet connected to the site, you've connected to another site, so none of t

> When you connect to a site over HTTPS Right, but if DNS is spoofed then you haven't yet connected to the site, you've connected to another site, so none of the security your described is relevant. How does https prevent DNS spoofing? As far as I know, it doesn't. You need DNS CAA records. Which your ISP can spoof just like it can intercept your unencrypted sessions. > 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. Earlier you talked about people who couldn't detect that ads were being injected into their browser. When you say "easier to detect", are you meaning easier to detect by people who don't recognize that their ISP injects ads? Is my readership able to recognize that their ISP is spoofing DNS for a MITM attack? How do I, right now check if my ISP is spoofing my DNS to MITM my access to my https site? 'Cause I have no clue. > However, that scenario is outside of the scope of HTTPS. Which was my point - what is the security threat I should care about? Look, I don't disagree that https has its place, and I'm fine with https on new systems. But again I ask what are the negatives? If I switch my site to https-only, how many people or devices will be negatively impacted? Can you answer that question? > The point of HTTPS is to increase the cost of doing such a thing from near 0 to significantly greater than 0. Which doesn't require https-everywhere, only https on most/significant number of places. > to sell that data to advertisers I've mentioned that that isn't a threat model that I or (I believe) my readership cares about. But let's examine it. I can ad a tracking pixel to each of my pages, right? And my readership won't notice it? And I could sell that information to advertisers? And I could put Facebook likes and other tracking methods in my pages? And you're fine with that at a technical level, since https doesn't prevent it. While it's touching that you what to ensure that I am part of the profit stream from any monetization of the contents of my site, I don't think my readership cares - I certainly don't - so it's not part of my threat model. > that the FTC asked This is the same government that allows cable monopolies and doesn't enact laws to prevent the ISPs from injecting ads into their downloads? Call my a crazy leftist, but I can't help but notice that this also strengthens the power of the big advertising companies like Google and Facebook by reducing the amount of competition, and that the FTC is looking at ISP rather than Google and Facebook abuses because the ISPs are relatively weak, making this a politically cheap action on their part.

MrRadar 6y ago
> How does https prevent DNS spoofing? My post explained in detail how HTTPS prevents DNS spoofing. If you do not understand any of the steps in my argument, please point them out. Otherwise, if you are unable to understand how TLS and certificates work that is not my problem and I ask you to please stop spreading misinformation based on your misunderstanding. > When you say "easier to detect", are you meaning easier to detect by people who don't recognize that their ISP injects ads? I mean easier to detect by people who know how HTTPS works, i.e. by technical experts. There are people monitoring the Certificate Transparency logs for domains that have certificates being issued by a different authority than they normally use and/or by an authority that does not match the DNS CAA record. > How do I, right now check if my ISP is spoofing my DNS to MITM my access to my https site? 'Cause I have no clue. It's extremely simple: does the lock icon in your URL bar have an error symbol? If no, you can be almost[1] 100% certain the site you are connecting to has not been spoofed because it has a valid certificate. If yes, you should assume you have no better (though also no worse) security than unencrypted HTTP. If you want to go further you can view the certificate your browser received and compare it against the certificate presented to other services running on other networks, e.g. the Qualys SSL Labs server test: https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ > Which was my point - what is the security threat I should care about? To me this is a question of whether you respect and value your user's privacy and security. Enabling HTTPS (and HTTPS-only) is so trivial today that there is no reason not to do it. HTTPS is just basic security hygiene on the modern web regardless of the "importance" of the data. ISPs and other middle networks have proven themselves to be untrustworthy over the years and authenticated encryption (such as that provided by HTTPS) is the only workable defense. > But again I ask what are the negatives? If I switch my site to https-only, how many people or devices will be negatively impacted? Virtually none. Even on fairly ancient Android phones (Android 4.1+), which are the least likely to receive software updates, you can install Firefox and get a modern TLS stack and root store. Pretty much every desktop and laptop PC made in the last 10 years can run the latest version of Windows or Linux with the latest version of Firefox or Chrome. Sticking with software so obsolete it cannot interoperate with modern TLS is a choice and the people making that choice should be knowledgeable enough to understand the consequences of that choice (including the workarounds they can do to accommodate that obsolete software, e.g. proxy servers). > Which doesn't require https-everywhere, only https on most/significant number of places. If you do not use HTTPS on your site then the cost of surveilling your site is 0 regardless of whether other sites use HTTPS. > And you're fine with that at a technical level, since https doesn't prevent it. Yes, I am fine with that because it means that I got exactly what you intended me to receive and I can be confident in ascribing that decision to you and to judge you by that. My point about ad injection was just to show a real-world scenario where an ISP or other middle network has tampered with the data being delivered. You say you are a leftist, what about if someone inject "alt-right" talking points into your blog? What if someone swapped your contact information for a spoofed version so they can intercept e-mails and other private communication intended for you? What if someone replaced code on your site with malware? What if someone injected a script into your site to DDoS Github[2]? These are all things that are possible with unencrypted and unauthenticated connections (i.e. plain HTTP). If you can't generalize from the examples I'm giving you then I ask you to engage your imagination more vigorously. [1] The "almost" qualification is primarily to account for intentional MITM appliances used by whoever is running your network (which would require them to install their own MITM certificate on your client) or malware running on your client, as well as much more rare scenarios like mis-issued certificates or state actor intervention. [2] https://www.bankinfosecurity.com/github-hit-by-its-largest-ddos-attack-a-8058 https://www.bankinfosecurity.com/github-hit-by-its-largest-d...

MrRadar 6y ago

> How does https prevent DNS spoofing? My post explained in detail how HTTPS prevents DNS spoofing. If you do not understand any of the steps in my argument, please point them out. Otherwise, if you are unable to understand how TLS and certificates work that is not my problem and I ask you to please stop spreading misinformation based on your misunderstanding. > When you say "easier to detect", are you meaning easier to detect by people who don't recognize that their ISP injects ads? I mean easier to detect by people who know how HTTPS works, i.e. by technical experts. There are people monitoring the Certificate Transparency logs for domains that have certificates being issued by a different authority than they normally use and/or by an authority that does not match the DNS CAA record. > How do I, right now check if my ISP is spoofing my DNS to MITM my access to my https site? 'Cause I have no clue. It's extremely simple: does the lock icon in your URL bar have an error symbol? If no, you can be almost[1] 100% certain the site you are connecting to has not been spoofed because it has a valid certificate. If yes, you should assume you have no better (though also no worse) security than unencrypted HTTP. If you want to go further you can view the certificate your browser received and compare it against the certificate presented to other services running on other networks, e.g. the Qualys SSL Labs server test: https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ > Which was my point - what is the security threat I should care about? To me this is a question of whether you respect and value your user's privacy and security. Enabling HTTPS (and HTTPS-only) is so trivial today that there is no reason not to do it. HTTPS is just basic security hygiene on the modern web regardless of the "importance" of the data. ISPs and other middle networks have proven themselves to be untrustworthy over the years and authenticated encryption (such as that provided by HTTPS) is the only workable defense. > But again I ask what are the negatives? If I switch my site to https-only, how many people or devices will be negatively impacted? Virtually none. Even on fairly ancient Android phones (Android 4.1+), which are the least likely to receive software updates, you can install Firefox and get a modern TLS stack and root store. Pretty much every desktop and laptop PC made in the last 10 years can run the latest version of Windows or Linux with the latest version of Firefox or Chrome. Sticking with software so obsolete it cannot interoperate with modern TLS is a choice and the people making that choice should be knowledgeable enough to understand the consequences of that choice (including the workarounds they can do to accommodate that obsolete software, e.g. proxy servers). > Which doesn't require https-everywhere, only https on most/significant number of places. If you do not use HTTPS on your site then the cost of surveilling your site is 0 regardless of whether other sites use HTTPS. > And you're fine with that at a technical level, since https doesn't prevent it. Yes, I am fine with that because it means that I got exactly what you intended me to receive and I can be confident in ascribing that decision to you and to judge you by that. My point about ad injection was just to show a real-world scenario where an ISP or other middle network has tampered with the data being delivered. You say you are a leftist, what about if someone inject "alt-right" talking points into your blog? What if someone swapped your contact information for a spoofed version so they can intercept e-mails and other private communication intended for you? What if someone replaced code on your site with malware? What if someone injected a script into your site to DDoS Github[2]? These are all things that are possible with unencrypted and unauthenticated connections (i.e. plain HTTP). If you can't generalize from the examples I'm giving you then I ask you to engage your imagination more vigorously. [1] The "almost" qualification is primarily to account for intentional MITM appliances used by whoever is running your network (which would require them to install their own MITM certificate on your client) or malware running on your client, as well as much more rare scenarios like mis-issued certificates or state actor intervention. [2] https://www.bankinfosecurity.com/github-hit-by-its-largest-ddos-attack-a-8058 https://www.bankinfosecurity.com/github-hit-by-its-largest-d...