8 ms·
Concerns about Trustcor
- Trouble_007 4y agoFYI: the Washingtonpost article; Mysterious company with government ties plays key internet role : https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/ https://www.washingtonpost.com/technology/2022/11/08/trustco...
- pabs3 4y agoHN thread (no comments yet): https://news.ycombinator.com/item?id=33539843 https://news.ycombinator.com/item?id=33539843
- woodruffw 4y agoFrom 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. [1]: https://crt.sh/?caid=164810 https://crt.sh/?caid=164810
- mike_d 4y agocrt.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.
- woodruffw 4y agoThanks for pointing that out. I wasn't aware they had a backlog.
- p-e-w 4y ago> crt.sh is useful [...] they don't have a single Google cert logged post 2020 Sounds like they're useless, actually, considering typical certificate validities nowadays.
- nickf 4y agoThere certainly is a backlog of certs being ingested from the logs: https://crt.sh/monitored-logs https://crt.sh/monitored-logs - but as you can see, it's tiny. 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 https://crt.sh/?id=7669606389
- mike_d 4y agoThat is just log monitoring and not the full ingestion pipeline. The search interface is woefully broken and has been for years.
- aaomidi 4y agoSearch for *.google.com
- midislack 4y agoThere are so many dodgy root certs these days. First thing I do is delete a BUNCH of them when installing or upgrading a browser.
- ohCh6zos 4y agoIs there a decent guide somewhere of what is safe to remove? I feel like I should prune root CAs, but also like I would need to know a lot more.
- pabs3 4y agoMaybe delete everything except Lets Encrypt and then re-enable ones for the sites you regularly visit that are now broken.
- Scaevolus 4y agoYou can get pretty good coverage (>90%) by just having the top 6 CAs (IdenTrust, DigiCert, Sectigo, GoDaddy, Let's Encrypt, GlobalSign): https://w3techs.com/technologies/overview/ssl_certificate https://w3techs.com/technologies/overview/ssl_certificate
- ohCh6zos 4y agoThat's an excellent idea.
- ttyprintk 4y agoHow to remove on Debian and family: sudo dpkg-reconfigure ca-certificates
- jbm 4y agoIt 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.
- deleted 4y ago[deleted]
- pabs3 4y agoI wonder when the web will move to a multi-signer model for https certificates.
- stevewatson301 4y agoThis 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. [1] http://www.cs.cmu.edu/~perspectives/firefox_help.html http://www.cs.cmu.edu/~perspectives/firefox_help.html
- p-e-w 4y ago> 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.
- stevewatson301 4y agoYou 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.
- mardifoufs 4y agoWoah 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.
- deleted 4y ago[deleted]
- p-e-w 4y agoAh yes, HTTPS, the critical security infrastructure with 168 single points of failure [1], each of which would mean a total, catastrophic system compromise... [1] https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
- Gigachad 4y agoIt’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.
- p-e-w 4y agoAnd 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.
- Gigachad 4y agoBeing 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.
- brohee 4y agoOnly if they use it irresponsibly. 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.
- Gigachad 4y agoIt 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.
- 0xbadcafebee 4y agoTaking 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.
- deleted 4y ago[deleted]
- Owen69 4y ago[dead]
- deleted 4y ago[deleted]