From crt.sh, it looks like TrustCor's DV CA has issued around ~2400 total certificates and around ~24k precertificates[1]. They have other CAs as well, including an OV one.
crt.sh is useful, but should NOT be treated as an authoritative and all inclusive source of information. They have a massive backlog of certificates not present in the database.
For example, do a search for 'google.com' and you'll see they don't have a single Google cert logged post 2020.
It looks like there is a response from the company in there and it probably needed an EQ review before releasing. It starts off with attacking the reporters, and then this:
> ... I know you guys promote some kind of app security solution commercially, but I did note in my earlier response that our company and MsgSafe has never shipped an app that was not in BETA only and that the 5-year-old app beta was abandoned years ago.
Trying to ignore the fact that there might have been malware in a security-focused message application they shipped is concerning. (I _can_ imagine how it might have been done innocently - a beta intended to be internal-only w/ various metrics analysis et al, for example). It's hard to trust part of the business if a separate section of the company engages in that sort of behavior.
That said, their note about an unrelated party in the US registering the same name for a company in the US is really weird and concerning.
> Our attorneys believe someone could have done this (and it agrees with our event timeline we’re creating as we investigate) for physical actions taken and may have used this with insurance companies to obtain additional nonpublic information about our company and our insurance infrastructure which is large and complicated just like every CA’s insurance has to be.
This feels vaguely scary if you run businesses abroad with US-based hosting or physical infrastructure.
This incident shows why CT is a poor model to recognize one-off attacks against persons of interest. A better model was the 2010-era Perspectives Project[1], which requires browsers to report the certificate fingerprints and CA to a notary server, which can then issue an alert if the certificate hasn't been widely seen.
> which requires browsers to report the certificate fingerprints and CA to a notary server
Browsers sending each certificate fingerprint (which can easily be translated to a hostname by building a database of certificates) to a server on the Internet has got to be one of the worst ideas in the history of information security. Yet more institutions knowing every domain you connect to is the absolute last thing we need.
You could do stuff like k-anonimity and onion routing (where every layer is run by a different company, similar to Apple Private Relay) to mitigate some of it, although it wasn't there in the initial implementation of the Perspectives project.
Woah that WSJ article is troubling. It seems like a US government financed scheme to track muslims in the Middle East, behind the cover of a "defense contractor." And they were using muslim prayer apps to do so! A foreign super power targeting foreign citizens belonging to a specific religious group with a massive surveillance operation is OK when the US does it I guess.
But yeah, not surprising then that they had the means to run a CA, too.
Ah yes, HTTPS, the critical security infrastructure with 168 single points of failure [1], each of which would mean a total, catastrophic system compromise...
It’s not quite that bad. Certificate transparency and things like the EFF observatory extension effectively solve this issue. An org issuing a malicious certificate would very quickly be detected and their keys revoked.
And in the time it takes to revoke those keys and roll out the revocation to browsers, half the planet can have their email credentials stolen, which means the horse has bolted long before the stable doors even begin to close.
Being able to sign a fake certificate doesn’t immediately let you intercept traffic. You also have to control the worlds ISPs to get your server in the middle.
Such an incredible feat that it has never happened before.
It should be possible for browsers to flat out reject any certificate that isn’t in the transparency logs. Not too sure if they do that currently but I can’t see why they couldn’t.
For the same reason they don't use the CRL, it very hard and expensive to scale, and in any case what to do if you cannot access the CRL/transparency log? An entity in position to intercept can simulate an outage as well..
That's not quite how CT works. The client doesn't (currently) need to have any access to the CT logs themselves.
Generally, a 'pre' certificate is submitted to a number of logs by the CA. The log returns a signed timestamp. These SCTs (signed certificate timestamps) are embedded in the final certificate provided to the subscriber - and the browser can verify those.
(The SCTs can also be stapled, and not signed into the certificate itself).
Taking this opportunity to sell my idea about how to "fix" part of the TLS cert trust process...
CAs can all issue certs for any domain, right? I mean, there's these hacks that are supposed to restrict that, but it's optional. The browser trusts any cert that a CA has signed. And in order for a CA to let you create a cert, they have hokey, problematic methods to allow you to prove that you, temporarily, at the moment, control the IP space that is pointed to by whatever DNS server a given CA trusts, and hope that BGP and DNS do not lie to the CA. So 1) BGP has to be trusted, 2) the DNS has to be trusted, 3) the CA has to be trusted, and 4) a temporary check of an IP address needs to show something to the CA that they think is valid (among other hokey validation methods, like an e-mail to some predetermined address at a domain, or an HTTP GET to the aforementioned IP).
That's a lot of stuff that we hope is all valid and not been tampered with! (In fact, these things [and more] do get tampered with, and have been exploited in the past to generate certs illicitly) So how can we make things a little more consistent and secure? Well all of this trades on the idea that the CA is trying to verify that you, the person asking for a cert, really own and control the domain name that you are asking for a cert for. That's tricky, because the registrar and the nameserver are the only entities that can authoritatively say who owns and controls the doman.
So... why don't we just confirm, cryptographically, with the registrar and the nameserver, that the requestor of the cert is who they say they are? If the registrar keeps a key that the domain owner has uploaded [or signed], and the nameserver keeps a key the nameserver owner has uploaded [or signed], and you create a CSR (including what CA should generate your cert), get it signed by both the registrar and nameserver, and send it to the CA, the CA can verify it with the registrar and the nameserver, and the cert can include the CSR signature from the registrar and nameserver. So now anyone who gets the cert can confirm 1) who was supposed to issue it, 2) that the real domain owner signed the request, 3) that the CA confirmed all this when it issued the cert, without depending on BGP or DNS or HTTP.
.....this will never happen, of course, because there are vested interests, and it would take a lot of hand-wringing and agreements and modifications to policies and new software and all kinds of stuff to make that happen. So we will continue relying on BGP, DNS, and the integrity of a couple hundred CAs, to make sure nobody ever 'exceeds their authority' and issues a cert they shouldn't have.
The marginal cost of a certificate is very close to $0.00, the same as a TXT record in a DNS server.
As you've realised, the reason they cost "real money" measured in dollars is because of rent seeking[1] by a few large corporations. These guys have sufficient clout to (mostly) snuff out any upstarts. For example, their response to Let's Encrypt was to start pushing CAA records for "security". You guessed it: the security in that context is not referring to your IT security, but to their revenue security.
Similarly, Microsoft Azure has CA integration... with the two biggest for-money certificate authorities. There is virtually no chance they'll ever willingly integrate with Let's Encrypt or add support for the generic ACME protocol because there is no margin on free.
There's not much that can be done to fight this, but there are options.
As you've said, DNS name servers and CA functions need to be combined. It's almost gibberish to have these as separate services in 2022, since practically everything uses TLS, which needs both to act in concert.
In fact, DNS-based traffic management, static DNS, dynamic DNS, DHCP, IPsec management, and CA services should all be combined into a single executable. This way back-end machines could enroll in certificates at the same time that they get their IP addresses. Their IP addresses would be registered under their name, and load balancers can add their IPs to service pools. Etc...
Microsoft almost did this right, with LDAP + DHCP + DNS + Enterprise PKI being mostly integrated, but not quite.
Keep in mind that the era when these things "had" to be separate services was when DNS needed a dedicated bare metal machine for performance. These days the DNS zone of a large corporation fits in L2 cache and can run out of a fraction of a CPU core!
What does CAA have to do with Let’s Encrypt? CAA’s first RFC was published years before Let’s Encrypt began issuing certificates, and they are an author on the latest RFC version.
CAA easily supports several CAs issuing for one domain.
Only in the sense that a car is a reinvention of a sled dog. What I'm proposing is drastically different in design, implementation and use case. But I'm sure browser makers (read: Google) would also resist anything they didn't invent.
42 comments
[ 0.18 ms ] story [ 121 ms ] threadMysterious company with government ties plays key internet role : https://www.washingtonpost.com/technology/2022/11/08/trustco...
https://news.ycombinator.com/item?id=33539843
[1]: https://crt.sh/?caid=164810
For example, do a search for 'google.com' and you'll see they don't have a single Google cert logged post 2020.
Sounds like they're useless, actually, considering typical certificate validities nowadays.
crt.sh does contain all the certificates the CT logs know about.
Google certs are there, just as any other: https://crt.sh/?id=7669606389
> ... I know you guys promote some kind of app security solution commercially, but I did note in my earlier response that our company and MsgSafe has never shipped an app that was not in BETA only and that the 5-year-old app beta was abandoned years ago.
Trying to ignore the fact that there might have been malware in a security-focused message application they shipped is concerning. (I _can_ imagine how it might have been done innocently - a beta intended to be internal-only w/ various metrics analysis et al, for example). It's hard to trust part of the business if a separate section of the company engages in that sort of behavior.
That said, their note about an unrelated party in the US registering the same name for a company in the US is really weird and concerning.
> Our attorneys believe someone could have done this (and it agrees with our event timeline we’re creating as we investigate) for physical actions taken and may have used this with insurance companies to obtain additional nonpublic information about our company and our insurance infrastructure which is large and complicated just like every CA’s insurance has to be.
This feels vaguely scary if you run businesses abroad with US-based hosting or physical infrastructure.
[1] http://www.cs.cmu.edu/~perspectives/firefox_help.html
Browsers sending each certificate fingerprint (which can easily be translated to a hostname by building a database of certificates) to a server on the Internet has got to be one of the worst ideas in the history of information security. Yet more institutions knowing every domain you connect to is the absolute last thing we need.
But yeah, not surprising then that they had the means to run a CA, too.
[1] https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
Such an incredible feat that it has never happened before.
A certificate tightly controlled by a three letter agency and used for spot interceptions on specific targets is very unlikely to be found.
Massive interception are likely to be detected nowadays, but the lone political opponent is still far from safe from them.
Generally, a 'pre' certificate is submitted to a number of logs by the CA. The log returns a signed timestamp. These SCTs (signed certificate timestamps) are embedded in the final certificate provided to the subscriber - and the browser can verify those. (The SCTs can also be stapled, and not signed into the certificate itself).
CAs can all issue certs for any domain, right? I mean, there's these hacks that are supposed to restrict that, but it's optional. The browser trusts any cert that a CA has signed. And in order for a CA to let you create a cert, they have hokey, problematic methods to allow you to prove that you, temporarily, at the moment, control the IP space that is pointed to by whatever DNS server a given CA trusts, and hope that BGP and DNS do not lie to the CA. So 1) BGP has to be trusted, 2) the DNS has to be trusted, 3) the CA has to be trusted, and 4) a temporary check of an IP address needs to show something to the CA that they think is valid (among other hokey validation methods, like an e-mail to some predetermined address at a domain, or an HTTP GET to the aforementioned IP).
That's a lot of stuff that we hope is all valid and not been tampered with! (In fact, these things [and more] do get tampered with, and have been exploited in the past to generate certs illicitly) So how can we make things a little more consistent and secure? Well all of this trades on the idea that the CA is trying to verify that you, the person asking for a cert, really own and control the domain name that you are asking for a cert for. That's tricky, because the registrar and the nameserver are the only entities that can authoritatively say who owns and controls the doman.
So... why don't we just confirm, cryptographically, with the registrar and the nameserver, that the requestor of the cert is who they say they are? If the registrar keeps a key that the domain owner has uploaded [or signed], and the nameserver keeps a key the nameserver owner has uploaded [or signed], and you create a CSR (including what CA should generate your cert), get it signed by both the registrar and nameserver, and send it to the CA, the CA can verify it with the registrar and the nameserver, and the cert can include the CSR signature from the registrar and nameserver. So now anyone who gets the cert can confirm 1) who was supposed to issue it, 2) that the real domain owner signed the request, 3) that the CA confirmed all this when it issued the cert, without depending on BGP or DNS or HTTP.
.....this will never happen, of course, because there are vested interests, and it would take a lot of hand-wringing and agreements and modifications to policies and new software and all kinds of stuff to make that happen. So we will continue relying on BGP, DNS, and the integrity of a couple hundred CAs, to make sure nobody ever 'exceeds their authority' and issues a cert they shouldn't have.
As you've realised, the reason they cost "real money" measured in dollars is because of rent seeking[1] by a few large corporations. These guys have sufficient clout to (mostly) snuff out any upstarts. For example, their response to Let's Encrypt was to start pushing CAA records for "security". You guessed it: the security in that context is not referring to your IT security, but to their revenue security.
Similarly, Microsoft Azure has CA integration... with the two biggest for-money certificate authorities. There is virtually no chance they'll ever willingly integrate with Let's Encrypt or add support for the generic ACME protocol because there is no margin on free.
There's not much that can be done to fight this, but there are options.
As you've said, DNS name servers and CA functions need to be combined. It's almost gibberish to have these as separate services in 2022, since practically everything uses TLS, which needs both to act in concert.
In fact, DNS-based traffic management, static DNS, dynamic DNS, DHCP, IPsec management, and CA services should all be combined into a single executable. This way back-end machines could enroll in certificates at the same time that they get their IP addresses. Their IP addresses would be registered under their name, and load balancers can add their IPs to service pools. Etc...
Microsoft almost did this right, with LDAP + DHCP + DNS + Enterprise PKI being mostly integrated, but not quite.
Keep in mind that the era when these things "had" to be separate services was when DNS needed a dedicated bare metal machine for performance. These days the DNS zone of a large corporation fits in L2 cache and can run out of a fraction of a CPU core!
[1] https://en.wikipedia.org/wiki/Rent-seeking
CAA easily supports several CAs issuing for one domain.