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.

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

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.

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.

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.

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.

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.

Yes, it probably was me.

CAA assumes the Certificate Authorities are honest which I believe on the whole is a reasonable assumption - but it doesn't only protect you against accidents. Malevolence from third parties might be blocked by CAA too.

For example, suppose you conclude the some of the 3.2.2.4 Blessed Methods are unacceptably vulnerable to impersonation of your organisation. You identify that a particular CA specifies in their CPS that they never use any of these methods, you can use CAA to tell every other CA not to issue. As a result, these methods cannot be used to successfully obtain certificates that shouldn't exist. If an adversary tries to use another CA your CAA record tips off that CA that there's a problem, and if they try on your preferred CA then the vulnerable methods aren't offered.

I believe there is still work in progress to try to hook CAA together with ACME so that it would be practical to express "Only Let's Encrypt may issue, and only using dns-01" which rules out a lot of otherwise practical attacks for a resourceful adversary, but I don't track the status of that work.

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.