hospedagem de site - planos de hospedagem
Tudo sobre hospedagem de sites , planos profissionais , economicos e muitos outros , sua empresa na internet por apenas 2,99 ao mês! http://www.hosting4u.com.br host hospedagem site internet webpage ___ 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: Goals, Worldviews, Policies
Gervase Markham wrote: Ian G wrote: Here's my view: we are already in State B. Can you point to any financial losses caused by someone falsely trusting certs issued by CAs trusted by Firefox? In answer to your question, no. But this does not show we are not in State B. As you've elided the definition I proposed of State B, here it is again: State B: we can not (any longer) trust all the CAs all the time. The reason I suggest we are in that state is because we can calculate or guess or even test how much it costs to acquire a false cert. 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. Everyone got blindsided by the Shmoo thing (although we shouldn't have been), the CA concerned included. Blaming the CA alone is somewhat unfair. I'm not blaming the CA. I'm saying that what happened there was normal. It will happen again, in accordance with the value of same. It's normal because any application of agency theory, governance theory, systems or security theory will show that the systems in place are only statistical and have well understood holes in them. It will happen to *all* CAs. It will happen on a regular, statistically modellable basis. In security, the question of whether or not a false cert can be obtained is meaningless. The questions that we ask are ones of risks, costs and benefits. The pertinent question for certs is: how much does it cost and how much it is worth? 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 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: Goals, Worldviews, Policies
Ian G wrote: Here's my view: we are already in State B. Can you point to any financial losses caused by someone falsely trusting certs issued by CAs trusted by Firefox? 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. Everyone got blindsided by the Shmoo thing (although we shouldn't have been), the CA concerned included. Blaming the CA alone is somewhat unfair. Gerv ___ 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: about bug 286107 : Remember visited SSL details and warn when changes, like SSH
Ian G wrote: > 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. Nice practical solution. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Detecting CC numbers
I think this idea has many benefits: 1 helps the user do the right thing 2 drives better behavior in the market (CC#s are sensitive and should be protected) 3 user experience friendly, I don't think a Pentium2 user would notice any latency change 4 cost effective, relatively small amount of relatively simple software ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: $90 for high assurance _versus_ $349 for low assurance
Ian G wrote: > In the below, John posted a handy dandy table of cert prices, and > Nelson postulated that we need to separate high assurance from low > assurance. Leaving aside the technical question of how the user > gets to see that for now, note how godaddy charges $90 for their > high assurance and Verisign charges $349 for their low assurance. > > Does anyone have a view on what "low" and "high" means in this > context? Indeed, what does "assurance" mean? >From an issuance policy perspective one definition of assurance classes could be: 0 No assurance. An enrollment was received and a certificate issued (a few million Netscape In Box Direct certificates were issued this way) 1 Low assurance. An enrollment was received and an email containing a secret was sent to the enrollee specified address who then presented the secret to the enrollment site which then issued the certificate. 2 Medium assurance. An enrollment was received wiht a set of identifiying information which validated using third party mechanisms (commercial identity databases, credit agencies, phone books) in addition to an email round trip with a secret as in class 1. 3 High assurance. An enrollment was received along with multiple points of contact and legal documentation. Government and commercial databases where used to verify the information submitted. Out of band methods were used to contact the purported enrollees legal right to represent them. Out of band methods were used to advise the purported enrolling entity that an enrollment was made on their behalf. Multiple operations staff had to independantly review collected infomration and approve the enrollment. The domain-control-certificates are equivalent to a class 1 as described above. VeriSign's $349 certificates are class 3. A separate but equally important issue is whether a CA enables revocation checking. As you might imagine even a high assurance certificate can be mis-issued and so the revocation concept of PKI is important. So if a CA does not offer revocation checking services (e.g. by providing CDPs and crl responders, or ocsp AIAs adn ocsp responders) that would substantially diminish the value of any authentication they perform. > John Gilmore wrote: > > For the privilege of being able to communicate securely using SSL and a > > popular web browser, you can pay anything from $10 to $1500. Clif > > Cox researched cert prices from various vendors: This is most unfortunate. I would like to see software providers like MoFo, Opera, Microsoft and others improve the situation. Thought it's worth noting that you can issue your own certificates and many browsers will allow you to override the lack of a known trust anchor and accept the certificate permanently - that doesn't make it better though as it adds to the problem of taxing users' focus and patience such that they learn they should [not really!] click OK automatically when you get a pop-up [presumably this is why sometimes the OK and CANCEL buttons are reversed - so you don't automatically approve formatting your harddrive when you click the wrong menu option]. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: [Bug 286107] Remember visited SSL details and warn when changes, like SSH
Again, I think Nelson brings up points better off transferred to the wider forum rather than within the narrow context of the bug. [EMAIL PROTECTED] wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=286107 --- Additional Comments From [EMAIL PROTECTED] 2005-03-16 13:33 PST --- Above, I didn't mean to accuse Ian of any wrongdoing, and in retrospecet I see that what I wrote could be construed to imply that I did. I only mean that the suggestion that we need a solution to a problem of untrustworthy CAs will influence some (who are not fully aware of the current CA trust policies) to imagine that this is a problem that exists today, and to persue solving this non-problem. I think we should focus instead on the problem at hand. Certainly I try and separate the people from the discussion, that's why I'm boringly dogmatic in stressing (my) goal in this discussion. As to whether "we need a solution to the problem of untrustworthy CAs" I also addressed that in the previous post so won't repeat it here. I do not think that security policy should be decided entirely democratically, nor that we should relax out standards so that they no longer exceed the average person's understanding of the issues. The standards are there to spread the knowledge of a complex subject, where coordination is needed. Often people will follow standards as a rule set because it is far easier to do that than to figure out what to do everytime a question arises. Yet standards can get out of date. And standards are in place for the norm, not the exception. As we have here a situation which (I assert) is in crisis / epidemic proportions then the standard may be expected to bend or even need to be replaced entirely. I am afraid that this issue is going to be (unduely, IMO) influenced by the sheer volume of words exxpressed on on side of this discussion. It's a complex subject. As written voluminously, browsing is in crisis. What lesser volume could we write to get some attention on that point? This isn't a matter of blindly following standards and RFCs. There is a large community of security cognoscenti who are all behind PKI. I respect their collective judgements. However they do not speak much in mozilla's forums and bug reports. Mozilla's forums do hear a lot of the dissenting opinion, however, and it is possible for someone whose only understanding of the issues comes from these forums to conclude that these dissenting opinions are the majority opinions, the opinions of the experts. This is how cults operate, the members hear only one view. OK, that's a serious issue and I'll address it. The reason Mozilla's forums hear a lot of dissenting opinion is twofold. Firstly, Mozilla happens to represent the great white hope of the browsing world. It's growing rapidly, and therefore can expected to have some heavy effect on the marketplace. It's also open source, it's also got the only open security forum in the business (this group). This is the only place you can find any security representation - you, Frank, Bob, Julian, David, sorry for missing anyone out - so, yes, you are point men on the browser security community for every other browser by default. Sorry about that :) Secondly, the reason the dissenters are dissenting is because they have thought about it, and in general they can see the flaws. But more importantly you will find that the dissenters have no bias towards the model. I for example make zero bucks one way or the other. Peter Gutmann makes a bit of dosh selling his toolkits on occassion, but he might make more money by being solid and truthful about flaws than sounding like he's selling used cars as do most security tool sellers do. Bruce Schneier, another frequent critic, makes no money as he has his own company. Dan Geer, another critic, has lost his job over telling the truth, so I guess maybe he has got a bias now :) OTOH, you won't find RSADSI or Verisign here dissenting because they almost certainly sell a PKI toolkit, and their not likely to commit commercial suicide just to maintain some academic integrity. Which brings us to your next point - the large security community who are behind PKI. Historically this was a fair assessment, but I think it is changing. It might be the time to ask for opinions on that, to re-open the question of just who is solidly "behind PKI" without question. Over on the cryptography group I'd say that more than half would now question PKI and easily more than half would say that PKI as it is setup in HTTPS/ secure browsing contributes to phishing, as well as forms the basis for its solution. Yes, you don't get out of this one by just reciting security wisdom and RFCs... Over in the marketplace, the market for PKI has been in the doldrums for a few years, and I really don't want to print what the average *purchaser* thinks about it. I simply want the readers of this bug to be sure that they're solving the real problems today, not the pro
