I like how periodically we briefly get reminded that PGP's web of trust really is the superior system but we forget about it in a few minutes and move on.
Certificates not only about encryption, but also about authority: am I really connected to my bank? PGP only solves that if I already have verified keys, which is the hardest part left unsolved.
Unfortunately, proprietary two factor apps seems to be the way this is increasingly solved. Even further removed from a superior system (but, apparently, practical).
But the standard we've got is, once you're "in" to the CA root store, technically you can issue certificates for anything in any context, and the way we interact with them is to simply trust them uniformly.
What we need is a system which let's us easily contextualize the actual trust problem we're solving with a connection: i.e. "I'm contacting a bank in <country>, so I want to know that the government of that country thinks its a bank, (maybe through the reserve bank of that country which expresses trust as to that identity". Chains of trust which make sense for the relationship.
As it is, if I visit say - pm.gov.au and check the certificate I get that it was issued by GlobalSign. Who are they? Well, they're in the Root CA store which is why they're involved because that was the only requirement. But what I want to actually know is "Am I talking to the Australian government and at what level?"
- connection security: are the crypto credentials being used for signing e-mails or encrypting web traffic belonging to the entity in question? This should have been solved by putting the fingerprints into DNS so that clients can validate it on their own instead of having to trust a CA. DNSSEC and certificate pinning would have been the answer, but both are incredibly complex to set up and littered with failure scenarios that may be very difficult to recover from, but in the end it got "solved" by LetsEncrypt/ACME where the CA acts as a proxy. For e-mail, it got solved better by DKIM, but that's only applicable to the scenario "an email server wishes to check if an email it received from example.com actually originates from example.com", but not for "an email client wishes to send an encrypted email to foo@example.com and needs the public key for this mailbox".
- connection authenticity: is the server a client is talking to (e.g. bank.com) actually belonging to the legal entity the user expects it to be? That one is what CAs were originally designed to verify and where a much larger amount of trust is placed on the CAs doing their job correctly. One idea to do that was SSL EV certificates, but for whatever reason these fell out of favor - and right now, there is no replacement at all for this use case.
Additionally, the situation is made even more complex by legal or compliance requirements, e.g. banks who have to record virtually everything their employees do. For that, they have to break HTTPS by providing their own root certificate.
And if you do trust the connection to be free from active attackers then you don't need certificates at all, e.g. diffie helman key exchange would be enough to create a shared secret that in the presence of a passive adversary that can only observe.
But you've opened your bank account in person. When you got the token to login to the bank website they might as well ask you to sign their certificate since you are there.
Many banks do not require this. Many do not even have physical branches to visit.
I guess that's why you have a huge problem of people opening debt under other people's name there, which is a thing that doesn't really happen here.
All the same, two factor devices (you can mail them too) are phased out across the blad in favor of mobile apps. Which is nog great.
My bank linked that very directive when they retired the physical token in favour of using the phone, saying the bad EU was forcing them to do this money saving step.
I couldn't believe it was true, I read the actual text of the directive and it was in fact not true.
* the people that run the Signal Servers (or whoever).
* The people that send the verification SMS.
* The phone company.
... even for a little while.
Two factor only verifies you, not the bank.
Also google's app doesn't easily let you export and backup the seeds. So you either remember to do that initially or breaking your phone == losing access to everything.
I agree that having to use a proprietary app is not great, but TOTP is vulnerable to MITM attacks because the tokens are not restricted to a specific action but only to a time slice. For many use cases that is not a big problem, but for a bank account I'd want more security. Of course being able to do your banking in the same app or a slightly different one on the same device kind of defeats the purpose.
With certificate transparency, there has been almost no invalid certificates found, and anyone who produces one is immediately struck off.
I can't really imagine how web of trust would let me (for example) securely connect to hellbunny.com, a website I have no direct connection to,.and isn't that famous.
https://www.techtarget.com/searchsecurity/news/252436120/230...
The "trusted" party sometimes fails spectacularly it seems.
> hellbunny.com, a website I have no direct connection to,.and isn't that famous.
And what do you know about that certificate? That some root CA signed it. Do they follow a proper process?
I don't care about random websites. For those letsencrypt is fine. But for banking or paying taxes I want some more checks done. And they aren't provided.
They aren't. In the story you link Trustico are a reseller. Once Trustico revealed that they had these keys which they shouldn't have, all the certificates were invalidated because they're worthless, the issuing CA - DigiCert - did exactly what we want them to do.
If the corner store near me sells cans of Coke which they have poisoned, that's not a problem with Coca-Cola, it's problem with that local store. The local cops should get involved, and yes as happened here, the company whose product reputation they harmed should be angry about that and cut ties to them, no more Coke branded fridge if the store owners somehow stay in business (and indeed in my hypothetical if they avoid jail).
The purpose of m.d.s.policy, the discussion group where the decision to distrust Trustcor was made, is to oversee these root CAs. As part of that, we require them to use at least one of the Ten Blessed Methods (there aren't actually currently ten of them) to decide whether a subscriber is entitled to certificates for particular DNS names.
You can read in the CAB BRs https://cabforum.org/baseline-requirements-documents/ what the currently allowed Blessed Methods are in section 3.2.2.4 Validation of Domain Authorization or Control -- each method is numbered e.g. 3.2.2.4.19 is the most often used Let's Encrypt (ACME standard) web site authentication.
You can also read in the CA's own documentation how they claim to implement one or more of the Blessed Methods, for example Let's Encrypt offer 3.2.2.4.19 and explain that, but they don't offer say 3.2.2.14 which is sending out emails with a magic random number in them to a domain contact's email address.
TLS links a key fingerprint (ultimately the identity in any cryptographic trust system) to a host name. PGP links the key fingerprint to a name and email address (although the standard does not prevent you from linking, say, your phone number as well). So in either case we link the fingerprint to a more convenient alphanumeric string. That's it, that's all we are doing here. The whole trick is in what you think that alphanumeric string represents.
I sometimes fantasize about a world where the head office of a bank has a giant QR code literally chiselled into the stone of the building representing the key fingerprint of their root identity. That way anyone that walks by can verify all the bank's identities down to the individual employee simply by snapping a pic with their phone. Part of the responsibility of someone working there would be to check the QR code every morning to ensure that no one had come in the night with a jack hammer and concrete...
If the certificate says "Company AB", nobody checks if that's true.
But, this is not very useful because:
* Consumers generally have no idea who "Company AB" are. You wanted funny-cat-gifs.example not "VXK Enterprise LLC of New Jersey" who might happen to run funny-cat-gifs.example. Lots of famous brands are actually offered by companies with unrelated names, so then you're asking the CA to vouch for the brand name, which is an extra layer of indirection...
* Jurisdiction is a thing. Maybe I trust Greasy Geoff's Cider And Pork, but alas I was thinking of the Kansas Greasy Geoff's, not the one from Missouri.
* Machines can't do anything with this so it's only useful in the rare case a human spent time thinking about it, whereas the DNS name check is something the machine cares about for every single HTTP transaction, of which often several per second happen.