Comment by sebzim4500
12 hours ago
Interesting, what would be the alternative?
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
12 hours ago
Interesting, what would be the alternative?
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
Zero would be hard but we could have signed CA cert put into DNS record and from that the org itself can create the certs for that domain.
Then at the very least one of the CAs leaking isn't automatic compromise, as leaking the key still doesn't make you insecure, that would also require intercepting and changing DNS records
In practice we have Certificate Transparency Logs that let us check whether a CA has issued a certificate for a domain you control without you asking them to.
This really reduces how much we need to trust the CAs, because we can detect any untrustworthy actions after the fact. Now detecting after it happened is too late. But it does mean that mistakes or malicious actions are much more expensive to a CA. In practice this has really reduced the risk, especially to those whom aren't interesting enough to burn a valuable capacity on. Which is the vast majority of people. Though perhaps if you count TLS traffic weighted by importance that count is different.
I think someone explained that only browsers and maybe some applications check the CT logs in the first place. Most applications don't, so someone can impersonate any URL an application connects to and the attacker doesn't have to publish to a CT log.
How would certificate transparency logs have helped here though? If the private key leaks and anyone can mint a valid certificate that gets accepted, those logs aren't going to reveal it.
If an attacker takes the CA key and issues a valid certificate, but does not log it to CT, mainstream browser clients will not accept it.
When a certificate is logged to CT, you get back an SCT, and the issuing CA will normally include that in the certificate. The browser will then accept this certificate as it has the correct SCTs (there are always at least two).
The attacker issued certificate hasn't been logged, so can't have an SCT, so won't be accepted by the browser.
We can't say that no certificates have been issued by an attacker. We can say that no certificates have been issued by an attacker that a modern browser client would accept.
Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs.
tptacek argues that DNSSEC is too flawed to actually do this:
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
He's right. DNSSEC is a mess, and we should fix that. We should fix that whether or not we delete CAs because CAs rely on DNS to verify that you own your domain. If DNS isn't secure, neither are CAs.
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
2 replies →
ECDSA was added to DNSSEC 3 years before that blog post in april 2012 (rfc6605).
3 replies →
I have seen their comments across this site for a very long time. Unfortunately I do not respect or put any stock in what they say, because of how unbelievably rude and dogmatic they are, and always have been.
"As a rule, strong feelings about issues do not emerge from deep understanding."
4 replies →
Making DNS secure is not trivial though. In a way that's just moving the problem.
A secure DNS is valuable whether or not we get rid of CAs, since CAs rely on DNS queries to verify domain ownership.
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
7 replies →
Isn't this what DNSSEC solves?
5 replies →
So like, the cable company now controls the certs for most consumers?
shudders
Yes. This is basically the DANE pitch. Subtextually, supporters argue that two big shifts will immediately happen:
(1) We're also rearchitect the way all DNS is done so that every lookup from every phone and laptop is fully recursive, so that everyone validates DNSSEC chains instead of relying on the AD bit that cable company DPI devices switch off.
(2) People will lose all attachment to their current domain names and simply migrate to TLDs that have policies they agree with, rather than .COM and .IO, which are under the demonstrated de facto control of the NATO IC.
That still requires trust stores to be distributed to the clients and some clients don't need that baggage on the dns. Also, dns is by default insecure, dnssec is a configuration nightmare
> That still requires trust stores to be distributed to the clients
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
6 replies →
But how do you make DNS secure without CAs?
You just have one big one on the root.
(Half joking).
2 replies →
Perhaps browser fans will check the source code to verify that their browsers or operating systems using DoH ("Private DNS" or whatever they call it) check the certificates presented by DoH providers against CT logs
The dependency of "accetpable", i.e., not self-signed, TLS certificates on DNS, i.e., a domain name in a TLD created by "ICANN", is funny when one considers that the traffic to authoritative nameservers is still unencrypted. It stands to reason that DoH and other "accepted" forms of "DNS security" are only to stop ISPs from stealing Silicon Valley's surveillance advertising racket. Neither is "DNSSEC" providing the user with any real "security"; it's protecting a monopoly. The "security" is against anyone who might try to use domains names not blessed by "ICANN"
Indeed there's no need for CAs just as there is no need for ICANN
Stop validating names, start signing content.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
That solves integrity but not confidentiality. It does not protect against MITM.
It does protect against MITM. A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.
If confidentiality is required, well you already have a public key that you're using to verify content, then the content can say: "reach us at 196.7.3.45" and then you encrypt communications to that address with the same public key you use for validating content.
Or maybe they'll specify, in the content, that you should use a different key for that, but either way the chain of trust is preserved.
This would of course all be protocol level stuff, handled by the browser, not a human. They just have to maintain a list of keys they trust.
2 replies →
You are describing key pinning. You have invented QR-code-based key pinning.
My intent is to provide users with the ability to revoke trust if in a source of information if they realize it is malicious, and to gossip that revocation among their peers.
RFC 7469 appears to be more geared towards service providers attempting to protect their users. Laudable, but we're still assuming we know something about who the user deems trustworthy, which I think is presumptuous.
It's one thing to suss out cases where somebody is lying about their name, that's pretty cut and dry. But ever since web2.0 there's no longer much of an association between the hostname and the trustworthiness of the content. If we instead provided a means of validating the content's provenance it wouldn't much matter which host was involved in its delivery.
So, have each domain run its own root CA (scoped to the domain), and have users trust them one at a time when they have cause to interact with them?
In the modern day that's arguably fine, most users only interact with a few actual companies online (though many of them haphazardly use dozens of domains and dozens of unrelated certificates).
The only 'real' problem though with this approach is it requires a trusted path for the bank to get the "JP Morgan Chase root CA cert" into my hands (like a QR code they hand me physically). Serving it up over http: or over an unvalidated SSL context at first use seems to defeat the purpose since I could be being MitMd the first time I hit chase.com. In practice most people would be angry that they couldn't use the bank's website if their new phone or PC didn't have the certificate yet, and if places start advertising their cert QRs everywhere, it will normalize the idea that you add a CA certs all the time, leading to CA cert QRs being on billboards and bus stops and eventually fraudulent ones would be snuck in that way.
Yes to smaller scopes, with keys passed of during interactions that organically arise, preferably face to face, but maybe not always. No to making domain names be the thing that's being trusted.
We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.
So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.
Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.
This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.
> When your browser runs accross data tagged "financial" it checks the trusted keys
'Cos no scammer would ever be so sneaky as to leave off the tag... /s
> it up with whoever asked you to trust their key
'Cos no scammer would ever pretend to be that person... /s
Well if you find unsigned content, you should probably just not show it to the user at all.
As for tagging... We could use something like color to indicate domain. So if your well trusted plumber is giving financial advice maybe it shows up, but not in the "financial" color? Idk it seems like a solvable UX problem.
1 reply →
For me the complexity of anything connected to public internet is now over what I can secure.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
I quite like how i2p does it. Public keys are part of addresses, human readable names are user defined and shared but static.
The first time you go to the bank, you do the "trust exchange" (maybe scanning a QR? People sure love that) that verifies future connections, similar to how you acquire digital certificates today when you deal with the government online and similar.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
Not all banks have physical locations, not everyone has the ability to get to the ones which do.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
1 reply →
Presumably you had some reason to trust the bank in the first place. Maybe a recommendation from somebody you know? Get the key from them.
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
3 replies →
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.
And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.
We are well and truly doomed to living in a scammers' paradise.
2 replies →
That could be kind of interesting.
It does seem to lean on the physical bank-front being trustworthy (no evil clerks).
If we’re meeting physically to set up connections, we could even use something like a one-time-pad, and be information-theoretically secure. How many bits does your bank really need to send you securely anyway?
Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Like...TOTP or FIDO2?
[dead]