221–230 of 329 posts
Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?
Earlier quoted context omitted.
Well, just looking at the Bank of America example, they don't seem to use HSTS in their landing page. How widespread is HSTS? How long is the expiry period typically set for (I would guess a long time?) Does anyone still use browser bookmarks? Actually, just thinking about it, it might be even simpler than this. If Bank of America wanted to, couldn't they still host their redirect landing page over SSL with a valid n…
HSTS is currently used by 2.8% of all websites, up from 1.2% this time last year. [1] If people are using Qualys SSL Labs tool to check their "grade", they won't be awarded an A+ grade unless their HSTS max-age is at least 6 months [2], so I'm going to assume the average is somewhere close to that due to how common usage of that tool is. My grandma still uses browser bookmarks, but I have no none-anecdotal source for…
Earlier quoted context omitted.
I think it's likelier that Symantec will start a negative PR campaign, leading its users to yell at google to change things, perhaps calling this FUD. Whether that'll be effective is another question.
Yes. You can't just jeopardize a substantial portion of a large company's revenue stream like this and not expect retaliation. Guaranteed that unless the executive team steps in to reverse this, Google has made itself a few powerful enemies. Google is playing with fire here. I would expect Symantec and other major business who stand to be negatively affected, especially the extremely large ones that Symantec was acco…
Earlier quoted context omitted.
Pretty much it will decide the question on whether or not the certificate system is even workable. My thesis is that either Symantec will not be able to respond (and so lose their ability to be a root certificate) in which case it will warn other root cert authorities to shape up or lose their business, or they will placate the Google and Chromium teams somehow and show that root cert authorities can be brought to be…
It is workable. This gets brought up every time we have an issue like this. The problem is that existing CA's keep fucking up. But the system is clearly working: bad CA's get excluded. I think the likely result here is more widespread adoption of LE. The point is that CA's shouldn't be businesses.
Earlier quoted context omitted.
The exception process used by payment processors such as First Data were for SHA-1 certificates chaining to a root that was still publicly-trusted. They couldn't use an off-reservation root because their client devices didn't trust them. The roots that Symantec took off-reservation are regularly issuing SHA-1 certificates to anyone whose check clears. Got $1,699 to spare? https://www.thesslstore.com/symantec/secure-s…
I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted? Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
Yes, if a client isn't receiving root store updates it will continue to trust certificates chaining to the off-reservation root. This is why taking previously-trusted roots off-reservation is bad for the ecosystem and would ideally be prohibited.
> Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
Many payment systems apparently have no automatic update mechanism, so I assume there is no requirement for such.
Earlier quoted context omitted.
Pretty much it will decide the question on whether or not the certificate system is even workable. My thesis is that either Symantec will not be able to respond (and so lose their ability to be a root certificate) in which case it will warn other root cert authorities to shape up or lose their business, or they will placate the Google and Chromium teams somehow and show that root cert authorities can be brought to be…
> Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse. IIRC that's Amazon's answer to 'how should a user install Amazon Prime on Android?' I don't know how successful they've been convincing users to allow installation of untrusted apps (I certainly…
Earlier quoted context omitted.
EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name. ie. https://paypal.com-customerservice.ru vs PayPal Inc [US] | https://paypal.com I run https://certsimple.com . We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the…
If a site with an EV cert is being spoofed using a similar-looking domain name and a DV cert, how realistically is the user going to remember that the real site is supposed to have an EV cert? (Besides just maybe remembering it for Paypal in particular.) See also the Nordea section at https://hsivonen.fi/bank-idp/ . How is a user supposed to form a mental model about multi-server org who don't use EV consistently?
There's no simple, single answer here: you can stop validation downgrades is pinning to EV roots but browser UI is also a huge part: mobile Safari, for example, simply uses the validated legal entity as the address and keeps it on screen during the entire session (even when you scroll). Visit https://stripe.com on mobile Safari and you'll see
> _______________Stripe Inc.______________
...persistently on top of the screen throughout the entire session [1]. Other browsers don't show validated identity as effectively though.
[1] Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.
Earlier quoted context omitted.
Small correction: the CA industry doesn't self-regulate. Both browsers and CAs participate in the CA/Browser Forum and my (admittedly outsider) impression is that browsers almost always have the upper hand.
Things that go to vote in the CAB Forum are often split pretty exactly down CA v. browser lines, and the CA outnumber the browsers and hence typically win. That said, the power of the browser vendors as those who maintain the trust stores is obviously there.
Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?
Earlier quoted context omitted.
EV actually causes a different "secure" UI to display in the browser. Usually it is the name of the corporate entity that the certificate is issued for. If you don't have EV you only get a padlock.
Oh, I know. But name me a non-IT professional that knows the difference, or would care that their bank has "secure" and not "Bank of America LLC". I think there are groups of smart PKI/UI people discussing how better to design security warnings at various levels of EV/HTTPS/Partial HTTPS/HTTP.