[hadcomplained]

> Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities.

This fact has been irritating me for a long time. Because no one should believe that every single certificate authority is tolerant to any attempts to steal the private keys. But that is exactly the underlying assumption behind HTTPS being the only way to use HTTP in a more secure manner than exchanging in plaintext.

Let's think about this scenario: Suppose that I built a web service for my personal use and hosted it in public cloud. I don't trust any certificate authorities, so I created my own TLS certificate without using them. I installed my own certificates on the machine from which to connect to my web service. Now the server for my web service is serving in HTTPS using my own certificate. Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM.

The problem of being forced to trust certificate authorities can be solved by adding the feature to embed a public key in a url. For example, it would be wonderful to have a url like httpsecure://rsa:PUBLICKEY/example.com/ to make sure example.com always responds using the key PUBLICKEY. IIRC, the Tor onion services is an instance of this -- the .onion domains include public keys.

[judge2020]

> Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM.

You're probably more safe than you'd think. Certificate Transparency is now required for Chrome, Firefox, or Safari or you'll get an error message during the TLS connection, before any private data is sent to the (potentially MITM'd) site.

Given that all certificates are logged, site operators can use some of the many CT alert websites to let them know if and when a new certificate is issued for their domain, so if some random authority they haven't heard of before issues a cert or it's done at a time they know they didn't need to renew their certs, it'd be time to raise major alarms about the occurrence and thus would mean instant loss of all business for that authority; plus, shockwaves would be sent across the internet as this would be a huge event, especially if it's against a company worth burning a CT for (eg. Google which houses so many fortune 500 companies' secrets).

> the .onion domains include public keys.

The .onion domain is, in itself, a public key. The side effects of your proposed solution are:

A) it would mean you HAVE to trust whoever sent you a link

A) 1) for web-based referrals, this would mean you trust your (possibly state-sponsored) search engine to never MITM you (this is currently mitigated by CT which would expose Google's GTS issuing a random domain's cert)

A) 2) for IRL events, this would mean you have to trust that the business themselves put up a certain QR code with the public key and not some malicious actor

B) This would mean site.com could never rotate their private key without changing all of their backlinks to one with the correct public key.

These are all problems Tor already faces - you have no idea if the onion site you're linked to is actually the site it says it is if it perfectly mimics it and/or reverse proxies the real site. You're currently always advised to get URLs from a trusted source once then only use bookmarks to access them to prevent reverse engineering. And you can't rotate your private key without doing this domain change.

[kenniskrag]

Can't you pin the cert (http pinning)? Can we pin a CA cert of one CA? Can we add to dns which CA is allowed to issue certs for this domain like which ip is allowed to send emails?

[tialaramex]

Web browsers no longer offer key pinning because it's both a foot gun and subject to ransom attacks.

So what that means if, maybe the person in charge of the web site "cleverly" enables key pinning, then loses the keys, you fire them for incompetence but too bad your site is now unreachable for a long period, hope it wasn't important. But worse, maybe everybody you employ is smart or careful or both, but unfortunately bad guys break in, and they set up key pinning, then deliberately remove the keys. Now your site is unreachable... unless you pay them a ransom for the keys.

For non-browsers (e.g. a phone app) pinning is still very much possible, and I would say judging from what we see on community.letsencrypt.org that it does indeed function as a footgun - e.g. we had an outfit that does industrial IoT stuff and their things all believed they needed to see certificates from Let's Encrypt X3, which is a shame because X3 was retired in favour of R3 and so those things just broke until a human could reach them to perform a manual firmware update.

A DNS record to indicate which CAs may issue for a DNS name exists today, it's called CAA, and you are welcome to go set it up. However, CAA is about preventing a different issue than the one your parent was ranting about. CAA tells a trustworthy CA that you don't want them issuing, for example because their processes aren't suitable. But it does not prevent them from doing so, it would be a misissuance (policy forbids, they did anyway, that's a policy violation), but it wouldn't be impossible and is deliberately not detected by software like web browsers.

Let me give two examples, one where CAA fixes it and one where it's not applicable at all

1. [Yes this really happened] Facebook has a deal with a CA where Facebook pays them money and they have a bespoke process to issue certificates which includes ensuring the Facebook security team is happy. However, Facebook did not set CAA, and so when a contractor who didn't know any better just created a new web server something.something.fb.com and asked Let's Encrypt for a certificate, they got one. Facebook freaked out. Setting CAA would have prevented this, Let's Encrypt would say "Cannot issue, prohibited by CAA for fb.com" and the contractor asks his contact at FB, who then checks with security first and they either say "No" or get a certificate from their preferred CA. Today Facebook sets CAA.

2. Someone buys a domain example.com, and they're annoyed that the previous owner has a valid certificate for example.com which is still valid, from Entrust. So, they blacklist Entrust in CAA. This has no effect on that existing certificate, it only means the new owner can't get new certificates for that name from Entrust. The correct fix they should have done was to show Entrust that they, as the new owner, want this certificate revoked, in most cases that's just a matter of sending an email and doing what the reply says although the details vary by CA.