Fwd: Time to dump NSS
Forwarding to dev-tech-crypto where this is more on-topic. -Dan Veditz ---BeginMessage--- 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 Environments): http://webpki.org/papers/SKS-KeyGen2_FullStack.pdf NSS cannot deal with provisioning of TEEs because it doesn't support provisioning of keys in an E2ES (End-To-End-Security) fashion. This is hardly surprising since keygen was designed 1995. In addition we need entirely new key access protection models: http://webpki.org/papers/key-access.pdf With a new key-system you could do things like: https://mobilepki.org/WebCryptoPlusPlus There's much more to this but I wanted to hear what Mozilla are thinking regarding key-storage. I'm prepared to help making this upgrade possible! Cheers, Anders Rundgren ___ dev-security mailing list dev-secur...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ---End Message--- -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 suppose we can discuss it elsewhere, but if it involves cryptography (how could it not?) then the tech.crypto group is the one the people who know about cryptography participate in. There are several (sometimes competing) efforts within the W3 and IETF to create standards around concepts like key management. We're unlikely to implement a solution that doesn't get buy-in from other browser and server makers in that kind of forum. -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 add a specific PKCS#11 module to Firefox and keep getting the, rather uninformative, message Unable to add module. What I'd like to know is how one might be able to get some more info on _why_ the module can't be loaded? Also noticed that one can debug modules using a specific environment variable, but since the actual module is never loaded at all that's pretty much a no go. Any info would be really appreciated! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. The client supplies the credentials. Not every server or application is equally vulnerable, not all SSL connections use the HTTP protocol. Sure, there may be specific attacks due to this flaw that could be prevented in other ways (a typical anti-CSRF nonce in a web form, say) but that is not a general defense. SSL is a building-block and is supposed to guarantee an authenticated, encrypted, tamper-proof connection to the application layers above. It was broken and turns out to allow the injection of prefix content in some situations. Whether that can lead to compromise depends on what was built above the SSL layer. When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. You don't know that! Depends on what the client is doing and what the server is. What if the attack is to make the client connect to an open redirector on the target site? The client could leak all kinds of data by sending it to the wrong site. SSLv2 was disabled in Firefox only a short while ago, Three and a half years ago, October 2006 (longer if you count six months of 2.0 pre-release builds). But the ability for users to choose to disable it was available for years before that. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Then we would be foolish to toggle the default on that pref any time soon. Refusing to speak to servers that don't support RFC 5746 [... will force] the user to accept unsafe renegotiation Why? Those are two separate prefs. The user can easily speak to servers without rfc 5746 and still refuse unsafe renegotiation. But you know this because Minefield broke client-auth on your site with precisely these settings. What's your real point? It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. 99.9% of bank customers will never have their bank go out of business. Why should they bother to check whether their bank is federally insured? -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 always patch your servers to support the new protocol. Unfortunately this flaw is not fixed until all servers and all clients are patched, and getting there is going to be painful. If you use apache then patches are available for both mod_nss and mod_ssl. If you use some other server then site admins such as yourself should contact them and press for a solution. You'll need one soon enough, and getting fixes from a non-open-source vendor might take a long lead time. I don't expect to ship a stable version of Firefox with broken SSL client-auth any time soon but it seemed appropriate for Minefield testing. We may revisit the Minefield choice if it's breaking too much, but maybe we'll just release note the temporary pref -- Minefield users are supposed to be savvy consumers of alpha software well capable of handling that kind of thing. -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 Engert for the client (Firefox) integration piece. To solve the problem for real in the long run both servers and clients need to be patched, and patched clients and servers must not talk to unpatched servers and clients. In the short run that's unrealistic so the Firefox settings are currently extremely permissive, but paranoid users who only need to talk to a couple of servers that they know are patched could make it strict if they like. Test server at https://ssltls.de Firefox nightlies have been patched since Feb 8 or 9 https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Kai's write-up on the various client options https://wiki.mozilla.org/Security:Renegotiation Official RFC (released Friday) http://tools.ietf.org/html/rfc5746 Currently the only change in Firefox behavior is that it will not RE-negotiate with an unpatched server--but it will complete an initial handshake so it's still vulnerable to the flaw. This will break client-auth in most cases so there's a global pref that allows unsafe renegotiation, and another pref so you could whitelist a server or two you need to do client-auth with. Firefox will also spit out messages to the error console for each unpatched server it encounters. Another pref will show broken-ssl indicators for such servers and yet another will refuse connections to unpatched servers if you really want to get hardcore (and not use SSL at all for a while). These are _test_ builds and don't necessarily reflect how we'll ship a future Firefox update. For updates on the stable branches we'll probably have to allow unsafe renegotiation for a while, it's not a good strategy to ship a security updates and force people to choose between security and connecting with their bank/gov't/work. Or we might have to do some UI work so affected users can tweak this without having to wade into about:config. Although currently not an option, one approach might be to downgrade EV sites to normal SSL if they aren't patched and at least put pressure on the sites that think they have something to protect. Later this year we can start showing broken SSL indicators for unpatched servers, when at least some servers are patched. -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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: 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 FireFox (I am using FF 2.0.10). Now, if requested keys are for signing - everything looks good. But if requested keys are for key exchange (e.g. rsa-ex), the generated CRMF request structure has a number of issues. Here are the issues I am facing: 1) A PKIArchiveOptions control is included (http://www.ietf.org/rfc/ rfc4211.txt, section 6.4). The EncryptedKey structure in it is encoded as a SEQUENCE while it actually is a CHOICE. Our CRMF decoder is throwing as soon as it sees this structure. Shall I raise a bug ? 2) The EncryptedKey is encoded as the now deprecated EncryptedValue structure. Is there a plan to encode the value with EnvelopedData structure any time soon ? 3) Finally, the ProofOfPossession structure looks broken in this scenario as what we see is: A2 05 80 03 00 03 00, which does not seem to relate to any of the permitted options desrcibed in RFC 4211, section 4. FYI: If CRMF request contains cert request for a signing key pair the ProofOfPossession is valid (a correct instance of POPOSigningKey) and is correctly verified by our decoder. Does anyone know if these issues have been addressed in FF 3.5 and if not, will they be addressed in the next releases of FF ? Many thanks in advance, Nikolai Koustov. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 problem--the real money is in bank heists. You can't ignore one problem or the other. The paper is not a surprise, but at the same time it's the crispest demonstration for why it's necessary to remove this broken algorithm everywhere it is being used, he said, before adding there are bigger things to worry about, like browser bugs and operating security bugs. Absolutely. Let's plan to phase out support for MD5 and move on to bigger issues. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 reported problems? Oh btw. where do you see three roots to drop? The three CAs who have recently issued certs to unauthorized parties are RapidSSL (md5 hack), Certstar/Comodo, and StartCom. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 root itself. Users could still get to the sites so we're not punishing users and not putting sites out of business, but the site owners are no longer getting what they paid for and that will put pressure on the CA. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 over the and other public sites bit, which I believe to be an attempt to cover things like government sites, charities and the like -- and as such that's pretty much still a true statement as well. Public, as opposed to private sites which might legitimately use a self-signed. Can you suggest better wording that would help our roughly 200 million users make the right choice? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 Thunderbird. Why is that any different? The fake CA these guys produced could be used to issue forged S/MIME certs too. Or authenticode certs. This problem is NOT limited to SSL. Or am I completely misunderstanding you? -Dan Veditz ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 reliably distinguish between DV and OV certs I'd love to see some UI difference there, too, and so would some of the Firefox UI folks I've talked to. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 'get certificate' (why I should have to do this is beyond me, since firefox obviously already has the certificate downloaded since it told me 'sec_error_untrusted_issuer', which it couldn't have known without the certificate in its possession ANYWAY) Not that it changes your point any, but if you set the pref browser.ssl_override_behavior to 2 then you won't need to get Certificate. Firefox 3.1 will have this behavior by default. If you set browser.xul.error_pages.expert_bad_cert to true then you won't have to click a link to reveal the add exception button, saving a click at that step, too. Firefox 3.1 won't be adopting that default though. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 for theoretical future damages incurred by using their free software? Put more rudely, why do you expect Daddy to fix it for you when you can fix it yourself, more easily and more quickly, if you want to? Isn't that a bit like an auto maker issuing a notice If you don't want your car to explode in a fender bender you can crawl under the right rear and remove the screw marked 34A on the following diagram. Everyone should be able to do that so I'm sure that gets the auto maker off the hook, right? Assuming all 200 million Firefox users even hear about the problem. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 updates for Firefox and other Mozilla-based products. And we don't have a magic switch we can flip in the office. We'd have to make the change, test the change, make the builds, ship the builds, users would have to update (about a week from ship until most users have the update). If the sole purpose of the update was to break lots of sites (from the user's POV) then some number of them disable updates, making them less secure in the future. If Comodo is acting in good faith then anything they can do would be lightyears faster than a client update. If they're not fulfilling their responsibilities then a permanent removal would make sense, but given the time scales it's hard to see how a temporary month-or-so removal helps. Maybe we need to build in something like a CRL that pings back to Mozilla that would let us revoke roots without having to ship a client update. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
