Dramatic SSL UI changes in Google Chrome for EV certificates
Paul van Brouwershaven
this is not a Firefox issue but I'm posting this here because there are many involved people people
active on this list.
http://code.google.com/p/chromium/issues/detail?id=41481
They want to show a DV and OV validated SSL certificate in green just like an EV certificate.
This could easily mislead users that are just get used to look at the 'green bar', they could think
that a site with a low trust SSL certificate is using a high trusted certificate!
I'm not sure if this also break the EV guidelines but I think this should not be allowed!
--
Kind regards,
Paul van Brouwershaven
Networking4all B.V.
Check you certificate installation at: http://ismysitesafe.com
Paul van Brouwershaven
>> They want to show a DV and OV validated SSL certificate in green just
>> like an EV certificate.
>
Any OV/DV certificate
> If Google wants their browser to treat their servers' certs specially,
> I don't have a big problem with that. But, if they want to give equal
> treatment to all OV/DV certs as to EV certs, well, hmmm ...
There is still a slight difference, an EV certificate has a company name near the padlock and an
DV/OV certificate not. But all certificates will be shown in green as of it's an EV certificate.
--
Regards,
Nelson B
> I would like to notice this list on the following issue (41481) in
> Google Chrome, I'm aware that this is not a Firefox issue but I'm
> posting this here because there are many involved people people active
> on this list.
>
> http://code.google.com/p/chromium/issues/detail?id=41481
>
> They want to show a DV and OV validated SSL certificate in green just
> like an EV certificate.
_Any_ OV/DV cert? Or just their own?
> This could easily mislead users that are just get used to look at the
> 'green bar', they could think that a site with a low trust SSL
> certificate is using a high trusted certificate!
>
> I'm not sure if this also break the EV guidelines but I think this
> should not be allowed!
This list is not the EV police nor the competition browser police.
With respect to Google's own cert, I'm sympathetic with Google's plight.
They run a HUGE server farm. They really want an EV wildcard certificate
for *.google.com but the EV guidelines prohibit wildcard EV certs.
Wildcard certs would be OK if there was any way to be sure that the holder
of that cert would only use it for servers that claimed to be that holder's
own identity. I (for one) personally believe that Google could be trusted
to do that.
The problem is that some other site might attempt to use a wildcard EV
cert to operate, say, BankOfAmerica.mortgage-department.com, and
chase.mortgage-department.com and citibank.mortgage-department.com,
attempting to represent itself as all those banks. A wildcard EV cert
would give the issuer no way to avoid/prevent that sort of abuse, and would
undoubtedly cause people to lose respect for the value of EV.
Ian Fette
We are certainly discussing the matter and there is division
internally. This is currently only on the dev channel, where we are a
bit more liberal in trying things out and seeing how they work. The
current design has a green lock + green https for DV/OV, and adds in a
green bubble with the attested information in the case of EV. This is
still a very noticeable difference between DV/OV and EV, but I
certainly appreciate the concerns. We are not done yet and are still
working on these changes - I've already had people from Mozilla, CA/B
Forum, and others contact me on the matter, as well as comments
internally, so clearly we will take these comments into consideration.
Again, we have a process on the dev channel of rapid iteration, what
you are seeing right now is one iteration that is not even fully
representing the design we had planned, but rather an in-between
state. There will be more iteration and discussion before any of this
goes out to all users.
-Ian
Paul van Brouwershaven
> We are certainly discussing the matter and there is division
> internally. This is currently only on the dev channel, where we are a
> bit more liberal in trying things out and seeing how they work. The
> current design has a green lock + green https for DV/OV, and adds in a
> green bubble with the attested information in the case of EV. This is
> still a very noticeable difference between DV/OV and EV, but I
> certainly appreciate the concerns. We are not done yet and are still
> working on these changes - I've already had people from Mozilla, CA/B
> Forum, and others contact me on the matter, as well as comments
> internally, so clearly we will take these comments into consideration.
> Again, we have a process on the dev channel of rapid iteration, what
> you are seeing right now is one iteration that is not even fully
> representing the design we had planned, but rather an in-between
> state. There will be more iteration and discussion before any of this
> goes out to all users.
on everyone's part") comment in the bug from pkasting:
"Using blue rather than green for non-EV would be more consistent with Firefox but would
violate what seemed to be an agreement on everyone's part that blue was lame and
meaningless and we wanted green for both."
But most CAs are linking EV to the color green!
For example:
Comodo
* The green address bar, exclusive to EV SSL, provides visual assurance to visitors that the site
is verified and secured. *
http://www.comodo.com/e-commerce/ssl-certificates/ev-ssl-certificates.php
Entrust
* Activates green address bar and other visual security cues, The future of online Web security is
green. *
http://www.entrust.net/
GlobalSign
* Activate the Green Address Bar! *
http://www.globalsign.com/ssl/index.html
GoDaddy
http://www.godaddy.com/ssl/ssl-certificates.aspx?ci=9039
* In addition to the lock icon and "https" prefix, a distinctive green browser bar further assures
Website visitors they are on a secure site *
StartSSL
* Green Trustbar, Extended Validation certificates help to increase identity awareness and customer
confidence due to the the new green address bar on next-generation browsers. *
http://www.startssl.com/?app=39
VeriSign
* Extended Validation, Green Address Bar *
http://www.verisign.ch/ssl/buy-ssl-certificates/index.html
... and probably there are much more!
--
Regards,
Gervase Markham
> But most CAs are linking EV to the color green!
If the Chrome changes this, then that would IMO be a great thing.
EV is not about looking for a particular colour, it's about looking for
site identity. The best situation would be if every browser displayed
exactly the same identity information in the same format e.g.
Company Name Ltd. (CountryCode)
in the same place in the browser, but it was green in IE, blue in
Firefox, fuschia in Chrome, lilac in Safari and purple in Opera.
Then people might actually look at the identity info instead of the colour.
Gerv
Paul van Brouwershaven
> EV is not about looking for a particular colour, it's about looking for
> site identity. The best situation would be if every browser displayed
> exactly the same identity information in the same format e.g.
>
> Company Name Ltd. (CountryCode)
You are totally true, EV is about a site identity, and looking for a company name is much better
then just looking for a color if you know witch company to expect.
But also the identity does not aways tell you how it's verified and how does the user knows? For
example there is also shown an identity in the certificate if you have an OV certificate. You can't
say to a user: "look for the identity/company name" but you have to specify where they have to look
in the browser for the identity. A user could easily be fooled!
Mozilla is showing the domain name in blue for a DV certificate, and this is a really good
protection against fraude with wildcard certificates. But let say we have a company "ABC Inc."
running a site "http://www.abc.in". EV shows "ABC Inc. [US]" DV shows "abc.in" when this would have
the same color it could mislead the user.
The strength of EV is the combination of the identity and the green bar.
> in the same place in the browser, but it was green in IE, blue in
> Firefox, fuschia in Chrome, lilac in Safari and purple in Opera.
>
> Then people might actually look at the identity info instead of the colour.
I think even if a user was only paying attention for the color this should not be a big issue. As
long the users knows that there has been done a proper validation (EV) he could probably trust the
site. Yes, this does not protect against phishing attacks, but if there was a phishing site with a
green bar you would have a very stupid swindler or one of the CAs has issued a false certificate.
Why does a traffic light use colors? It's more user friendly because it's easier to recognize.
--
Kind regards,
Matt McCutchen
<p.vanbrouwersha...@networking4all.com> wrote:
> This could easily mislead users that are just get used to look at the 'green bar', they could think
> that a site with a low trust SSL certificate is using a high trusted certificate!
I want to fight the common misconception that DV is "low trust".
Domain-validated SSL meets the technical goal of making sure the
browser is connected to the authorized operator of the requested
domain name. The domain validation procedure for DV certs is, or at
least ought to be, the same as for EV certs, because DV content can
script EV content from the same domain. What EV adds is the identity
of the organization, some basic assurance of its legitimacy, and
additional fraud checks.
That said, I agree with your conclusion. To paraphrase Mike
Beltzner's comment from here:
https://code.google.com/p/chromium/issues/detail?id=41481#c12
DV SSL is perfectly secure if you know you typed the correct domain
name, but meaningless otherwise, since anyone can get their own domain
with DV SSL. OTOH, EV sites are unlikely to be fraudulent, and that's
what the green represents.
I think Firefox's blue badge with the domain name is just right for
DV. It presents the verified information prominently without
suggesting any trust in the site operator.
--
Matt
Peter Saint-Andre
> I want to fight the common misconception that DV is "low trust".
> Domain-validated SSL meets the technical goal of making sure the
> browser is connected to the authorized operator of the requested
> domain name.
<snip/>
> DV SSL is perfectly secure if you know you typed the correct domain
> name, but meaningless otherwise, since anyone can get their own domain
> with DV SSL.
I concur. Besides, trust cannot be generalized easily or at all: there
is no such thing as a low-trust certificate, although there might be
certificates in which you or I have low trust.
Peter
--
Peter Saint-Andre
https://stpeter.im/
Matt McCutchen
> Besides, trust cannot be generalized easily or at all: there
> is no such thing as a low-trust certificate, although there might be
> certificates in which you or I have low trust.
Agreed. "Assurance" would be a better term.
--
Matt
Kurt Seifried
> Domain-validated SSL meets the technical goal of making sure the
> browser is connected to the authorized operator of the requested
> domain name. The domain validation procedure for DV certs is, or at
I would disagree. Until recently it was trivial for example to get
certificates for webmail providers that didn't lock down their
ssladmin@, etc addresses. As long as domain "verification" only
consists of emailing someaddress@ the domain it will be a lot easier
to get certificates than it should be (webmail providers, compromised
email servers, DNS servers redirecting email, sniffing traffic,
phishing an account, etc.). And of course there is no confirmation of
the domain, i.e. hotmail.ro is not a Microsoft hotmail site (which is
what DV/EV is for). Whether we like it or not users do place trust in
domain names (otherwise phishers/scammers wouldn't be registering
walmart-sales.com or whatever, they do it because it works!).
> DV SSL is perfectly secure if you know you typed the correct domain
> name, but meaningless otherwise, since anyone can get their own domain
> with DV SSL. OTOH, EV sites are unlikely to be fraudulent, and that's
> what the green represents.
No DV is not, again, it's far to easy to get a certificate for a
domain you don't control. The verification measures are simply still
very weak at various providers and since Firefox trusts all CAs with
root certificates equally (i.e. I get a lock icon if it's Verisign or
if it's "Big Bobs certificates and house of pancakes").
> I think Firefox's blue badge with the domain name is just right for
> DV. It presents the verified information prominently without
> suggesting any trust in the site operator.
I agree with this, I think it's very important to differentiate
between the three types of certificates as they are quite different.
> --
> Matt
-Kurt
Eddy Nigg
> No DV is not, again, it's far to easy to get a certificate for a
> domain you don't control. The verification measures are simply still
> very weak at various providers and since Firefox trusts all CAs with
> root certificates equally (i.e. I get a lock icon if it's Verisign or
> if it's "Big Bobs certificates and house of pancakes").
>
Do you imply that "Big Boobs" is good and "Verisign" not? Your recent
discoveries might suggest that ;-)
Anyway, the lowest level must be robust enough to establish domain
control, otherwise the browsers probably shouldn't trust it at all, no
matter who the issuer is.
> I agree with this, I think it's very important to differentiate
> between the three types of certificates as they are quite different.
I've been promoting that for years. Welcome to the club...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Matt McCutchen
> > I want to fight the common misconception that DV is "low trust".
> > Domain-validated SSL meets the technical goal of making sure the
> > browser is connected to the authorized operator of the requested
> > domain name. The domain validation procedure for DV certs is, or at
>
> I would disagree. Until recently it was trivial for example to get
> certificates for webmail providers that didn't lock down their
> ssladmin@, etc addresses.
That is an implementation mistake which is being addressed, not a
fundamental weakness in the model.
> As long as domain "verification" only
> consists of emailing someaddress@ the domain it will be a lot easier
> to get certificates than it should be (webmail providers, compromised
> email servers, DNS servers redirecting email, sniffing traffic,
> phishing an account, etc.).
The lack of a secure transport for the verification emails is a big
problem. Obviously, sending email to the domain being verified presents
a chicken-and-egg problem, so there has to be another way. This would
be worth discussing in a new thread.
Your other points amount to "subscribers and their hosting providers
have to operate their servers competently and not fall for scams", which
is nothing new.
> And of course there is no confirmation of
> the domain, i.e. hotmail.ro is not a Microsoft hotmail site (which is
> what DV/EV is for). Whether we like it or not users do place trust in
> domain names (otherwise phishers/scammers wouldn't be registering
> walmart-sales.com or whatever, they do it because it works!).
That does not make DV "low trust" (or assurance) for the purpose for
which it was designed. As I said, DV SSL is secure if you know you
typed the correct domain name, but meaningless otherwise. EV may be a
more appropriate solution for the case you mention.
> The verification measures are simply still
> very weak at various providers and since Firefox trusts all CAs with
> root certificates equally (i.e. I get a lock icon if it's Verisign or
> if it's "Big Bobs certificates and house of pancakes").
Again, that is being worked on. For example, see:
https://groups.google.com/group/mozilla.dev.security.policy/msg/a272639e02665217
--
Matt
Kurt Seifried
> fundamental weakness in the model.
I would argue it's a fundamental weakness. Control over a single email
address is equated to control over a domain. These things are not
actually the same.
For example requiring the email check, and a DNS check (i.e. add a
record for random SHA1 sig) and a web site check (i.e. add a random
SHA1 sig.html to the web root) would essentially prove that either
this is legit, or the attacker has control over DNS, email and www in
which case any technical checks will be passed regardless.
> The lack of a secure transport for the verification emails is a big
> problem. Obviously, sending email to the domain being verified presents
> a chicken-and-egg problem, so there has to be another way. This would
> be worth discussing in a new thread.
Adding different checks
> Your other points amount to "subscribers and their hosting providers
> have to operate their servers competently and not fall for scams", which
> is nothing new.
Right, but there are degrees of this. For example with a DNS check and
web check there's a much better chance that losing control of a single
email address won't result in your losing control of your domain to an
improperly issued SSL certificate.
> That does not make DV "low trust" (or assurance) for the purpose for
> which it was designed. As I said, DV SSL is secure if you know you
> typed the correct domain name, but meaningless otherwise. EV may be a
> more appropriate solution for the case you mention.
DNS can be compromised, cache poisoning/wireless networks in a coffee
shop/etc. SSL in this case should not rely upon DNS behaving correctly
in order to behave correctly. The only thing SSL in this case should
rely upon is the root certificate store of the browser being correct.
If SSL only works if other protocols such as DNS behave correctly than
SSL is pretty useless.
-Kurt
M.Hunstock
> If SSL only works if other protocols such as DNS behave correctly than
> SSL is pretty useless.
SSL is trying to prevent MITM attacks, so it is perfect for the case
that DNS doesn't work or is compromised.
Matt wrote: "if you know you typed the correct domain name" - typing an
incorrect name is different from having a compromised DNS system.
Matt McCutchen
> That is an implementation mistake which is being addressed, not a
> > fundamental weakness in the model.
>
> I would argue it's a fundamental weakness. Control over a single email
> address is equated to control over a domain. These things are not
> actually the same.
Control over a single *well-known administrative* email address is
equated to control over a domain. That is a reasonable assumption.
> For example requiring the email check, and a DNS check (i.e. add a
> record for random SHA1 sig) and a web site check (i.e. add a random
> SHA1 sig.html to the web root) would essentially prove that either
> this is legit, or the attacker has control over DNS, email and www in
> which case any technical checks will be passed regardless.
Your proposed change makes no difference against network attackers,
who can spoof all of those services with equal ease. It only helps in
cases where the subscriber made a configuration blunder that
compromised (for example) an administrative email address but not the
web server. I'm not convinced that the benefit is significant enough
to mandate the extra checks for all CAs.
> DNS can be compromised, cache poisoning/wireless networks in a coffee
> shop/etc. SSL in this case should not rely upon DNS behaving correctly
> in order to behave correctly. The only thing SSL in this case should
> rely upon is the root certificate store of the browser being correct.
>
> If SSL only works if other protocols such as DNS behave correctly than
> SSL is pretty useless.
I agree.
My preferred solution would be to have the subscriber add a hash of
the CSR to the WHOIS data and have the CA fetch the WHOIS data over a
secure transport. That requires beefing up the security of WHOIS, but
that's probably easier than inventing a new system.
--
Matt
Matt McCutchen
> Am 22.04.2010 09:16, schrieb Kurt Seifried:
>
> > If SSL only works if other protocols such as DNS behave correctly than
> > SSL is pretty useless.
>
> SSL is trying to prevent MITM attacks, so it is perfect for the case
> that DNS doesn't work or is compromised.
Kurt's point was about the domain validation process, which is
unsecured.
--
Matt
M.Hunstock
> Kurt's point was about the domain validation process, which is
> unsecured.
If he was pointing on the registrar part of DNS (whois records etc.)...
well, that's true indeed.
Kurt Seifried
> equated to control over a domain. That is a reasonable assumption.
Yes and once we've confirmed that every single CA in the
firefox/mozilla root store is complying with this I'll feel a bit
better, but we're not there yet.
> Your proposed change makes no difference against network attackers,
> who can spoof all of those services with equal ease. It only helps in
Which sort of is my point. We make a best effort to confirm the domain
(multiple checks, within reason) so that we have one of two
possibilities:
1) this is the legit domain holder
2) the domain is so utterly compromised that further technical checks
would be largely meaningless
The funny thing is Google used to require this (maybe they still do)
for some of their services (like google analytics), which are way less
important (security wise at least) than SSL certificates.
> I agree.
>
> My preferred solution would be to have the subscriber add a hash of
> the CSR to the WHOIS data and have the CA fetch the WHOIS data over a
> secure transport. That requires beefing up the security of WHOIS, but
> that's probably easier than inventing a new system.
But I want a private WHOIS registration so I don't get spammed/etc.
Sadly we can no longer rely upon WHOIS to even be available (some have
removed access for the public and you must pay a fee to get WHOIS
data). WHOIS is basically a historical oddity at this point (for all
practical intents and purposes at least).
> --
> Matt
-Kurt
Matt McCutchen
> > Control over a single *well-known administrative* email address is
> > equated to control over a domain. That is a reasonable assumption.
>
> Yes and once we've confirmed that every single CA in the
> firefox/mozilla root store is complying with this I'll feel a bit
> better, but we're not there yet.
Right.
> > Your proposed change makes no difference against network attackers,
> > who can spoof all of those services with equal ease. It only helps in
>
> Which sort of is my point. We make a best effort to confirm the domain
> (multiple checks, within reason) so that we have one of two
> possibilities:
>
> 1) this is the legit domain holder
> 2) the domain is so utterly compromised that further technical checks
> would be largely meaningless
You still have not convinced me that there is a real benefit compared
to checking a single administrative email address. The fact that
"further technical checks would be largely meaningless" is not in
itself a level of security.
> > My preferred solution would be to have the subscriber add a hash of
> > the CSR to the WHOIS data and have the CA fetch the WHOIS data over a
> > secure transport. That requires beefing up the security of WHOIS, but
> > that's probably easier than inventing a new system.
>
> But I want a private WHOIS registration so I don't get spammed/etc.
Irrelevant. You can add the CSR hash and leave the rest of the proxy
contact information in place.
> Sadly we can no longer rely upon WHOIS to even be available (some have
> removed access for the public and you must pay a fee to get WHOIS
> data).
That's a problem. But, it's either fix WHOIS or invent a new, largely
equivalent system.
--
Matt
Kurt Seifried
> to checking a single administrative email address. The fact that
> "further technical checks would be largely meaningless" is not in
> itself a level of security.
No, it's a case of we do the best we can within reason so that we can
be certain it's either legit or that further checks would be largely
meaningless. "the CA takes reasonable measures to verify" (quoted from
pretty much any CPS document). I believe that checking a single email
address is not a reasonable measure (it's weak, single failure, you
don't even have to access the email; sniffing traffic is sufficient,
etc.).
> Irrelevant. You can add the CSR hash and leave the rest of the proxy
> contact information in place.
Not really, the registrars I seem to use pretty much give you on/off
for privacy.
# whois pirateparty.ca
[Querying whois.cira.ca]
[whois.cira.ca]
Domain name: pirateparty.ca
Domain status: EXIST
Approval date: 2006/06/08
Renewal date: 2011/06/08
Updated date: 2009/07/18
Registrar:
Name: Tucows.com Co.
Number: 156
the hash goes where exactly?
> That's a problem. But, it's either fix WHOIS or invent a new, largely
> equivalent system.
But I'm not inventing anything new. I'm simply asking that "the CA
takes reasonable measures to verify" (quoted from pretty much any CPS
document) by establishing that the person requesting the certificate
also has control over DNS and the web server as opposed to a single
email address. These are not hard things to implement (create a hash,
tell the user to add a dns record pointing to a specific ip, create a
hashname.html file, do a dns lookup and request the file a few minutes
later).
> --
> Matt
-Kurt
Matt McCutchen
> > You still have not convinced me that there is a real benefit compared
> > to checking a single administrative email address. The fact that
> > "further technical checks would be largely meaningless" is not in
> > itself a level of security.
>
> No, it's a case of we do the best we can within reason so that we can
> be certain it's either legit or that further checks would be largely
> meaningless.
What's the goal here, security or throwing up our hands and claiming
we have done our best?
> I believe that checking a single email
> address is not a reasonable measure (it's weak, single failure, you
> don't even have to access the email; sniffing traffic is sufficient,
> etc.).
Once again, that's an *administrative* email address, and doing more
checks doesn't help against compromised DNS, only certain specific
classes of configuration mistakes.
> > Irrelevant. You can add the CSR hash and leave the rest of the proxy
> > contact information in place.
>
> Not really, the registrars I seem to use pretty much give you on/off
> for privacy.
Right, there needs to be a field for the CSR hash that is editable
when privacy is on.
My point is that if we want a domain validation mechanism that mirrors
the DNS delegation structure, WHOIS is already most of the way there
and we could adapt it rather than invent something new.
> > That's a problem. But, it's either fix WHOIS or invent a new, largely
> > equivalent system.
>
> But I'm not inventing anything new. [...]
We're considering two alternative proposals: (1) adding more MITM-able
checks and (2) switching to a secure transport and contacting the
registrar (because contacting the site being validated presents a
chicken-and-egg problem). My remark was about #2.
--
Matt
Matt McCutchen
> The lack of a secure transport for the verification emails is a big
> problem.
Let me amplify this point. DV SSL as currently implemented is no
better than Perspectives (http://www.cs.cmu.edu/~perspectives/) with
the Mozilla-recognized CAs as the notaries, except for some extra
fraud checks on well-known trademarks. And remember that EV SSL pages
can be scripted by DV SSL content delivered in the same domain.
--
Matt
Ben Bucksch
> Then people might actually look at the identity info instead of the
> colour.
While true, what prevents a DV issuer from putting a name in the name field?
EV is not about the fact that there's a name, but that that name is
verified.
Ben Bucksch
> I want to fight the common misconception that DV is "low trust".
> Domain-validated SSL meets the technical goal of making sure the
> browser is connected to the authorized operator of the requested
> domain name.
No, it doesn't, and this discussion doesn't belong here.
How is DV validated? By sending an email - without SSL! Great thinking.
Ben Bucksch
Nevermind!