about bug 286107 : Remember visited SSL details and warn when changes, like SSH
I have some comments about this request, but I'm not sure inside the bug is the best place. Anyway the bug is about implementing some things that have been discussed here recently. I'm not convinced by the "let's add another warning" side of this bug. Especially when I see the reporter suggesting to put it inside a pop-up dialog. Dialog have proven until now they don't work, so why would this one by any different ? It works well for SSH, because you decide what machine you connect too, and you keep connecting to the same set of machines, so when that dialog pops up, it rings a bell. Also the population of SSH users is *not* *exactly* the general population. Now the problem about SSL is that in most cases, you don't choose where you do an ssl connection, when you want to buy something, it's the sellers who chooses the secure site, same for entering password, etc... So in that case, when the seller tells you "go to that site for the transaction", what use will be the warning ? Users will get used to seeing regularly that annoying warning, and to click through it or ignore it. Sometimes they will click on a link expecting that link to lead to a site they trust because they know it well, and there it's important to have the message, but how does the browser know *when* that happens ? Because if it outputs this warning too often, people will stop reacting to it. And will the average user react appropriately ? : "Why the hell is Firefox telling me it's the first time I go to ebay.com, they really have a bug !" ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Some Non-Critical Secunia Advisories
Just got these for Mozilla, Firefox and Thunderbird today. All are listed as '"Save Link Target As..." Status Bar Spoofing Weakness' and all have the same solution: 'SOLUTION: Never save files via untrusted sources.' http://secunia.com/advisories/14565/ - Firefox 0.x & 1.x http://secunia.com/advisories/14567/ - Thunderbird 1.0 http://secunia.com/advisories/14568/ - Mozilla 1.7.x ___ 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: Padlocks as Evidence of Security?
Gervase Markham wrote: Er... which paper? The link was at the bottom, here it is again: http://www.ischool.washington.edu/networksecurity/Articles/Web_Security.pdf And if still keen, read this one: http://www.ischool.washington.edu/networksecurity/Articles/Risks_Harms_Web.pdf Also, while we are on the subject of HCI of how users view web security, Chris pointed out on my blog that "Simson Garfinkel's dissertation is worth looking at in this context." http://www.simson.net/thesis/ 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: Padlocks as Evidence of Security?
Ian G wrote: Ka-Ping Yee wrote: *** Everyone who is doing browser security should read this paper. *** It's very short -- just two pages -- so you only have to spare five minutes. That I agree with. Definately. Er... which paper? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
*~*Outdoor Pissing Girls Party*~**
Do you remember the time you used to be a child and how great was the relief when you could let yourself go in peeing inside your pants? Well those nasty girls surely know. If you dont believe it, take a look in this section where the best place to go when you want to piss is not in the bathroom, but inside your pants! Free Movies here: www.maniakenpiss.com FREE ACCESS !!! Enjoy ! ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
**~*New Concept for your Ego Life Style...!*~**
We are happy to present the new look of your preferred website www.virtualvideoshow.com: new graphics user-friendliness and new sections. Henceforth you will have the choice to 15 categories and more of 1000 movies and only day we put on-line new movies. Free Access and 10 minutes Free Porn Movies for All No Membership & No Credit Card Required ENJOY and Have FUN. ___ 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: Detecting CC numbers
HJ wrote: You will notice a swift towards e-mail phishing soon, because there's a lot of chatter about it already. Again, people use Mozilla features on their bank sites, like the password manager, and that makes your inbox even more interesting. Mining useful data from email accounts is harder, and probably involves a human step, so is harder to automate. If phishers are reduced to trying to break into your email, we'll have won a significant victory. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
RE: Copy and paste issues
Dan, When using firefox with a php website program it doesn't not let me paste in text from a program at all when using ctrl-V when I try to do this I get a message with a link (screen shot attached) taking me to a site with the fix - supposedly - I have tried everything they suggest and still get the message. It references unprivileged java scripts (I think it has something to do with the fact the PHP uses java to create web pages) Thanks, Bo. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Veditz Sent: Monday, March 14, 2005 1:20 AM To: mozilla-security@mozilla.org Subject: Re: Copy and paste issues Warmbold, Bo wrote: > > New to firefox but having trouble with something - Our district > uses PHP as our web development software firefox doesn't support using > Ctrl-v to paste things in. There is a fix on the website involving > the user.js file. I have done this and firefox has copied the new > user_pref lines to the prefs.js file so all seems well but I still > cant use Ctrl-v but I can go to paste in the edit menu I am sure it is > something I am doing wrong. Any suggestions? Paste things where? Ctrl-v works for me in form controls. Which website, fix for what? Since the paste shortcut works as I think it should I'm having a hard time imagining what user.js changes you'd want to make. I have a bit of a bad feeling about it, in fact. -Dan Veditz ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security desktop.doc Description: desktop.doc
Re: Detecting CC numbers
Gervase Markham wrote:
Idea off the top of my head - please tell me why it won't work.
Could we parse all form submissions over unencrypted channels and put up
an alert ("You _really_ don't want to do this!") if any of the fields
was a sixteen-digit number which passed the credit-card-number checksum
algorithm?
OK, so some places have four boxes for four digits each, but with clever
coding, we might be able to catch that version too.
Gerv
for details an what goes into each companies card numbers, just contact
the companies.
most e-commerce, from the business end, is through third party site.
the banks have a contract with at least one company that handles all
online transactions for thier business customers. transactions such as
processing your credit card data when you buy something from the company.
you could go through the banks to get thier online group, then talk to
them about what they want as input, so that the browser can be secured
to make the risks lower for both sides of the transaction.
( Canadian system different than US system, different from european
system )
each payment agency has different layouts, so that is where layouts are
controlled, not the site end.
e-commerce sites have to use the processing companie's format, which
really has nothing to do with the card type, or length of card number
___
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
Re: possible general solution to homograph attacks
Gervase Markham wrote: HJ wrote: So your proposal adds all SSL domains to a SSL history (hash codes) even one of a phishing site? I think you need to go and read it again. :-) Gerv I will ;) /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
HJ wrote: HJ wrote: Gervase Markham wrote: Ian G wrote: > Much of phishing isn't about credit card details so much as *any* information. Well, I'm sure a phisher isn't really interested in my laundry list. CC numbers are one very quick way to get access to cash, and one people are used to typing into web browsers. And, as attackers are able to adjust their policies to suit what's out there, they could also make their sites foil the checks. Possibly. At the moment, phishers copy-and-paste pages from legit sites. This would at least make them modify them. Gerv You will notice a swift towards e-mail phishing soon, because there's a lot of chatter about it already. Again, people use Mozilla features on their bank sites, like the password manager, and that makes your inbox even more interesting. /HJ ...thing lost password buttons/links! Darn, make that "think..." I shouldn't edit and press Send without reading my comments first :( ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
HJ wrote: Gervase Markham wrote: Ian G wrote: > Much of phishing isn't about credit card details so much as *any* information. Well, I'm sure a phisher isn't really interested in my laundry list. CC numbers are one very quick way to get access to cash, and one people are used to typing into web browsers. And, as attackers are able to adjust their policies to suit what's out there, they could also make their sites foil the checks. Possibly. At the moment, phishers copy-and-paste pages from legit sites. This would at least make them modify them. Gerv You will notice a swift towards e-mail phishing soon, because there's a lot of chatter about it already. Again, people use Mozilla features on their bank sites, like the password manager, and that makes your inbox even more interesting. /HJ ...thing lost password buttons/links! /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
Gervase Markham wrote: Ian G wrote: > Much of phishing isn't about credit card details so much as *any* information. Well, I'm sure a phisher isn't really interested in my laundry list. CC numbers are one very quick way to get access to cash, and one people are used to typing into web browsers. And, as attackers are able to adjust their policies to suit what's out there, they could also make their sites foil the checks. Possibly. At the moment, phishers copy-and-paste pages from legit sites. This would at least make them modify them. Gerv You will notice a swift towards e-mail phishing soon, because there's a lot of chatter about it already. Again, people use Mozilla features on their bank sites, like the password manager, and that makes your inbox even more interesting. /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
Gervase Markham wrote: HJ wrote: A credit card number can be as long as 19, 6 for the issuer, 12 for the account number and 1 for the checksum. Ah, OK. Do you have a reference to a document describing the format and the checking algorithm? I assume there is one, as sites do check for valid numbers. Gerv Just do a search for: ANSI X4.13 and/or ISO/IEC 7812-1:1993 /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
Ian G wrote: > Much of phishing isn't about credit card details so much as *any* information. Well, I'm sure a phisher isn't really interested in my laundry list. CC numbers are one very quick way to get access to cash, and one people are used to typing into web browsers. And, as attackers are able to adjust their policies to suit what's out there, they could also make their sites foil the checks. Possibly. At the moment, phishers copy-and-paste pages from legit sites. This would at least make them modify them. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
HJ wrote: A credit card number can be as long as 19, 6 for the issuer, 12 for the account number and 1 for the checksum. Ah, OK. Do you have a reference to a document describing the format and the checking algorithm? I assume there is one, as sites do check for valid numbers. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: possible general solution to homograph attacks
HJ wrote: So your proposal adds all SSL domains to a SSL history (hash codes) even one of a phishing site? I think you need to go and read it again. :-) Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
