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
Goals, Worldviews, Policies
Nelson just posted a bug comment, but I think the response and discussion of the points he raised are too broad for that bug, so I'll move them here, if nobody minds. I have two points to make here - the reality of the CA trust decision, and the goal. [EMAIL PROTECTED] wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=286107 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 10:29 PST --- Ian's arguments are predecated on the existence of untrustworthy CAs who will issue certs falsely for domain names that are justly certified by one or more other CAs. That situation may arise someday, if we let untrustworthy CAs into the list. But that has not yet been decided, and is not yet even proposed by the current draft Mozilla CA cert policy. If one of the CAs trusted under the present draft policy were to issue a rogue cert, and did not revoke it, that would be cause for removal from the trust list. My first point is that I have a different view of these things and it is very important to understand that all my thoughts derive from this view, while all your thoughts derive from your view. Here's your view, if I can be excused for interpreting your words: You think that we currently have a situation where we can trust the CAs currently in the root list to get it right. You also think or fear with a high degree of risk that if we enact the new policy, we will move from State A - we can trust the CAs - to a new State B where we can no longer trust all the CAs all the time. OK? Correct me, please, so we can all understand the ground from which we speak. Here's my view: we are already in State B. Enacting the policy will IMHO make no difference to the state, because we are already there. I would have thought that was abundantly clear from the Shmoo example, but I guess we need more evidence to determine the truth or otherwise. But - at least let's understand each other's world views: You think we are in State A - trust and the new policy will take us to State B (you fear). I think we are already in State B. And the policy is simply going to help us deal with that by making it more visible. (A marginal improvement, but welcome nonetheless.) So I suggest that we do not assume it to be the case today. Folks, it remains the policy that we TRUST the CAs that we've decided to TRUST. Ian very much would like to see the world be very different and is doing every thing in his power to influence it all to be changed. OK. Now my second point is that I have a goal. I'd like to hear what your goal is but bear with me while I outline my goal. This causes my worldview. My goal is security. The security of the net. In this, I see the biggest current danger to the security of the net as phishing. (we can discuss why, but I'm just claiming that for now.) In order to address phishing, I see things like the list and comments of Peter Gutmann today, the ideas of Gervase, the code of Amir Ahmad, some of the other theoretically inspired ideas from the petnames / caps community, etc etc, as very promising. They all seem to suggest a way forward for dealing with phishing. In opposition to that, we know that SSL and certs as they stand today do nothing to stop phishing. Nix, zip, nada. So I conclude that anything that maintains the status quo needs to show how it addresses security, and very specifically how it helps to address the real threats facing users today. So my goal is security, and it reduces to let's fight phishing. Can you tell me how your policy helps that? But be aware that any such policy change must be carefully considered and not implemented piece-meal in some parts of mozilla without considering the security implications across the board. I have to agree that Gerv's favorite proposal has none of these objections. It does not represent a policy change regarding trust of CAs, nor does it prevent one in the future. Then, support that! This subject is so complex and so involved with so many people, that any small radial steps will be welcome. Once people start thinking about how a new feature or a new switcheroo works, the precise way to deal with phishing will come out in a mixture of experimentation, theory, risks and downright mistakes. 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: Some Non-Critical Secunia Advisories
Allen Farley wrote: Nate wrote: On Tue, 15 Mar 2005 10:51:26 -0500, Allen Farley [EMAIL PROTECTED] wrote: From the article: The weakness has been confirmed in version 1.0.1. Other versions may also be affected. I also tested the sample code with FF 1.0.1, and they are right. It's not unusual for me to save a zip (because I want to keep a copy), and then right-away click Open when it's finished downloading. Now I know that could be a recipe for disaster, if I were not to notice the change in filename. So thanks for posting the alert. I suppose it's too-good-to-be-true that there is an email alert service for these exploits? One that covers only FF, not every thing under the sun? ...and it occurs to me yet once again, that one big reason for the proliferation of spam, spyware, viruses and on and on ad nauseum is that the bad guys hardly ever suffer any punishment. It's like burglars being allowed to try as many doors as they want to. In the too-good-to-be-true category, would a webpage do as a stop-gap measure? http://secunia.com/product/4227/ There may be other possibilities there as well. On punishing the bad guys, my suggestions would most likely be considered inhumane for these creatures. Allen Generally, I oppose such things as torture, or maiming, but in the case of this kind of pernicious activity, prison sentences aren't enough. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Getting people to click Yes
Here's one way to gently socially-engineer people to click Yes on a security permissions dialog: http://www.errorguard.com/search-ie.html Ignore the rest - it's the Yes button that's important... Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: about bug 286107 : Remember visited SSL details and warn when changes, like SSH
I think there is value in the concept but it has a major failing from a usability perspective that falls out of data center operational practices. How many webservers do you think a big bank has? Some folks use SSL accelerators in front of their web-server or app-server farm, some folks have multiple machines wiht independant identities as they take a different strategy for meeting availability targets (capacity, uptime, performance). The UI benefit of advising you've never been here would disappear by the time folks noticed that they could get the warning when it is clearly wrong (the tenth time they visit their bank site and it throws the new site warning half the time). This works very well when you have some other way to authenticat the site and need only ensure that you are visiting the site again. Of course one way to authenticate a site is to use PKI as opposed to stand alone PK techniques. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: about bug 286107 : Remember visited SSL details and warn when changes, like SSH
Ram A M wrote: I think there is value in the concept but it has a major failing from a usability perspective that falls out of data center operational practices. How many webservers do you think a big bank has? Some folks use SSL accelerators in front of their web-server or app-server farm, some folks have multiple machines wiht independant identities as they take a different strategy for meeting availability targets (capacity, uptime, performance). The UI benefit of advising you've never been here would disappear by the time folks noticed that they could get the warning when it is clearly wrong (the tenth time they visit their bank site and it throws the new site warning half the time). This works very well when you have some other way to authenticat the site and need only ensure that you are visiting the site again. Of course one way to authenticate a site is to use PKI as opposed to stand alone PK techniques. This is something that Julien brought up and Amir addressed by setting the border at the CA. As the user identifies a particular CA as good, the security app module accepts any cert from that CA. https://bugzilla.mozilla.org/show_bug.cgi?id=286107#c6 https://bugzilla.mozilla.org/show_bug.cgi?id=286107#c19 Now, this isn't as good as identifying the identity token of the company via something solid like a cert, but we have to live with reality. If companies are using multiple identity tokens with many slight differences, then something broader may be set as an acceptable boundary for them. Where I would raise an eyebrow is if they are using multiple CAs to craft these multiple identities. If that is the case, due to voluminous logic found else- where, then they will be open for attack, IMHO. So I think it no big hardship to ask a big bank to at least stick to one CA. (Bear in mind that the bank should be centrally controlling the identity certs anyway, as otherwise they would be opening themselves up to insider theft of their identity. Also, they have a vested interest in helping us reduce phishing, so if they see it working, I suspect they'll be happy to help.) 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: authenticationManager.clearAll()
Henrik Gemal wrote: You cant call extensions from a client side javascript Well that's not entirely true. Interpreting the term extension broadly you can create a javascript component that adds methods and, for example, sticks them on the window object to be called willy-nilly. Dangerous, of course -- that add-on had better be written very carefully and expect malicious abuse. An example of such a component is nsSidebar.js in the Suite. It's ancient so there may be other ways to accomplish something similar. If you're implementing a new interface rather than one already there you'll have to also ship a corresponding .xpt file. But Henrik's right that you can't call just any old extension, only those whose authors went out of their way to expose. -Dan Veditz Bob Chauvin ( Paix dehors ) wrote: Found posts from previous questions that answered my question. I wonder if I can call an extension from javascript? Such as... http://extensionroom.mozdev.org/more-info/clearhttpauth ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Getting people to click Yes
That's nothing new, unfortunately. Sites were doing that back in the Netscape 4.x days for Java privilege request prompts. You're going to get something that looks like [image]. It's normal, just click OK. Gervase Markham wrote: Here's one way to gently socially-engineer people to click Yes on a security permissions dialog: http://www.errorguard.com/search-ie.html Ignore the rest - it's the Yes button that's important... Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
