Re: Strawman proposal for SSL UI changes
Ian G wrote: It's an americanism as far as I know. You sometimes see it in the Caribbean, but that would be a sign that they were trying to appeal to americans, which is actually a red flag (probably a scam). I was making the general point - company names are not unique, and CAs don't attempt to enforce uniqueness. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ian G <[EMAIL PROTECTED]> writes: >In Firefox 1.0, when the SSL connection is established >without any problems, Firefox puts the domain name from >the cert in the bottom right of the status bar (great!). Having grumbled previously about UI issues, I must say that that's a nice feature to have. As Ian says, more, more! Peter. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: > Ram A M wrote: > > 1 One vector site-spoof attacks rely on is hiding the true domain name. > > True - so users should make sure they are certain of the true domain > before interacting with a site. If they can't be sure, they shouldn't > interact with it. > > Currently, of course, if the connection isn't over SSL, _we_ can't be > sure that they are connected to a particular domain. And if the browser > can't be sure, the user certainly can't. Fair point. Do you think that regular old homoglyph attacks are so easy that it's not worth eliminating this type? I'd rather see users trained to only trust high risk activities to TLS bound connections but incremental progress is still progress. The confusion point you make below may very well outweight the perhaps slight benefits this change would bring. > > How about if the address bar by default showsonly the domain-name and > > the user can change that to be the current behavior. Further the domain > > name only appears in the status-bar when TLS is in use and the domain > > name of the site is in the certificate? > > While we might do the address bar differently if we were starting > browser design again, I think I can fairly safely say that changing the > way it works now is a non-starter from a usability point of view. It > would be too confusing for users. I would love to see data on this. I think the majority of non-expert browser users consider the address bar useful primarily for entering domain names and secondarily useful for checking where they're at. The first is reasonable the second is riskier under the current model than it needs to be. I know better than to glance at the address bar and draw conclusions (I scroll left and right to be sure it says what it looks like - or if it's TLS bound I have even better options). > > Showing the name of the company may. Showing > > "firstbankofsomewhere.sometld" is not as reliable as showing "First > > Bank of Somewhere" as the organization name. > > I note your example includes a geographical location; not many business > names do. How many "First Banks" are there around the world? I think it holds either way, consider "Bank Cial" who controls some but not all of: "bankcial.ch", "cialbank.ch", "bankcial.com", "cialbank.com", "cial.ch". ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ian G wrote: Gervase Markham wrote: Ram A M wrote: Showing the name of the company may. Showing "firstbankofsomewhere.sometld" is not as reliable as showing "First Bank of Somewhere" as the organization name. I note your example includes a geographical location; not many business names do. How many "First Banks" are there around the world? It's an americanism as far as I know. You sometimes see it in the Caribbean, but that would be a sign that they were trying to appeal to americans, which is actually a red flag (probably a scam). There's First National Realestate in Australia, while not being a bank, I'm guessing it's not that unique either... ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: Ram A M wrote: Showing the name of the company may. Showing "firstbankofsomewhere.sometld" is not as reliable as showing "First Bank of Somewhere" as the organization name. I note your example includes a geographical location; not many business names do. How many "First Banks" are there around the world? It's an americanism as far as I know. You sometimes see it in the Caribbean, but that would be a sign that they were trying to appeal to americans, which is actually a red flag (probably a scam). iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ram A M wrote: 1 One vector site-spoof attacks rely on is hiding the true domain name. True - so users should make sure they are certain of the true domain before interacting with a site. If they can't be sure, they shouldn't interact with it. Currently, of course, if the connection isn't over SSL, _we_ can't be sure that they are connected to a particular domain. And if the browser can't be sure, the user certainly can't. How about if the address bar by default showsonly the domain-name and the user can change that to be the current behavior. Further the domain name only appears in the status-bar when TLS is in use and the domain name of the site is in the certificate? While we might do the address bar differently if we were starting browser design again, I think I can fairly safely say that changing the way it works now is a non-starter from a usability point of view. It would be too confusing for users. Regardingthe value of showing the organization name and country. I say it's hard to know if "subbrand.sometld" is really owned and operated by "mega-product company." Showing the domain name to the user does not address this. That's the first good argument I've heard for this change. :-) Showing the name of the company may. Showing "firstbankofsomewhere.sometld" is not as reliable as showing "First Bank of Somewhere" as the organization name. I note your example includes a geographical location; not many business names do. How many "First Banks" are there around the world? This is especially true when certificates are issued to enrollees who demonstrate control of a domain at most. We need to deal with that particular issue a different way, IMO. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Regarding the domain indicator - I assume you mean the one that appears adjacent to the padlock. I think that's great. However I'll give you two reasons to allways display the the domain name. 1 One vector site-spoof attacks rely on is hiding the true domain name. 2 How many users look at the address bar all loaded up and say - umm yeah I'm not a programmer, why are they showing me this nonsense. If screen-space is so valuable (AND IT IS!!) then we might as well get rid of stuff that doesn't help people, at least in the default setting. How about if the address bar by default showsonly the domain-name and the user can change that to be the current behavior. Further the domain name only appears in the status-bar when TLS is in use and the domain name of the site is in the certificate? Regardingthe value of showing the organization name and country. I say it's hard to know if "subbrand.sometld" is really owned and operated by "mega-product company." Showing the domain name to the user does not address this. Showing the name of the company may. Showing "firstbankofsomewhere.sometld" is not as reliable as showing "First Bank of Somewhere" as the organization name. This is especially true when certificates are issued to enrollees who demonstrate control of a domain at most. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Benjamin D. Smedberg wrote: Gervase Markham wrote: The chances of this sort of change to the address bar are near-zero. But have you seen the new domain indicator in Firefox 1.0 and above? What new domain indicator? In Firefox 1.0, when the SSL connection is established without any problems, Firefox puts the domain name from the cert in the bottom right of the status bar (great!). It also colours the URL bar at the top yellow (nice!). It's a great start. (more! more!) As an example of great experimentation the Firefox guys also added another padlock inside the the URL bar on the right hand side. Unfortunately, by means of a cunning technology called favicons, one can also have ones own padlock on the left hand side: http://www.pgp.com/ But every little experiment helps! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: The chances of this sort of change to the address bar are near-zero. But have you seen the new domain indicator in Firefox 1.0 and above? What new domain indicator? --BDS ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ram A M wrote: Agree. To repeat a comment I made in another thread, I think the default address bar should not list pre-protocol-specifier items (username/password@) nor post host-name data (/foo/bar/some.jsp), an option should be to change back to the currently popular model of showing the full gory bits. The chances of this sort of change to the address bar are near-zero. But have you seen the new domain indicator in Firefox 1.0 and above? * Retain the current "normal case" SSL/TLS Firefox UI: - display locked padlock in status bar - location bar background is yellow - site domain name from certificate is displayed in status bar Again I say show the certificate subjectDN (organization, country..) and the basic domain name not the full address bar, these are valuable. Why do you think they are valuable, given that we already display the domain name, which is unique? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: Gervase Markham wrote: On a related point, can we perhaps use this new high/low assurance bit Uh, what new high/low assurance bit? Has someone already committed to implement this, and we've agreed to take the patch? :-) You know what I mean :-) If we have a new high/low assurance bit... 1. A number of "high assurance" CAs do not have OCSP set up. In doing my CA list at http://www.hecker.org/mozilla/ca-certificate-list (which covers only new CAs applying for inclusion) I tried to track down information on CA's OCSP services; as you'll note, it's not that common. However providing CRLs is almost universal, but... OK... so could we stipulate OSCP or CRLs? 2. Neither Firebird nor Thunderbird have CRL checking (let alone OCSP validation) turned on by default; it must be manually enabled by users (e.g., by clicking on a link to a CRL -- try one of the ones on the page referenced above). This is a big product gap that needs to be filled, e.g., by recruiting some more NSS/PSM developers. Sure. Although one could argue that the fact that we don't take advantage of it yet is no reason not to stipulate it... Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
A quick point, the idea of including a statement of relying party warranty has great potential. A cert extension in EE, chain, or root certificates could include a numeric value. There is some work to be done in terms of standardization (actually IIRC I saw a post indicating this work is done, underway, or imminent). There are issues around currency - it could be specified in Euros, US Dollars, Gold weight or others, there are probably at least a few conventions that would suffice (probably not a currency that is prone to heavy devaluation). ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Great job Frank. Frank Hecker wrote: > Briefly, the motivations behind this proposal are as follows: I like the foundation. > Without further ado, here's the proposal: > > * Retain the current Firefox UI when SSL/TLS is not used: > >- no padlock or other SSL/TLS-related indicator in status bar >- location bar background is white >- site domain name is *not* displayed in the status bar Agree. To repeat a comment I made in another thread, I think the default address bar should not list pre-protocol-specifier items (username/password@) nor post host-name data (/foo/bar/some.jsp), an option should be to change back to the currently popular model of showing the full gory bits. > * Retain the current "normal case" SSL/TLS Firefox UI: > >- display locked padlock in status bar >- location bar background is yellow >- site domain name from certificate is displayed in status bar Again I say show the certificate subjectDN (organization, country..) and the basic domain name not the full address bar, these are valuable. I like the dispaly of authenticated domain-names in the status bar (ie if they come from a cert at the site). For the rest of the UI variations I need to give it a lot more thought than I have time for at the moment. Mock-ups would probably make a big difference in conveying the ideas (I'm not asking for them, but I'm not likely to make them either). > Some follow-on comments: > * The UI for SSL/TLS with low-assurance certs should be similar but not > identical to that for high-assurance certs. I don't have a strong sense of what the right feedback mechanism should be. But some things to consider feedback for, some of which you address (and most not in the terms presented in the list): =MoFo policy "high assurance" =MoFo policy "low assurance" =MoFo policy "no assurance" =Unknown issuer =Entity name authenticated =Domain name authenticated =Certificate is revoked (perhaps revoked should never be accepted without going through a deep options menu) =Certificate is expired (note that CAs may not offer revocation checking for expired certificates, either by purning CRLs or by refusing OCSP service) =Certificate domain-name matches DNS domain-name =Number of visits to site (the problem here is this wil sometimes unduly scare the user - consider how many dns names WFB uses for their service) > * This proposal in a sense "breaks" existing sites using low-assurance > certs, since users of those sites will no longer see the padlock. To > ease in the transition, it may be appropriate to put up a warning dialog > or informational message the very first time the browser encounters a > low-assurance cert, so that the user will be informed about what is > going on and will (we hope) be less confused when they see the checkmark > instead of the padlock. I like this model many users are completly new users and giving them these kinds of tidbits goes a long way to educating them - few will read a dummy's guide. There should be at least such a pop-up for every note-worthy new event (first high assurance, first low assurance, first domainname mismatch, first unknown CA, first revoked, first expired, change of CA for known site (possible DNS attack). > * In the case of a self-signed cert or cert from an unknown CA, Firefox > should *not* offer users the opportunity to accept the certificate or > the certificate's issuing CA as "trusted", at least not from the > immediately visible UI. This seems a necessarily compromise to avoid the 'click through everything' behavior the user seems to have today. > * In the case of a cert from a known CA but with an non-matching domain > name, the warning dialog should be displayed at least once per browser > session, without the possibility of turning it off permanently for that > site. If an informational message is displayed in this case, then > perhaps its dropdown menu can contain an option to not display the > informational message in the future for not matching domain names > (similar to the option for self-signed certs or unknown CAs); in this > case the UI indicators would remain the same, except for an "X" mark > replacing the "exclamation mark in circle" accompanying the original > informational message. This may be a bit complicated but I don't have a better suggestion off hand. > (I don't think it makes sense to not display a status bar indicator at > all after dismissing the information message, and to treat this case the > same as a non-SSL site. There really is something wrong with the site -- > it's either misconfigured or is using a stolen key and cert -- and the > UI should reflect that.) Agree. > * A "high assurance" certificate can be defined at a high level as "a > certificate issued only after some level of human review of the cert > subscriber", whereas a "low assurance" certificate might be issued > through an automated process, I suggest the inclusion of technical robustness criteria as well. Consider that
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: On a related point, can we perhaps use this new high/low assurance bit Uh, what new high/low assurance bit? Has someone already committed to implement this, and we've agreed to take the patch? :-) in the cert store as something to hang cert revocation off? If you want to be in the high assurance store, you have to have a working OCSP server defined in your certs, or something like that? Two points: 1. A number of "high assurance" CAs do not have OCSP set up. In doing my CA list at http://www.hecker.org/mozilla/ca-certificate-list (which covers only new CAs applying for inclusion) I tried to track down information on CA's OCSP services; as you'll note, it's not that common. However providing CRLs is almost universal, but... 2. Neither Firebird nor Thunderbird have CRL checking (let alone OCSP validation) turned on by default; it must be manually enabled by users (e.g., by clicking on a link to a CRL -- try one of the ones on the page referenced above). This is a big product gap that needs to be filled, e.g., by recruiting some more NSS/PSM developers. Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: On a related point, can we perhaps use this new high/low assurance bit in the cert store as something to hang cert revocation off? If you want to be in the high assurance store, you have to have a working OCSP server defined in your certs, or something like that? That would be to impact the definition of "high" assurance with the policy aspects of getting OCSP going. Until OCSP is up and going and shown to be a really good idea, it is not a good idea to link it to another area of uncertainty. The unintended consequences of that might actually make either of "high" assurance or OCSP more difficult to get going. If one wanted to signal that OCSP was correlated to "high" assurance, maybe the notion is to put another little icon on the status bar that said "OCSP in action." Then, as time goes on, we could see if that became a good signal of quality or not? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
On a related point, can we perhaps use this new high/low assurance bit in the cert store as something to hang cert revocation off? If you want to be in the high assurance store, you have to have a working OCSP server defined in your certs, or something like that? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Peter Gutmann wrote: "Location bar is something more noticeable than yellow". Have you ever looked at the pastelly-white vs. pale-yellow location bar on a laptop LCD screen in bright room light or outdoors? The two are virtually indistinguishable. I've seen older laptops with either poor-to-begin-with or faded-over-time LCDs where you can't actually tell the difference between the two colours. This is a valid point. I guess alternatives would include a different color and/or some sort of patterned background to further increase the contrast. Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 HJ wrote: |> 2) Some important sites are not using SSL for their login pages - Yahoo |> apparently being one. | | | I have a Yahoo e-mail account, and that uses SSL for logins. | Are you talking about the free Yahoo webmail or paid Yahoo e-mail accounts? | I recently had occasion to traipse through Yahoo!'s login process - it's actually rather neat: if you choose the non-default "Secure" login then you're connected via SSL as expected. If you take the default "Standard" login route, it then checks to see if your browser supports Javascript and has it enabled then it generates a password hash for login. If you have Javascript disabled, etc., then it *falls back* to the "Secure" login. Rather slick! I think their "Standard" login description is a bit of a misnomer in this case. - -- Cheers! J. Wren Hunt Cambridge, MA. USA - "In theory, there is no difference between theory and practice. But, in practice, there is." - Jan L.A. van de Snepscheut +--+ | v-card http://wrenhunt.homelinux.org/data/wren.vcf | | x.509http://wrenhunt.homelinux.org/data/thawte_wren_hunt.cer | | OpenPGP ADF5 1432 A59E 8F4D 4AE7 4DFE 03FA 91E1 4A24 D6F4 | +--+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1rc2 (Darwin) iD8DBQFCODOAA/qR4Uok1vQRAwEIAJ0WoiaDwl40ByQhvhK49wuBLNfb5gCg3c3W NcKXJO/IoRADrUCuakz0UO0= =Yudv -END PGP SIGNATURE- ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker <[EMAIL PROTECTED]> writes: >* Retain the current Firefox UI when SSL/TLS is not used: > - location bar background is white >* Retain the current "normal case" SSL/TLS Firefox UI: > - location bar background is yellow "Location bar is something more noticeable than yellow". Have you ever looked at the pastelly-white vs. pale-yellow location bar on a laptop LCD screen in bright room light or outdoors? The two are virtually indistinguishable. I've seen older laptops with either poor-to-begin-with or faded-over-time LCDs where you can't actually tell the difference between the two colours. Peter. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: HJ wrote: I have a Yahoo e-mail account, and that uses SSL for logins. Are you talking about the free Yahoo webmail or paid Yahoo e-mail accounts? This was Dan's example; and I think he meant the login page was unencrypted but submitted to an encrypted target. Amazon does this also, I've noticed. Yep, correct, which is probably done to save server resources. 2) We need a way to brand every browser window so that it can't be confused with an OS window. Just the status bar - a featureless grey blob - doesn't really do that. Having the domain makes it clear. There is, or should be, (for now) that Mozilla Firefox icon (at least on Windows) at the upper left corner of the window (I don't have a clue what the official for it is). Hmm, well, maybe. It's not really enough, though. Fair enough, but it might help, at least for now. ps s/official/official name Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
HJ wrote: I have a Yahoo e-mail account, and that uses SSL for logins. Are you talking about the free Yahoo webmail or paid Yahoo e-mail accounts? This was Dan's example; and I think he meant the login page was unencrypted but submitted to an encrypted target. Amazon does this also, I've noticed. 2) We need a way to brand every browser window so that it can't be confused with an OS window. Just the status bar - a featureless grey blob - doesn't really do that. Having the domain makes it clear. There is, or should be, (for now) that Mozilla Firefox icon (at least on Windows) at the upper left corner of the window (I don't have a clue what the official for it is). Hmm, well, maybe. It's not really enough, though. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: Frank Hecker wrote: What's your and Dan's motivation for doing that? Because the domain name as displayed in the address bar may be misleading (e.g., by people doing tricks to spoof the name as displayed)? There were several reasons behind the decision. There is discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=262366 . Basically: 1) Most phishers are currently not using SSL, and people are left parsing complex URLs in the URL bar. 2) Some important sites are not using SSL for their login pages - Yahoo apparently being one. I have a Yahoo e-mail account, and that uses SSL for logins. Are you talking about the free Yahoo webmail or paid Yahoo e-mail accounts? 2) We need a way to brand every browser window so that it can't be confused with an OS window. Just the status bar - a featureless grey blob - doesn't really do that. Having the domain makes it clear. There is, or should be, (for now) that Mozilla Firefox icon (at least on Windows) at the upper left corner of the window (I don't have a clue what the official for it is). I'm still not really convinced it's a good idea, but the real reason I agreed to it, though, was that otherwise Dan was threatening to port his Firefox 1.0.1 patch which puts the URL in the _title_ bar on popups (as IE now does) over to the trunk. :-) And I figured that if we were determined to display the domain somewhere on insecure popups, at least we should: - be consistent - keep security UI to the status bar, without letting it creep everywhere - avoid the problems IE has with their title bar implementation. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: What's your and Dan's motivation for doing that? Because the domain name as displayed in the address bar may be misleading (e.g., by people doing tricks to spoof the name as displayed)? There were several reasons behind the decision. There is discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=262366 . Basically: 1) Most phishers are currently not using SSL, and people are left parsing complex URLs in the URL bar. 2) Some important sites are not using SSL for their login pages - Yahoo apparently being one. 2) We need a way to brand every browser window so that it can't be confused with an OS window. Just the status bar - a featureless grey blob - doesn't really do that. Having the domain makes it clear. I'm still not really convinced it's a good idea, but the real reason I agreed to it, though, was that otherwise Dan was threatening to port his Firefox 1.0.1 patch which puts the URL in the _title_ bar on popups (as IE now does) over to the trunk. :-) And I figured that if we were determined to display the domain somewhere on insecure popups, at least we should: - be consistent - keep security UI to the status bar, without letting it creep everywhere - avoid the problems IE has with their title bar implementation. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: Er... a slight snag here is that dveditz and I just agreed that we would start displaying domain names on non-secure sites. What's your and Dan's motivation for doing that? Because the domain name as displayed in the address bar may be misleading (e.g., by people doing tricks to spoof the name as displayed)? Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Gervase Markham wrote: Frank Hecker wrote: 5. Discourage typical users from modifying the default list of "trusted" CAs and certificates, in particular by adding new site or CA certs as warning dialogs pop up. I'm not sure I understand this sentence. I meant the following: Right now when you connect to a site that presents a self-signed SSL cert, or an SSL cert issued by a CA not currently in the Firefox/NSS default list (or in the list, but with SSL "trust bit" set to "no"), the user is presented with a warning dialog that (among other things) offers them the option to "trust" the site cert and/or the CA cert on a permanent basis. This in turn causes at least some end users to modify the default cert list simply in order to get past the warning dialog and get on with viewing the page. (The user could also cancel the connection or accept the cert only for the current session, of course, but I suspect a significant percentage of people actually accept the site or CA cert permanently.) I believe that we should discourage such behavior, by removing the warning dialog entirely. Instead Firefox should simply display the web page in question without popping up a dialog, with some UI indicator to indicate that the page was not retrieved via a "normal" SSL connection. (For example, I suggested displaying a question mark instead of a padlock, and not changing the address bar background at all.) If the user then wants to actually "trust" the site or CA cert they could do so in some other way, e.g., through a menu item on an informational message dropdown, or through FF preferences, or whatever. But making such a decision would be optional, not forced through use of a modal dialog. Note that this issue is entirely separate from the issue of using different UI for "low asurance" vs. "high assurance" certs, and IMO should be considered no matter what people decide om the latter issue. Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: 2. Acknowledge the typical user's expectation that the display of a padlock is something associated primarily with e-commerce or financial sites, and basically means "it's safe for you to enter sensitive financial or other personal information on this page". I'd concur that this is what users who notice the padlock at all expect it to mean. 5. Discourage typical users from modifying the default list of "trusted" CAs and certificates, in particular by adding new site or CA certs as warning dialogs pop up. I'm not sure I understand this sentence. Without further ado, here's the proposal: * Retain the current Firefox UI when SSL/TLS is not used: - no padlock or other SSL/TLS-related indicator in status bar - location bar background is white - site domain name is *not* displayed in the status bar Er... a slight snag here is that dveditz and I just agreed that we would start displaying domain names on non-secure sites. But that's not set in stone. I've invited him over here to participate. Having read your proposal, I think I'm going to do some "thinking out loud". We want to clearly indicate the following information, all of which is useful: 1) Can I be certain I'm connected to the domain in the URL bar? Yes/No 2) Is the connection encrypted? Yes/No 3) Can I put my CC number into this web page? Yes/No 1) could be fulfilled by a high-assurance cert, low-assurance cert, self-signed cert or Secure DNS. 2) could be fulfilled by any sort of cert, and is a subset of 1). 3) is a subset of 2), and is fulfilled when there is a high-assurance cert. If this is true, then it's just a matter of determining the UI. Here's one suggestion: We have a tick for "domain name verified" (case 1) We have the yellow background for "encrypted" (case 2) We have the lock (instead of the tick) for "CC-safe" (case 3) My only concern with this plan is that then the UI difference between cases 2 and 3 is not as visible as it could be. But it's only a plan - the real question is, is my 1/2/3 division correct? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote re insurance related to certs:
However I think in practice this approach might be problematic, for a
variety of reasons. First, CAs have much fewer economic incentives to
care about relying parties (who aren't actually their customers) than
they do about subscribers (who are the ones paying them). Second, even
assuming that the cost of getting sued by relying parties is such an
economic incentive, it's quite possible that lawyers for CAs would be
easily able to blunt the impact of such suits, e.g., by pointing to
contributory negligence on the part of the relying party and/or escape
hatches for the CA. ("You didn't view the certificate details and look
at the certificate policy governing the certificate?" "You didn't read
the relying party agreement, particularly the limitation of liability
section?" And so on.)
One very quick comment: The point I was trying to make here is that I
think it's unlikely that relying parties who got phished would actually
be able to recover damages from CAs, which causes problems for a
market-based approach involving insurance. Similar reasons to those
holding back Bruce Schneier's idea of improving the security of software
via holding software vendors liable (with insurers then prodding vendors
to clean up their act) -- the s/w vendors today have little or no
(legal) reason to care, and no one in a position to do so (e.g.,
government) is forcing them to care.
Till later,
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ian G wrote: Now for MAJOR point #2. What is the definition of "assurance" ? And what is meant by "high assurance" ? I'll apologize in advance for not addressing all your points, both in this message and your others. I have a tight time window for doing this sort of thing, and I wanted to concentrate on a couple of key points below. Frank Hecker wrote: The reason for making the "high/low" distinction depending on the presence or absence of human review is that this is directly related to the cost (in time and/or money) of doing phishing attacks that direct people to SSL-protected sites. OK, this is getting closer to a rationale of economic security. For the phisher, there is only one question, which is how much does it cost me and how much do I earn? Agreed, which is why I think realistically any notion of "assurance" has to ultimately justify itself based on economic analysis. To expand on your comments on the threat du jour represented by phishing, pharming, etc., one presumed thing we want to prevent (as I noted) is phishers getting throwaway certs for throwaway domains, and thereby being able to more convincingly impersonate "real" ecommerce and financial sites. (Note that I don't certainly don't think this is the only possible anti-phishing defense, or even necessarily the best one, but it certainly seems to be what people are concerned about in the whole series of discussions we've been having re "raising the bar" relative to CAs. Hence my interest in putting out a strawman proposal on how to do this, to make the discussion less abstract and more concrete.) Here's my attempt at a quick "back of the envelope" analysis of the economics of phishing as they relate to SSL certs (not a real analysis, but a mere sketch): "How much do I earn" could be quantified as expected "revenue" per day resulting from standing up a given phishing site at a given domain, times expected lifetime of that site at that domain (e.g., before the domain or server is taken down by others or blocked by phishing blacklists or whatever). (Expected "revenue" per day is dependent on other factors, such as the type of site being impersonated, number of phishing spam emails sent out, etc., but we'll leave all that aside for now.) "How much does it cost me" could be quantified by some formula involving the direct monetary cost of the SSL cert, related monetary costs of applying for the cert (e.g., cost of obtaining fraudulent id documents), the time required to get the cert (which equates to potential "revenue" lost from that domain that could otherwise be "earned" in the meantime), the probability of the cert application being rejected (more lost time, assuming rejection is not instant), and the probability of the phishing fraud being traced back to the actual phisher (which combined with the probability of being caught by law enforcement and convicted of something, plus the expected fines and/or jail time, equates to loss of future gains from phishing, which can then be used to calculate a net present value figure to go into the overall cost estimate). There may be other elements I haven't thought of, but these will serve as examples. Given such a calculation, we could (at least in theory) define a "high assurance" cert for our purposes as a cert whose cost to the phisher exceeds the expected "revenue" (i.e., fraudulent gain) for the domain with which the cert is associated. Whether we could make such a cost calculation in practice is of course uncertain, but I don't think it's totally out of the question given sufficient motivation to collect the data and do the calculations. The other thing I'll note here is that under this approach CAs could have wildly different attributes but still have the same resulting expected costs from the phisher's point of view. For example, one CA might sell cheaper certs (or even provide free certs) than another CA, but might require a week to issue a cert where the more expensive certs might require only a day. Or, in your example of the automated but arguably high assurance CA using smart cards, etc., the short time required to get a cert might be balanced by an increased likelihood of fraudulent applicants being detected and an increased risk of significant consequences arising from violations of national id laws. The problem then is for the defender to say "how much is this cert worth?" The relying party and the cert owner both have the same question. Now, the question is *not* totally answered by "how much does it cost?" As I described above, the cost of production of the cert is only a very weak indicator of how much it is worth. If by "cost of production" you mean marginal cost to the CA of issuing the cert (including variable costs, e.g., labor, plus amortized fixed costs) and by "how much is it worth" you mean something like my "cost to the phisher relative to expected revenue" then I'm with you, dude :-) The best way to answe
Re: Strawman proposal for SSL UI changes
Jean-Marc Desperrier wrote: A few days ago, I reached pretty similar ideas as a conclusion of the recent debatting, reinforced by remembering how valid the old SSL usability rant of Matthew Thomas was (http://mpt.phrasewise.com/2003/11/11), Great rant, but as with many rants I notice MPT didn't propose any real alternative approaches (which is why I like Ian's rants better than MPT's :-) Just a few things : - There's too many cases. Only experts are actually interested in why the site is not secure, just tell the general public that it's not, and you have to open the details windows to learn why. So below I will discuss several ways of restricting the options to a minimum. Actually I think in practice Firefox users (to the extent they're paying attention at all) pay most attention to the yellow background appearing in the location bar. (As a personal anecdote, I've been using Firefox for almost a year now and only noticed last night that -- unlike Mozilla -- Firefox does *not* display an open lock on a page not using SSL/TLS, it just shows nothing.) The yellow bar could remain a binary option, displayed only in the "high-assurance" case, with the status bar icons being secondary indicators that could be multi-state. There's quite a lot that can be debatted about the "high-assurance"/"low-assurance" distinction. It might be good to implement first the second, and allow more time to think about what we want for the first. Well Ian would say (and I can't blame him) "if you can't define low vs. high, why bother implementing a UI to show the difference?" IMO his question needs to be addressed in some manner. - "high-assurance" is something new, I'd see a new icon. I disagree. I think that in the context of the CA market and the web as it's evolved "low assurance" is the new thing, and that typical user's expectations (to the extent they have expectations at all -- some clearly don't) are that the lock means "good for e-commerce and finance". In any case, we need to limit the case as much as possible, so alternatively what I'd see is : nothing/a discreet check mark/lock. This is basically what I proposed for the "normal" cases, so I presume you're objecting only to using icons for the "unusual" cases. > Cliking the "check mark" would show the detail windows. I presume you mean double-clicking the check mark (i.e., to bring up the "Page Info" window). In Firefox a single click on the padlock does nothing, so the same should hold true for clicking on a checkmark. This said, I'd see a closed eye icon, rather than a check mark for this. Choice of icon is up for debate. I like the check mark because it's tied to the display of the domain name from the cert and whether it does or doesn't match the requested name. - About the non-matching cert name, many people misconfigure servers, it's not definitively showing an attack attempt. That's why, and also in order to limit the number of possible case, I'd just remove the warning (warning are bad, the blocked popups warning is less bad but is still bad), and display the normal GUI as if there's no encryption in that case. Removing the warning popup is OK I think, but I think there should be some indication of a problem for non-matching cert names. Otherwise we'd be displaying a domain name in the status bar, one that doesn't happen to match the one in the location bar, with no graphical indicator (like the "X" or whatever) that might serve to draw the user's attention to that fact. That's all the time I have now. I'll try to comment more this weekend sometime. Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
(I don't have time for detailed responses right now, but will try a quick one or two.) Duane wrote re discouraging users from modifying the default cert database: There was a bug on bugzilla for this and it has since been marked won't fix... https://bugzilla.mozilla.org/show_bug.cgi?id=276827 You should also have a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=267515 Note that I'm *not* in favor of totally locking users out from accepting new CA certs or server certs as valid. Rather what I would like to see us eliminate is forcing such decisions on naive users by presenting them with warning dialogs that have to be clicked through to proceed. That's why I think connecting to sites with self-signed certs or sites with certs from unknown CAs should *not* cause warning popups, but should include informational messages by which users who wanted to could get more information and the opportunity to accept new server or CA certs. Adding a new cert could be a menu item right off an informational message dropdown menu (probably more suitable for adding a self-signed server cert), or could be on a subsequent dialog box; the main point is that users wouldn't have to do anything, they could just view the page and not worry about having to answer questions they don't necessarily understand. Frank -- Frank Hecker [EMAIL PROTECTED] ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Now for MAJOR point #2. What is the definition of "assurance" ? And what is meant by "high assurance" ? Luckily Frank dives right in here below and defines "high assurance." Frank Hecker wrote: * A "high assurance" certificate can be defined at a high level as "a certificate issued only after some level of human review of the cert subscriber", whereas a "low assurance" certificate might be issued through an automated process, e.g., one that simply verifies that the cert subscriber controls the domain listed in the certificate. With a low-assurance cert we can assume there is some basic protection against certain types of phishing attacks (e.g., attacks based on DNS spoofing), but we don't necessarily want to give the user the impression that the site is in the same category as traditional e-commerce/financial sites where they've been conditioned to look for the padlock. Out of the above, I see these things: A meaning for "high assurance" certificates is: "is a traditional e-commerce/financial site." A test for "high assurance" certificates is "human review." A meaning for "low assurance" certificates is that the domain is as it says it is. A test (of sorts) is that the issuance is automated. That's a little bit strained, but might do for now. The issues then arise that actually, these definitions don't buy you enough to be worth the effort. For example, imagine I want to start selling high assurance certs for $10. If the test is human review, I simply employ nepalise school kids to do a bit of browsing and reading of faxed documents. Alternatively, imagine we live in the future world of strong identity tokens, like they do in some countries in Europe. http://www.financialcryptography.com/mt/archives/000249.html So, with a little bit of jiggery with smart card readers and so forth, I can set up a system that issues individual level certs to people who over the net plug in their smart card, sign the request and get the delivery sent to their secure email address. Not only have I got reliable chain from smart card to email delivery, I also have the law backing me up, as once signed by a smart card, it is an accepted signature and contract. Hey presto, I can set up a "high assurance" certificate delivery system and I can automate the lot. I know it is high assurance because every step along the way is high assurance, the linkages are high assurance, and the courts are high assurance. OK, so having broken the meaning and the test (sorry Frank!) why is this? Well, it relates directly to the failure to define "assurance". Unless assurance is defined, there can be no meaning to "high assurance" and no tests. Hence, although the meanings and tests can be imagined and proposed, the only thing we have to go on is gut feel. Does it feel right? As an example: "automation is too easy ... so it must be bad for high assurance, right?" Well, maybe. _The challenge then is to define assurance_. This is really tough. The obvious problem is that assurance depends on who and when we are talking about. Is it: * Lazy lina who is buying a book from amazon? * Dodgy dan who is surfing porn with his wife's credit card? * General Jim who is just sneaking back to the NSA so as to up load his night's work on the latest threats to the nation? * Teenaged Timmy who's chatting with his girlfriend and trying to score without his kid sister peaking and spoiling everything? * Crypto Che who's sending the plans for the rebel attack to the revolutionary high command? All of these contexts result in highly distinct threat scenarios. SSL "covers them all." What is high for one may be low for another, and vice versa. As we know, the imposition of the binary security model has a difficulty in the real world of browsing. In practice, it cannot find peace in any "high assurance" model, as there is no way to deliver that "high assurance" to all those people. It *can* find peace in the "low assurance" model, but only by settling on the lowest common denominator - the least protection. Which annoys everyone. Hence the demands for "high assurance" but these demands simply repeat the conundrum - how to define "high assurance" and more basically, what is assurance? Replacing a binary security model with a ternary security model does not solve the problem. It does one thing for us, which is to isolate and point fingers at the problem ... but that isn't enough to solve it. So in order to define assurance, we need something hard: The reason for making the "high/low" distinction depending on the presence or absence of human review is that this is directly related to the cost (in time and/or money) of doing phishing attacks that direct people to SSL-protected sites. Just as the low cost of domain registration allows phishers to register "throw-away" domains for their sites, evading anti-phishing defenses based on flagging URLs that contain IP addresses instead of domain
Re: Strawman proposal for SSL UI changes
OK, so MAJOR point #1: The meaning of the padlock. > 2. Acknowledge the typical user's expectation that the display of a > padlock is something associated primarily with e-commerce or financial > sites, and basically means "it's safe for you to enter sensitive > financial or other personal information on this page". I feel this is uncertain. Here are some reasons why I feel short of subscribing to this: a. There is very little documentary evidence of that meaning, or indeed of any others. b. There is widespread disagreement among communities, with the crypto side thinking it means TLS in place, and the cert sales people saying "read our CP/CPS." c. There is evidence that users ignore the padlock completely when entering sensitive info. This evidence is substantial: phishing is almost totally non-padlock based or padlock-spoofed. d. The CAs do not subscribe to that meaning, as evidenced that almost all CAs supply certs without checking 'fitness-for-purpose'. e. From security model terms, the meaning has no founding, as the value of "safe" changes from user to user and from event to event. You can't say something is safe unless you can tie it down to contexts and values. f. There is no research to confirm this as a meaning. g. The history of the padlock does not agree. When it originally started, it was a key, with one tooth for 40 bits and 2 teeth for 128 bits. This meant that it was safe from eavesdroppers, according to some cryptorebel measure. But, safety for entering personal details wasn't what the teethy folks were thinking. Then it changed to be a padlock, so we probably have to go back and ask what the padlock inventors thought it meant. I'm sure there may be others, for the case for and against. But the key point here would be that I would see it as very difficult to rely on that meaning. ( Now, it may be that Mozilla as a community says "ok, so the meaning wasn't clear, sorry about that, now we are going to make it clear, and here's what it means!" Sure, but that's a whole other ball game. ) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
OK, sounds like fun :) Following are some MINOR comments that hopefully would improve the proposal ... I'll post my two MAJOR comments under separate cover. iang Frank Hecker wrote: Prompted by some comments by Gerv Markham, the following is an strawman proposal for changing the Firefox UI relating to web pages retrieved via SSL/TLS. It was created upon waking in the middle of the night, so please feel free to treat it with extreme skepticism :-) (This is relevant to both n.p.m.security and n.p.m.crypto, so I'm cross-posting to both forums, but I'm setting followups to n.p.m.security to direct discussions to the wider audience associated with that forum.) Briefly, the motivations behind this proposal are as follows: 1. Make the SSL/TLS UI as simple as possible, but not simpler. I'm not as yet sure what you mean by the "SSL/TLS UI" ... hopefully that will become clear. (padlock? edit/prefs/privacy?) 2. Acknowledge the typical user's expectation that the display of a padlock is something associated primarily with e-commerce or financial sites, and basically means "it's safe for you to enter sensitive financial or other personal information on this page". 3. At the same time, allow for other legitimate uses of SSL/TLS beyond the traditional e-commerce/financial uses, and in particular promote wider use of SSL/TLS as a useful component of a comprehensive anti-phishing strategy. OK. (I've written on the goal of security elsewhere.) It would be desirable for Mozilla to adopt a goal of security. At the moment, it is written about but not adopted. If it were adopted, we could then identify anti-phishing as a "clear and present danger" to users and then pursue that as a danger to be addressed. Having a goal of security forces you to meet the goal. This helps because it separates out the distractions from the important tasks. In the above, "promote wider use of SSL/TLS" is a distraction. Only if it helps security should it be used, as a tool. Wider use might actually make things more insecure, if employed like a hammer on all nails in sight. Also (annoyingly) we need to differentiate between SSL, TLS, HTTPS, S/MIME, certs, PKI... in any proposal. I generally use SSL to refer to "the lot" and TLS to refer to the raw protocol, sans certs. HTTPS as TLS+certs+browsing. But others do not do that... 4. Eliminate or at least minimize SSL/TLS-related error messages and warning dialogs, particularly in cases where they are arguably not warranted based on the security risk relative to not using SSL/TLS at all. OK. 5. Discourage typical users from modifying the default list of "trusted" CAs and certificates, in particular by adding new site or CA certs as warning dialogs pop up. Discourage typical users ... Um. That I'm unsure of. The user is king, or queen in cryptoterms. It may be that the browser cannot distinguish between "user is told by boss" and "user is told by phisher" but that isn't really enough to go on in. Without further ado, here's the proposal: * Retain the current Firefox UI when SSL/TLS is not used: > - no padlock or other SSL/TLS-related indicator in status bar - location bar background is white - site domain name is *not* displayed in the status bar This I agree with. I note there is some preference to display a site domain name even without SSL, as being "this is where you ended up". If so, it should be a different colour or the like. But, I'd prefer it not to be there at all, for strategic reasons. * Retain the current "normal case" SSL/TLS Firefox UI: - display locked padlock in status bar - location bar background is yellow - site domain name from certificate is displayed in status bar *but* reserve it for the cases where the site's certificate is a "high-assurance" certificate from a known CA. (Assume, at least for now, that we have a reasonable way to decide whether a given site certificate is "high-assurance" or "low-assurance"; see also below.) OK. Hopefully we also find out what "assurance" means :-) We then add the following new SSL/TLS UI cases, for which we do *not* use the traditional "padlock" indicator in any form: * SSL/TLS connection involving a "low-assurance" certificate from a known CA: - display check mark in status bar (instead of padlock) - location bar background may or may not be yellow (this is debatable) - site domain name from cert is displayed in the status bar OK, so if we accept the assumptions (!) then I think you have this about correct. The status bar is (for me) Mozilla's security display, so it should show the domain that the cert says you got to. This is valid regardless of the assurance level, which displays something else. The yellow location bar is just another padlock for me, one that is easier to see. * SSL/TLS connection involving a self-signed certificate or a certificate from an unknown CA: option 1: - display question mark in status bar (instead of padlock) - location bar backgr
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: That pretty much completes my night-time excursion into the wonderful world of Firefox security UI discussions. Feel free to flame away. A few days ago, I reached pretty similar ideas as a conclusion of the recent debatting, reinforced by remembering how valid the old SSL usability rant of Matthew Thomas was (http://mpt.phrasewise.com/2003/11/11), but had no time to describe it in a coherent and convincing way like you just did. Just a few things : - There's too many cases. Only experts are actually interested in why the site is not secure, just tell the general public that it's not, and you have to open the details windows to learn why. So below I will discuss several ways of restricting the options to a minimum. - I see two parts in this plan. One is introducting the "high-assurance"/"low-assurance" distinction, the older is removing all warning dialogs nobody reads least understand, and reflecting the insurance in the GUI. There's quite a lot that can be debatted about the "high-assurance"/"low-assurance" distinction. It might be good to implement first the second, and allow more time to think about what we want for the first. - "high-assurance" is something new, I'd see a new icon. I think the solution is an icon representing a vault, and not a lock for "high-assurance". I think it's a symbol everyone understand the meaning of without explanation, and it means you don't need to tell some CA you removed them the 'lock' list, just that they don't meet the criterium for the new 'vault' list. We just need a good vault icon that doesn't look like something else for anybody. That way, we can keep the lock for the normal SSL case, and not change it's meaning with today. - If we take apart the "high-assurance"/"low-assurance" distinction, I'd go even further than you. I think the binary option is tempting. It's secure, fully, or it's nothing, and the GUI doesn't show anything. In any case, we need to limit the case as much as possible, so alternatively what I'd see is : nothing/a discreet check mark/lock. The discreet check mark would be something usually people would not notice, it should fail "look for the lock" (http://www.gerv.net/security/stay-safe/), but it would keep people happy who would find it unfair that any error in the checking means there is nothing in the GUI showing the communication is any different from ordinary http. Cliking the "check mark" would show the detail windows. This said, I'd see a closed eye icon, rather than a check mark for this. - About the non-matching cert name, many people misconfigure servers, it's not definitively showing an attack attempt. That's why, and also in order to limit the number of possible case, I'd just remove the warning (warning are bad, the blocked popups warning is less bad but is still bad), and display the normal GUI as if there's no encryption in that case. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: * The only way to add new CAs or server certs or to change the default "trust bits" should be through the Firefox preferences UI or (perhaps) through a detailed certificate dialog reached by selecting an item from the dropdown menu associated with an informational message (if used). (This latter option would be similar to the "Edit Popup Blocker Options" menu item displayed for the blocked popups informational message.) There was a bug on bugzilla for this and it has since been marked won't fix... https://bugzilla.mozilla.org/show_bug.cgi?id=276827 You should also have a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=267515 ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
