[HN Gopher] Everything we're told about website identity assuran...
___________________________________________________________________
Everything we're told about website identity assurance is wrong
Author : nikbackm
Score : 150 points
Date : 2022-02-16 12:38 UTC (10 hours ago)
(HTM) web link (www.troyhunt.com)
(TXT) w3m dump (www.troyhunt.com)
| zuzun wrote:
| I don't see what's fundamentally wrong with EV certificates, as
| long as the certificate authorities do the proper verification.
| The certificates contain more than just the business name, so I
| think the criticism should be directed towards browsers that hide
| the relevant information behind 5 clicks.
| blurker wrote:
| What about the Stripe Inc. example? That example alone is a
| pretty big nail in the coffin for EV in my opinion. Not to
| mention all the usability problems that user studies have found
| which render it effectively useless. It's not just the number
| of clicks either. What about how the corporate names don't
| match the TLD's? What about conglomerates that have all sorts
| of entity names? What about misspellings of corporate names,
| just like misspellings of TLD's?
| snowwrestler wrote:
| The Stripe.com example is widely misunderstood, even by the
| person who did it.
|
| 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.
| blurker wrote:
| yeah, about that paper work...
|
| 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?
| snowwrestler wrote:
| 1. An EV or OV cert tells you where the company is
| registered. So the user, presented with this information
| in a nice UI, would be empowered to decide whether they
| want to order a new laptop from a store in their own
| jurisdiction, in a country with a legal system they can
| trust, or from anywhere.
|
| 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.
| blurker wrote:
| Even if it's registered in a local jurisdiction, the
| paper work may not be reliable and it will be possible
| for scammers in those jurisdictions to get that paper
| work. It's not like there aren't plenty of shady
| incorporated companies already. It's still going to be a
| time-consuming and expensive process to track down the
| paper trails. Probably it will require a specialist. It
| can get pretty difficult pretty quickly as people use
| shell companies and god knows what other tricks that are
| available in these systems. And the police aren't going
| to just jump on the case and do this all for you. They
| don't have the resources. For the average person, your
| police report is going to go in the bin. You're gonna
| have to do a lot of work or pay someone to do it.
|
| - 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
| roywiggins wrote:
| > 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.
|
| 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 PS19m. 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...
| zuzun wrote:
| I must admit, I didn't consider that many US companies are
| incorporated in Delaware and otherwise hide their
| whereabouts. I checked the certificates of my bank and my tax
| authority and both provide sufficient information, which
| makes spoofing almost impossible.
| commandlinefan wrote:
| My problem with EV certificates is that you're paying more for
| the certificate authority to do what they were supposed to be
| doing in the first place.
| simiones wrote:
| The certificate authority has no requirement to verify that
| they are emitting a certificate to a human person that has
| any legal right to the domain name they are obtaining the
| certificate for.
|
| 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.
| bell-cot wrote:
| > ...as long as... ...browsers that hide...
|
| Sounds like EV is great in theory, nigh-worthless in practice.
| outloudvi wrote:
| I guess the same idea also applies to QWAC.
|
| https://www.eff.org/deeplinks/2022/02/what-duck-why-eu-propo...
| xg15 wrote:
| Genuine question: suppose you get a link from a known,
| nontechnical friend for some interesting product on Amazon. The
| link goes to:
|
| https://amazon.shopping/...
|
| How do you determine whether this is actually Amazon or a
| scammer?
| nixpulvis wrote:
| The arguement that 'Nobody Looks "Beyond the Lock"' is not really
| valid in my opinion. If even 0.001% look, there's a chance
| someone will blow the whistle on a sketchy operation. Not to
| mention that I might only look closely on some responses.
|
| The other issues with EVs are more damning to me.
| snowwrestler wrote:
| Troy and others have made great hay out of explaining how badly
| browsers work with EV certs.
|
| 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.
| ryan29 wrote:
| > 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.
|
| 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.
| lazide wrote:
| Have you done it in your jurisdiction? Here in CA you can
| form an LLC or Corp without even providing your ID or doing a
| notarized anything. You do have to provide a real physical
| address at least (no pmb forwarders or Poboxes - kinda).
| Delaware I know is the same.
| notatoad wrote:
| >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.
|
| 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.
| snowwrestler wrote:
| Browsers accurately render the fields of the cert for your
| current website session in a debugging view; that's the best
| I can say. That is technically a "UI" but it does nothing for
| most users.
|
| 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.
| lazide wrote:
| How is that materially different than the traditional
| difficulty in pulling up any official record on a
| corporation for instance?
|
| 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.
| snowwrestler wrote:
| You don't need the official corporate record to file a
| complaint, you just need enough info that someone else
| can look it up. If you get food poisoning, you just tell
| the city the name and address of the restaurant. They
| take care of figuring out who is legally responsible.
|
| 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.
| lazide wrote:
| What database/records do you think the cops check when
| you call in a complaint?
|
| 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.
| xg15 wrote:
| So what is the solution then?
|
| 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?
| lazide wrote:
| Right now we have no solution, we're relying on 'mostly
| works' real world stuff to stop the biggest scams, and
| lots of small scammers are running around scamming lots
| of people and not being punished for it.
|
| 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?
| camgunz wrote:
| I think you're broadly right; I would agree the article comes
| for DigiCert when it should come for browsers, and this pretty
| embarrassing for the web.
|
| 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.
| caylus wrote:
| > This is an attack that doesn't really have an analogue in
| meatspace
|
| 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.
| camgunz wrote:
| Oooh, good example yeah. I recently saw a short list of
| grift/scam taxonomy; I wonder if there's a similar list for
| stuff like this.
| lazide wrote:
| Well, people do still pretend to be representatives, and do
| still scam people successfully.
|
| 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.
| Sytten wrote:
| EV have their place in the ecosystem, they are just useless for
| websites.
|
| 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).
| bombcar wrote:
| How does that help (much) in the case where some rando can get
| an EV for "Stripe, Inc."
|
| 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?).
| Animats wrote:
| I built Sitetruth.com to try to solve that problem. I'm going to
| shut it down soon.
|
| 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.
| crooked-v wrote:
| > 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.
|
| 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.
| bryanrasmussen wrote:
| well not for the problem of security, but for their problem
| of trying to identify who is actually behind a site it of
| course is a problem that the ties to identity became weaker.
|
| 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.
| Animats wrote:
| My metric is, "if you needed to sue the website operator,
| could you find them?"
| coldcode wrote:
| Snake Oil is a long standing business practice.
| newaccount74 wrote:
| I am soooo grateful for LetsEncrypt -- before them, getting
| certificates was such a hassle. Even if you didn't fall for the
| EV or OV or whatever certs, just getting a DV cert was annoying.
| Every vendor had a slightly different web interface that was
| really annoying to use, and to get the cheapest price you usually
| had to go through a reseller, and they had even worse web forms.
|
| 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!
| snowwrestler wrote:
| Let's Encrypt does a great job of enabling encrypted
| connections.
|
| 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.
| tptacek wrote:
| It's not just TLS's job to authenticate your transactions;
| your financial institution also runs its own authentication
| system, which should ideally break phishing and reframing
| attacks (for instance, with WebAuthn).
| snowwrestler wrote:
| Why does every discussion of "how do you trust a website on
| first visit" get redirected to "here's how to trust a
| website you've already visited?"
|
| 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?
| tptacek wrote:
| The point of the authentication systems I'm talking
| about, which address specifically the concern of the
| parent comment, is that financial transactions don't
| generally happen on first visits to websites, and
| "transactions" on your first visit to
| chase.com.phishing.xyz should be blocked by something
| like WebAuthn, not the EV policies of a TLS CA.
| em-bee wrote:
| _financial transactions don 't generally happen on first
| visits to websites_
|
| 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.
| snowwrestler wrote:
| This is what tptacek is talking about. If you have an
| account with a website that you have already verified,
| it's possible for the website to authenticate you in a
| way that can't be fooled like a person can. Basically
| it's like 2FA that only works on the original website. Of
| course not every site has deployed this yet. But the
| solution exists.
|
| If you don't log in, or don't have an account, though, it
| obviously can't help you.
| em-bee wrote:
| and every time i reinstall, or switch computers i loose
| that verification and i have to start afresh.
|
| 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
| tedunangst wrote:
| No? You'd use the same USB key on the second computer,
| and the third, and...
| lazide wrote:
| So what happens when the USB key gets lost, which regular
| folks do all the time? (Same as lose their IDs, credit
| cards, etc.)
| snowwrestler wrote:
| "Financial transactions don't generally happen on first
| visits to websites" is just a description of how things
| are today, it doesn't help us think about how things
| could be or could have been.
|
| Any purchase is a financial transaction; not sure why you
| zeroed in on banking. Those happen during first visits
| offline all the time.
| tptacek wrote:
| I'm responding to the specific concern raised on the
| thread, not presenting my unified theory of
| authentication. WebAuthn is a better solution to
| "authenticating connections to services we have long-term
| relationships with, regardless of our relationships to
| particular websites" than anything in the TLS protocol
| could be.
| andrewaylett wrote:
| Most of my banking I bootstrapped from a physical
| interaction. The one provider I haven't had any physical
| interaction with I validated on the Financial Services
| Register: https://www.fca.org.uk/firms/financial-
| services-register
|
| 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/
| tptacek wrote:
| I worry a lot about making credit card transactions with
| websites I don't have stable credentials on, and always
| opt to pay via Amazon or (gak) Paypal if it's my first
| time buying somewhere, unless they're using Stripe.
| spearo77 wrote:
| Is there anything you check for to confirm that it is
| Stripe? I was deceived last week, paying for something
| via something that looked like an embedded Stripe payment
| form.
| nybble41 wrote:
| > Is there anything you check for to confirm that it is
| Stripe?
|
| 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.
| camgunz wrote:
| I think the flows are different. If I want to open up an
| account at amalgamatedbank.com, I probably type it in or
| I come from Google. Unless something is super wrong with
| my machine and someone's built an incredibly convincing
| bank website that matches what I would expect, I'm
| probably fine.
|
| 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.
| pjc50 wrote:
| > security in financial transactions
|
| 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.
| XorNot wrote:
| Sure but this is a problem the concept of web of trust should
| have solved for us if we had focused on government and
| enterprise buy in.
|
| 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.
| jacobwg wrote:
| Is the domain insufficient? As an end user, that's the only
| signal I get, browsers are no longer showing me an EV
| certificate any differently than a DV certificate. If I'm
| communicating with mybank.com and I receive a valid DV
| certificate that was maliciously acquired, I have bigger
| problems than could be solved by EV certificates.
|
| I suppose Certificate Transparency is the tech working behind
| the scenes to flag mistaken or malicious certificates should
| they be issued.
| bombcar wrote:
| The domain isn't even shown anymore in some browsers ...
| sigio wrote:
| Yeah, but also not via any of the other methods we've been
| using the last couple of years.
| Galanwe wrote:
| > How do you do that part today? Not via Let's Encrypt.
|
| 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.
| windexh8er wrote:
| I wouldn't say that it's all a "joke" in the context of
| assurance. I know a number of vendors that implement mTLS
| as part of their customers onboarding. I wouldn't be
| surprised to see product movement in this space to better
| address the consumer markets (maybe financial first?) with
| something that better manages and abstracts this for them.
| This, in many ways, solves a lot of exposure issues, but at
| the cost of what's overly complex for most users today.
| Gormo wrote:
| That's true, but "can I trust the party on the other end of
| this channel?" and "is the channel secure against third-party
| eavesdroppers?" are fundamentally two different questions,
| and trying to answer both with the same solution was never a
| viable approach.
|
| 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.
| bombcar wrote:
| HTTPS would have been a lot better (in my opinion) if it
| had been more like SSH when encountering a certificate it
| didn't recognize.
|
| 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).
| josephcsible wrote:
| Yeah, it's never made sense to me why browsers show such
| a scary warning before visiting a site over HTTPS with an
| invalid certificate, when they didn't show any warning at
| all before visiting a site over insecure HTTP, since the
| latter leaves you vulnerable to a superset of attacks.
| tetraca wrote:
| It makes sense though?
|
| 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.
| andrewaylett wrote:
| It's only recently that it's become reasonable to add
| interstitials without annoying everyone. Firefox in
| HTTPS-Only mode does exactly that.
|
| A bad certificate is a sign that something's actively
| _wrong_ while (at least historically) no certificate
| doesn 't really give a strong signal.
| Karunamon wrote:
| The problem is that those classes of wrongness are
| treated identically when they are emphatically not:
| scary, hard-to-understand-by-users warnings, if not
| outright inability to connect in some cases.
|
| 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.
| NikolaNovak wrote:
| I may be wrong, but it made sense to me:
|
| * 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)
| lazide wrote:
| Also, that most people will not remember what option they
| clicked as little as the instant they click it and the
| window goes away.
| snowwrestler wrote:
| You're right but it's basically a cultural legacy.
|
| 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.
| jrockway wrote:
| I don't think that broken corporate policies should
| dictate what the public web does. If they must use split-
| horizon DNS (which is the worst thing ever) and can't do
| a DNS challenge, there are still plenty of ways to make
| browsers avoid warnings; every IT department can push
| trusted certificates to workstations and mobile devices.
| It's built into every device management system in the
| world.
|
| 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.
| andrewaylett wrote:
| If you thought things were better before LetsEncrypt, I'm
| afraid you were mistaken. They weren't the first to
| provide free DV certificates, and even paid certificates
| aren't immune to crises of identity. Troy mentions the EV
| certificate issued to "Stripe, Inc" which caused so much
| consternation back in the day.
|
| 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.
| cottager2 wrote:
| You do it via let's encrypt... let's encrypt only issues
| chase.com certificates to hosts it verifies are behind
| chase.com domains. That's why they're trusted as a CA.
| ryan29 wrote:
| Anyone along the route between LE and chase.com can
| possibly get a certificate from LE. For example, if you
| have access to a chase.com firewall or load balancer and
| can redirect traffic for a minute you could get a DV
| certificate.
|
| 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.
| nailer wrote:
| That's not correct. LE will happily issue certs for
| chase.com.swag.ru and doesn't claim otherwise.
| tptacek wrote:
| The idea that CAs are effective anti-phishing systems by
| dint of EV programs has been discredited for like a
| decade now, right?
| plainnoodles wrote:
| Really, it's the browsers' faults to conflating the
| variously-tangentially-related concepts of entity
| identity, domain ownership, and connection encryption.
| 7steps2much wrote:
| True, but chase.com.swag.ru is not chase.com
| jasode wrote:
| _> True, but chase.com.swag.ru is not chase.com_
|
| 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
| ...
|
| The generalized way that's been attempted is Certificate
| Authorities being hardcoded/whitelisted inside of
| browsers, etc. This helps for _encryption_ to prevent
| MITM attacks but has many loopholes for _identity_
| verification. LetsEncrypt dv certs are more helpful for
| _encryption_. In contrast, something like EV certificates
| was trying to help with _trusted identity_.
|
| 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...
| 7steps2much wrote:
| Now, I don't disagree with what you are saying, but the
| simple truth is that people didn't do this anyways. In
| fact, the one time I tried to explain to my grandmother
| how this whole thing works she then told me:
|
| 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.
| 5560675260 wrote:
| From user's perspective only difference between EV
| certificate, LetsEncrypt certificate and no certificate
| are couple of words hidden somewhere in browser UI and
| maybe an icon. You still need some level of expertise to
| use this info, IMO even more than you'd need to notice
| that "chase.com.xxx.xxx" isn't legit.
| Ajedi32 wrote:
| Yes, and that's a problem with browser UI that should be
| solved.
|
| 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.
| [deleted]
| brightball wrote:
| I need to dig it up, but PayPal once did a security presentation
| on "trust indicators" like EV certs related to user behavior.
|
| 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.
| bell-cot wrote:
| Bluntly put, SSL Certificates exist (or at least are widely
| promoted and used in their current form) to protect the business
| models of a few very large corporations. Especially against
| parties like sleazy ISP's, who might love to (say) replace all
| the Google Ads on web pages which their customers view with new
| ads sold by the ISP.
|
| 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]
| bombcar wrote:
| Ha the example site at the end has already been taken down.
| chias wrote:
| The link and the url are not the same.
| throwaway984393 wrote:
| The funniest thing to me was always how any non-EV cert can be
| used in place of an EV cert if you want to MITM. Just find a way
| to generate a non-EV cert for a domain (from any of the hundreds
| of CAs) and go ahead and intercept traffic. Nobody will notice
| that the domain no longer uses an EV cert. The browser won't
| care. So it's not actually providing any security at all.
|
| 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.
| blurker wrote:
| I feel like a lot of commenters may not have watched the video of
| Emily Schecter's that was linked in the article. IMO it actually
| did a better job of explaining the problem with EV's than the
| author's post did. Or at least it was very complementary.
|
| 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.
| Sander_Marechal wrote:
| I thought that the ideas behind that video are terrible. Google
| and Chrome are working tirelessly to do away with the URL for
| some nefarious reason. I bet it has something to do with
| ramming down AMP down everyone's throat. Do away with the URL
| and people can't tell they're on Google's cached copy instead
| of the original site.
| blurker wrote:
| Can you elaborate specifically which ideas you thought were
| terrible and why?
|
| 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?
| ryan29 wrote:
| OV certificates are even worse. The verification is a hassle and
| it's _extremely_ difficult to distinguish OV from DV. Try to
| figure it out. The only way I 'm aware of is to make sure the
| `Policy Identifier` [1] of the certificate is `2.23.140.1.2.2`.
|
| 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-...
| billpg wrote:
| "Nobody Looks Beyond the Lock"
|
| 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.
| mananaysiempre wrote:
| Browsers stopped showing the banner a couple of years ago[1-3],
| around the time of the Ian Carroll's Stripe, Inc. of Kentucky
| demonstration[4]; maybe that was it?
|
| 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...
| 300 wrote:
| The problem is real and it's not the only one in this space. I
| was surprised to see so many words and so little substance. If
| feels like Troy didn't really try about this one.
| nailer wrote:
| > Remember, EV only works if people change their behavior in its
| absence and clearly, that just doesn't happen.
|
| 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.
| bombcar wrote:
| The only real validation that actually works is certificate
| pinning built into the browser itself - and even that only
| guarantees that Google.com is signed by Google - not that
| goooooooogle.orgbiz.com.au is properly marked as a scam.
| nailer wrote:
| The term validation is overloaded so I'm avoiding it.
|
| 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.
| bombcar wrote:
| The problem is that proof of identity doesn't really give
| you much when you dig into it - either it's after the fact
| (which is what happens with EV, even if someone DID scam
| using one, AND it was traced back to what was likely a
| shell company).
|
| 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
| nopenopenopeno wrote:
| > _"realpolitik browsers"_
|
| 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.
| nailer wrote:
| If I had my time again I would have sold part of CertSimple
| to Google with the aim of integrating with Google My Business
| so Google would make money from verification.
|
| I feel this would prompt browsers to care about robust
| identity - both in terms of better verification and better
| display.
| zaphar wrote:
| I fundamentally think this is not a solvable problem using
| certs. Short of calling up the company directly and asking no
| amount of signaling in the browser will help.
|
| 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.
| nailer wrote:
| > Short of calling up the company directly and asking no
| amount of signaling in the browser will help.
|
| EV is literally the result of calling up the company directly
| and asking, signed by someone your browser trusts.
| snowwrestler wrote:
| You don't care if the banking website you're using is
| actually owned by your bank?
| ROARosen wrote:
| For physical banks, every piece of stationary from my bank
| states their domain name so once I have a DV verified
| showing I'm actually connected to that domain I can trust
| it.
|
| 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.
| nailer wrote:
| Most people don't visit URLs by typing them into their
| browser. Links, messaging apps, email, native apps etc.
| account for more than manually typed links do.
| Karunamon wrote:
| The EV UI was sunset in all browsers because as it turns
| out, ensuring that your address bar says 'wellsfargo.com'
| and that you didn't get MITM'd is plenty good enough due to
| the other protections.
| [deleted]
| zokier wrote:
| Sure, ev certs might not be all that great, but I do find Troys
| long-running crusade against them weird. I mean, it feels pretty
| disproportionate, like does anyone care that some corpos end up
| paying few hundred bucks extra for their certs or whatever? Isn't
| there almost endless amount of more important issues in the
| security landscape?
| SAI_Peregrinus wrote:
| It's fraudulent activity (false advertising) by some of those
| very agencies who are trusted to authenticate certificates! CAs
| selling EV certs is fine. CAs advertising EV certs as providing
| a meaningful benefit to customers is NOT fine, it's an abuse of
| their trusted position.
| CrendKing wrote:
| Probably explained in the very first sentence of the post: "I
| have a vehement dislike for misleading advertising." Human
| somethings do things driven by their emotion, even if the thing
| is not the most logical or profitable decision.
| y-c-o-m-b wrote:
| > nobody is actually going to look beyond the lock anyway. (Yes,
| I know there'll be someone somewhere who eventually does, let's
| just agree that "nobody" is a number that rounds to 0%.) I mean
| seriously, do you ever do this?
|
| 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.
| bombcar wrote:
| This is a huge problem - _legitimate_ sites are getting names
| that look damn scammy - even "www.securebillpay.net" starts to
| look suspicious and they get way worse.
|
| If the companies aren't going to bother there's no hope for the
| users.
| tgbugs wrote:
| I've been coming around to the idea that the threat models that
| are often used for website identity are not the ones we want. The
| ssh threat model related to changes in host keys seems to me to
| be a better one.
|
| 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.
| notriddle wrote:
| SSH's model isn't very good, either. You can be MITM'ed for
| free the first time you connect (obviously, that's what TOFU
| means), and server identities are tied either to network
| addresses or to domain names, neither of which are permanent.
|
| 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.
| MaxBarraclough wrote:
| > SSH's model isn't very good, either. You can be MITM'ed for
| free the first time you connect
|
| 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
|
| [1] https://serverfault.com/questions/996828/
|
| [2] https://en.wikipedia.org/wiki/Trust_on_first_use
___________________________________________________________________
(page generated 2022-02-16 23:01 UTC)