Re: [ANNOUNCE] NSS 3.27 Release

* Kai Engert: > On Sun, 2016-10-02 at 01:48 +0200, Kai Engert wrote: >> The maximum TLS version enabled by default has been increased to TLS 1.3 > > I have been corrected. > > The maximum TLS version enabled by default is still TLS 1.2. > > However, there are applications that query the list of TL

Re: Proposal: Disable SSLv3 in Firefox ESR 31

* Kai Engert: > When attempting to connect to a SSL3-only server, Which is now treated as version-intolerant, it seems. > I see Firefox 34 attempting three connections, with TLS 1.2 {3,3}, > TLS 1.1 {3,2} and TLS 1.0 {3,1}, but not SSL3. This still shows the fallback attempts, to TLS 1.0 even,

Re: Proposal: Disable SSLv3 in Firefox ESR 31

* Julien Pierre: > The whole TLS_FALLBACK_SCSV would be unnecessary if not for this > browser misbehavior - and I hope the IETF will reject it. Technically, we still need the codepoint assignments from the IETF draft because of their widespread use, and that requires Standards Action, which means

Re: Proposal: Disable SSLv3 in Firefox ESR 31

* Reed Loden: > On Thu, 16 Oct 2014 20:27:24 +0200 > Florian Weimer wrote: > >> * Richard Barnes: >> >> > If there are any objections or comments on that proposal, please >> > raise them in this thread. >> >> A lot of this has already been ha

Re: Proposal: Disable SSLv3 in Firefox ESR 31

* Richard Barnes: > If there are any objections or comments on that proposal, please > raise them in this thread. A lot of this has already been hashed out on the IETF TLS WG mailing list, with a slightly different perspective. Why is disabling SSL 3.0 acceptable, but getting rid of the broken f

Re: Chrome: From NSS to OpenSSL

* Julien Pierre: > Strange that "PKCS#11 support" is listed as a "con" for NSS . I found the PKCS#11 approach rather difficult to deal with if you're adding cryptography to some library whose client code has no idea that there is cryptography involved (and that NSPR and NSS need initialization).

Re: Proposing: Interactive Domain Verification Approval

difficult to come up with a single country which accurately describes where the CA is located. -- Florian Weimer / Red Hat Product Security Team -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox

* Brian Smith: > The first question is: Should we change our UI to be the same as > other browsers? My answer is no. It *is* a good idea to show the > root certificate's organization name in this part of the UI. But, it > is also important to show all the intermediate organizations' names > in thi

Re: Two-factor auth for Bugzilla

* Marsh Ray: > My personal opinion is that IP source addresses are not actually a > particularly strong factor. Here are some reasons: It really depends on what you're dealing with. Mozilla shouldn't disclose that to the general public, so it's difficult to make good recommendations. >> As a re

Re: Two-factor auth for Bugzilla

* Gervase Markham: > Goal: fix bug 570252. Provide 2-factor authentication for some > Bugzilla accounts. > https://bugzilla.mozilla.org/show_bug.cgi?id=570252 The IP address restriction is a pretty strong factor. Basically, it means that a potential attacker would have to compromise a device qui

NSS API reference documentation

