Closed Bug 430790 Opened 16 years ago Closed 15 years ago

Users can be tricked into thinking sites are encrypted with new visual cues added by bug 417844

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: wgianopoulos, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [sg:want])

Attachments

(2 files)

clearlooksclassic, ssl vs favicon
11.57 KB, image/png
Details
FQDN showing enabled
6.11 KB, image/png
Details 
There are 2 big issues with the new visual cue for an non-EV cert SSL site created by the fix fog bug 417884.

Both of these have to do with themes other than winstripe.

Basically the issue has to do with themes for which the shape of the area surrounding where the the site icon displays in the URL bar is relatively square and the border area around the site con is not very large.

Issue 1:

Coloring the are around the site icon blue might not be particularly noticeable.

Issue 2 (and this one is far worse):

I could probably fool users into thinking my site was SSL encrypted merely by changing the background color of my site icon to blue.

THe simplest way to fix both of these issues is to change the default for the browser.identity.ssl_domain_display preference to 1 so that the effective TLD is displayed for https sites for the non-EV cert case.

This is obviously how things were set when the mock-ups displayed in bug 417884 were created, but this is NOT the Firefox 3 default setting.  This would make a much larger blue area that is outside of the websites control as to appearance.
Flags: blocking-firefox3?
I suggest adding a note in the what-should-theme-developers-know-for-fx3 documentation that third-party theme devs should either make the site identity button big enough that there is a noticeable amount showing through or that they should change the address bar color to match (green, blue, or no coloring), and provide sample code to that effect.

The problem is that when you're talking about third-party themes, they could do just about anything: they could remove the coloring from the site identity button all together if they wanted or they could decide to use brass for the DV/EV address bar if they really liked the old Fx2 style.  The way that default theme works would cause a problem for third-party themes only if third-party themes decide to design their theme in a way that shoots themselves in the foot.

