Everything we're told about website identity assurance is wrong(troyhunt.com)
troyhunt.com
Everything we're told about website identity assurance is wrong
https://www.troyhunt.com/how-everything-were-told-about-website-identity-assurance-is-wrong/
145 comments
Sounds like a problem of policy really at the core - maybe when we get some more nerds in Congress this will be finally addressed?
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?
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?
> 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.
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.
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.
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.
My metric is, "if you needed to sue the website operator, could you find them?"
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-...
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-...
"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.
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.
This is the reason I honestly sometimes prefer buying from smaller online businesses who are too small to do their own payment processing and instead outsource it to a processor like Shopify or similar. They are probably taking a bigger loss than they would if they could process it themselves long term but at least I have relative peace of mind that I have used the service before, the certs stay consistent, and that they are likely doing a decent job with security in general (given that processing is their whole thing). A lot of times the look and feel of some of the process will be customized but for the most part you can quickly identify when its a payment process you have used before given the web forms. And of course it is easy to verify the cert after this.
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...
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...
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.
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.
>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.
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.
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.
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.
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.
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.
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 [email protected], 480-624-2505.
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 [email protected], 480-624-2505.
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.
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.
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?
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?
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?
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?
>so what's the solution then?
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.
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.
Ok, but then why actively block attempts to tackle this problem?
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.
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 they give a guarantee
"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.
"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.
[deleted]
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
I'm fairly sure you need to provide ID and notarized docs where I am, but I've never done anything more than a sole proprietorship since we're allowed to conduct business under our personal name up to a certain point.
> 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.
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.
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.
If the companies aren't going to bother there's no hope for the users.
ccbill.net is the one I've always been the most skeptical about, since I associate it with age verification things decades ago for certain sites that were not serviced by other payment providers
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.
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.
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.
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.
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.
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?
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?
> 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.
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.
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.
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.
> 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.
EV is literally the result of calling up the company directly and asking, signed by someone your browser trusts.
You don’t care if the banking website you’re using is actually owned by your bank?
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.
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.
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.
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]
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.
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.
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.
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
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
> “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.
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.
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.
I feel this would prompt browsers to care about robust identity - both in terms of better verification and better display.
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.
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?
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.
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.
> 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 £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...
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...
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?
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?
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.
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.
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
- 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
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.
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.
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.
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.
> ...as long as... ...browsers that hide...
Sounds like EV is great in theory, nigh-worthless in practice.
Sounds like EV is great in theory, nigh-worthless in practice.
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?
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.
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.
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]
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]
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?
https://amazon.shopping/...
How do you determine whether this is actually Amazon or a scammer?
Right now, if what Troy is saying is true, then self-signed certificates are basically every bit as good as a LE cert - because no one actually verifies the chain of authority. But oh no, self-signing is a bad practice, and effectively useless because browsers will throw up warnings. So you go to LetsEncrypt and get a certificate that has a pretty green padlock.. because their `certbot` made it with 0 review of who you are or what the site does? How is this different at all?
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'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.
> because their `certbot` made it with 0 review of who you are or what the site does? How is this different at all?
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.
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.
> 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
Might as well just stick the certificate hash in a DNS record and forget about keeping a public consensus on universally trusted CAs.
Might as well just stick the certificate hash in a DNS record and forget about keeping a public consensus on universally trusted CAs.
Isn't this is what DANE is trying to do?
I'd forgotten the name, but yes it is. And I'd seen it dunked on for relying too much on the registrars being secure.
Yes, SSL prevents MITM but my point was that a self-signed certificate does this just as well as an automated certificate from LetsEncrypt.
It doesn't though. The attacker could simply present their own self-signed certificate - and there'd be no reliable way to determine which certificate is the right one.
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.
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.
Oh cool, that makes sense now. Thanks!
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.
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.
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 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.
The other issues with EVs are more damning to me.
The counterpoint to that is that I'm not spending money, and substantial amounts of hassle, to buy an EV to increase my customer base by 0.001%.
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.
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.
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.
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.
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.
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.
> 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
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
That’s true, but I guess my point is that Hidden Service addresses are harder to misuse. If you get the 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.
> If you get the 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.
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
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
I just realized that the way I phrased it was misleading.
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.
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.
> because TCP/IP is not inherently secure, I don't think raw TCP/IP addresses should be exposed to end-users
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.
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 advantage of Tor Hidden Services* is that it doesn't need DNS, and it doesn't need CAs.
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.
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.
> The problem with DNS is that DNS names are global, and human readable, and therefore rely on a central authority to handle disputes.
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.
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.
I guess the same idea also applies to QWAC.
https://www.eff.org/deeplinks/2022/02/what-duck-why-eu-propo...
https://www.eff.org/deeplinks/2022/02/what-duck-why-eu-propo...
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).
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).
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?).
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?).
Says the site being MITM by cloudflare. Not that he's wrong, but glass houses...
Snake Oil is a long standing business practice.
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!
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!
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.
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.
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.
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.
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).
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 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.
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.
> Let's Encrypt finally solved that, but at the same time effectively made SSL certs mostly worthless for identity purposes
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.
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.
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.
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.
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.
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.
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.
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)
* 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)
Also, that most people will not remember what option they clicked as little as the instant they click it and the window goes away.
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.
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.
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.
A bad certificate is a sign that something's actively wrong while (at least historically) no certificate doesn't really give a strong signal.
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.
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.
> 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.
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.
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.
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.
I suppose Certificate Transparency is the tech working behind the scenes to flag mistaken or malicious certificates should they be issued.
The domain isn't even shown anymore in some browsers ...
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.
That’s not correct. LE will happily issue certs for chase.com.swag.ru and doesn’t claim otherwise.
True, but chase.com.swag.ru is not chase.com
>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:
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...
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...
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.
> You still need some level of expertise to use this info
Verification markers are common UI elements used on Instagram, Twitter, Facebook, WhatsApp and many other end user focused apps.
Verification markers are common UI elements used on Instagram, Twitter, Facebook, WhatsApp and many other end user focused apps.
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.
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.
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.
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.
> 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.
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?
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 idea that CAs are effective anti-phishing systems by dint of EV programs has been discredited for like a decade now, right?
Really, it's the browsers' faults to conflating the variously-tangentially-related concepts of entity identity, domain ownership, and connection encryption.
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.
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.
[deleted]
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.
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.
Yeah, but also not via any of the other methods we've been using the last couple of years.
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).
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?
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?
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/
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/
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.
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.
> 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.
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.
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.
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 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.
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.
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.
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.
If you don’t log in, or don’t have an account, though, it obviously can’t help you.
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
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
No? You'd use the same USB key on the second computer, and the third, and...
So what happens when the USB key gets lost, which regular folks do all the time? (Same as lose their IDs, credit cards, etc.)
You have backup factors. If you're using USB keys, you always have 2; there is never a reason to buy just one USB security key.
here a usb key is given to me by the bank, so i only get one. and it requires some invasive proprietary driver to use too.
if i loose it then i am stuck until i can go to the bank to get a new one
“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.
Any purchase is a financial transaction; not sure why you zeroed in on banking. Those happen during first visits offline all the time.
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.
> 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.
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.
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.