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.
Perhaps intermediate CA.
https://en.wikipedia.org/w/index.php?title=Intermediate_cert...
If the evil CA is default-trusted by major OS and browser vendors then they can - with their own private key then do a MITM.
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.
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]: https://blog.cloudflare.com/introducing-certificate-transpar...
[2]: https://github.com/chromium/ct-policy/blob/master/log_policy...
But indeed, an SCT and a later timestamp on the log without having logged the cert would be the cryptographic evidence I talked about.
2. A DNSSEC-signed website can use DANE to specify which certificate, intermediate or key is authorized to be used. [2][3]
[1]: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c...
[2]: https://weberblog.net/how-to-use-danetlsa/
[3]: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-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.
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.
You know the old saying: you’re entitled to your own opinion but not your own facts.
[1]: https://stats.dnssec-tools.org/#dnssec
[2]: https://tools.ietf.org/html/rfc8461#section-2
A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742
The entire idea behind STS protocols is to use continuity schemes to defeat downgrades. It's literally the only threat model.
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 SMTPI'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.
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.
* geektimes.com
* gmx.com
* mail.com
* comcast.net
* dd24.net
* debian.org
* freebsd.org
* gentoo.org
* ietf.org
* isc.org
* netbsd.org
* openssl.org
* samba.org
* torproject.org
There's a DANE TLS SMTP server checking tool: https://www.huque.com/bin/danecheck-smtp
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.
Lets test openssl.org:
Domain Name: openssl.org
MX host: 50 mta.openssl.org
#################################################################
### CHECKING MX HOST: mta.openssl.org
#################################################################
TLSA records found: 1
TLSA: 3 1 1 6cf12d78fbf242909d01b96ab5590812954058dc32f8415f048fff064291921e
Connecting to IPv6 address: 2001:608:c00:180::1:e6 port 25
recv: 220-mta.openssl.org ESMTP Postfix
recv: 220 mta.openssl.org ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-mta.openssl.org
recv: 250-PIPELINING
recv: 250-SIZE 36700160
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
1 Subject CN: Let's Encrypt Authority X3
Issuer CN: DST Root CA X3
SAN dNSName: mta.openssl.org
DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0
Validated Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
SAN dNSName: mta.openssl.org
Connecting to IPv4 address: 194.97.150.230 port 25
recv: 220-mta.openssl.org ESMTP Postfix
recv: 220 mta.openssl.org ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-mta.openssl.org
recv: 250-PIPELINING
recv: 250-SIZE 36700160
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
1 Subject CN: Let's Encrypt Authority X3
Issuer CN: DST Root CA X3
SAN dNSName: mta.openssl.org
DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0
Validated Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
SAN dNSName: mta.openssl.org
[0] Authentication succeeded for all (2) peers.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.
[citation needed]
If that were true, I'd expect browser/OS makers to promptly revoke trusted CA status for them.
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.
[1] https://security.googleblog.com/2015/10/sustaining-digital-c...
[2] https://security.googleblog.com/2017/09/chromes-plan-to-dist...
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)
Comodo issued bogus certs, so did MCS. It's happened a few times over the years.
Edit: https://media.libreplanet.org/u/libreplanet/m/seth-schoen-le... the question is at 46:22.
why target them when it's OSINT? :)
[ed: compromise of their HSM would be bad and I didn't consider active attacks, only passive]
Incidents at WoSign/ StartCom presumably involved malfeasance by key staff. I guess that doesn't count as a breach unless you'd call it a "Bank raid" if the manager just empties the vault into his own car and flees.
At Symantec they knew third parties had the independent ability to issue with any of their CAs but that was specifically contracted third parties (in particular a Korean firm named CrossCert) not just random people, it's just that issuance records weren't properly kept and oversight was inadequate. Again the ability to cause issuance isn't technically a breach, the keys stayed inside the HSM but it was possible to cause unrecorded issuance so there's not much moral difference.
I don't know of any public cases where an org has disclosed that an external attacker exfiltrated key material from an HSM. That being said, there have been a number of disclosed vulnerabilities against HSMs/vendors that could allow this sort of attack to happen. CVE-2015-5464 is my favorite of these. There are also plenty of attacks that compromise the servers that talk to the HSMs, which usually would give an attacker the ability to perform arbitrary crypto operations using the keys in the HSM with no restrictions and little-to-no audit trail. I also know of attacks where the compromised "servers" are part of the HSM itself, but outside of the crypto/FIPS boundary.
But if you compromise the security of a PKI, you can decrypt the traffic.
In TLS 1.3 the session key is always chosen before any certificates go anywhere, using some flavour of elliptic curve Diffie Hellman key agreement - both sides agree on the same secret key without it being sent anywhere because Mathematics is Cool. So even if you were a fool and entrusted the Private Key corresponding to your web servers to somebody you shouldn't there's no way for bad guys to decrypt stuff without a live MITM attack.
The middle ground (modern browser, co-operative server, but older TLS version) is in between, bad guys can't retrospectively decrypt but it is clunky and some stuff (e.g. certificates) is not encrypted at all.
This all depends on the ciphersuite used by the client and server. In TLS 1.2 some ciphersuites use forward-secret methods (typically "DHE" and "ECDHE"), and some don't.
In TLS 1.3 you always get the benefits that you mention, but in TLS 1.2 and earlier you sometimes get them. :-)