[HN Gopher] The SSL certificate issuer field is a lie
___________________________________________________________________
The SSL certificate issuer field is a lie
Author : pabs3
Score : 84 points
Date : 2023-06-16 07:47 UTC (15 hours ago)
(HTM) web link (www.agwa.name)
(TXT) w3m dump (www.agwa.name)
| agwa wrote:
| Author here. Happy to answer any questions!
| dsr_ wrote:
| You missed a fun bit here:
|
| "What about "Baltimore"? That's short for Baltimore
| Technologies, a now-defunct infosec company, who acquired GTE's
| certificate authority subsidiary (named CyberTrust) in 2000,
| which they then sold to a company named Betrusted in 2003,
| which merged with TruSecure in 2004, who rebranded back to
| CyberTrust, which was then acquired by Verizon in 2007, who
| then sold the private keys for their root certificates to
| DigiCert in 2015. So "Baltimore" hasn't been accurate since
| 2003, and the true owner has changed four times since then."
|
| The dance in between that you missed:
|
| CyberTrust was part of BBN; GTE bought BBN in 1997. Later GTE
| bought a small datacenter operator called Genuity. Then GTE
| merged with Bell Atlantic to become Verizon, spinning off
| Genuity, selling much of the network to L3, and selling BBN
| Technologies to Raytheon. When Verizon bought
| Betrusted/TruSecure/Cybertrust in 2007, that was buying back a
| chunk of its previous self.
| rendx wrote:
| Great work, thank you!
| T3RMINATED wrote:
| [dead]
| recursive wrote:
| I hope the day never comes when I have to really understand what
| is going on with certificates. Every time I get close to it, it
| seems to be a shifting maze of smoke and mirrors.
| matheusmoreira wrote:
| "Shifting maze of smoke and mirrors" is a surprisingly accurate
| description of the digital certificate mess. It looks like
| everyone just trusts the governments and corporations involved.
| I'd rather not even think about the implications and just
| assume it's better than literally nothing.
| agwa wrote:
| We definitely don't "just" trust the certificate authorities.
| Considerable effort is spent monitoring CAs for non-
| compliance, and CAs which are found untrustworthy are booted.
| matheusmoreira wrote:
| I'm not sure those efforts amount to anything, no matter
| how considerable. Some nation state can probably just
| scream national security and compromise the whole thing,
| complete with gag orders preventing people from blowing the
| whistle.
| agwa wrote:
| Transparency is not optional - Chrome and Safari don't
| accept certificates that aren't published in Certificate
| Transparency logs.
|
| Certificate Transparency logs use Merkle Trees so that if
| they try to hide a certificate, it can be detected.
|
| The system is designed to resist subversion, even by
| governments. While there are scenarios where a
| sufficiently-powerful attacker could successfully subvert
| the system, they run a high risk of being detected if
| they try. It's just not as simple as you imply.
| bavell wrote:
| I'd love to see some good links/resources to read up on
| this area more. What are all the feedback mechanisms the
| CA ecosystem uses to resist subversion and bad actors?
| ilyt wrote:
| All you need to know and care for is that cert is signed by CA
| that your app has in cert store, and have the right fields that
| your app wants/uses (usually for web use just CN and Subject
| Alternate Names[SAN]).
|
| Everything else is _basically_ smoke and mirrors
| perlgeek wrote:
| I feel similarly frustrated.
|
| The basics of CAs, trust chains and certificates are pretty
| easy to understand once you're roughly aware of public key
| cryptography.
|
| But then you get into the arcane and confusing details of which
| fields hold which information, the various serialization
| formats, confusing error messages when servers don't provide
| their intermediates, other software simply not dealing with
| intermediates (I'm looking at you, etcd) and on and on.
|
| A "fun" example: I have an openvpn client config that contains,
| among other things, this here: <pkcs12>
| -----BEGIN CERTIFICATE----- (base64-looking stuff here)
| -----END CERTIFICATE----- </pkcs12>
|
| This contains, confusingly, not just a certificate but also an
| encrypted private key.
|
| I wanted to change the encryption password, but it turns out
| that "openssl pkcs12" cannot actually read that block, because
| it turns out to be a base64-encoded DER format or some other
| shit. WAT?
| lilyball wrote:
| That text block is PEM. Putting PEM in a tag that says
| <pkcs12> is awfully strange (PKCS#12 is a binary format
| anyway). And are you saying there's a private key inside of
| the base64 data?
|
| Or, oh no, please don't tell me that the PEM block contains
| PKCS#12?? A PEM CERTIFICATE block is supposed to contain a
| single DER-encoded certificate.
| endofreach wrote:
| Might be OT, but it looks like a rocket!
| multani wrote:
| I'm surprised to see DigiCert name coming that often.
|
| I know they are a major certificate player and that it really
| helped they supported (signed) Let's Encrypt intermediate
| certificate for instance (also others, as the article mention),
| but I don't really understand what do they gain from this? In th
| end, customers now have more choice, and possibly many free
| alternatives to DigiCert itself. I guess this kind of people may
| not all have created certificates through DigiCert in the first
| place, but I still feel I'm missing something here.
| agwa wrote:
| DigiCert did not cross-sign Let's Encrypt; Identrust did.
| mdaniel wrote:
| I would suspect this was submitted due to Andrew's excellent
| contributions to the comments on the Let's Encrypt outage
| yesterday; put another way, "if you enjoyed this blog post, you
| may enjoy reading https://news.ycombinator.com/item?id=36342808
| also"
___________________________________________________________________
(page generated 2023-06-16 23:02 UTC)