There's not much to spy on. It's not like LetsEncrypt generate your private keys and give them to you. They sign a request that you send them (and they don't get to ever see your actual private key). So an evil CA won't be able to crack your encrypted website.
An evil CA can of course generate fake certificates for any hostname they like, but those people already exist. Have you taken a look at just how many different root CAs are out there, and are trusted by your OS/browser? It includes hundreds of companies and governments. Then there are even more (countless?) 'second level CAs' (I forget the proper term, sorry!) who can also generate and sign a trusted certificate for any hostname, because, while they aren't a root CA, their authority has been signed in turn by a top-level CA. The web of trust is very large and has many points of failure.
That would require them to issue a separate certificate. Certificate Transparency provides significant deterrence against that.
They can either log it into Certificate Transparency (and include the SCT, the "receipt" for logging it, in the cert), or not do that.
If they log it, the server operator can see (in the public CT logs) that a certificate was issued for his domain by someone else, and raise hell.
If they don't log it, the certificate won't have an SCT. That means that software that enforces CT can treat the certificate as invalid, and if someone saw the cert on the wire, it would immediately appear suspicious since all Let's Encrypt certs are supposed to have an SCT.
They could also get an evil CT log to issue a SCT without logging it, but that would generate irrefutable cryptographic proof of malfeasance of the CT log.
They could also get an evil CT log to issue a SCT without logging it…
If a SCT is issued, it has to be logged within a certain amout of time; 3rd party auditors check for this. [1]:
An auditor is a third party that keeps log operators honest. They query logs from various vantage points on the internet and gossip with each other about what order certificates are in. They’re like the paparazzi of the PKI. They also keep track of whether an SCT has been honored or not by measuring the time it took between the SCT’s timestamp and the corresponding certificate showing up in the log.
And only certain logs are trusted anyway [2]; a CT log that doesn't meet certain requirements wouldn't be trusted to begin with. And if a trusted CT log turned evil, it would quickly be noticed.
1. Certification Authority Authorization (CAA) specifies which CAs are allowed to issue certificates for your website. Of course if the CA is truly evil, they would ignore whatever is specified. [1]
2. A DNSSEC-signed website can use DANE to specify which certificate, intermediate or key is authorized to be used. [2][3]
Breaking news: there are other applications on the internet other than browsers.
And some of them use TLSA records. It’s the de facto standard for for secure email, especially if you want guaranteed protection from downgrade attacks.
Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Nor is it likely ever to be, since the major email providers standardized MTA-STS specifically to avoid DNSSEC, as you can see from the opening paragraphs of the standard.
DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]:
The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records.
Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons.
Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection.
The MTA-STS RFC [2] confirms this:
The DNS-Based Authentication of a Named Entities (DANE)TLSA
record [RFC7672] is similar, in that DANE is also designed
to upgrade unauthenticated encryption or plaintext
transmission into authenticated, downgrade-resistant
encrypted transmission. DANE requires DNSSEC [RFC4033] for
authentication; the mechanism described here instead relies
on certification authorities (CAs) and does not require
DNSSEC, at a cost of risking malicious downgrades.
There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them.
You know the old saying: you’re entitled to your own opinion but not your own facts.
As you well know, since this is the third time you've tried to make this point, the overwhelming majority of those zones were signed automatically by their European registrars; these counts have no relationship to actual emails sent.
The entire idea behind STS protocols is to use continuity schemes to defeat downgrades. It's literally the only threat model.
these counts have no relationship to actual emails sent
These domains wouldn’t have MX or TLSA records unless they were doing email.
Even if a zone is pre-signed, an admin has to intentionally create DANE records, which they wouldn’t do unless they were hosting SMTP servers.
But it does show the statement that DNSSEC, DANE and TLSA aren’t used for secure email to be utterly untrue.
MTA-STS has other issues:
* Authenticates domain control via CA leap of faith
* Vulnerable to MiTM at cert bootstrap
* Vulnerable to weakest root CA, and unauthorized certs
* Open to downgrade on first (or irregular) contact
* Complex mix of HTTPS, unsigned DNS and SMTP
Horseshit. I have something like 50 domains on a popular retail registrar and every single one of them has an MX record, despite me never doing a single thing other than claiming the name; they come by default with new domains. If I was in the Netherlands, every one of them would have DNSSEC signatures too, because European registrars opt domains into DNSSEC by default.
I'm having a hard time articulating how silly it is to try to dunk on MTA-STS for being "vulnerable" to downgrade attacks; it's like trying to say that HSTS is vulnerable to SSL-stripping attacks. You have to not understand the idea behind the attack or the countermeasure to lead with that argument.
Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA.
Here's a short list of domains that are using DNSSEC, DANE and TLSA to protect their email. I also provide a transcript of a utility that connects to and verifies the SMTP server and the DANE/TLSA records for openssl.org and could have done so for every domain on this list but there's no reason to get carried away.
Here's what it does:
This application checks a DANE SMTP Service. It queries the MX record set for the given domain, looks up DANE TLSA records at the MX targets, connects to the target servers, negotiates STARTTLS, and then attempts to verify the TLS server certificate against the TLSA records.
With the note that those are literally the best domain names you can come up with, and that you can go to the search bar below and look at my comments to see me running the Moz 500 through the same analysis, I feel like your list makes my point for me. Thanks.
DNSSEC standardization began in NINETEEN NINETY FIVE. That's twenty five years ago. They got GENTOO.ORG. That's the win you're crowing over. Congratulations! As goes GENTOO.ORG, so too goes the Internet.
Internet protocol evolution is in a funny place currently. IPv6 is just as old and it's only recently been widely deployed. There's just so much inertia.
It takes a very long time to revoke trust if you don't want to break the web. Symantec was discovered to have misissued a bunch of certs in 2015[1] (including for google.com). No one removed trust for them. Then in Jan 2017 it was discovered they misissued a bunch more[2]. I believe it was the end of 2018 before browsers finally removed trust for them.
An evil CA can generate fake certificates, because a CA can sign (generate) any certificate they want, because all they're doing is saying "this is legit, trust me".
People with the power to generate fake certificates for any hostname already exist regardless of the size of Lets Encrypt. Consequently LE aren't a particular threat. (And the short lifespan of LE certs significantly reduces the value of them as a target. Once the dodginess is identified, you could detrust them within a much shorter timeframe)
Only pedophiles and ISIL need encryption, so what are you worried about... just do all your banking etc. over plain HTTP... I'm sure no foreign governments are listening on ANY compromised devices in the middle, or have any motivations you disagree with.
An evil CA can of course generate fake certificates for any hostname they like, but those people already exist. Have you taken a look at just how many different root CAs are out there, and are trusted by your OS/browser? It includes hundreds of companies and governments. Then there are even more (countless?) 'second level CAs' (I forget the proper term, sorry!) who can also generate and sign a trusted certificate for any hostname, because, while they aren't a root CA, their authority has been signed in turn by a top-level CA. The web of trust is very large and has many points of failure.