@sleevi : I disagree. A domain name is like the adress of a house, or a phone number. It does not say who currently lives there or owns the number.
We need information uniquely identifying the owner responsible for a website.
These guys: https://www.virustotal.com/gui/ip-address/91.215.85.79/relations keep registering phishing domain names (one example of *many*).
It is devastating for way too many people to lose all of their savings.
We need:
1) Reliable CA's that reliably ifentify certificate requestors
2) Certificates containing human readable, uniquely identifying information of the owner, apart from domain names
3) Web browsers that help prevent phishing.
I know that big tech earns lots of money by facilitating cybercrime.
Trust in the internet will deteriorate if users continue to have to *somehow* determine, for each domain name, whether it belongs to the owner -as undoubtly suggested in the webpage-
or not.
In offline life, people are used to base trust in reputation - which requires that one knows WHO they are dealing with, often based on a trusted physical location (such as a shop in a mall - they typically do not get impersonated).
On the internet people know nothing.
#Authentication is pointless if #impersonation is easy.
I don't think that would help (at least for https) in face of two different certs for the same domain and with different properties-intended-to-decide-on-trust, because same site policies would consider entities presenting those two certs to fully trust each other.
In face of that ISTM that you'd rather have any such properties tied to the domain name and not a cert (with an expiry, too). Doing that should be way simpler and can be done independently of the CA system we have now.
@robryk : we should point out clearly that X.509 certs do not warrant any trust of the subject.
The only trust that certs should provide is that it should be clear to the user of the browser with how much effort it was determined that the subject is who they say they are. I.e. how reliably do I know who I'm communicating with, and therefore: what are my risks if the system makes me believe it's my bank.
Or USPS, DHL etc. stating that a package could not be delivered (and I have to pay a "small amount of money" for redelivery or taxes only to find out later that I've been robbed).
In nowaday browsers it's binary. Worse, nearly every website (fake or benign) has a certificate and even *educated* users who inspect certificates will know that nore and more websites switch to DV because "too few people" care.
Like in "offline life", to find out whether we can trust another person or their business, we (un)knowingly take 2 steps:
1) WHO is it
2) Knowing who it is: what is their past reputation and what indications do we have regarding the future.
In the internet step 1 is mostly non-existent for ordinary people, and increasinly for those that *do* check certs to find out the subject's identity - not being a domain name. As I said before: #authentication is pointless if #impersonation is easy.
For exact the same reason DMARC is mostly BS: impersonation is way too easy.
I don't see how this addresses what I wrote.
Let's say you have a system where some additional useful information is attached to the cert, with verifiable provenance, and it's displayed to the user when they are visiting a site (so that they can determine whether they want to trust its contents/trust it with secrets).
That will be made equivalent to what I sketched (separate system for assertions about domain names) by semantics of same origin policies: if you determine that cert A for foo.com identifies an organisation you trust with some secret, then any holder of a cert B for foo.com will be able to impersonate you in front of the holder of A and thus likely get the secret you entrusted to the holder of A.
@robryk wrote {
if you determine that cert A for foo.com identifies an organisation you trust with some secret, then any holder of a cert B for foo.com will be able to impersonate you in front of the holder of A and thus likely get the secret you entrusted to the holder of A.
}
Correct.
If your government issues a passport to someone else carrying their photo, but your name and SSN, you're in trouble.
If any bank issues a credit card on your name to someone else, idem.
Systems that are 100% perfect do not exist. Systems where reliability decreases, such as has happened more than significantly to the internet, do.
https server certs (a means to authenticate servers), were a burden for admins. DV certs have undoubtly made their life much easier. However, they also have made the life of cybercriminals much easier.
But, in the first place (definitely since forward secrecy is used), the idea of https certificates is that a visitor of a website knows which website it is.
Considering that impostors generate zillions of "could be from" domain names, just seeing a domain name in the browser's address bar, simply does not suffice for most people.
This is worsened by idiots who use domain names such as login.microsoftonline.com.
Why would sso-microsoft[.]com not belong to Microsoft?
Do you know how many "intelligent" peaple fell for the "circle-ci.com" scam (impersonating circleci.com)? Fake FlipperZero sites?
OK, so my argument is that you can get all the benefits you want already today. There is no need for any changes in TLS/CA infra/... The whole thing can be a totally separate system where you have e.g. a `.well-known` URL where you expect to find assertions about the domain owner made by various third parties (signed by those third parties, etc.). That is just as good, because these assertions have to be bound to a domain name only, not to a cert.
This is a setup that can be easily introduced incrementally, can be done browser-side in extensions, etc.
@robryk : I disagree.
Since (nearly) every TLS connection uses Diffie-Hellman, ignoring certificate-less connections (which are uncommon, but not impossible), then the X.509 cert sent by the server to the browser has *exactly* one purpose: authentication of the server.
If DNS replies received by my browser are trustworthy, then I do not benefit from a DV cert.
If DNS replies received by Let's Encrypt are not trustworthy, then I do not benefit from a DV cert.
DV does not prevent crypto-coin-theft: https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/ (that was not the only BGP-hijack that led to an unjustified DV-certificate submission).
Apart from the Fastly lunacy I mentioned (keaving out the huge number of other instances where TLS no longer has anything to do with E2EE), DV did also not prevent (the German?) goverment from snooping la Jabber server (the server was located in Germany): https://notes.valdikss.org.ru/jabber.ru-mitm/
Big tech does not want QWAC's because those would allow govt snooping and CSP's would not be sanctionable. However, nobody sanctions DV-CSP's who have issued malicious certs.
IFurthernore, it just makes no sense to add *another* server(-owner) authentication system.
In fact, if that were a good system but optional, crims will not use it and most ordinary people visiting their websites would not notice.
It MUST be standard and universal.
@sleevi