FWIW, the question of turning on ETLD+1 (including what bug 417844 would mean for that) had already been discussed in bug 414627.
(In reply to comment #1)
> I suggest adding a note in the what-should-theme-developers-know-for-fx3
> documentation that third-party theme devs should either make the site identity
> button big enough that there is a noticeable amount showing through or that
> they should change the address bar color to match (green, blue, or no
> coloring), and provide sample code to that effect.
> 

This is not just a third party theme issue.  It is only with the Winstripe theme that I think it is probably unlikely that anyone would be fooled, so the current method is really on non-spoofable for windows only.
(In reply to comment #2)
> This is not just a third party theme issue.  It is only with the Winstripe
> theme that I think it is probably unlikely that anyone would be fooled, so the
> current method is really on non-spoofable for windows only.
> 

Ah, okay.  Thanks for clarifying that.  I assume that you are referring to gnomestripe, which does seem to have very little in the way of spacing around the favicon?  (From screenshots, it doesn't seem like pinstripe would be affected, but I don't have a Mac to see.)  For gnomestripe, the horizontal spacing could be increased, or some subtle coloring could be added to the address bar.
Well actually, it is probably really late for this suggestion, but the real issue is the overloading of the favicon for the identity button purpose.  There should be a separate button to the left of the favicon that is either an open lock, a secured lock on a blue background or a secured lock on a green background with the identity information.  The favicon should display to the right of this additional security button next to the url.  This does not make the favicon (which is under control of the website) have anything at all to do with the security/identity indicators and permits restoring the function of clicking on the site icon to selecting the url in the textbox.
(In reply to comment #4)
> the real
> issue is the overloading of the favicon for the identity button purpose.

Yea, that issue was discussed at length in bug 414627.

FWIW, I think Microsoft and Opera got it right by placing the security info on the opposite end of the address bar and by keeping the favicon separate on the left as just a favicon.
(In reply to comment #4)
> Well actually, it is probably really late for this suggestion, but the real
> issue is the overloading of the favicon for the identity button purpose.

Finally! :)

(I brought this particular point up a few times before. I don't want to add anything here, I'm just glad to see that I'm not completely alone with this opinion.)
Well the entire problem with referring to what was already discussed and
decided on in bug 414627, was that at the time the primary visual indicator to
the user that a site was encrypted was the urlbar background changing to
yellow.  Since that is no longer the case, anything decided in that bug based
on the favicon button being an indicator only for identity and not encryption
is really irrelevant at this point.


(In reply to comment #7)
> Well the entire problem with referring to what was already discussed and
> decided on in bug 414627, was that at the time the primary visual indicator to
> the user that a site was encrypted was the urlbar background changing to
> yellow.

Not true for Mac. It was also pretty clear that bug 417844 would happen.
(In reply to comment #3)
> Ah, okay.  Thanks for clarifying that.  I assume that you are referring to
> gnomestripe, which does seem to have very little in the way of spacing around
> the favicon?  (From screenshots, it doesn't seem like pinstripe would be

Actually the issue is even worse than you think under gnomestripe.  I run
fedora and use the default bluecurve theme. SO lets say i go to google.com and
my default search engine is google.  so now i have 2 identical looking google
icons on the same toolbar.  one of them having a blue background means there is
a search engine on the page and the other one having an identical looking
background means the site is SSL encrypted?

And this is supposed to be the primary visual cue to a user that for a security
function?

(In reply to comment #9)
> And this is supposed to be the primary visual cue to a user that for a security
> function?
> 

At the risk of rehashing bug 414627, yes.  The idea here is that with the proliferation of cheap (and sometimes even free) certificates, all that DV means is confidentiality, and since the biggest threat these days isn't packet interception (and it never was much of a threat except maybe in public WiFi), DV should be de-emphasized in favor of EV, which does add text to the site icon.

Not that I with how things turned out (see comment 5), but it's what was decided in bug 414627.
Perhaps we should reconsider bug 420958 for this. If the dropdown arrow is there then it at least provides some additional space which the favicon will be unable to affect.
What Kai said is essentially right.  We know that DV certs more or less mean little more than "your connection is encrypted" which isn't really anything to do with security.  Blue doesn't mean "you are secure" it means "there is information here if you click on it"  That's it.
Component: General → Security
QA Contact: general → firefox
This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.
Flags: blocking-firefox3? → blocking-firefox3-
But it may be worthwhile to increase the size of the Larry button on Linux, as my understanding from the comments here is that it's too small there.  Can anyone provide a Linux screenshot?
(In reply to comment #12)
> What Kai said is essentially right.  We know that DV certs more or less mean
> little more than "your connection is encrypted" which isn't really anything to
> do with security.  Blue doesn't mean "you are secure" it means "there is
> information here if you click on it"  That's it.
> 

Well what about OV certificates, which as near as I can figure out are equally as trustworthy as EV certificates except that they cost 10 times less, yet Mozilla treats them equally to DV certificates?
> Well what about OV certificates, which as near as I can figure out are equally
> as trustworthy as EV certificates except that they cost 10 times less, yet
> Mozilla treats them equally to DV certificates?
> 

Unfortunately, I don't think that's something that anyone can change this late, esp. since changes like this will require lots of discussion beforehand.  So it's not anything that's actionable at the moment.  But increasing the size of the site icon on Linux is.  Maybe it's best if you filed a bug specifically for increasing the size of the Linux site icon, include a screenshot, and then that can be taken care of, while leaving this bug open for more general and long-term issues?
(In reply to comment #15)
> Well what about OV certificates, which as near as I can figure out are equally
> as trustworthy as EV certificates except that they cost 10 times less, yet
> Mozilla treats them equally to DV certificates?

By what objective set of criteria shall we judge the quality of OV certificates, Bill?  I agree that the best OV issuing practices out there are as good, maybe better, than EV, but if we had a set of consistent, cross-CA rules for what constituted an "acceptable" OV certificate, we wouldn't have needed EV in the first place.  The tenor of your comment suggests either malice, ignorance or avarice on Mozilla's part for failing to recognize OV certs as a distinct category and it seems a touch insulting to several people besides myself.  Am I reading too much in to it?

I agree wholeheartedly with Kai in comment 16.  We have a solvable problem here if the concern is that gnomestripe doesn't have enough pixel width to make the state transitions visible.  If you would rather tackle that in a separate bug and spend this one re-living the last 3 years of browser-CA discourse, we can do that too, but I confess it's difficult for me to understand how your comments are intended to be constructive.

(In reply to comment #17)
> (In reply to comment #15)
> > Well what about OV certificates, which as near as I can figure out are equally
> > as trustworthy as EV certificates except that they cost 10 times less, yet
> > Mozilla treats them equally to DV certificates?
> 
> By what objective set of criteria shall we judge the quality of OV
> certificates, Bill?  I agree that the best OV issuing practices out there are
> as good, maybe better, than EV, but if we had a set of consistent, cross-CA
> rules for what constituted an "acceptable" OV certificate, we wouldn't have
> needed EV in the first place.

Well, you are obviously correct here.  One of the things EV certificates did was at least create an well defined objective criteria for judging if a CA was doing a proper job in following the procedures for issuing EV certificates.

It would have been better if there had also been some kind of independent, Internationally recognized body to audit compliance by the CAs with the requirements so that the browser vendors did not have to each do this on their own.  I fear that because of this, eventually EV certs might end up not making a substantial difference.  I hope I am wrong about this, but Microsoft already decided to make every CAs proposed EV certs turn the addressbar green with no regard to compliance with any of the requirements. :-(


> The tenor of your comment suggests either
> malice, ignorance or avarice on Mozilla's part for failing to recognize OV
> certs as a distinct category and it seems a touch insulting to several people
> besides myself.  Am I reading too much in to it?

Well, I'm sorry if it cam off that way.  My comments were directed at comment #12, which first of all said that end-to-end encrypting did nothing to enhance security, and also seemed to suggest that any certificate other than an EV certificate was completely worthless and perhaps no visual differentiator should be presented for non-EV certificates.  Perhaps I was reading too much into that comment, but that was the way it sounded to me.

I suspect that in the near future most financial institutions and e-commerce sites will be using EV certificates.

However I also suspect that close to zero business will be using EV certificates for their intranet servers.  Further I suspect that the Federal Government and Government contractors will continue to use their own methodology to cross-certify and establish trust of each others certificates.  In those environments I think it is still very important to not make those certificates appear less trusted than they should be.

(In reply to comment #18)
> (In reply to comment #17)
> > By what objective set of criteria shall we judge the quality of OV
> > certificates, Bill?  I agree that the best OV issuing practices out there are
> > as good, maybe better, than EV, but if we had a set of consistent, cross-CA
> > rules for what constituted an "acceptable" OV certificate, we wouldn't have
> > needed EV in the first place.
> 
> Well, you are obviously correct here.  One of the things EV certificates did
> was at least create an well defined objective criteria for judging if a CA was
> doing a proper job in following the procedures for issuing EV certificates.

Yeah, that's the principal reason we are member of the CABForum.  Getting higher quality information out there in a way that we can evaluate across all CAs saves us from the mishmash of DV/OV (or Class 1/Class 2, or whatever system $CA has devised), even if it does mean constructing something not too far off what some CAs were already doing.  In the early days, one of the proposals in CABForum *was* to just adopt one of the CA's OV issuing policies as the standard, but I think we got to a pretty acceptable place in terms of verification criteria anyhow.

> It would have been better if there had also been some kind of independent,
> Internationally recognized body to audit compliance by the CAs with the
> requirements so that the browser vendors did not have to each do this on their
> own.  I fear that because of this, eventually EV certs might end up not making
> a substantial difference.  I hope I am wrong about this, but Microsoft already
> decided to make every CAs proposed EV certs turn the addressbar green with no
> regard to compliance with any of the requirements. :-(

To be fair, the CABForum was deadlocked for a long time and MS drawing a line in the sand and saying that Draft 11 was going to be called EV for IE7 probably moved things along.  Nevertheless, I honestly don't know how their cert program works.

What I *will* point out, though, in case it's not clear, is that Frank only approves EV applications from CAs that have a valid 3rd party audit.  So yes, it is on us to ensure that CAs present that audit, but that is a lot less burden than us verifying the actual issuing practices.  You're exactly right that if it is on the browsers to verify issuing practices, we're set up for the same downward spiral, since we don't have the resources to do that.  But the EV guidelines require issuers to have regular audits by third party auditors ensuring that they are doing things right.  If they didn't, it would be very easy for us to justify pulling the EV-flag on a given root, even if they continued to be trusted as a cert issuer in general.

> > The tenor of your comment suggests either
> > malice, ignorance or avarice on Mozilla's part for failing to recognize OV
> > certs as a distinct category and it seems a touch insulting to several people
> > besides myself.  Am I reading too much in to it?
> 
> Well, I'm sorry if it cam off that way.  My comments were directed at comment
> #12, which first of all said that end-to-end encrypting did nothing to enhance
> security, and also seemed to suggest that any certificate other than an EV
> certificate was completely worthless and perhaps no visual differentiator
> should be presented for non-EV certificates.  Perhaps I was reading too much
> into that comment, but that was the way it sounded to me.

This late in the release, we all get a couple free passes to be punchy, and I'm sorry if I seemed to be making to much out of it.  Comment 12 goes further than I would, in terms of diminishing the value of DV certs, but I think it reflects the same frustration we all feel, that historically there has not been a way to sort the "high quality" from the "low quality" certs.  EV gives CAs a new high-priced product to sell, no doubt, but we obviously aren't in it for that.  We're participating, and highlighting EV, because we think it will be good for our users, and for the internet.

So let's stipulate that we agree that some differentiation between DV-SSL and straight-http is a good thing.  What actions does this bug boil down to, in that case?

I'd argue that there's no gain to be had from bringing back the yellow bar (which MS now uses to mean "caution") and there's ample research pointing to the padlock going unnoticed.  Certainly things like bug 414627 would make things more noticeable but that is a non-starter for now.  I actually don't think the current state of affairs is a problem on Windows or Mac, where the button colour change is pretty noticeable with the latest styling changes that have landed.  But I haven't seen gnomestripe lately, if the site button area is too small to be a good indicator here, or if the colouring is too subtle, it would give this bug something concrete to discuss.
(In reply to comment #19)
> have landed.  But I haven't seen gnomestripe lately, if the site button area is
> too small to be a good indicator here, or if the colouring is too subtle, it

200080516 screenshot, for reference
(In reply to comment #10)
> At the risk of rehashing bug 414627, yes.  The idea here is that with the
> proliferation of cheap (and sometimes even free) certificates, all that DV
> means is confidentiality, and since the biggest threat these days isn't packet
> interception (and it never was much of a threat except maybe in public WiFi),
> DV should be de-emphasized in favor of EV, which does add text to the site
> icon.
> 

Sorry, but do you have the slightest clue about what you are talking about?

I represent the only CA which provides server certificates for free (which you seem to dismiss for no other reason than of them being provided without charge **) and please allow me to correct you, but DV and otherwise validated certificates answer a specific need to protect the transfer of information between servers and clients. Or would you suggest to send your passwords to your forum, blog, Bugzilla, Trac, portal and whatnot in plain text? Why is this Bugzilla running in secured mode? Scores of other applications with login facilities protect them with SSL/TLS. Eavesdropping isn't an issue today BECAUSE of SSL. Did you ever point a sniffer to a network to intercept data? If not, I'll be glad to point to some handy tools... 

Higher validated certificates answer a different need and EV yet another one. Verifications and validations of identities and other attributes have their place as well in the PKI landscape, but of course not for you guys...I'm sure you all got EV certificates at your servers (please send me a link).

Johnathan, I'm posting here, because the current UI really suggests to better use plain text than SSL (besides EV). For reference see the attachment 318834 [details] which I posted on bug 417844. The favicon icon looks disgusting, one can hardly find a difference between plain and secured...are we going back to have to educate users to look for the little padlock? And if it's really that useless, why make all the efforts for governing CAs over at dev-tech-crypto?

And if encryption has nothing to do with security as in comment 12, than what is it? Why invest in the NSS library efforts to prevent eavesdropping in first place? Why do CAs have to perform any validation at all in order to conform to the Mozilla CA policy? Perhaps Debian's removal of a few lines at their OpenSSL library was a good thing then, because who needs good random numbers anyway if encryption is useless?

And how do your statements here reflect with reality? 5000 issued EV certificates is all we got, even now after more then 1 1/2 years since Microsoft with IE7 put its weight behind it. This compares to more than 500,000 legitimate issued DV/IV/OV certificates. EV is fine, but why cripple all the rest to the extend to make it even look shabbier then plain? Seriously, This blueish stuff which makes the favicon icon look completely ugly isn't something which gives any confidence. It looks like....iiikkk, get me out of here. But I wouldn't be surprised if this was your intention all along. I understand that SSL should be discouraged at all!

LONG LIVE PLAIN CONNECTIONS, MAY OUR CONFIDENTIAL INFORMATION PASS ALONG THE NET FOR EVERYBODY TO SEE. DOWN WITH ENCRYPTION, WE WANT EAVESDROPPING HERE AND NOW. LONG LIVE ALL THE SMART PEOPLE, WHICH REALLY KNOW WHAT PKI IS ALL ABOUT.

** StartCom has done much more for the Internet community, by providing legitimate certificates of all kinds without charge, than all of you here! We encourage the use of SSL, explain and educate, provide assistance and take down the financial barriers by providing part of our services for free. And which effort are you doing?

Johnathan, in comment 19, you wrote:
> Certainly things like bug 414627 would make things more noticeable but 
> that is a non-starter for now. 

Bug 414627 is Resolved Fixed.  
So, is it a non-starter because it's finished? :)
Or did you mean some other bug? 
or was there some unimplemented proposal in that bug to which you are referring?

Oh, and BTW, color-blind users DO rely on the lock icon, because all those
different colored URL bar backgrounds are indistinguishable.  We're talking
over 10% of the male population.  I just wish the lock was in the bar at the
top, and was much bigger.
Attached image FQDN showing enabled — 
I could live with browser.identity.ssl_domain_display set to 1, which looks much better and really would distinguish plain versus secured. Additionally THIS isn't easily spoofed as shown in attachment 321469 [details]
(In reply to comment #23)
> Johnathan, in comment 19, you wrote:
> > Certainly things like bug 414627 would make things more noticeable but 
> > that is a non-starter for now. 
> 
> Bug 414627 is Resolved Fixed.  
> So, is it a non-starter because it's finished? :)
> Or did you mean some other bug? 
> or was there some unimplemented proposal in that bug to which you are
> referring?

Yeah - that bug (and I absolutely forgive a person for not reading it in all it's detail) was concerned with the setting of the pref Eddy mentions in comment 24, which would have made SSL state much more evident, but with obvious tradeoffs in terms of redundancy (since the host is already a part of the location bar), input space in the location bar itself, etc.  If you want the arguments, then I really do recommend reading the bug, because it would take a very long time to rehash them all here, and I will mercilessly said rehashing, too.  :)

Eddy - I think you know that I value DV-SSL, that I recognize the benefits of an encrypted channel, and far better than that, a channel that's encrypted to a known-and-identified endpoint.  I do substantially prefer the added information we get out of a cert whose O= field we can trust, but I am already on record in this bug saying that DV is substantially more than 0, as a guarantee.  I don't think it particularly serves our users or the original intent of this bug to revisit all of that, but let's take it as basically granted, since I think this is an area where you and I agree almost wholeheartedly.

Your concerns (albeit phrased in unhelpfully combative ways, but such is your special style :) as I understand them are chiefly:

a) That the button coloration doesn't look good
b) That it makes it too easy to miss the distinction between http and DV-SSL

I would further submit that this is more of a concern on Linux than on the other platforms.  The treatment on windows makes the button stand out more than on Linux, and on mac, the blue button is distinctly visible in an otherwise grey colour scheme.  So how do we fix it?

I think the long term way to fix this is, as you mention yourself in comment 24, to use some kind of text in the button there to draw attention.  Several strategies were discussed in bug 414627 that would accomplish this, but module owners made the call there, and we're not going to revisit it for Firefox 3, so that is deferred until whatever comes next.

I don't think the yellow background is a particularly helpful thing to contemplate bringing back. I think we security-focused people noticed it, but I think the fact that browsers like IE use a yellow address bar to mean "warning", combined with the academic data saying that people don't notice the existing indicators of SSL state anyhow argue that bringing it back isn't a high-value decision.

I think what's left in the short term is to find a linux-specific way to make the button transitions more apparent.  As I say, attachment 321422 [details] makes it clear that the treatment is not as visible there as on other platforms.  That feels like a solvable problem, and is what Kai L was mentioning earlier - by growing the button, or otherwise making it more apparent that a change has occurred.  I think it is productive to talk about other ideas for making that work, but less productive to revisit the last 10 years of crypto history.

(In reply to comment #21)
> LONG LIVE PLAIN CONNECTIONS, MAY OUR CONFIDENTIAL INFORMATION PASS ALONG THE
> NET FOR EVERYBODY TO SEE. DOWN WITH ENCRYPTION, WE WANT EAVESDROPPING HERE AND
> NOW. LONG LIVE ALL THE SMART PEOPLE, WHICH REALLY KNOW WHAT PKI IS ALL ABOUT.
> 
> ** StartCom has done much more for the Internet community, by providing
> legitimate certificates of all kinds without charge, than all of you here! We
> encourage the use of SSL, explain and educate, provide assistance and take down
> the financial barriers by providing part of our services for free. And which
> effort are you doing?

I understand why you felt slighted and why you might want to set the record straight, but I don't think it helps for CAs and the Mozilla Contributors to start beating their chests about who has done more for the internet community. You wanted to air a grievance, fine, but let's get back to trying to solve the problem.
Grievance? Not really, rather a state of shock! What have you done to "my" Firefox and "my" certificates? And I admit being guilty of having a special style ;m-)

Just for the record, part of my comment wasn't pointed at you - I know about you enough and besides that have supported most efforts of yours (also publicly and not only here at Mozilla). And I'm glad that you see a need for fixing it.

I'm not sure if the module owners have this thought through enough, but settings browser.identity.ssl_domain_display to 1 would be acceptable (even if it's initially only on Linux). This solution is indeed a little bit dominant, but it hasn't grown on my turf - I merely taking it because it exists. Also scores of blog posts and news sites have shown exactly those images and not the ugly ones which exist now in this RC. 

Not sure what you and Kai can cook up, but something has to be done IMO.

(In reply to comment #26)
> but something has to be done IMO.
>

A simple increase of the button's padding to make it wider should help with the problem, I think.  I don't have a Linux box to play with (my Linux VPC is way too old to run Fx3, and I keep putting off updating it), so I don't know how much of an increase would be appropriate and would look good.  There is 50% more blue to the left and right of the favicon in Windows than in Linux--6px vs 4px--so maybe that's a good value to shoot for?  Or maybe even more than that, to compensate for the lack of a distinct button-like styling?
(In reply to comment #26)
> Grievance? Not really, rather a state of shock! What have you done to "my"
> Firefox and "my" certificates? And I admit being guilty of having a special
> style ;m-)

No, its not a special style.  It was an angry rant with a unhealthy dose of arrogance.  No one has the right to act out like that in Bugzilla, please reread the Bugzilla etiquette doc before doing that again.  I'll let you have a warning this time, but Bugzilla admins have a fairly low tolerance for behaviour of that sort.

> I'm not sure if the module owners have this thought through enough, but
> settings browser.identity.ssl_domain_display to 1 would be acceptable (even if
> it's initially only on Linux). This solution is indeed a little bit dominant,
> but it hasn't grown on my turf - I merely taking it because it exists. Also
> scores of blog posts and news sites have shown exactly those images and not the
> ugly ones which exist now in this RC. 

We've thought it through more than enough, whether you believe that is up to you.  None of the options are ideal, but I think there's plenty of evidence that users either ignore SSL indicators, or interpret them improperly.  I also think that the right answer demands some degree of nuance, as not all SSL validation is created equal.

> Not sure what you and Kai can cook up, but something has to be done IMO.

I think I disagree that Something Must Be Done on this issue.  There's no data that the old UI was well understood (and in fact, there's studies showing that it was either meaningless or harmful) so other than "we used to make a clear visual distinction, now we don't" I don't see an argument here.  That isn't to say we shouldn't try to do better, but the evidence is lacking that it would make a real-world difference, which doesn't help to promote a sense of urgency here.

As for SSL's value, SSL is better than no SSL, but there's a lot of ways to abuse low-validation SSL certs, so I'm very wary of over-promoting it as anything other than an anti-eavesdropping technology.  Based on the data I have in hand, I don't see this as dangerous for users, except for having the same shortcomings as basically every non-EV SSL UI we've had in the 14 year history of browsers.
During the last few years I had a yellow bar to look at (besides the somewhat useless padlock). Now I've got nothing besides that: attachment 321422 [details]
If you think that's about the same as we had in FF2, fine...not arguing anymore. I understand that your claims and arguments are better than mine. I also understand that statements as in comment 10 and comment 12 are fine too (which was probably based on fact studies and thorough research and I'm talking utter nonsense).
 
Please also re-read my post where I explicitly stated for what DV and otherwise validated certs are good for. And this makes up the bulk of secured web sites (not in volume of trading, but in volume of secured sites, speak sites owners - get the Netcraft SSL report for reference). Nobody is going to buy EV for mail, blog, forum, bugzilla, wiki etc. sites and it doesn't make sense either. Yes, it's about eaves-dropping, but of course I'm wrong that such sites should be distinguished between plain text.

(In reply to comment #28)
> No, its not a special style.  It was an angry rant with a unhealthy dose of
> arrogance.

My job is running a CA (amongst other things) and yours is making a browser. What would you say if we'd turn tables and from tomorrow on, no secured site will be recognized as such in your browser and your users can't distinguish between plain and SSL anymore? That's about how I see it.

I made a point with this post, I didn't used any bad language nor did I call names! I replied mostly to what people wrote here. And I asked critical questions to what was said previously. Feel free to point me to any statement I made in this post which isn't appropriate and I'll correct and apologize.
Just tell me we still have the lock icon for DV/OV on all platforms, and that 
web sites can't spoof it, whereever it is (e.g. no fake status bar is allowded, 
if that's where it is) and I'll be happy WRT DV/OV.
One suggestion could be to feature a small Larry icon in front of the favicon icon. This could be maintained for all states (plain, ssl, ev, warning, error) and all platforms and would:

1.) be a central and prominent indicator
2.) invite users to click on *
3.) help distinguish between the different states
4.) be consistent and compatible with the identity indicator
5.) provide an alternative to the padlock **
6.) inform about the state of the current page without the need to look further


* It isn't at all clear for most users from what I've seen at comments at news sites and blogs. The Favicon was (and still) is used to create a link for this page by dragging. Not sure who expects more information by clicking on the favicon which changes from site to site.

** The padlock isn't shown anywhere when the status bar isn't displayed. It is legitimate to open pages via Javascript without it and users can opt to browse without the status bar.
Alternatively the Larry icon could be displayed at the end of the address bar where the bookmark star and other icons also appear. Or set such a Larry icon in front of the address bar. This would make it much harder to spoof (same as having it at the end of the address bar). Perhaps one of the two would be a better idea than having it next to the favicon icon.
(In reply to comment #32)
> Alternatively the Larry icon could be displayed at the end of the address bar
> where the bookmark star and other icons also appear.
> 

Bug 431495
Apparently others have thought about the same thing. Could we say that bug 431495
 is a duplicate of this one or the other way around? I find it incredible difficult to have lots of bugs (not even talking about finding them) all of them saying about the same thing...

Perhaps create a umbrella bug for the ones covering all this at one central location?
Depends on: 431495
It's surprising that there's no action on this design flaw.  There's a good summary from Peter Gutmann here:

http://www.mail-archive.com/cryptography@metzdowd.com/msg09795.html

Personal opinions:
1) The distinction made between ordinary and EV certs seems unjustified.  Seems strange to provide a positive security indicator for EV certs (a "green bar") but treat ordinary SSL the same as plain unencrypted HTTP (as far as address bar background).  The faith placed in EV certs seems misplaced.
2) Eliminating the unspoofable SSL indicator (padlock icon) and replacing it with a spoofable indicator (border around favicon) seems like a step backwards.

My recommendation: Some FF developer with an understanding of usable security ought to take another look at this bug and consider re-prioritizing it.
I'm curious about some of these comments:  #10, DV certs mean confidentiality;
DV to be "de-emphasised", #12 encryption not to do with security?, #16 OV certs
may have a meaning but it is not actionable?, #17 ????, #19 we avoid a mishmash
of DV/OV?

Can someone point me to a policy document or a Mozilla decision where these
things have been laid out?

As an interested party (I audit a CA), I am somewhat interested in any
potential decision made by Mozilla here.  The audit is done to criteria, and
the criteria are specifically written to check various claims to users --
Mozilla users.  Nowhere in the criteria does it say "browser chooses meanings
for certificates..."

As an aside, it is not clear in PKI terms that the browser makes the decision
as to what the relative merits of a certificate are;  this is primarily a
question for the CPS, the CA and the relying party.  It is for this fundamental
reason that (in the absence of easy-to-read CPSs) the essential component
offered by the browser, beyond crypto-blah-blah, is to state what the CA's name
is.

That all said;  we've all been here before, we all know the flaws that make any
and all of these propositions problematic.  So we can argue, etc.

However:  people are working **** a playing field with a set of rules.  If
the rules are changing, where are these rules written?
(In reply to comment #35)
> It's surprising that there's no action on this design flaw.  There's a good
> summary from Peter Gutmann here:
> 
> http://www.mail-archive.com/cryptography@metzdowd.com/msg09795.html
> 
> Personal opinions:
> 1) The distinction made between ordinary and EV certs seems unjustified.  Seems
> strange to provide a positive security indicator for EV certs (a "green bar")
> but treat ordinary SSL the same as plain unencrypted HTTP (as far as address
> bar background).  The faith placed in EV certs seems misplaced.
> 2) Eliminating the unspoofable SSL indicator (padlock icon) and replacing it
> with a spoofable indicator (border around favicon) seems like a step backwards.
> 
> My recommendation: Some FF developer with an understanding of usable security
> ought to take another look at this bug and consider re-prioritizing it.

As you have no doubt anticipated, there is an extensive amount of history on both of the issues you mention. I'm reasonably certain it will not benefit us all to rehash it again.  I have sent email to professor Gutmann, I suspect he and I are not far off of agreement here, given the content of his posting, but in the meantime, those who might imagine these decisions were taken without consideration are encouraged to read bug 414627 again.

It is not a question of prioritization, the code is simple - it is a question of reaching some level of agreement on the correct thing to which to move.
Johnathan, what means "he and I are not far off of agreement"?
(In reply to comment #37)
> As you have no doubt anticipated, there is an extensive amount of history on
> both of the issues you mention. I'm reasonably certain it will not benefit us
> all to rehash it again.  [...]
> in the meantime, those who might imagine these decisions were taken without
> consideration are encouraged to read bug 414627 again.

OK, I've read bug 414627.  Thanks for pointing me to that discussion.  Sorry I missed it -- that was my fault.

OK, fine, this is hard stuff.  Sorry if I'm wasting your time bringing up things you already know.

Regarding rehashing old discussions: As I read bug 414627, there was a lot of analysis and developer energy put into looking for something better, but everyone ran out of time and ran into the deadline to ship FF3, and that cut off the discussions.  I completely understand the need to make a decision, any decision, when deadlines loom.  At the same time, just to be clear, I see no reason to defer too strongly to prior decisions when those decisions were made primarily on the basis of deadline pressure.

Regarding blue background: Was there discussion on bug 414627 that the blue-background favicon is spoofable?  If so, I apologize for missing it (it was a long thread).  It still seems to me like a flaw that a security indicator is spoofable; arguably, a spoofable security indicator is more dangerous than none at all.  But if you say this is not a flaw, OK, that's your call.  My apologies if I've wasted your time.
(In reply to comment #39)
> Regarding blue background: Was there discussion on bug 414627 that the
> blue-background favicon is spoofable?  If so, I apologize for missing it (it
> was a long thread).  It still seems to me like a flaw that a security indicator
> is spoofable; arguably, a spoofable security indicator is more dangerous than
> none at all.

Especially since it is simple to make it non-spoofable.  Just change the default value of browser.identity.ssl_domain_display to 1.

For some odd reason there seems to be a great amount of resistance to making this change.
browser.identity.ssl_domain_display = 1 is great and helps a lot during hectic and daily work with the browser, I recognize that it's secured without actually needing to concentrate on it. The yellow bar in FF2 had a similar effect when one knew on which site you landed, the address gave the right indicator quickly. It becomes kind of a second nature...
(In reply to comment #39)
> (In reply to comment #37)
> > As you have no doubt anticipated, there is an extensive amount of history on
> > both of the issues you mention. I'm reasonably certain it will not benefit us
> > all to rehash it again.  [...]
> > in the meantime, those who might imagine these decisions were taken without
> > consideration are encouraged to read bug 414627 again.
> 
> OK, I've read bug 414627.  Thanks for pointing me to that discussion.  Sorry I
> missed it -- that was my fault.
> 
> OK, fine, this is hard stuff.  Sorry if I'm wasting your time bringing up
> things you already know.

I don't want to give you the impression that I don't appreciate your interest in finding a better solution, I share it.  Having seen the bug though, I'm sure you can appreciate how little any of us want to do it all again.  :)

> Regarding rehashing old discussions: As I read bug 414627, there was a lot of
> analysis and developer energy put into looking for something better, but
> everyone ran out of time and ran into the deadline to ship FF3, and that cut
> off the discussions.  I completely understand the need to make a decision, any
> decision, when deadlines loom.  At the same time, just to be clear, I see no
> reason to defer too strongly to prior decisions when those decisions were made
> primarily on the basis of deadline pressure.

I agree.


(In reply to comment #38)
> Johnathan, what means "he and I are not far off of agreement"?

I don't presume to speak for him in any way, but his concerns with the state we reached in Firefox 3 echo my own (and, I suspect, yours as well Eddy).  The expression is meant to suggest as much - that we are saying the same kind of things in different ways; at least as I understand his post.  I have written to ask him for elaboration on a few points, since he is someone else who thinks a lot about these things.
Thanks for clarifying. Yes, I think that also you agreed somewhere at sometime that 2 pixels around the site icon isn't really a good way to distinguish SSL sites. Can't recall now where it was, but feel free to correct me.

FF3 is great - only the core issue of this bug should be corrected IMO (not how prominent SSL is displayed, but that it's displayed in a thoughtful way which isn't easy spoofable).
Whiteboard: [sg:want]
This is fixed/wfm by bug 480357, right? Personally I'd prefer we also changed the background color behind the URL, but it's no longer just a couple of pixels of blue as in the original complaint here.
Depends on: 480357
Yes it was.  Marking fixed by 480357.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: