Everything we're told about website identity assurance is wrong
troyhunt.com
troyhunt.com
The goal of SiteTruth was to try to find the real-world business behind a web site, and look up information about the business, such as how long it has been in business and its annual revenue. That's become harder and harder over the last decade.
First, it's now acceptable to have an online business with no real-world address and no visible legal existence. This is illegal in the European Union and illegal in California if the business accepts payments, but enforcement is nonexistent.
Second, more sites have become inaccessible to scraping by servers. I have a system which looks for a human-readable business address on a site. It looks in the obvious places (front page, "about", "legal", "terms", "contact", etc.) and quits after trying the 20 most likely pages. It uses a honest agent ID ("Sitetruth.com site verification system", registered with the now meaningless "bots vs browsers" list) and obeys robots.txt. A sizeable fraction of the time, it can't read the site at all.
Third, the data sources for company information have been becoming less accessible. There used to be two reliable data sources: Hoovers, and Dun and Bradstreet. They merged. Dun and Bradstreet for a while became rather corrupt. They licensed a company in Santa Monica, CA to use their name, and sent the small-business part of the business to them. This unit's marketing approach was "Nice credit rating. Be a shame if it something happened to it". After much litigation, DnB HQ bought the Santa Monica company, but the reputational damage was done and DnB is no longer the gold standard of company information. There are lower tier data sources (look up "US Business List"), but the data quality is poor. Anything based on user recommendations, like Yelp, gets spammed, so that's out. Yahoo Directory, which was reasonably spam free, is gone.
Fourth, the SSL cert industry became corrupt. OV standards were never very high, and EV standards started slipping. Then there was the Cloudflare problem. Cloudflare is a certificate authority, and they issue certs to themself for domains which run through Cloudflare. So looking up a cert just gets Cloudflare's info.
Fifth, Google is making it harder and harder to have Chrome plug-ins that critique their ads. I dropped Chrome support recently, and only have a Firefox add-on at this point.
So, after fifteen years, Sitetruth is coming to an end.
Tying SSL certs to identity (rather than just to verification that someone has the authority over a given domain) was a dumb idea in the first place, so I hardly see a problem with workarounds in that regard.
on edit: yes, they want to verify identity because their purpose is really to provide a form of security as well, so it is sort of removed by a step / nothing works all the way down, getting confusing at this point.
Seems like this could just be a government run database (assuming these businesses are paying taxes and not completely shady) with some of it publicly accessible.
Have you tried also looking at US shipment logs? I know there is that guy who a few years ago made a site that scraped and indexed all of the public shipping logs (anything crossing US borders by land or sea goes into huge public databases - for some reason air is excluded). Could be a way to cross reference this data to fill in the blanks for some of the things you are talking about?
I've also never had a good experience with the validation process from any of the CAs. They often push anything that's not immediately discoverable back to the applicant and expect them to do the leg work. I've had both Comodo and DigiCert do this to me in the past. Here's an example from DigiCert. This happened this year (2022).
> First, As part of the verification process, we are required to confirm the registration of your organization with the local registering authority.
> We have attempted to locate the registration records using online resources, however we have not been able to locate such a document. If you are aware of any government based search tools for your jurisdiction that can be used to locate proof of the organization's registration, please reply to this email with a link and instructions for locating that record. Once received, our validation team will confirm the record and proceed with the validation process.
Really? To me that seems like someone who isn't familiar with my jurisdiction because they don't know the process. What's stopping me from sending them a link to a fake, official looking site? It seems like an invitation for social engineering. Code signing certificates are the same. It's infuriating.
In my experience, they look for your company on Google Local (or whatever it's called now) or similar and if they can't find it they punt it back to you. I think the whole process is worse than nothing because it's selling a false sense of security for anyone who believes the marketing.
From a customer value standpoint, I'd rather pay for a DV certificate where the value comes from helping me to set up proper CAA records to prevent mis-issuance as well as certificate monitoring for any potential lookalike domains. Of course, the margins on that probably wouldn't be as good.
Thankfully I only deal with one place that insists on buying expensive certificates because "they're better". Just for fun sometime go look at the TLS certificates used by all of your local government websites and try to figure out what they cost. Then factor in the labor for multiple people to coordinate annual renewals and manual installation. It's frustrating.
1. PDF Warning: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...
I did. A high-value (to me) service used a cert with the green banner and I'd look to it to be reassured I was in the right place. Then one day, it disappeared.
Alarm bells started ringing and I tried to find out what was going on. I called their help desk and asked if they had changed their TLS certificate but the helper I spoke to had no idea what I was talking about and couldn't be persuaded to escalate my query.
Just in case my connection was being hacked by someone who managed to register a lesser TLS certificate, I left it a day until I could try again from my home broadband.
In the end, I did go ahead and use the site without the green banner, which makes me my own worse enemy.
It caused a great outcry from CAs, and I would’ve normally been against a single-sided, mostly Google-driven change like this, but the discussion[5] shows, at least as I read it, that CAs are unwilling to clearly communicate that the EV “green bar” does not imply “trustworthy”, it just upgrades “you have been securely connected to satan.com”, an authenticated DNS name, to “you have been securely connected to Satan LLC”, an authenticated legal-entity name.
And as Stripe, Inc., of Kentucky shows, it’s not clear this is an upgrade at all, because while the rules for domain uniqueness in the DNS are relatively (barring IDNA) straightforward and well-known, the rules for uniqueness for names of legal entities are complex and dependent on jurisdiction to such an extent that neither users nor even CAs can be reasonably expected to follow them all. (I think one discussion on the CA/Browser Forum list mentioned that—forget state-scoped legal names in the US Stripe case—Germany has township-scoped legal names, so jurisdictionOfIncorporation would literally have to record, and UAs to show, the address of a specific town hall in Germany. Sure you know which one it should be?) Even today you will find CA websites[6-8] proudly proclaiming “customers think the EV green bar means trustworthy” (and, presumably, if they don’t, you should teach them to). Except it doesn’t, and believing it does is harmful for users, so into the dustbin of history it goes.
(Of course, the conventional legal system is not completely clueless about this namespace issue and in most countries implements “field of endeavour”-scoped trademarks as a solution, but the issue of jurisdiction on a global Internet, as opposed to a billboard in your hometown, is only somewhat attenuated, and the discussion seems to show CAs were unwilling to move away from “green bar = secure” marketing, which is harmful however you spin it.)
There’s a more general line of research on the uselessness of positive security indicators, that first entered the public eye perhaps with Moxie Marlinspike’s green-padlock-favicon demonstration[9] at Black Hat 2009. The Google announcement page[1] links to some later developments in that respect. Chrome later phased out “secure” for HTTPS sites completely in favour of showing “not secure” for HTTP ones, highlighted in red once a password input or similar appears[10].
Fortunately for you if you want your EV TLS certs back, the corpse seems to be in the process of being raised[11,12] through the necromantic power of money and government coercion. (What is it about PKI that drives everywhere bureaucrats so wild?..)
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1572936
[3] https://www.troyhunt.com/extended-validation-certificates-ar...
[4] https://arstechnica.com/information-technology/2017/12/nope-...
[5] https://groups.google.com/g/mozilla.dev.security.policy/c/iV...
[6] https://www.digicert.com/faq/when-to-use-ev-ssl.htm
[7] https://www.globalsign.com/en/blog/why-ev-ssl-is-here-to-sta...
[8] https://www.thesslstore.com/new-to-ssl/is-ev-worth-it.aspx
[9] https://vimeo.com/50018478, slides at https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/...
[10] https://security.googleblog.com/2018/02/a-secure-web-is-here...
[11] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
[12] https://www.eff.org/deeplinks/2022/02/what-duck-why-eu-propo...
They spend considerably less time talking about why browsers do such a terrible job of surfacing cert information for website visitors. Yes, cert UI sucks; not sure we needed an enormous article to belabor that. The real question is, why does cert UI suck so bad? (UI design is a choice.)
The answer is that everyone who runs a major browser has a vested interest in making sure decentralized site verification sucks. Because they are supported by highly centralized private site verification schemes.
Decentralized verification is the norm offline. Do you carefully Google and research every store you walk into? No, because to open a store, the store owner has to establish a paper trail. And if you have a problem at that store, your advocate (a credit card company, insurance company, lawyer, law enforcement, etc) can follow that paper trail to find a party they can negotiate with, or investigate.
Over time, the effectiveness of this system—in which all parties have invested—creates a barrier to in-person scams. The result is a society where you can walk into a new store, a restaurant, a bar, etc. with confidence.
And note that name collisions don’t matter in this system. There are tons of restaurants called “McDonalds,” all owned by different people. But each one has an address and a unique paper trail that leads to a specific person or business. If you can remember which one you visited, your advocate can follow the paper trail for that one in particular.
The idea of EV and OV certs was to use the power of encryption to hook your browser to this same set of offline paper trails. You wouldn’t even need to remember anything; the browser would maintain a log of the sites you visited for you. If you got scammed, you just look back in your history and forward the business info to your advocate or law enforcement.
The decentralized nature was a feature; businesses had the choice of which cert to get, who to buy it from, and users had the choice of browser. Competition and mutual distrust would create incentives for parties to hold each other honest.
To be clear, an EV or OV cert would not magically prevent scams. But they would provide cryptographic guarantees that an advocate or law enforcement could trace back to an entity, to prosecute or make you whole. Just like in a real life store.
Instead, browsers became dominated by companies who run for-profit search engines, app stores, and identity platforms. So today what is the advice for verifying a website’s legitimacy? Google it. Or get their app from the curated App Store.
The result is a web dominated by a few huge gatekeepers. SEO is life or death because Google is the only way for a website to be “real” for people.
And most techies went along with it because they shared the vested interest, or did not appreciate the existing system that creates the real life shopping experience we see every day.
And so where are we today? A new generation of techies trying to use the power of encryption to create a decentralized web. Web3.
I don't agree. I think a lot of tech people (like me) felt like the whole system was a grift and that nothing of value was lost when LE offered an alternative. If you start a business in my jurisdiction your paperwork is going to get a lot more scrutiny than what the certificate authorities were (or are) providing.
And I think you're right about EV? Ignoring gross CAs trying to juice the web, it makes sense to try to link the web's web of trust to our... non-web web of trust. The web is still pretty new, it's still pretty unfamiliar, and a lot of the signals we use to suss out a fraudulent physical shop don't really apply to the web.
I would counterargue, though, that you're really mythologizing physical stores. I think tons of fraud and abuse happen in physical stores, up and down the stack. The "paper trail" is like 45 minutes on LegalZoom. I think it's worth separating things like banks and bank websites from like, illegal casinos and gambling websites (crypto exchanges are what I mean here).
When you kind of pick away at the "physical stores have no fraud" pillar, then I think the web's security/trust model actually holds up. I don't simply rely on TLS to tell me that bankofamerica.com is legit, and I don't think anyone does, which is good because it doesn't! I also have totally different behavior when I'm doing online banking than when I'm [insert risky/shady thing here], because the threat model is different.
And there's where I think we hit a crossroads, because that "risky/shady" thing for everyone is "getting an email that looks like it's from your bank". This is an attack that doesn't really have an analogue in meatspace, but it's super effective because again, we don't have all the signals we normally do. If it were meatspace, I'd notice this wasn't my usual branch and then probably notice some other differences that might give me pause, but the web makes it possible to create a very convincing copy.
So, I think you're right in the large and I super agree. I just think that phishing is very bad and you shouldn't say you solved it when you in fact haven't solved anything. That's (almost certainly) browsers' fault, but that's a little irrelevant imo.
Here's a potential analogue - sometimes people stand in parking lots and collect fees, claiming to be representatives of the lot's owner, but in reality pocketing the money.
Some lots counter this by posting signs along the lines of "do not pay any attendant; pay only via kiosk/online". But since some lots do in fact collect payment via attendants, a potential way to secure this would be for the attendant to present proof that they are employed by a certain company. While the customer might not be able to verify that "ABC Parking, Inc." is in fact the owner of the lot, at least they would have a trail to follow if they were scammed.
This is an area where cyberspace has an advantage - the closest analogue to an EV certificate in the physical world would be a piece of paper with some official seal on it, which can still be forged in a way not easily detectable by the average person.
The underlying issue internet wise is unlike the scam you’re referring to, the people can be in another random jurisdiction and impossible to even arrest and still succeed at doing it online. In fact, in many cases it’s even economically preferable to do so (regardless of potential punishment) due to lower costs of living.
So you aren’t dealing with 5 lots in SF the owner is trying to avoid the problem on (and for which at least in theory someone could be caught and prosecuted by looking at a camera or walking there), you’re dealing with potentially every lot everywhere all at once, and that it is in theory scammable by people anywhere. And that there is no lot the owner can walk over to and see if it’s happening easily.
i don't see how it follows from this that the UI browsers provide for EV certs is bad. you claim that the value is not in inspecting the cert before a transaction, but in the logging of that data. the UI that browsers provide for EV certs allows you to inspect a cert if you really want to, but goes out of its way to avoid any implication that an EV cert is doing anything to prevent you from being scammed. that's a good thing. the browsers are honestly representing the effectiveness of EV certs.
Click on the lock in Chrome. It shows you the domain name. There’s no reason it could not read the cert fields and give you the parent org name and where it is registered. As opposed to clicking twice more and pulling those fields out of dozens of technical fields. It doesn’t pull the human info out, for a human to look at easily.
Or take a look through your browser history. Is site metadata logged with each entry? Can you look back at what the browser logged from the cert or network data when you visited a site last month? Is there a nice UI to help you find the problem site and package that info up so you can send it to someone else?
Browsers suck at safety UI in general. Let’s say I do find a phishing site. Where is the button to “report a problem with this site”?
Chrome has a screen to report browser bugs; in Firefox “deceptive site” is the last item in the help submenu. Compare to the prominent “report spam” button in email clients or the report features of social media.
Even if browser providers don’t want to take these complaints, the browser itself knows the domain registrar, DNS provider, and host for every website I visit. Each of those is a company that should have a process to handle abuse complaints. Registrars are required to supply abuse contact info in WHOIS. The browser could give me a nice UI to make use of that info.
If anything, it seems way easier? It also isn’t showing a potentially overly sure view of who the cert is really registered to for everyone.
Could it be made easier? Sure. But most folks aren’t going to be able to usefully process that information anyway. There are a ton of ways of making Whois information look plausibly like it’s owned by a bank when it’s not.
Of course you don’t have to go to a restaurant; you can buy burritos from a guy in an unmarked van by the river. But we understand that in doing so, we’re taking on more risk than going to a restaurant in a storefront.
That was the idea behind OV and EV certs: give businesses a tool by which they could overtly make themselves more accountable to consequences. Like leasing space and opening a storefront.
> There are a ton of ways of making Whois information look plausibly like it’s owned by a bank when it’s not.
You can’t affect the WHOIS fields where your registrar lists their own contact info, like abuse@godaddy.com, 480-624-2505.
You can call in a complaint about a bogus website to them too, and it’s even easier to figure this out? (From being familiar with those databases)
The issue is that unlike someone with a physical presence in a specific place which makes someone vulnerable to being physically arrested, the internet makes it easy to do something that would otherwise result in that consequence from a place where that consequence is impossible.
And no amount of traditional records and ‘call the cops’ type processes are going to address that. And no amount of extra visible information somewhere in a place that will be overwhelming and ignored is going to fix it either.
Cops are about physical restraint (generally), aka ‘arrest’, which is the only proven ‘lowest common denominator’ way anyone seems to have figured out to ACTUALLY stop someone from doing something. You take them physically, put them in a cell where they can’t access anything but the things you hope they can’t abuse, and hold them until another resolution is figured out or you have to release them anyway.
To avoid problems like a random cop in rural Arkansas from going to Washington and arresting the president, the area different police are able to do this in is restricted, various rules and laws, etc. further restrict when, where, and how they can do it, etc.
Fundamentally that means most cops are helpless in this scenario unless said bogus website scammer is dumb enough to scam people in his same town/city/state/whatever.
And unless everyone takes a ‘scam unless proven innocent’ approach which pretty fundamentally breaks the internet’s usefulness, CA signing and the like doesn’t really solve any of that problem, no matter how accurate the information is.
On the one hand, we're supposed to trust no one on the web, on the other hand the web is only useful if we're effectively trusting everyone (except the most obvious scammers).
So how do you verify trust on the web?
If someone does a big enough scam on a big enough target (like a crypto ransom on a major oil pipeline), they’ll get the attention of someone who can ‘bend the rules’ enough to make their life hell and get you anyway, no matter where you are. But that doesn’t stop them from ruining a ton of people who aren’t that noticeable. Because those people aren’t noticeable, it’s also a lot of value that can be extracted that way, which makes the problem worse.
Most people currently consider it working well enough to be better than the alternatives based on overall numbers.
however as the scam economy develops, which it has been doing, something is going to break.
it’s not going to go in the direction of random police officer in Vietnam, Nigeria, or Russia arresting his buddy (no matter how solid the evidence looks) because someone in the US wants it to happen.
Think what happened with email and spam in the late 90’s - up until that point, spam filtering was a niche thing only nerds did. Then it got to the point email was useless without it, and thankfully for email, spam filtering worked and the providers provided it.
Phones, phone providers haven’t been interested in, so except for some business cases almost no one uses phones directly any more (it’s texts or everything to voicemail first or whatever).
So no idea how this is going to go - curated marketplaces for anyone online? Federal/EU Gov’t certs to do business online? ‘Great firewalls’ to keep the scammers out/limit traffic to where it can be policed? Consumers bailing on online purchases except for specific already known and ‘trusted’ names?
this is not a solved problem - that's the whole point. there is no general way to verify trust on the web. We can verify trust in certain connections or transactions, but it's not possible to trust "the web". and until the problem is solved, anybody trying to sell a way to do that is selling snake oil.
Yes, there are edge cases in which EV certs can be confusing, but in general they give a guarantee that you're dealing with a registered company from a country with generally respected business standards. That's a lot better than the current state where the site might as well be served from a raspberry pi in some teenager's basement.
If the company's name is not sufficient to identify them, put an address in there, too, or registration number or whatever. I don't get what's so hard about this.
And as for "people are ignoring them", I'm sorry, but this is largely the browser vendors' fault. For a long time, people were ignoring cert errors as well. Browser vendors reacted with a massive UI revamp up to intentional dark patterns to change behaviour here - and it worked.
Meanwhile, with EV certs, UX went into the exact opposite direction: Browsers were increasingly de-emphasizing the EV data, to the point that people are actively discouraged from looking it up. No wonder then that no one checks EV information.
"in general, except for the edge cases" is the opposite of a guarantee. they create a situation where users assume a level of trust that can't be actually guaranteed, which is exactly what fraudsters exploit.
browsers aren't actively blocking attempts to tackle this problem. browsers are blocking schemes which falsely claim to tackle the problem.
Yes, yes I do... did. I'm in the US and get a vast array of bills coming from all kinds of different sources (utilities, doctors, etc.) that manage their payments via some random portal. Some of the "payment portals" they send me to are sketchy as hell and it brings me great anxiety to use them even though it's guarantees my payment arrives on time and I don't have to fuss with snail mail (and its associated thefts). I always make sure they are https and I used to look "beyond the lock" to make sure they a well-known CA was being used. Well as Troy mentions, it's effectively a worthless endeavor. I'm glad he's bringing this topic up to gain more visibility and awareness towards the issue.
If the companies aren't going to bother there's no hope for the users.
The conclusion was essentially that trust indicators offer no benefit at all and can even go as far as creating harm since it could encourage a user to trust an entity that they don’t know if the system is abused. The psychology of it boils down to this: people trust lots of sites, services and other people who haven’t paid extra for these trust indicators and because of that it’s not going to change their behavior at all.
On the flip side, inline and accurate warning indicators go a long way towards making users more cautious. Big red warnings from Google about users outside your domain for example.
There are a lot of flaws in EV. I think the biggest one I saw was that it is effectively no more useful than TLD's/subdomains. In fact, it's worse, because unlike domains, there can be multiple owners of the same corporate name!
To the people saying there is a paper trail... What good is that? There are "paper trails" for domain registration too. But that isn't very reliable and the same would happen with corporate registration. We know this all too well from how wealthy people use shell corporations to hide. And I'm sure there will be plenty of places around the world where it will be easy to incorporate for bad actors, even if some places do a good job of creating a paper trail.
Fundamentally, this is a hard problem to solve and I really don't see EV solving this any better than domains.
fwiw, I am not the biggest fan of Google's level of control either, but I think that the ideas in the video stand for themself. Forget the Chrome-specific stuff and just focus on the basic UX concepts.
Without providing some specifics, your comment comes across as pretty shallow and more about your dislike of Google than criticism of the actual ideas.
Here are some of the ideas that I think stand on their own regardless of who presented them:
- EV's cannot be trusted by users because different entities can have the same name, how is the user going to vet that?
- EV's have a problem of corporate name != domain name, how is the average user going to figure out if it's the right entity?
- Domains are difficult for users to verify because there are so many permutations possible with all the new TLD's, as well as subdomains
- URL's are difficult to read because paths are often non-human readable
- URL's are hard to share through non-digital means
and more... lots of generally applicable stuff that isn't all a giant Google conspiracy.
What is terrible about these ideas?
Web browsers told me they'd try better verification markers for years. They never did. So we don't know, except to say:
a. the 'green bar' verification marker isn't very effective.
b. the 'blue tick' logo as used for UIs like https://twitter.com/troyhunt hasn't been tried so browser makers have no data here.
It's a moot point: the realpolitik is browsers don't care about identity as it's not in their financial interest to do so.
Disclaimer: I spent 5 years of my life trying to verify the web.
So much truth expressed in this phrase. More than most of us would like to believe.
This is why I can’t avoid reading HN.
I feel this would prompt browsers to care about robust identity - both in terms of better verification and better display.
EV is/was proof of identity. And proof of identity needs a scalable solution for the web. Certificate pinning won’t scale unless the browser knows all possible certificates in advance.
Knowing whether something is a scam is a separate topic from verification. Think of other verification systems - people may be known, but bad. Admittedly twitter muddied the water here terribly by removing verification badges from people that twitter considers to have broken their terms of service.
It's literally why banks were massive stone buildings - proving that they had the resources to build a solid thing that wasn't going to move or change was a part of establishing their identity as a something that can be trusted.
So the equivalent for EV would have been to make them cost ... say ... $185,000 to register and $25k a year - wait, that's a TLD and would be a much more powerful form of identity and ... it's not used at all. https://google.google redirects to ... google.com
Also why do I care about an EV cert as a user? does it tell me anything actually useful? Things I do care about as a user:
* Is my connection encrypted? (Browsers tell me this just fine)
* Is the site known to be malicious? (Browsers tell me this just fine)
* Have I been MiTM'd (Browsers protect against this just fine)
Things I don't care about as a user:
* Is this site actually owned by a specific Corporation?
Literally have never cared. Not once. Knowing this has never made me more secure or given me more confidence because fundamentally knowing who someone on the internet is does not tell me how trustworthy they are without way more context.
EV is literally the result of calling up the company directly and asking, signed by someone your browser trusts.
For online banks, I only got to them online by which automatically means I have their correct domain name.
The question of how I get the online bank's domain name to begin with does not really come in to this conversation, can be an ad, a friend etc.
It doesn’t matter that it was a name collision with Stripe the payment processor. EVs were not designed to resolve name collisions. They were not even intended to attest that a business is legitimate.
What matters is that Ian had to register a company to get that EV. Which means that if he had actually tried to scam people with it, the police would have a nice paper trail back to him.
The paper trail is the deterrent. All the EV does is attest to the existence of a paper trail.
Name collisions are not a problem in general. There are other people in the U.S with the same first and last name as me. There are thousands of restaurants called “McDonalds” that all look the same even though they are owned by different companies.
It’s a solved problem. It is solved with legal documentation, like taxpayer ID numbers, articles of incorporation and payment records. The sole purpose of EV and OV certs is to cryptographically connect your browser to those.
1. The paper trail is probably not as good as you think. I feel like you're thinking of a US system where there might be some pretty solid systems in place, but what about all the other countries around the world? I'm sure there will be at least a few places that will not be great paper trails.
2. The paper trail only helps you after you've been scammed as a way to maybe track down whoever did that. A costly and time consuming process which may be next to impossible if you think about the complications of shell companies and legal jurisdictions. Or are you suggesting that before you use a site you go through all this work proactively?
2. Companies and law enforcement have lots of experience tracking paper trails. Is it perfect? No, obviously not. But it has worked well enough offline that in jurisdictions with good rule of law, we have little fear about checking out a new shop or restaurant for the first time.
- there will be scammers even in the areas with stronger legal systems (look at one of the other sibling commenters RE: Britain, for example)
- having a paper trail is reactive, not proactive
- the average person will have a difficult time tracking down a paper trail
Well, maybe. Maybe not:
> company formation agents signed up people who, for a fee, would declare themselves directors of newly created companies. Edwina Coales, a serial director of companies registered at 29 Harley Street, is or has been an officer at 1,560 of the companies listed on the Companies House website...
> In Britain, almost half of agents were happy to sell a company without checking the identity of the person buying it. If the agent does not record the beneficial owner of a company, then there is no way law enforcement officers can discover that information...
> From 2010 to 2013, cold callers harassed thousands of British households with claims that land near the Brazilian seaside town of Fortaleza would rocket in price thanks to the then-forthcoming World Cup. The cold callers seemed plausible, and 600 people put up a total of £19m. But, in 2013, the Insolvency Service stepped in, forcibly winding up a group of related companies involved in the scam, among them Pantheon Limited, and Pantheon Realty Consultancy Limited, both registered at 29 Harley Street.
> The only culprits the authorities could find were Ismael Rajabi and Ahmed Mohammadi, both from Afghanistan, whose names appeared on the companies’ registration documents. They are real people, but Companies House had, of course, not checked if they actually were the owners of the companies, which they were not. The real shareholders vanished, taking the investors’ money with them, and all the law could do was disqualify Rajabi and Mohammadi from being directors for 11 years.
https://www.theguardian.com/business/2016/apr/19/offshore-ce...
All the PKI requires of CAs (for DV certs) is to ensure that the entity requesting a certificate has control of the domain name they are requesting the certificate for. That entity may very well be a server, not a person; and it may very well be malware that has infiltrated on Google's servers, requesting a certificate for google.com. It's not up to the CA to verify which it is, for DV certs.
Sounds like EV is great in theory, nigh-worthless in practice.
Beyond that, it's all FUD, marketing, and hype. And at least 90% of any actual benefits to normal users of the web fall under "convenient side-effect of what the large corporations would have done anyway, for their own benefit".
[/cynic]
How do you determine whether this is actually Amazon or a scammer?
I'm not an expert, but at high level it seems to me that the only way to get trust is to tie every digital property to a real person, do some sort of KYC on them and allow for dispute resolution. The usual bureaucratic pains of doing anything in the real world would extend to the digital world, and the usual arguments about increase in regulation entrenching existing power structures and slowing innovation apply.
I think it only makes sense if you view the whole HTTPS everywhere initiative as a counter against MITM attacks - and only that. Everything related to identity has effectively been delegated to domain registrars. TLS certs as envisioned by browsers are really only about proving that you have genuine control of a particular domain - they give no indication at all who you are, whether your intentions are good or whether or not you're trying to imitate a different domain.
In that sense, the UI redesign from "neutral/secure" to "insecure/neutral" in Chrome makes some sense: HTTPS is necessary but not sufficient to make a site trustworthy: A https site might still be a scammer, but a http site can always be intercepted and manipulated by MITM, so http sites can can never be trustworthy at all.
You could mitigate this with some kind of (non-scary) trust-on-first-use UI. But even that doesn't help you if you're unlucky enough to encounter the attacker before the real site. (Which isn't even that unlikely if the attacker is e.g. an ISP proxying all connections by default)
What LE gives you is a signed statement saying in effect: "we've seen that the owner of this cert can make changes to the domain which are visible from multiple different network locations - so they are very likely the real owner of the domain and not a MITM".
That's valuable, even if it doesn't tell you anything about who that entity is.
What I absolutely would wish for is some mechanism to include a cert hash in the URL. Then you could e.g. distribute QR codes with the cert hash embedded and circumvent the trust problem that way. Then, I agree, there would be no reason not to use self-signed certificates with that technique.
Might as well just stick the certificate hash in a DNS record and forget about keeping a public consensus on universally trusted CAs.
I blame the browsers. They could have made it perform some kind of check, give some kind of warning. We've had to drag them kicking and screaming to adopt every ridiculous security extension to the web. They still use half-ass measures like HSTS that are trivial to work around. Nobody look at the big pink elephant.
The other issues with EVs are more damning to me.
Im not sketchy, my site isn't sketchy, and so there's nothing for the 0.001% to complain about.
So my site is DV, always has been, and no one has ever complained about that. So the money, and more importantly the hassle has no benefit to me.
Rinse and repeat for (some large % of web sites), users don't care about green bars or not, and EVs become useless.
The first time you connect to a website you get whatever identity it wants to show you. Whether it is a real site or not doesn't particularly matter, it only matters when the identity changes. If my first access was MITMed and then I connect to the "real" site, I should go and check to see what information changed, and if I sent any sensitive information I should probably do something to mitigate that (the exact action would depend on the exact type of info you sent). In the reverse case where you trust the original identity more than a changed identity you would ignore the event and might possibly want to inform the original entity that someone is trying to impersonate them.
Still fairly complicated for the original user, but certificate expiration would no longer be the insanity that it is now, and you can at least get transport security without the big scary self signed warnings that show up now.
Tor Hidden Services are closer to a well-designed petname system. The important insight is that, since domain names are too technical for ordinary people anyway, they might as well just be random numbers. If you trust someone to give you the real domain name for the server, you can also trust them to give you a signature for their real public key, and you don't even need a CA any more. The advantage of using a cryptographic signature for your address is that it implicitly forms a web of trust, using the links that people were already sharing.
The biggest problem with this — and SSH doesn't seem to do a better job of it than Tor does — is key rotation. Deprecating an old cryptographic algorithm is a total disaster in any system that doesn't support key rotation — it's fine on the server side (just host with both keys, and serve a 301 redirect from the old one to the new one), but the client side eventually needs to stop supporting the old algo, because those would be vulnerable to downgrade attacks, and at that point you cut off anyone who hasn't switched to the new one yet. CA's take care of this, because it's literally their job, but distributing the responsibility to everyone can easily mean it doesn't get taken care of properly.
This is how many people seem to use SSH, yes. It's also quite plainly the wrong way. I'm thankful the people behind HTTPS have higher standards than the typical Unix user seems to have.
I've mentioned before on HN that I once submitted a ServerFault question after finding myself unable to match the SSH fingerprint shown on the EC2 web interface against the one PuTTY was showing. [0][1] It turned out that PuTTY's fingerprint scheme was MD5/hex, whereas OpenSSH had switched to SHA256/Base64. I was surprised no one else had asked the question.
I dabbled with Azure recently, and iirc it was close to impossible to view the SSH fingerprint of a new instance using their web interface. Perhaps it was possible via a web-based command-line session. Either way it was disappointing.
I now suspect I'm part of a tiny minority of people who ever think to check SSH fingerprints.
> You can be MITM'ed for free the first time you connect (obviously, that's what TOFU means)
Judging by the old thread [0], at least one person uses it to mean Check manually on first use then trust it, rather than to mean Blindly trust on first use. Wikipedia seems to agree that the term can refer to either strategy. [2] I now make a point to say blindly trust on first use, or check manually on first use, to disambiguate.
Also, for what it's worth, SSH certificates do apparently exist, [0] but I know nothing about them.
[0] https://news.ycombinator.com/item?id=23958456
No, that's wrong. That's my point. If TCP/IP were inherently secure we wouldn't need SSH in the first place.
SSH fingerprints offer you the opportunity to cryptographically verify that you're connecting to the machine you think you're connecting to. If you fail to check the fingerprint, and instead blindly assume it's ok, you could be connecting to an attacker's machine instead.
This turned up in the previous thread too. https://news.ycombinator.com/item?id=23960905
It's not that I think TCP/IP is inherently secure. It's that, because TCP/IP is not inherently secure, I don't think raw TCP/IP addresses should be exposed to end-users. In other words, the right way to phrase it would have been.
> If you get the TOR address from a trusted source, like the Azure dashboard, then you’re connecting to the correct machine. No need to rely on people being meticulous enough to compare hex addresses.
Right, that's why we have TLS.
Most network protocols these days use crypto, one way or another. Many use TLS, as it's generally the right answer. For better or worse, SSH does things its own way.
I have to admit I don't know much about Tor, but I don't see how it has much to offer here. The more relevant technology would be VPNs. Properly configured SSH is pretty solid on its own though, especially if combined with IP whitelisting to filter out port-scanners and help stop you getting in trouble if there's a zero-day against your SSH server software.
The problem with DNS is that DNS names are global, and human readable, and therefore rely on a central authority to handle disputes. They aren't even particularly good at human-readability, because they have a vestigial hierarchy that doesn't even mean anything half the time, and they aren't given enough scrutiny to make sure that nobody uses confuseable, typo squatted, or bit squatted names.
The problem with CAs is that they're centralized, and they need to be able to see your domain name in order to validate it. This makes air gapped systems a pain in the neck, along with anything else that calls into question the global reach-ability assumption that they're making (like plain ol' networking glitches).
* The Tor network also has exit nodes that can access the regular web. For this to be secure, you need all of the normal security practices for websites, including TLS. Hidden Services don't need exit nodes, and they don't need TLS.
This isn't a problem in practice. DNS security issues do exist, but typically don't relate to its centralisation.
That's not to say there are no downsides to centralisation. I'm not especially happy about the way everyone with a website has to pay money to rent-seekers. I'm also opposed to the unending addition of novelty TLDs, and to the way special domains like t.co are only available to organisations with unusual clout.
> They aren't even particularly good at human-readability, because they have a vestigial hierarchy that doesn't even mean anything half the time
I don't see a real problem here either.
> they aren't given enough scrutiny to make sure that nobody uses confuseable, typo squatted, or bit squatted names
The basic goal, roughly speaking, is to map from string to IP address, so the existence of confusingly similar strings is a problem sometimes, yes. Again I really don't know much about Tor - how does Tor solve this?
> they need to be able to see your domain name in order to validate it. This makes air gapped systems a pain in the neck
You're not the only one to say this, but I don't see the problem. You can get a cert for intranet.example.com, give it a 'parked' public-facing page, get a cert for it, then use that cert internally for your intranet. You could also get a wildcard cert. Seems like a pretty solid solution.
> along with anything else that calls into question the global reach-ability assumption that they're making (like plain ol' networking glitches)
I'm not sure I follow here, what do you mean? DNS is very robust.
> Hidden Services don't need exit nodes, and they don't need TLS.
I see. How can I trust the connection though? What's to stop an attacker taking control of my network connection and pointing me at their machine instead?
Doesn't there need to be some kind of secret-management system in place? SSH answers this with fingerprints. HTTPS answers it with certs and CAs.
https://www.eff.org/deeplinks/2022/02/what-duck-why-eu-propo...
You still need them to properly sign binaries for Windows or get your logo showing in Gmail (BIMI), which are legit usecases where you want to verify the identity of the company.
The alternative to that is each business setup their own verification mechanism similar to what Apple does and you have to pay each one a good chunk of money. (Arguably the EV certs are not cheap either).
The idea behind EV was almost a good one - but you'd need a central authority that can say "This Nissan is the Nissan you're expecting" which is nearly an impossible problem at scale (see https://nissan.com vs https://www.nissanusa.com).
What has happened is Google is the central authority for 90% of the web - you search the company and click the link (which maybe is an ad to a scam site?).
LetsEncrypt is such a breath of fresh air. And the short 90 day validity period more or less forces you to set up an auto-renew script, so you can typically set it and forget it.
And if you mess something up, they even email you to warn that your cert is about to expire!
But encryption alone is insufficient for security in financial transactions. You also need to verify that the entity you’re exchanging encrypted traffic with is the one you intended to do business with.
How do you do that part today? Not via Let’s Encrypt.
For finance transactions there's basically a number of well known entities who should be vouching for the data I'm sending, who have large out of band systems for identity verification.
Sadly none of that has happened.
I suppose Certificate Transparency is the tech working behind the scenes to flag mistaken or malicious certificates should they be issued.
Not even via TLS.
In all seriousness, PKI at web scale is a joke. Nobody knows which CAs are installed in their browser, who these entities are, how trustable they are, etc.
I have long accepted that TLS brought encryption, but certainly not trust.
Making the answer to the second question dependent on also answering the first -- so it was necessary to set up a whole chain of trust via a hierarchy of CAs just to encrypt your connections -- just delayed widespread adoption of HTTPS by decades.
The points that the article is making are the aftermath industry having muddled validation of identity and encryption of traffic up with each other in the first place.
Let's Encrypt finally solved that, but at the same time effectively made SSL certs mostly worthless for identity purposes (as it just means the domain you're talking to is the domain you're talking to).
If you're browsing via HTTP there is no expectation at all that what you are doing is secure.
If you have a problem in HTTPS, you are expecting to be secure, you might not be. Hence, a warning.
A bad certificate is a sign that something's actively wrong while (at least historically) no certificate doesn't really give a strong signal.
A cert that's a day out of its expiration time has zero implications to the confidentiality and identity of the parties to the connection. The same cannot be said about a bad CN or signature.
Most browsers really want to show scary warnings for HTTP connections these days. But there are enough complaints about it as a concept that they have not implemented it yet.
“Zero trust” or “BeyondCorp” security strategies are not widely deployed; a lot of organizations still use browsers over HTTP for internal apps, and don’t have a captive CA or a way to satisfy Let’s Encrypt challenges from outside the firewall. No one wants thousands of companies to train their employees to ignore cert warnings.
And there is a small but vocal set of folks who believe one should not have to satisfy a CA (even Let’s Encrypt) to put up a website.
If you don't manage employee devices AND can't get TLS certificates to internal applications, the employees are right to be scared by the browser's warning. You have failed as a corporate IT department.
* Visiting site with HTTP, there's no expectation of encryption / comms security. So there's no need for warning.
* Visiting site with HTTPS, there's expectation of encryption / comms security, so please let me know if it's not working as intended or there are warning signs.
That being said, I'm at the crossroads of "little knowledge is a dangerous thing". Vast majority of my friends and family would not know HTTP is not encrypted... but they also won't even bother reading an experied cert warning and will just click to proceed.
(on a broader level, working in operations has underlined to me that default user behaviour with any modal dialog, window, warning, error, is to click everything until something works. There is no reason whatsoever to read or understand WHAT was clicked, or pay it any attention later, other than remembering which thing was clicked. It's an entirely binary world of "things that when you click them don't make it work" and "things that when you click them make things work". There is literally no other useful information for most users)
Not to mention that it's never been difficult to get a certificate for a dodgy domain, especially when doing so made a phish more likely to succeed.
Which was and is reasonable, given that encryption mitigates risks that can't be mitigated otherwise, and is therefore a more pressing concern for security -- you can take many other measures to verify who the party on the other end of a connection is, but once unencrypted traffic exits your network, there's not much you can do to prevent snooping.
It again goes back to muddling up these two separate concerns. If we used CA-issued certificates only for identity validation, we could have optimized them for that purpose and not diminished their value because the need for ubiquitous encryption was a higher priority. Meanwhile, we could have just had web servers auto-generating encryption keys (a la SSH, as you point out), without being shackled to the trust hierarchy, and had universal adoption of HTTPS 20 years ago. Instead, we got a single solution to two different problems that is still forcing us to compromise one for the other.
Your reply is missing the point and the difficulty of the topic.
Yes, _you_ know "chase.com.swag.ru" is wrong but the harder computer science question is: "How does a web browser deterministically evaluate if "chase.com.swag.ru" is not the real Chase bank the web surfer intends to reach?"
In other words, the FireFox/Chrome browser doesn't have a function such as:
if (ask_7steps2much_if_domain_is_real_instead_of_fake("chase.com.swag.ru")) then ...
But it looks like EV certificates were not a UI signal used by most web surfers so Chrome/Firefox dropped the visual indicators: https://www.google.com/search?q=chrome+firefox+remove+ev+cer...
This is a major flaw I've seen with a lot of the anti-EV rhetoric that's been espoused in recent years by security experts and browser vendors. They correctly identify that the EV certificate system has major flaws, then incorrectly conclude that rather than fix those flaws, the solution is to get rid of the EV certificate system.
Yes, EV certs are currently insufficient as means of identity verification. How does eliminating EV certificates solve that problem? What alternative is being proposed that would be better than EV certificates at verifying the identity of real-world entities? So far, the plan seems to be to just get rid of EV certificates and replace them with... nothing? That's not exactly helping the situation.
Verification markers are common UI elements used on Instagram, Twitter, Facebook, WhatsApp and many other end user focused apps.
I just need to type in that address by hand and make sure I don't mistype right?
She then proceeded to inform me that her bank person had made sure she knows what an internet address is and that chase.com is in fact not chase.com.scammer.ru
EV certs are not unique. If I were to want a cert saying that it is issued to Chase Inc. then I would just have to found a company called Chase.
Domain names however are unique.
EV certs were always an ugly hack and quite frankly a bad one as well. I think LE handing out certs just for encryption is good. Users should not associated encryption with identity verification.
If you want something like that then the easy way would be to not use CA at all, but banking apps that connect to a server with only certain certs. Or maybe hand out Yubikeys that perform a handshake with the website.
But relying on EV certs is like relying on the fact that a certain envelope has a logo on it.
In the US duplicate business name are indeed an issue. Trademarks are however federally unique and could be used to solve this problem.
> (my grandma) then proceeded to inform me that her bank person had made sure she knows what an internet address is and that chase.com is in fact not chase.com.scammer.ru
Wow. That’s better than most programmers. Did everyone clap?
The thing is, TLS certificates are a "weakest link" system. Even if chase.com is buying EV certificates, a bad actor can still get a DV certificate. You can mitigate that a bit by using a CAA record in DNS, but AFAIK there's no way to specify anything like a policy identifier (which indicates the type of certificate) in a CAA record. The best you get is the ability to limit issuance to a specific issuer.
There could be _some_ value to using a CA like DigiCert if you use a CAA record that limits certificate issuance to them only. Since they don't offer DV certificates you reduce the risk of a MITM using HTTP to get a DV certificate for your domain. You'd also want to reconcile every certificate issued to make sure they're legitimate requests.
I understand it’s the larger security problem because there are far more return visits than first visits. But that doesn’t mean it is the only security problem online.
What is the web equivalent of walking into a store for the first time and feeling confident I won’t get assaulted or robbed?
Any purchase is a financial transaction; not sure why you zeroed in on banking. Those happen during first visits offline all the time.
every time i switch computers, reinstall or whatever i get a new first visit. seems to me that first visits are more likely than just the first time when signing up for that account.
If you don’t log in, or don’t have an account, though, it obviously can’t help you.
it happens in the reverse too. google gets very suspicious when i log in from a new device. but this happens more often than you think
Now think about coming back to that site after I've made an account. I may be coming from an email, a push notification, a text message, a targeted ad, etc. The risk is a lot higher because I'm not initiating the flow by using a trusted search engine or typing it myself.
Or like, to be more succinct, it's because MITM rarely happens and phishing happens constantly.
The FCA website can be validated using the UK Government website: https://www.gov.uk/registration-with-the-financial-conduct-a...
And if someone's managed to break gov.uk then I've got bigger problems.
I'll note, though, that most of the time I'm going to be using a credit card and it'll be obvious fairly quickly if whatever goods or services I've ordered don't appear. It's only really if I'm making multi-year investments (or going completely off the correct payment rails) that it's catastrophic if I make a mistake. See also: https://bam.kalzumeus.com/archive/no-payments-are-final/
You check the domain name in the address bar.
Embedded forms aren't safe—one must assume that the surrounding page has access to anything entered into the form, so you're not just giving your CC data to Stripe, you're also giving it to whatever site embedded the form. If you don't trust the merchant with your credit card, the only safe system is the one where you're directed to a top-level page hosted by Stripe to enter the payment details.
In the cryptocurrency world, it's usually a feature to be unable to tell who you're sending money to, or even whether they exist, and this does not seem to have hindered adoption.