Is there a reference manual for the public NSS API, specifically the TLS part, the certificate API? (The ASN.1 and CMS functions might be interesting at some point, too.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy: revoke on private key exposure

* Ian G.: >> Huh? Typical CA policies explicitly state that subscriber >> certificates are not confidential, and are not treated as such by the >> CA (so that they can be used by marketing, for instance). > What I know of, not exclusive or reliable: > > 1. privacy, as Eddy has pointed out. Th

Re: Policy: revoke on private key exposure

* Eddy Nigg: > On 01/22/2009 11:59 AM, Florian Weimer: >>> http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt >> >> The list doesn't include sub-CAs, which are equivalent to listed CAs >> for all practical purposes. > > Well

Re: Policy: revoke on private key exposure

* Michael Ströder: > Florian Weimer wrote: >> What about requiring that all certificates must be published by the CA >> (including sub-CAs)? > > No, this might lead to also revealing internal DNS names never meant to > be public. Huh? Typical CA policies explicit

Re: SSL Blacklist : List of servers using compromised private keys

* Chris Hills: > Florian Weimer wrote: >>> Perhaps Mozilla should change its policy to require CAs to revoke certs >>> when the private key is known to be compromised, whether or not an attack >>> is in evidence, as a condition of having trust bits in Firefox. >&g

Re: SSL Blacklist : List of servers using compromised private keys

* Jan Schejbal: > I know, but they are SSH only as far as I can see. Is there such a > release for SSL? And would you consider such a release a good idea? (I > see little value for both attackers and legitimate use) You need it if someone claims that your weak key detector has a false positive be

Re: Policy: revoke on private key exposure

* Eddy Nigg: > On 01/22/2009 11:04 AM, Florian Weimer: >> * Eddy Nigg: >> >>> As a matter of fact, most CAs have policies in place which require >>> them upon knowledge of potential or *suspected* compromise to revoke >>> ANY certificate. I'

Re: Policy: revoke on private key exposure

* Eddy Nigg: > As a matter of fact, most CAs have policies in place which require > them upon knowledge of potential or *suspected* compromise to revoke > ANY certificate. I'm certain those policies exist for the top CAs > covering the majority of certificates. The keys are compromised, not > only

Re: SSL Blacklist : List of servers using compromised private keys

* Nelson B. Bolyard: > IMO, yes, it is enough evidence. But the position of those CAs, as I > understand it, is that such publication is only a potential compromise. > They require evidence that the published key is actually being used to > attack the site. Otherwise, their customer agreement do

Re: PositiveSSL is not valid for browsers

* Gervase Markham: > Florian Weimer wrote: >> Section 18 does not require that the domain holder is aware of the >> application. > > Section 18 requires that the domain holder _be_ the applicant. Some CAs disagree with this interpretation. Here's an example: Domai

Re: Pre- and Post- controls

* Ian G.: > So what to do? Should "Mozilla" become "the judge" in the post-event > phase? Do we leave this job to the courts? Should we group together > on this list and pass final judgement? Should we all vote? Demand > changes? Should we implement California rules -- 3 strikes and the > ro

Re: PositiveSSL is not valid for browsers

* Ben Bucksch: > On 03.01.2009 18:09, Florian Weimer wrote: >> >>> Are you saying that Fluff, Inc. could get a cert for mozilla.org, >>> assuming Fluff, Inc reveal its legal identity? >>> >> >> Yes, that's the essence. > Wel

Re: PositiveSSL is not valid for browsers

* Gervase Markham: > Florian Weimer wrote: >> Organizations not on this list can usually get an EV certificate >> through a corporate sponsor. The EV process does not verify that the >> party to which the certificate is issued is the actual end user, or >> that i

Re: PositiveSSL is not valid for browsers

* Ben Bucksch: > On 03.01.2009 15:54, Florian Weimer wrote: >> The EV process does not verify ... that it is the legal entity which >> controls the domain name mentioned in the Common Name field. > > Are you saying that Fluff, Inc. could get a cert for mozilla.org, > as

Re: Unbelievable!

* Eddy Nigg: >> just because CAs start to play games with each other. This is not >> about "security proper". You're trying to pull us into a PR attack >> on one of your competitors, thereby willingly reducing confidence >> in ecommerce. (I'm exaggerating a bit, of course.) > > Exactly the oppo

Re: PositiveSSL is not valid for browsers

* Eddy Nigg: >>> There is a middle ground ignored which is bad. There >>> are organizations which can't be validated according to EV, they would >>> certainly benefit from it. >> >> For example? > > Anything out of this list: https://www.startssl.com/?app=30#requirements > > Self-employed and smal

Re: CABForum place in the world

* Kyle Hamilton: > "Legitimate sites will never ask you for your credit card, national ID > number, or any other sensitive information after asking you to add an > exception." What about sites which use ActiveX? They ask for an exception, too. ___ dev-

Re: A business model

* Ben Bucksch: > Florian, I think you refer to cert issued to spammers holding a > domain, and getting a DV cert for that domain that they registered? > The cert is issued correctly for the domain, just the organization > does not do clean business. This is a totally different issue. Oops, sorry,

Re: MD5 irretrievably broken

* Kyle Hamilton: > I would suggest requiring all new roots approved to state that they do > not and will not use MD5 in any newly-minted certificate (except > possibly in a configuration like the TLS pseudo-random function). If they issue certificates for sub-CAs, they have no technical means to

Re: Unbelievable!

* Michael Ströder: > Florian Weimer wrote: >> Even if you've got the certificate, you need to attack IP routing or >> DNS. If you can do that, chances are that you can mount this attack >> against one of the domain-validating RAs, and still receive a >> cer

Re: PositiveSSL is not valid for browsers

