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
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
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
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
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
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
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
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
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
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 regardless of the techniques use to vet an enrollment every CA with
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
-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
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
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: 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
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: snip 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
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
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: sbip 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. snip 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 answer this is to ask how much the
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
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
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
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 background is white - site domain
