Re: Fwd: Time to dump NSS

Your subject, "time to dump NSS", intimately affects NSS developers who will have to worry about replacing all the things NSS does for us before they can even start to think about the additional concepts. If you're proposing a mechanism that can live on the side without actually dumping NSS then I

Fwd: Time to dump NSS

Forwarding to dev-tech-crypto where this is more on-topic. -Dan Veditz --- Begin Message --- NSS was designed when physically distributed smart cards were anticipated to become the norm. This didn't really happen but instead we got mobile devices with support for TEEs (Trusted Execution Environ

Re: "Unable to add module", but why?

Forwarding question to the mozilla.dev.tech.crypto group. Is this a module you're creating yourself, or one you know works fine with Firefox for other people? On 1/21/11 6:21 PM, Lbm wrote: > Hi, first of all I hope I'm posting this question in the right place. > > Anyway, I've been trying to ad

Re: Alerts on TLS Renegotiation

On 4/3/10 9:30 AM, johnjbarton wrote: > If the *users* of Firefox are truly in jeopardy, then this alert should > be provided to *users*. Since this alert is not shown to users I can > only assume that in fact there is no practical threat here. You're > putting this message in the Error Console bec

Re: Alerts on TLS Renegotiation

On 3/31/10 5:26 AM, Eddy Nigg wrote: > security.ssl.require_safe_negotiation > > I believe this to be a mistake for various reasons, but first and > foremost because an attack on a server without compromise of the client > data as well, is basically useless. When a attacker induces > ren

Re: Fix for the TLS renegotiation bug

On 2/18/10 5:54 AM, Eddy Nigg wrote: > Which reminds me that we were at this stage already in the past. > Basically the authenticated session would have to be relayed through to > the second server, something I rather prefer not to do. I suspect that > there is no other way around that. You could

Fix for the TLS renegotiation bug

I'm surprised not to see it mentioned here yet, but Firefox nightlies implement the new TLS spec to prevent the renegotiation flaw. The fixes in NSS can also be used to build your own patched version of moz_nss for apache. Huge thanks to Nelson Bolyard for implementing the spec in NSS and Kai Enge

Re: Creating digital signature with JS in Firefox?

On 1/31/10 9:51 PM, John J. Barton wrote: > The Mccoy program, > https://developer.mozilla.org/en/McCoy > can sign update.rdf files. It has a dll to support the signature work. I > wonder if something has improved in the firefox code base since the time > Mccoy was written, such that the signature

RSA 768 factored

Just-released paper on successfully factoring RSA 768 http://eprint.iacr.org/2010/006.pdf (or http://bit.ly/8xXSgy) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: is there any way to connect without CA?

On 10/8/09 2:00 PM, Ian G wrote: On 08/10/2009 22:30, Daniel Veditz wrote: If you're asking about how to do it from Firefox you could try the "MITM Me" addon (Description: "This add-on is a terrible idea, and you shouldn't install it.") https://addons.mozill

Re: is there any way to connect without CA?

On 10/7/09 4:00 PM, Guenter wrote: Hi, is there any way to overwrite the default behaviour that a remote SSL host is verified against the CA list in the certdb? At what level? Assuming you're asking in this newsgroup because you're writing code to use NSS directly (or through PSM) you could lo

Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()

Moving discussion to mozilla.dev.tech.crypto, but do go ahead and file bugs. I doubt 3.5 behaves any differently than 3.0 (you did mean 3.0.10, right? If you're using Firefox 2 please stop). nk wrote: > Hi all, > I am researching the window.crypto.generatedCRMFRequest() function > available on Fir

Re: Work-around for Moxie Marlinspike's Blackhat attack

Didn't notice my follow-up didn't include m.d.t.crypto, and this warning is perhaps important enough to warrant a repost for this audience since the thread did continue on here despite Jean-Marc's followup-to header. Jean-Marc Desperrier wrote: > Until a better solution is deployed, here is the wo

Re: PositiveSSL is not valid for browsers

Ian G wrote: > "SSL protects data in transit but the problem isn't eavesdropping on the > transmission. Someone can steal the credit card on some server > somewhere. The real risk is data in storage. SSL protects against the > wrong problem," he said. That's like saying "No, no, mugging isn't a pr

Re: Proposal to split this list

Paul Hoffman wrote: > You are missing the parts where there are actual technical questions > or assertions in the middle of threads that started as trust anchor > rants. Requesting actual details in the middle of a long ranty thread is a good way to get missed no matter what newsgroup or topic. __

Re: Pre- and Post- controls

Florian Weimer wrote: > EV is (also) an attempt to devalue existing infrastructure, so it's > some form of group punishment. It also provides browsers with a slightly less blunt weapon. If a CA clearly violates EV guidelines the browser could remove the EV-ness of the root without removing the roo

Re: Pre- and Post- controls

Eddy Nigg wrote: > On 01/04/2009 10:20 AM, Eddy Nigg: >> On 01/04/2009 04:48 AM, Ian G: >>> On the punishment side, about all we have is "drop the root!" which I >>> earlier described as a blunt weapon. Are we being sensible when we now >>> have to "drop the root" for the three CAs who have reporte

Re: Full Disclosure!

Paul Hoffman wrote: > Why is this relevant to this mailing list? Doesn't it go along with the other "are CA's trustworthy?" threads? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

Kyle Hamilton wrote: > ("legitimate sites will never ask you to add an exception" my ass.) If we shorten the phrase to "Legitimate banks and stores will not ask you to do this" would you not agree that is true enough as far as the average non-expert user need be concerned? The furor seems to be

Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation

Kaspar Brand wrote: > Michael Ströder wrote: >> I'd love to have an option to forbid CRMFRequest calls... > > Not too difficult to achieve, actually. Just add this line to your > prefs.js: > > user_pref("capability.policy.default.Crypto.generateCRMFRequest", "noAccess"); That may work now, but c

Re: PositiveSSL is not valid for browsers

Frank Hecker wrote: > (It's not 100% clear to me how they distinguish DV certs from OV > certs, so I'd take this last figure with a grain of salt.) [...] > In practice we have a de facto differentiation between EV certs and > all other certs, as embodied in the Firefox UI. If Firefox could reliabl

Re: MD5 broken, certs whose signatures use MD5 now vulnerable

Paul Hoffman wrote: > At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote: >> I should have written: digital signatures on certificates. >> The patch that I wrote only affects signatures on digital certificates. > > Good. I am quite concerned if we start affecting signatures in things like > Thunde

Re: Unbelievable!

Kyle Hamilton wrote: > I then have to click at least six > times to try to figure out what's going on, and then when I do find a > site that's protected by an unknown CA certificate (OR that I've > removed the trust bits on), I have to do the following: > > 1) Click 'add an exception' > 2) click '

Re: Unbelievable!

Paul Hoffman wrote: > At 1:16 AM +0200 12/24/08, Eddy Nigg wrote: >> Select Preferences -> Advanced -> View Certificates -> Authorities. >> Search for AddTrust AB -> AddTrust External CA Root and click >> "Edit". Remove all Flags. > > Doesn't this seem like a better solution than "sue Mozilla fo

Re: Unbelievable!

Frank Hecker wrote: > Eddy Nigg wrote: >> Disabling the trust bits of "AddTrust External CA Root" could be a >> temporary measure to prevent damage to relying parties > > Also note that any "suspension" of a root would last at last 1-3 months, > since that the typical interval between security upd

Re: Documenting default trusted CAs

Wan-Teh Chang wrote: >> which can be seen at >> > > That URL is the latest version of the certdata.txt file, which is different > from > the version in NSS 3.11.9. The "CVS Blame" link can point at specific revi