* Frank Hecker: > No e-commerce site should be using DV certs, and IMO all e-commerce > sites should consider upgrading to EV certs. The market for DV certs > is people like me, who want to provide basic security measures for a > web site (or email server) but are not dealing with data of any > mo

Re: MD2

* Ben Bucksch: > Yet, when I went through the cert store, I see not only MD5 certs, but > MD2 certs as well. Partially from VeriSign. How comes? These are self-signatures only. They should not be evaluated. (I hope that NSS doesn't even contain an MD2 implementation. 8-/) __

Re: A business model

* Ben Bucksch: > Now, 3 years later, some scammers and spammers actually notice me and > set up fake SSL sites with my certs. Not just fake sites. Some of the OEM software spammers use valid SSL certificates for the checkout procedure, e.g.: For those t

Re: Unbelievable!

* Eddy Nigg: > On 12/27/2008 05:38 PM, Florian Weimer: >>> Isn't that, by itself, a very good reason to take immediate action? >>> Security should be default-fail rather than default-pass. >> >> This is not about security, this is about the presence or ab

Re: Suspend the trust bits

* Paul C. Bryan: > Presumably it was Comodo that underwent an audit to be added to > Mozilla's roots, and Comodo should not be allowed to delegate trust to > their resellers for domain validation. If, today, trust is delegated > to their resellers, then we can't trust Comodo, period. Many of the

Re: Unbelievable!

* Hendrik Weimer: > Frank Hecker writes: > >> My intent is to balance the disruption that would be caused by pulling >> a root vs. the actual security threat to users. Right now we have no >> real idea as to the extent of the problem (e.g., how many certs might >> have been issued without proper

Re: DNSSEC? Re: MITM in the wild

* Alaric Dailey: > DNSSEC is an assertion of validitity of the DNS. > EV certs assert that the business behind the cert is legit. Only that a legal entity exists (whether its "legitimate" is not checked). EV certificates are routinely issued to organizations which do not run the business which e

Re: questions on root creation

* Nelson B. Bolyard: >> * expiry should be? >> + minimum 8 years? >> + maximum 30 years? > > In that same NIST publication there is a table of recommended key sizes > to use for secrets that need to be protected until year 2010, 2030, and > beyond. It's table 4, page 66. I think they re

Re: EV issues with redirects...

* Kyle Hamilton: > This is a valid PayPal URL that issues a redirect to an external site, > which just happens (at this moment) to spoof the PayPal layout. > > Is there any provision anywhere for a "you are leaving an EV site to > go to a non-EV SSL site or an unencrypted site" kind of warning? T

Re: Comodo request for EV-enabling 3 existing roots

* Eddy Nigg: > The CAs should prevent issuance of certificates which are suspected to > be used for phishing attempts and other fraud. This includes cases like > real domain names (mic0s0ft.com, paypa1.com) and sub domain names > (paypal.nelson.com). Is there any CA which is part of the browse

Re: Terminating SSL on the web proxy

* Robert Relyea: >>> I've seen proposals for this kind of gateway back in the early 90's as >>> a way of providing secure email access for browsers which did not >>> support https:. >>> >> >> IIRC, Netscape 3 or 4 had some kind of "extend trust to proxies" option. >> > Not when it comes to

Re: Terminating SSL on the web proxy

* Robert Relyea: >> Oh, how unfortunate. Is it possible to disable all certificate checks? > So the question naturally arises: "why do you want this?". I want to get rid of the HTTPS confirmation dialogs for testing automation purposes, preferably without patching the source code. (The latter

Re: Terminating SSL on the web proxy

* Nelson Bolyard: > Florian Weimer wrote, On 2007-12-07 02:54: >> Is it possible to configure NSS (or, more precisely, Firefox) to >> terminate SSL connections on the web proxy, so that the proxy receives >> requests in the clear (and handles the certificate verification)? &g

Terminating SSL on the web proxy

Is it possible to configure NSS (or, more precisely, Firefox) to terminate SSL connections on the web proxy, so that the proxy receives requests in the clear (and handles the certificate verification)? ___ dev-tech-crypto mailing list dev-tech-crypto@list

Re: The Browser Digital Signature Riddle

* Anders Rundgren: > Somewhat surprising, the people who seem to be the least aware of > these efforts to transform the ubiquitous Internet browser from being > a "Universal Thin Client", to become a "Universal PKI-enabled Thin Client" > are actually the browser vendors and W3C! > > Comments? The