4 ms·

I get that it's unreasonable to expect users to distinguish EV from DV certs. But a machine should be able to distinguish. There should be an Expect-EV pin hea

by Buge 8y ago

I get that it's unreasonable to expect users to distinguish EV from DV certs. But a machine should be able to distinguish. There should be an Expect-EV pin header, just like HSTS and Expect-CT. That way you can be sure the certificate wasn't issued via DNS hijacking.

nailer 8y ago
We have UI that distinguishes verified accounts from non verified accounts in almkat every current communications system. And yes, machines can distinguish EV, there's an OID (field) if every EV cert for it.
- Buge 8y ago
  A machine that just distinguishes it then does nothing is useless. I want the browser to enforce it. EV doesn't have the user distinction benefit of a blue checkmark if no major websites use it. No one notices EV. Twitter randomly switches between EV and non-EV, but no one gets worried.
  - nailer 8y ago
    You could feasibly (as of recent Mozilla builds) have the browser warn on POST requests to non-verified sites, but it requires verification to get more popular. Any system starts from no usage, and no education and works up - every bank, payment and fintech company is a pretty good start. Browser security indicators resembling more common verification indicators would help.
    - Buge 8y ago
      Do you have a source for the POST thing? I can't find anything by searching. Yeah, I agree EV has some potential for users to distinguish. If we add mechanical way for the browsers to enforce it, that could help increase website adoption, and thus also help users to notice it more.
ubernostrum 8y ago
The root problem is SSL/TLS was largely promoted, for years and years, as conflating two concerns: 1. Can an arbitrary third party eavesdrop on my communications? 2. Am I communicating with who I think I'm communicating with? It is now extremely easy to handle use case (1). Use case (2) is still genuinely hard, because even extremely technically literate security-savvy people can still easily be phished (my current go-to example is this talk: https://www.youtube.com/watch?v=ZjW12K0IHgo https://www.youtube.com/watch?v=ZjW12K0IHgo). Compounding the problem, many people insisted, for many years, that use case (2) was the overwhelming majority of all the value of SSL/TLS, and use case (1) was at best a tiny microscopic fraction of a fraction of a fraction of what was useful about SSL/TLS. Lest you think I'm exaggerating: I've spent years arguing with people, including right here on HN, about this, and being condescendingly told that identity verification is the crown jewel, and that if I'm not going to make use of that then I might as well literally just go back to plain unencrypted HTTPS, because apparently that's actually better than using SSL/TLS without identity verification. Also, I really recommend watching that video I linked. It's a security engineer at Stripe, talking about how she ran some pretty successful campaigns within the company. Whatever you may think of them, they're not unlettered philistines. But even things like your "Expect-EV" wouldn't have helped -- she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway. There just aren't any easy "just do X" technical solutions here.
- tzs 8y ago
  > she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway One big reason people do that is because probably 99+% of the time their password manager fails to fill the fields is not because it is the wrong site. It is almost always because the site has done something with its fields that is either preventing the password manager from finding the fields, or is blocking it from filling them (often intentionally).
  - ubernostrum 8y ago

by Buge 8y ago

nailer 8y ago

We have UI that distinguishes verified accounts from non verified accounts in almkat every current communications system. And yes, machines can distinguish EV, there's an OID (field) if every EV cert for it.

Buge 8y ago
A machine that just distinguishes it then does nothing is useless. I want the browser to enforce it. EV doesn't have the user distinction benefit of a blue checkmark if no major websites use it. No one notices EV. Twitter randomly switches between EV and non-EV, but no one gets worried.
- nailer 8y ago
  You could feasibly (as of recent Mozilla builds) have the browser warn on POST requests to non-verified sites, but it requires verification to get more popular. Any system starts from no usage, and no education and works up - every bank, payment and fintech company is a pretty good start. Browser security indicators resembling more common verification indicators would help.
  - Buge 8y ago
    Do you have a source for the POST thing? I can't find anything by searching. Yeah, I agree EV has some potential for users to distinguish. If we add mechanical way for the browsers to enforce it, that could help increase website adoption, and thus also help users to notice it more.

ubernostrum 8y ago

The root problem is SSL/TLS was largely promoted, for years and years, as conflating two concerns: 1. Can an arbitrary third party eavesdrop on my communications? 2. Am I communicating with who I think I'm communicating with? It is now extremely easy to handle use case (1). Use case (2) is still genuinely hard, because even extremely technically literate security-savvy people can still easily be phished (my current go-to example is this talk: https://www.youtube.com/watch?v=ZjW12K0IHgo https://www.youtube.com/watch?v=ZjW12K0IHgo). Compounding the problem, many people insisted, for many years, that use case (2) was the overwhelming majority of all the value of SSL/TLS, and use case (1) was at best a tiny microscopic fraction of a fraction of a fraction of what was useful about SSL/TLS. Lest you think I'm exaggerating: I've spent years arguing with people, including right here on HN, about this, and being condescendingly told that identity verification is the crown jewel, and that if I'm not going to make use of that then I might as well literally just go back to plain unencrypted HTTPS, because apparently that's actually better than using SSL/TLS without identity verification. Also, I really recommend watching that video I linked. It's a security engineer at Stripe, talking about how she ran some pretty successful campaigns within the company. Whatever you may think of them, they're not unlettered philistines. But even things like your "Expect-EV" wouldn't have helped -- she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway. There just aren't any easy "just do X" technical solutions here.

tzs 8y ago
> she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway One big reason people do that is because probably 99+% of the time their password manager fails to fill the fields is not because it is the wrong site. It is almost always because the site has done something with its fields that is either preventing the password manager from finding the fields, or is blocking it from filling them (often intentionally).
- ubernostrum 8y ago