4 ms·

> If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? This is probably the argument I hear most often. B

> If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? This is probably the argument I hear most often. But it completely ignores the fact that for the last 20 years, when I wanted to grab a Wikipedia article, I got it in 100% cases, whereas the number of broken HTTPS websites (usually because of expired certs) is non-negligible. You can blame "incompetent admins" as much as you want, but with HTTP this particular problem simply doesn't exist.

rezonant 5y ago
Sure, it is incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. But regular users want WiFi at their favorite coffee shop, and there are still plenty of unsecured wireless hotspots at those shops. The capability to intercept insecure WiFi has been heavily commoditized over the years since the techniques were created. Well within reach for a disgruntled lover, or a stalker, or perhaps for corporate espionage. Sure, more sophisticated organizations should have and more often do have protections for this (including, of course, strong TLS/HTTPS) but not everyone does, and we should protect them too. But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.
- ArchOversight 5y ago
  > incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. Comcast and other ISP's would love to have a word with you with their injecting JavaScript to warn you about going over your alloted data usage... same for various other providers that injected ads, or man in the middled YouTube connections (T-Mobile) to reduce the quality delivered over their network or the hidden CDN's to reduce interconnect load... ISP's have "managed" their networks in a variety of ways, and a lot of those "techniques" were straight up hijacking your original request.
  - simfree 5y ago
    T-Mobile is throttling all traffic from certain IP addresses in their current Binge On scheme, primarily to reduce edge load (on their cell towers) as that is where nearly all of their network congestion occurs. Binge On doesn't do much different for http video content compared to https content as far as I have read and seen.
    - ArchOversight 5y ago
      These days they may simply throttle entire IP blocks, there was a time when they would purposefully change the manifest file that was served to users to reduce the available qualities thereby forcing the client to think there was no higher quality video content available.
- fnml 5y ago
  A state actor can issue a certificate, because the browser's default cert stores are full of sketchy ones. The Internet didn't exactly collapse between 1990-2010, before this HTTPS-everywhere campaign started. Interest groups want to get you hooked on HTTPS and then squeeze you, one way or another.
  - vegardx 5y ago
    No, it doesn't work like that. Certificate Transparency Log makes this almost impossible to do this undetected. In addition to this you have CAA records which quickly would make it evident for the entire world that said certificate is fraudulent and that the signing CA isn't to be trusted anymore.
    - schoen 5y ago
      I used to think that CAA records would be checked at both issuance time and certificate acceptance time, but someone on Hacker News (probably tialaramex) corrected me: the CAA RFC specifically says that it should only be checked at issuance time and that it's not valid to check it at acceptance time. As a result, there's no browser that checks CAA or uses it to warn about possibly-misissued certificates. Furthermore, if you reported a certificate to a CA or browser based on an apparent conflict with CAA issuance policies, you would probably get the reply that that only applies at issuance time. And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it. Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.
      - vegardx 5y ago
        Makes complete sense, and like you said, this information is key for security researchers who routinely trawls CT logs looking for discrepancy. And failing on CAA shortly after issuance is quite a huge red flag. If the scenario of rogue national state managed CAs was an issue we'd have pretty good evidence of it by now. Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.

rezonant 5y ago

Sure, it is incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. But regular users want WiFi at their favorite coffee shop, and there are still plenty of unsecured wireless hotspots at those shops. The capability to intercept insecure WiFi has been heavily commoditized over the years since the techniques were created. Well within reach for a disgruntled lover, or a stalker, or perhaps for corporate espionage. Sure, more sophisticated organizations should have and more often do have protections for this (including, of course, strong TLS/HTTPS) but not everyone does, and we should protect them too. But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.

ArchOversight 5y ago
> incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. Comcast and other ISP's would love to have a word with you with their injecting JavaScript to warn you about going over your alloted data usage... same for various other providers that injected ads, or man in the middled YouTube connections (T-Mobile) to reduce the quality delivered over their network or the hidden CDN's to reduce interconnect load... ISP's have "managed" their networks in a variety of ways, and a lot of those "techniques" were straight up hijacking your original request.
- simfree 5y ago
  T-Mobile is throttling all traffic from certain IP addresses in their current Binge On scheme, primarily to reduce edge load (on their cell towers) as that is where nearly all of their network congestion occurs. Binge On doesn't do much different for http video content compared to https content as far as I have read and seen.
  - ArchOversight 5y ago
    These days they may simply throttle entire IP blocks, there was a time when they would purposefully change the manifest file that was served to users to reduce the available qualities thereby forcing the client to think there was no higher quality video content available.
fnml 5y ago
A state actor can issue a certificate, because the browser's default cert stores are full of sketchy ones. The Internet didn't exactly collapse between 1990-2010, before this HTTPS-everywhere campaign started. Interest groups want to get you hooked on HTTPS and then squeeze you, one way or another.
- vegardx 5y ago
  No, it doesn't work like that. Certificate Transparency Log makes this almost impossible to do this undetected. In addition to this you have CAA records which quickly would make it evident for the entire world that said certificate is fraudulent and that the signing CA isn't to be trusted anymore.
  - schoen 5y ago
    I used to think that CAA records would be checked at both issuance time and certificate acceptance time, but someone on Hacker News (probably tialaramex) corrected me: the CAA RFC specifically says that it should only be checked at issuance time and that it's not valid to check it at acceptance time. As a result, there's no browser that checks CAA or uses it to warn about possibly-misissued certificates. Furthermore, if you reported a certificate to a CA or browser based on an apparent conflict with CAA issuance policies, you would probably get the reply that that only applies at issuance time. And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it. Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.
    - vegardx 5y ago
      Makes complete sense, and like you said, this information is key for security researchers who routinely trawls CT logs looking for discrepancy. And failing on CAA shortly after issuance is quite a huge red flag. If the scenario of rogue national state managed CAs was an issue we'd have pretty good evidence of it by now. Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.