Re: Welcome to the "dev-security" mailing list
On Tuesday, 18 August 2020 05:57:19 CEST, Ragavendhiran Bhiman (rabhiman) via dev-security wrote: Hi, I am facing problems in NSS library libnsssoftkn package. Where can I report my problems on memory leak? Is it the right forum to post my query? https://bugzilla.mozilla.org/ Product: nss -> Libraries Thanks a lot. Regards, Raghavendran On 18/08/20, 9:24 AM, "dev-security on behalf of dev-security-requ...@lists.mozilla.org" dev-security-requ...@lists.mozilla.org> wrote: Welcome to the dev-security@lists.mozilla.org mailing list! To post to this list, send your message to: dev-security@lists.mozilla.org General information about the mailing list is at: https://lists.mozilla.org/listinfo/dev-security If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://lists.mozilla.org/options/dev-security/rabhiman%40cisco.com You can also make such adjustments via email by sending a message to: dev-security-requ...@lists.mozilla.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe without confirmation. It is: raghav1## Mailman can remind you of your lists.mozilla.org mailing list passwords once every month, although since most people don't like having their passwords mailed in the clear, this is disabled by default. If you prefer, you can enable this in your account options. There is a button on your options page that will email your current password to you. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: What are CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA used for?
On Friday, 7 December 2018 23:26:32 CET Eli the Bearded wrote: > In mozilla.dev.security, Jeremy Rand wrote: > > I was digging through the NSS source code, and I ran across two > > undocumented trust flags: CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA > > . > > > > As far as I can tell, CERTDB_INVISIBLE_CA seems to indicate that the UI > > should hide the existence of the CA from the user, while > > CERTDB_GOVT_APPROVED_CA seems to have something to do with crypto export > > regulations. I'm wondering if anyone can explain what exactly the > > intended purpose of these flags is, and whether they actually have any > > effect in any of the NSS software ecosystem (including Firefox, but also > > including the NSS certificate verifier, any of the various NSS tools > > distributed by Mozilla, and anything else that uses NSS that you're > > aware of). I can't think of any reason for CERTDB_INVISIBLE_CA to exist > > (other than making it easier for backdoors to be stealthily inserted, > > which I assume isn't the intended use case), and I'm also surprised that > > CERTDB_GOVT_APPROVED_CA is a thing in 2018 since (as far as I know) > > crypto export regulations haven't existed for a couple of decades. > > This four year old bug report claims they are not used anymore: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1045907 > > Comment 4 (in part): > > However, note line 1670. CERTDB_PRESERVE_TRUST_BITS is > > (CERTDB_USER | CERTDB_NS_TRUSTED_CA | > > CERTDB_VALID_CA | CERTDB_INVISIBLE_CA | CERTDB_GOVT_APPROVED_CA). > > So these don't have mappings through the PKCS #11 trust interface. > CERTDB_USER is set based on finding the associated private key. > CERTDB_GOVT_APPROVED_CA is set based on a different PKCS #11 > attribute. It's no longer used by NSS. > CERTDB_NS_TRUSTED_CA isn't used either. > > I'm not sure if CERTDB_VALID_CA or CERTDB_INVISIBLE_CA are even > stored anymore. I know NSS doesn't actually use them. > > Not sure if that's the reassurance you want. > > Elijah > -- > agrees that CERTDB_INVISIBLE_CA seems a dangerous thing yes, *if* it worked as its name suggests but NSS prises itself also on backwards compatibility, that unfortunately means that some identifiers that are no longer used need to be defined still as far as I can tell the MZBZ#1045907 is correct; while you can specify both the 'g' flag (to specify Government Approved CA) or 'i' (to supposedly make it invisible) in certutil trust flags, none of them have any effect - the CA remains visible and the 'G' flag is not reported I didn't find any other references to that constant: https://searchfox.org/nss/search?q=CERTDB_INVISIBLE_CA that would indicate special handling -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Disable certain ciphers and hashing algorithms while building FF and TB
On Tuesday, 13 March 2018 11:15:18 CEST f masood via dev-security wrote: > On Tuesday, January 23, 2018 at 9:39:46 AM UTC+5, f masood wrote: > > 1 I am building Mozilla Firefox and Mozilla Thunderbird 52 versions from > > source code. > > > > 2 By default all the ciphers and hashing algorithms are enabled while > > building those two applications. > > > > 3 How can I disable certain ciphers and hashing algos while building these > > two applications ? Can I specify in the CONF file or something ? > > > > 4 e.g I want to disable ALL other ciphers just one AES to be enabled > > I want to disable ALL other hashing algorithms just one SHA256 to be > > enabled > > > > (I know the above can have issues while communicating with major > > websites/email server) > PING !!! not when building, but you can do it at runtime using the policy mechanism used by Fedora: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings https://fedoraproject.org/wiki/Changes/CryptoPolicy -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mozilla RSA-PSS policy
On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote: > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario <hka...@redhat.com> wrote: > > and fine for NSS too, if that changes don't have to be implemented in next > > month or two, but have to be implemented before NSS with final TLS 1.3 > > version > > ships > > Is there a reason not to disable RSA-PSS support in NSS for certificate > signatures until that time? yes, disabling it without disabling RSA-PSS support in TLS (and thus TLS 1.3 in its entirety) is non-trivial and not possible with current code base > The argument in favor is that this would be a known-buggy implementation > (as already demonstrated by the parameter decoder) > The argument against is that, in addition to rejecting definitely-bad > certs, it would reject definitely-good certs, and thus would limit the > ability to test TLS1.3's experimental implementation. I don't think NSS does reject good certs, can you provide example of such a certificate? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla RSA-PSS policy
On Friday, 1 December 2017 16:33:10 CET Jakob Bohm via dev-security-policy wrote: > On 01/12/2017 16:23, Hubert Kario wrote: > > On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote: > >> On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario <hka...@redhat.com> wrote: > >>>> It does feel like again the argument is The CA/EE should say 'I won't > >>>> do > >>> > >>> X' > >>> > >>>> so that a client won't accept a signature if the CA does X, except it > >>>> doesn't change the security properties at all if the CA/EE does > >>>> actually > >>> > >>> do > >>> > >>>> X, and the only places it does affect the security properties are > >>>> either > >>>> already addressed (e.g. digitalSignature EKU) or themselves not > >>>> protected > >>>> by the proposed mechanism. > >>> > >>> a). I think you're talking about Key Usage, not Extended Key Usage > >>> b). digitalSignature is a Key Usage, not Extended Key Usage bit > >>> c). Extended Key Usage has only one flag for use in TLS - serverAuth - > >>> which > >>> doesn't say anything about applicability of the key for SKE signature > >>> but > >>> not > >>> RSA key exchange > >>> d). show me the clients that actually honour the Key Usage flags for TLS > >>> in a > >>> way that prevents use of certificate with rsaEncryption SPKI for RSA key > >>> exchange > >>> > >>> so, yes, I'm afraid that you "must be missing something" > >> > >> So while we started off in disagreement, it sounds like we have cycled > >> back > >> to the view that RSA-PSS-params, if present, should be memcmp() able > >> (between SPKI and Signature and between Signature and Policy) > >> So the only thing that we're debating here is whether or not expressing > >> RSA-PSS in the SPKI (at all) is a good thing. > >> > >> The view in favor of this is: > >> - Because CAs have made a complete mess of the existing rsaEncryption + > >> KU > >> , clients don't check KU for rsaEncryption (Notably, they do check KU for > >> ECDSA because that's necessary to distinguish from ECDH) > >> - If a certificate is encoded with rsaEncryption, it's possible for a > >> server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS > >> 1.3 > >> RSA-PSS ciphersuites > >> - If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that > >> the > >> implementation may be buggy and subject to Bleichenbacher > >> - And expressing (via the SPKI OID) is an 'effective' way to prevent that > >> downgrade, which itself is only a risk if you're using a buggy > >> implementation. > >> > >> Is that accurate? > > > > yes > > > >> To offset that risk, the goal is to use the SPKI algorithm as the signal > >> to > >> 'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5). > >> This, despite the fact that SPKI parsing does not correctly work on any > >> platform > > > > rejecting what you do not understand (iOS, Android) is completely valid > > and > > expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys > > imported from PKCS#12 file... > > > >>- Windows and NSS both apply DER-like BER parsers and do not strictly > >> > >> reject (Postel's principle, despite Postel-was-wrong) > > > > NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them > > (probably even 1.1.0), are you certain that Windows doesn't reject > > certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional > > code to know that the public key for OID rsaEncryption and rsassaPss is > > formatted in one and the same way... If you don't don't have that code, > > it looks like completely different key type (think EdDSA or ECDSA for > > RSA-only > > implementation) > > > >>- macOS and iOS reject unrecognized SPKIs as weak keys > >>- Android supports PSS-signatures but a provider for decoding said > >>public > >> > >> keys is not provided by default > >> > >> Are there any other arguments in favor of the PSS-SPKI not captured here? > > > > there is a remote chance that RSA-PSS with non-zero salts is strictly more > > secure (unforgeable) than PKCS#1 v1.5, but
Re: Mozilla RSA-PSS policy
On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote: > On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario <hka...@redhat.com> wrote: > > > It does feel like again the argument is The CA/EE should say 'I won't do > > > > X' > > > > > so that a client won't accept a signature if the CA does X, except it > > > doesn't change the security properties at all if the CA/EE does actually > > > > do > > > > > X, and the only places it does affect the security properties are either > > > already addressed (e.g. digitalSignature EKU) or themselves not > > > protected > > > by the proposed mechanism. > > > > a). I think you're talking about Key Usage, not Extended Key Usage > > b). digitalSignature is a Key Usage, not Extended Key Usage bit > > c). Extended Key Usage has only one flag for use in TLS - serverAuth - > > which > > doesn't say anything about applicability of the key for SKE signature but > > not > > RSA key exchange > > d). show me the clients that actually honour the Key Usage flags for TLS > > in a > > way that prevents use of certificate with rsaEncryption SPKI for RSA key > > exchange > > > > so, yes, I'm afraid that you "must be missing something" > > So while we started off in disagreement, it sounds like we have cycled back > to the view that RSA-PSS-params, if present, should be memcmp() able > (between SPKI and Signature and between Signature and Policy) > So the only thing that we're debating here is whether or not expressing > RSA-PSS in the SPKI (at all) is a good thing. > > The view in favor of this is: > - Because CAs have made a complete mess of the existing rsaEncryption + KU > , clients don't check KU for rsaEncryption (Notably, they do check KU for > ECDSA because that's necessary to distinguish from ECDH) > - If a certificate is encoded with rsaEncryption, it's possible for a > server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS 1.3 > RSA-PSS ciphersuites > - If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that the > implementation may be buggy and subject to Bleichenbacher > - And expressing (via the SPKI OID) is an 'effective' way to prevent that > downgrade, which itself is only a risk if you're using a buggy > implementation. > > Is that accurate? yes > To offset that risk, the goal is to use the SPKI algorithm as the signal to > 'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5). > This, despite the fact that SPKI parsing does not correctly work on any > platform rejecting what you do not understand (iOS, Android) is completely valid and expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys imported from PKCS#12 file... > - Windows and NSS both apply DER-like BER parsers and do not strictly > reject (Postel's principle, despite Postel-was-wrong) NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them (probably even 1.1.0), are you certain that Windows doesn't reject certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional code to know that the public key for OID rsaEncryption and rsassaPss is formatted in one and the same way... If you don't don't have that code, it looks like completely different key type (think EdDSA or ECDSA for RSA-only implementation) > - macOS and iOS reject unrecognized SPKIs as weak keys > - Android supports PSS-signatures but a provider for decoding said public > keys is not provided by default > > Are there any other arguments in favor of the PSS-SPKI not captured here? there is a remote chance that RSA-PSS with non-zero salts is strictly more secure (unforgeable) than PKCS#1 v1.5, but for the sake of argument let's say that what you said is the primary and only argument for RSA-PSS OID in SPKI so no, there aren't other arguments > I think that we agree on the substance of the PSS implementation - Must Be > Memcmp-able - makes many of the client complexity concerns. The deployment > complexity concerns are unavoidable - few clients support RSA-PSS in part > because of the disaster than is RFC 4055 - but that's a deployment concern, > not an implementation concern. > > As it relates to what changes this means for NSS: > - Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts > - That means NSS should NOT support arbitrary salt lengths, as doing so > adds flexibility at the cost of maintainability and security > - This resolves the DER-like BER decoding > - Strictly enforcing the KU for RSA-PSS (which it improperly enforces KUs > on keys today already, but hopefully RSA-PSS has not been ruined) > > Is that correct? yes, fine by me and fine
Re: Mozilla RSA-PSS policy
On Thursday, 30 November 2017 21:49:42 CET Ryan Sleevi wrote: > On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...@redhat.com> > > > > wrote: > > > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > > > > vulnerable to attacks like the Bleichenbacher, if it is not usable > > > > with > > > > PKCS#1 > > > > v1.5 it's not vulnerable in practice to such attacks > > > > > > A certificate does not produce signatures - a key does. > > > A certificate carries signatures, but only relevant to verifiers. > > > > and verifiers are who enforces if the signatures are sane > > and for verifiers only the certificate is visible, not private key > > and certificate for the user of the key is essentially a blob, not > > something > > he or she can edit, so it is a commitment (even for CA, as that self > > signed > > one is no longer in control of it) > > > > > Your reference to Bleichenbacher again makes it unclear if you're > > > expressing a concern about the protection of the private key or the > > > > quality > > > > > of the signatures, or whether you're conflating with ciphersuite > > > negotiation and encryption. > > > > key with rsaEncryption SPKI can be used for both signatures and > > encryption, > > key with RSA-PSS SPKI can't be used for encryption if at least one party > > is > > standards compliant > > > > and the only way the other party can tell if the key is a rsa or a rsa-pss > > key > > is by looking at the certificate > > > > so if the _private_ key is rsa or rsa-pss type is of purely philosophical > > concern > > Then I think this is an incredibly convoluted concern. > > If I'm understanding correctly - and I hope you can correct me if I'm not - > the view is that it is valuable to limit a public key via an unnecessary > complex encoding scheme so that it does not get used for encryption (in > what protocol? Obviously not X.509 - so presumably certificates) so that it > is robust against CCA like Bleichenbacher? > > It feels like I just spewed out words writing that out, because it does not > seem like it fits a consistent or coherent threat model, and so surely I > must be missing something. I discussed it with Bob Relyea, Daiki Ueno, Nikos Mavrogiannopoulos and they see it as a valid concern and acceptable solution. My feeling of the discussion on the TLS WG mailing about the same topic was the same - that prohibiting use of key for RSA key exchange has value. (continued below) > It does feel like again the argument is The CA/EE should say 'I won't do X' > so that a client won't accept a signature if the CA does X, except it > doesn't change the security properties at all if the CA/EE does actually do > X, and the only places it does affect the security properties are either > already addressed (e.g. digitalSignature EKU) or themselves not protected > by the proposed mechanism. a). I think you're talking about Key Usage, not Extended Key Usage b). digitalSignature is a Key Usage, not Extended Key Usage bit c). Extended Key Usage has only one flag for use in TLS - serverAuth - which doesn't say anything about applicability of the key for SKE signature but not RSA key exchange d). show me the clients that actually honour the Key Usage flags for TLS in a way that prevents use of certificate with rsaEncryption SPKI for RSA key exchange so, yes, I'm afraid that you "must be missing something" > > that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI? > > Both! > > I think the 'correct' solution from a policy perspective, given these > constraints, is: > - rsaEncryption as SPKI is perfectly fine (and, indeed, the only one that > interoperates) > - I would even go as far as to say rsaEncryption as SPKI should be > *required*, as anything else is merely an expression of intent that only > matters if the private key control has been lost or confused that's your opinion, not the community consensus > - The policy itself should express that while the certificate may not > express the intent, any other use of the associated private key is a > fundamental trust violation, regardless of whether or not clients will > accept it (again, because it means you've lost control of the key / cannot > keep it constrained as you intended to) I have no problem with phrasing it primarily in terms of policy and allowing for that policy to be duplicated in CA's certificate SPKI >
Re: Mozilla RSA-PSS policy
On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...@redhat.com> wrote: > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > > vulnerable to attacks like the Bleichenbacher, if it is not usable with > > PKCS#1 > > v1.5 it's not vulnerable in practice to such attacks > > A certificate does not produce signatures - a key does. > A certificate carries signatures, but only relevant to verifiers. and verifiers are who enforces if the signatures are sane and for verifiers only the certificate is visible, not private key and certificate for the user of the key is essentially a blob, not something he or she can edit, so it is a commitment (even for CA, as that self signed one is no longer in control of it) > Your reference to Bleichenbacher again makes it unclear if you're > expressing a concern about the protection of the private key or the quality > of the signatures, or whether you're conflating with ciphersuite > negotiation and encryption. key with rsaEncryption SPKI can be used for both signatures and encryption, key with RSA-PSS SPKI can't be used for encryption if at least one party is standards compliant and the only way the other party can tell if the key is a rsa or a rsa-pss key is by looking at the certificate so if the _private_ key is rsa or rsa-pss type is of purely philosophical concern > > > It does not do prevent such a signature from being created - that's what > > > > I > > > > > mean. > > > > now you're being silly > > > > the Mozilla policy doesn't prohibit the CA from making a service that will > > perform RSA private key operation on arbitrary strings either but we would > > still revoke trust from CA that would do such a thing, because just the > > fact > > that such a service _could_ have been used maliciously (to sign arbitrary > > certificates) is enough to distrust it! > > No, such CAs do exist, and we haven't revoked such trust. Your statement is > empirically false. > > That's why I'm trying to be explicit in the policy here - that the policy > is about the keys, not the certificates. but the private keys are invisible and they should be invisible to anyone but the owner! the only way to check if they are used according to their intention is to look at the corresponding certificate! it's fully an implementation's detail whether implementation stores the rsa- pss params with the private key or derives them from associated certificate - it doesn't matter > > I don't think that it's the act of making the signature that weakens the > > key > > Great, then we don't need to restrict keys. that's cherry picking and taking sentences out of context... > > > I understand - but I'm saying that what we're discussing fundamentally > > > relates to the key. > > > > > > If a CA was technically constrained to .com, said they would never issue > > > for something not .com, but then issued for .org, it's absolutely > > > grounds > > > for concern. > > > If it doesn't matter whether a CA issues for .com or .org, and they > > > > simply > > > > > choose to only issue for .com, then it doesn't make sense to require > > > clients to support the CA's expression of intent if doing so introduces > > > security risk to clients (and it does) and complexity risk. > > > > so where's the bug that removes support for that in Firefox? Will we get > > it in > > before the next ESR? /s > > You've again misunderstood the argument. But I'm not sure that there's much > value in continuing - I've attempted to get you to either outline the value > proposition or to outline the risks. the only risk you're bringing up again and again is a nebulous "but it's hard to do, so we may make mistakes" guess what: that's the case for all of crypto, all of network protocols, that's why we repeat the mantra of "don't implement crypto yourself", it's silly to bring it up in the first place > We've danced around on semantic games, And how am I supposed to answer to that without invoking an ad hominem? > but we've identified that there is no risk in comingling these hash > algorithms, no, there is risk, we just can't quantify it > that the only risk in being strict relates to a single software > product with an unknown (but understandably miniscule, by virtue of no bugs > being filed) number of extant certificates, while we have a profound > opportunity to do the Right Thing based on lessons repeatedly learned. that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI? > > you're arguing that machine readable C
Re: Mozilla RSA-PSS policy
On Wednesday, 29 November 2017 21:59:39 CET Ryan Sleevi wrote: > On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario <hka...@redhat.com> wrote: > > > So are you stating you do not believe cross-algorithm attacks are > > > > relevant? > > > > No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1 > > v1.5 > > are likely. > > > > I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be > > leveraged against both PKCS#1 v1.5 and RSA-PSS > > I'm really not sure how to parse your response. I'm not sure if your "No" > is your answer - as in you don't believe they're relevant - or "No" as you > disagreeing with my framing of the question and that "Yes", you do believe > they're relevant, despite them not being likely. > > I'm further not sure how to parse your remark about "users of PKCS#1 v1.5" > - as to whether you mean the signers or the verifiers. if the certificate is usable with PKCS#1 v1.5 signatures, it makes it vulnerable to attacks like the Bleichenbacher, if it is not usable with PKCS#1 v1.5 it's not vulnerable in practice to such attacks > > > Sure. But why does that intention - which cannot be technically enforced > > > > RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be > > technically > > enforced"? > > It does not do prevent such a signature from being created - that's what I > mean. now you're being silly the Mozilla policy doesn't prohibit the CA from making a service that will perform RSA private key operation on arbitrary strings either but we would still revoke trust from CA that would do such a thing, because just the fact that such a service _could_ have been used maliciously (to sign arbitrary certificates) is enough to distrust it! > If it doesn't prevent such a signature, and the act of signing weakens the > key itself, then such a constraint is pointless. > If it simply indicates to a client "Don't accept this signature", but the > act of signing weakens the key still, then such a constraint is pointless. > If it does not weaken the key, then indicating to the client such a > constraint is pointless, because any client that encounters such a > signature has proof that the CA has failed to abide by the policy of their > key - and if so, everything used with that key should be rightfully called > into question, and no 'damage mitigation' has been achieved. I don't think that it's the act of making the signature that weakens the key If I generate a certificate has RSA-PSS SPKI I won't be able to use it for PKCS#1 v1.5 signatures - no widely deployed server will use it like that and no widely deployed client will accept such use. So a chance that a key will be abused like that and will remain abused like that is negligible. and that's the whole point - defence in depth - to make it another hurdle to jump through if you want to do something stupid > > > and is itself related to the usage of the key, not the trust in the > > > signatures - need to be expressed in the certificate? > > > > If the certificates has SPKI with RSA-PSS id, that means exactly that - > > never > > trust PKCS#1 v1.5 signatures made with this key. > > Yes. And expressing that is pointless (see above). > > > > I disagree. I don't believe there's value in the expression of that from > > > the CA within the certificate, for the reasons I previously mentioned - > > > that intention can be subverted if the CA is willing to use SHA-1 or > > > SHA-256 when they declared they will not, or if the CA is not willing, > > > > then > > > > > it's introducing unnecessary complexity into the client ecosystem for > > > limited benefits. > > > > If the RSA-PSS parameters in SPKI say SHA-256, SHA-1 signature made with > > such > > certificates never was and never will be valid. So creating SHA-1 > > signatures > > is useless from point of view of legitimate CA. > > > > It's like having technically constrained CA limited to .com domain and > > issuing > > certificate for .org domain - no valid PKIX implementation will trust > > them. > > I understand - but I'm saying that what we're discussing fundamentally > relates to the key. > > If a CA was technically constrained to .com, said they would never issue > for something not .com, but then issued for .org, it's absolutely grounds > for concern. > If it doesn't matter whether a CA issues for .com or .org, and they simply > choose to only issue for .com, then it doesn't make sense to require > clients to support the CA's expression of intent if doing so introduces > secu
Re: Mozilla RSA-PSS policy
On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote: > On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > Because I do not consider making the salt length rigid (one value allowed > > for > > every hash) to be of any value. If it is not rigid, it would be silly to > > provide a correct encoding for every single possible valid encoding. > > I do not consider making the salt length flexible to be of any value. > Further, I point to the past issues with respect to flexibility - and to > the many CVEs across a wide spectrum of clients, including NSS, with > respect to decoding signature parameters, that such flexibility will be > actively detrimental both to the implementation within Mozilla products and > to the implementation within the broader Web PKI community. > > The extent of the argument for flexibility, so far, has been OpenSSL's > behaviour to produce RSA-PSS signatures with a maximal salt length. These > same clients are also incapable of parsing RSA-PSS SPKIs (that only came > recently, AFAICT). yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures, and my understanding is that we want the same kind of limitations for signatures and for SPKI - if only to limit the confusion > This probability of encountering such signatures within > the Web PKI itself is substantially lower, due to the many requirements > around protection of keys and the ease (or more aptly, difficulty) in > integrating such libraries with such systems - but even still, can be > configured by the client (nominally, the value of -1 indicates saltLen == > len(hash), while -2 indicates the maximal encoding) Web PKI, now - yes But the problem is that Microsoft CAs (for Active Directory) default to RSA- PSS signatures, which means that Firefox cannot be deployed on such internal networks. This does not help Firefox market share. and I'm not saying that it is not possible to create signatures with correct salt lengths with old OpenSSL - but it is not the default, so any kind of certificates that were created previously will likely use the default. That in turn means that it would require reprovisioning all certificates like that, not a task that is easy at scale, welcome or with any benefit from the PoV of users. > > > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 > > > and > > > RSA-PSS signatures with the same key? > > > > depends on the circumstances > > > > > > I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5. > > > > So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase > > the > > security of the system, but it doesn't decrease it either. > > So are you stating you do not believe cross-algorithm attacks are relevant? No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1 v1.5 are likely. I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be leveraged against both PKCS#1 v1.5 and RSA-PSS > If it is, then it either theorhetically or practically weakens the security > of the system. > If it's not, then there's no need to afford the flexibility. > > > if one does use rsa-pss only (or has such intention), then use of pkcs#1 > > v1.5 > > with such key would lower the security of the system. > > Sure. But why does that intention - which cannot be technically enforced RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be technically enforced"? > and is itself related to the usage of the key, not the trust in the > signatures - need to be expressed in the certificate? If the certificates has SPKI with RSA-PSS id, that means exactly that - never trust PKCS#1 v1.5 signatures made with this key. > I propose it doesn't > - which is where the need to express that intention introduces significant, > and unnecessary, complexity. I really don't think we're on the same page here... > > > 2) Do you believe it represents a security risk to mix hash algorithms > > > within RSA-PSS signatures with the same key? > > > > like I said before, the problem is not that the key can be used with > > sha-384 > > and sha-512 at the same time - that I don't see as a risk, at least not > > now > > Again, cross-algorithm attacks. > > > Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I > > don't > > think this should be allowed. > > But that's not a risk to the key - that's a risk being proposed in which > the client accepts SHA-1. > > > Now, one may expect that SHA-256 will go the way of SHA-1, then having > > ability > > say
Re: Mozilla RSA-PSS policy
On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario <hka...@redhat.com> wrote: > > > So no, we should not assume well-meaning actors, and we should be > > > > explicit > > > > > about what the "intention" of the RFCs is, and whether they actually > > > achieve that. > > > > but we should achieve that by saying "do this", not "don't do this", > > enumerating badness doesn't work - ask firewall people if you don't > > believe > > me. > > > > Or did we add to policy that keys revoked because they may haven been > > compromised (heartbleed) can't be reused? Ever? Even by a different CA? > > You've completely misframed my proposal. I'm enumerating a specific > whitelist of what is permitted. Every other option, unless otherwise > permitted, is restricted. I'm even going to the level of proposing a > byte-for-byte comparison function such that there's not even a prosaic > whitelist - it's such that the policy is black and white and transcends > language barriers by expressing directly in the technology. > > You're enumerating a blacklist - saying that all of the flexibility of 4055 > is permitted (except for these specific combinations), but propose to > enforce neither of those through code or policy. where did I do that? it's the second time you're putting words in my mouth, I really do not appreciate that. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla RSA-PSS policy
On Monday, 27 November 2017 20:31:53 CET Ryan Sleevi wrote: > On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario <hka...@redhat.com> wrote: > > > On the realm of CA policy, we're discussing two matters: > > > 1) What should the certificates a CA issue be encoded as > > > 2) How should the CA protect and use its private key. > > > > > > While it may not be immediately obvious, both your proposal and 4055 > > > attempt to treat #2 by #1, but they're actually separate issues. This > > > mistake is being made by treating PSS-params on CA certificates as an > > > important signal for reducing cross-protocol attacks, but it doesn't. > > > > This > > > > > is because the same public/private key pair can be associated with > > > > multiple > > > > > certificates, with multiple params encodings (and potentially the same > > > subject), and clients that enforced the silly 4055 restrictions would > > > happily accept these. > > > > the CA can also use sexy primes as the private key, making the private key > > easy to derive from the modulus... We can't list every possible way you > > can > > overturn the intention of the RFCs. > > > > we need to assume well-meaning actors, at least to a certain degree > > First, I absolutely disagree with your assumption - we need to assume > hostility, and design our code and policies to be robust against that. I > should hope that was uncontroversial, but it doesn't seem to be. my point was that there are some actions of the other party we interact with that must be taken on faith, like that the server_random is actually random, or the server private part of the key share stays secret, or a myriad other things that we cannot verify legitimacy or correctness of. Without assuming that good faith it's impossible to communicate. Same for generated keys provided to CAs. > Second, the only reason this is an issue was your suggestion (derived from > 4055, to be fair) about restricting the params<->signature interaction. The > flexibility afforded by 4055 in expressing the parameters, and then > subsequently constraining the validation rules, is not actually met by the > threat model. There was a threat model in RFC 4055? Is it so hard to imagine that a CA may want to ensure that the signatures it makes will never use weak hash? And even if it makes them, they won't be validated by a conforming implementation? > That is, if it's dangerous to mix the hash algorithms in PSS signatures > (and I'm not aware of literature suggesting this is necessary, versus being > speculative concern), then we should explicitly prohibit it via policy. > Requiring the parameters in the certificates does not, in any way, mitigate > this risk - and its presumptive inclusion in 4055 was to constrain how > signature-creating-software behaved, rather than how > signature-accepting-clients should behave. > > Alternatively, if mixing the hash algorithms is not fundamentally unsafe in > the case of RSA-PSS, then it's unnecessary and overly complicating things > to include the params in the SPKI of the CA's certificate. The fact that > 'rsaEncryption' needs to be accepted as valid for the issuance of RSA-PSS > signatures already implies it's acceptable, and so the whole SHOULD > construct is imposing on the ecosystem an unsupported policy. it would be nice if the world was black and white, it would make any kind of nuanced work so much easier... Those are all shades of grey, for some uses allowing possibility of cross- protocol attacks is not important, for other, not so much. > So no, we should not assume well-meaning actors, and we should be explicit > about what the "intention" of the RFCs is, and whether they actually > achieve that. but we should achieve that by saying "do this", not "don't do this", enumerating badness doesn't work - ask firewall people if you don't believe me. Or did we add to policy that keys revoked because they may haven been compromised (heartbleed) can't be reused? Ever? Even by a different CA? > > > So I think it's useful to instead work from a clean set of principles, > > > > and > > > > > try to express them: > > > > > > 1) The assumption, although the literature doesn't suggest it's > > > > necessary, > > > > > and it's not presently enforced in the existing WebPKI, is that the hash > > > algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single > > > hash algorithm for the private key. > > > > > > a) One way to achieve this is via policy - to state that all > > > signatures > > > > >
Re: Mozilla RSA-PSS policy
On Monday, 27 November 2017 17:28:02 CET Ryan Sleevi wrote: > On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > In response to comment made by Gervase Markham[1], pointing out that > > Mozilla > > doesn't have an official RSA-PSS usage policy. > > > > This is the thread to discuss it and make a proposal that could be later > > included in Mozilla Root Store Policy[2] > > > > I'm proposing the following additions to the Policy (leaving out exactly > > which > > sections this needs to be added, as that's better left for the end of > > > > discussion): > > - RSA keys can be used to make RSASSA-PKCS#1 v1.5 or RSASSA-PSS > > > > signatures on > > issued certificates > > > > - certificates containing RSA parameters can be limited to perform > > > > RSASSA-PSS > > signatures only by specifying the X.509 Subject Public Key Info algorithm > > identifier to RSA-PSS algorithm > > > > - end-entity certificates must not include RSA-PSS parameters in the > > > > Public > > Key Info Algorithm Identifier - that is, they must not be limited to > > creating > > signatures with only one specific hash algorithm > > > > - issuing certificates may include RSA-PSS parameters in the Public Key > > > > Info > > Algorithm Identifier, it's recommended that the hash selected matches the > > security of the key > > > > - signature hash and the hash used for mask generation must be the same > > > > both > > in public key parameters in certificate and in signature parameters > > > > - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and > > > > 64 > > bytes for SHA-512 > > > > - SHA-1 and SHA-224 are not acceptable for use with RSA-PSS algorithm > > > > 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844#c15 > > 2 - https://www.mozilla.org/en-US/about/governance/policies/ > > > > security-group/ > > certs/policy/ > > Hubert, > > Thanks for raising this issue in m.d.s.p. > > I think it's helpful to break the discussion into two (or more) parts. > > One part worth discussing is the CA policy - that is, what are CAs expected > to do or not do, and what constitutes "misissuance". Another part worth > discussing is client behaviour - what will NSS (and Mozilla) clients > support and not support, despite it not being misissuance, so that there's > a clear understanding about what's supported. but the latter must be a superset of the former. And it also describes the part that NSS will explicitly support (and thus must test) > The reason I make these distinction is that the relevant RFCs - 4055 and > 5766 - are bad RFCs. While well-intentioned, they were written at the > height of the obsession to 'parameterize all the things' to ensure 'future > compatibility' - but the consequence of this is that they introduced a > tremendous amount of complexity, while also mistaking risk mitigation for > policy advice. Because these RFCs confuse and conflate these two issues, > while also introducing significant area for mistakes, we need to be very > careful and very precise. > > On the realm of CA policy, we're discussing two matters: > 1) What should the certificates a CA issue be encoded as > 2) How should the CA protect and use its private key. > > While it may not be immediately obvious, both your proposal and 4055 > attempt to treat #2 by #1, but they're actually separate issues. This > mistake is being made by treating PSS-params on CA certificates as an > important signal for reducing cross-protocol attacks, but it doesn't. This > is because the same public/private key pair can be associated with multiple > certificates, with multiple params encodings (and potentially the same > subject), and clients that enforced the silly 4055 restrictions would > happily accept these. the CA can also use sexy primes as the private key, making the private key easy to derive from the modulus... We can't list every possible way you can overturn the intention of the RFCs. we need to assume well-meaning actors, at least to a certain degree > So I think it's useful to instead work from a clean set of principles, and > try to express them: > > 1) The assumption, although the literature doesn't suggest it's necessary, > and it's not presently enforced in the existing WebPKI, is that the hash > algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single > hash algorithm for the private key. > a) One way to achieve this is via policy - to state that all s
Re: Useful Heuristics
On Tuesday, 31 January 2017 09:27:30 CET Peter Bowen wrote: > On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario <hka...@redhat.com> wrote: > > On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote: > >> See notes inline about known cities with numbers in their name. > >> > >> On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen <pzbo...@gmail.com> wrote: > >> > While it is very hard to validate the subject content of certificates > >> > outside of DNS names, there are a number of heuristics that may be > >> > useful to trigger a deeper check to ensure that the data is accurate. > >> > > >> > A couple of these that I've found useful are: > >> > > >> > 1) If stateOrProvince or Locality type attributes contain a Number, > >> > this is a red flag. I've yet to find any verified legitimate case > >> > where this is correct > >> > >> Of course I hit send and then find a least one valid cases of a number: > >> > >> In Egypt (EG) there is a city called "6th of October". > >> > >> In the Czech Republic (CZ), ISO lists some subdivisions as having > >> numbers (https://www.iso.org/obp/ui/#iso:code:3166:CZ). Wikipedia > >> seems to suggest that these might not be current > >> (https://en.wikipedia.org/wiki/Regions_of_the_Czech_Republic), but I > >> think it should be considered reasonable for a CA to rely upon ISO > >> 3166. > > > > No, they still exist: > > https://en.wikipedia.org/wiki/Prague_1 > > http://www.praha1.cz/cps/index.html > > (note the address at the bottom of the page) > > Is the number part of the name of the stateOrProvince or is it a > postalCode? I know in Dublin there were numbered "postal districts" > prior to the implementation of Eircode, but the city and county are > both "Dublin" not "Dublin 8" or such. it is used as the name of city, so the following: Úřad městské části Praha 1 | Vodičkova 18, 115 68 Praha 1 is parsed as: Company: Úřad městské části Praha 1 Street: Vodičkova Building no: 18 Postal Code: 115 68 City: Praha 1 (implied) Country: Czech Republic > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > Am I parsing this correctly as follows? > > Company: Red Hat Czech s.r.o. > Street Address: Purkyňova 99/71 > Postal Code: 612 45 > City: Brno > Country: Czech Republic yes > Does this imply that addresses in the Czech Republic do not use a > state or province? yes, it's not used for postal addresses or legal documents, but if there's a field in form for it, it likely would be filled, so it being present in a X509 cert would not be surprising... that being said, for "Praha 1", the stateOrProvince would be "Praha" or "Hlavní město Praha" Speaking of uncommon locality names, in Budapest the districts use Roman numerals for names: https://en.wikipedia.org/wiki/Budapest#Districts -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Useful Heuristics
On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote: > See notes inline about known cities with numbers in their name. > > On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen <pzbo...@gmail.com> wrote: > > While it is very hard to validate the subject content of certificates > > outside of DNS names, there are a number of heuristics that may be > > useful to trigger a deeper check to ensure that the data is accurate. > > > > A couple of these that I've found useful are: > > > > 1) If stateOrProvince or Locality type attributes contain a Number, > > this is a red flag. I've yet to find any verified legitimate case > > where this is correct > > Of course I hit send and then find a least one valid cases of a number: > > In Egypt (EG) there is a city called "6th of October". > > In the Czech Republic (CZ), ISO lists some subdivisions as having > numbers (https://www.iso.org/obp/ui/#iso:code:3166:CZ). Wikipedia > seems to suggest that these might not be current > (https://en.wikipedia.org/wiki/Regions_of_the_Czech_Republic), but I > think it should be considered reasonable for a CA to rely upon ISO > 3166. No, they still exist: https://en.wikipedia.org/wiki/Prague_1 http://www.praha1.cz/cps/index.html (note the address at the bottom of the page) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Appropriate role for lists of algorithms and key sizes
On Saturday, 28 January 2017 06:51:10 CET Peter Gutmann wrote: > Jakob Bohm <jb-mozi...@wisemo.com> writes: > >DSA and ECDSA signatures are only secure if the hash algorithm is specified > >in the certificate, presumably as part of the AlgorithmIdentifier in the > >SubjectPublicKeyInfo. > > It's in the (badly-named) signature field of the cert, if it was in the > signatureAlgorithm it wouldn't be covered by the sig. Having said that, I > don't know how many implementations actually check whether what's in the > signature corresponds to the signatureAlgorithm, I tried it many years ago > (md5With... vs sha1With...) and nothing much seemed to notice, as long as > the signatureAlgorithm was the one that was correct for the signature. I've tested it for TLS signatures[1], and OpenSSL, NSS and GnuTLS do match the sig alg with the hash info structure in the actual signature. 1 - https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-certificate-verify-malformed-sig.py -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: SSL Certs for Malicious Websites
On Thursday 26 May 2016 05:13:43 Peter Gutmann wrote: > Richard Z <r...@linux-m68k.org> writes: > >If any criminal can easily get EV certificates what is the point of > >https? > The point of HTTPS is twofold: > > 1. Convince users that the Internet is safe to do business on > (financial transfers, medical data). > > 2. Provide a steady revenue stream for CAs. > > There's also something about privacy from NSA snooping, but that's a > recent thing, and mostly only geeks care about it. In addition > depending on how paranoid the geeks are, HTTPS may not provide the > privacy they want). people don't care only if you are asking the wrong questions[1], if you frame the question in the way they do understand, they do care: https://www.youtube.com/watch?v=XEVlyP4_11M 1 - https://www.youtube.com/watch?v=G0ZZJXw4MTA > Finally, point 1 doesn't really need HTTPS, you could just slap a > padlock into the UI and not bother with encryption. So it's mostly > point 2. I don't think that this level of cynicism is helping... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On Tuesday 17 May 2016 03:19:22 Peter Gutmann wrote: > Matt Palmer <mpal...@hezmatt.org> writes: > >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote: > >> knowingly issuing/tolerating certificates for sites known to inject > >> malware is > >> * contrary to user expectaions > > > >[Citation needed] > > So you're saying users expect CAs to certify malware sites? > > (There have been plenty of user studies showing that users expect the > padlock to protect them from malware, hackers, and all sorts of other > stuff. Please produce a study showing that users expect CAs to > certify malware sites and virus authors). then users expect impossible Go to Firefox and check what the connection information dialog says. Does it say that the party you're communicating with is trustworthy? CAs certify identity, always had, and unless they themselves start hosting those websites, they have no way to certify trustworthiness of the data served. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove Roots used for only Email and CodeSigning?
On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote: > 2) Remove included root certs that only have the Code Signing trust > bit enabled. To our knowledge, no one is using such root certs via > the NSS root store. I'm not familiar with the project, but Fedora Shared System Certificates[1] does use Mozilla Root list and it does encompass Java trust stores so Code Signing bits at the very least _should_ be used, if not already are used. 1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote: On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote: True, OTOH, if a third party says that there was a misissuance, that means there was one. I disagree. Only the domain owner knows for sure what is a misissuance, and what isn't. It seems likely that I might turn over all known certs for my domain to the third party, but they might find another one, and I might say oh, yeah, I forgot about that one. So a third party can only report to the domain owner, but cannot know if the cert is legitimate. the implied situation was that the tool is run by the domain owner/admin -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New certificate search tool - crt.sh
On Tuesday 09 June 2015 10:53:37 Rob Stradling wrote: On 08/06/15 15:09, Rob Stradling wrote: On 08/06/15 14:54, Hubert Kario wrote: On Wednesday 03 June 2015 09:43:23 Eric Mill wrote: This is outstanding - simple, but totally what people need to start getting the idea and benefit of CT. One high ROI addition might be RSS feeds for search terms. That way, I could create e.g. an IFTTT alert that emails me whenever a certificate is publicly logged as being issued for my domains. -- Eric +1 on the awesome tool Thanks Hubert. :-) and I would like to propose to extend the RSS to a general web API (JSON) Makes sense. I've added this to my to-do list. Hubert, I think a standard API for interfacing with CT monitors would be a bigger win than an API that's specific to https://crt.sh. See the message I just posted to the CA scope transparency thread. I agree, but we need to start from somewhere. and starting with a versioned API, that is precisely defined and documented, on the crt.sh website would be, IMHO, a good way to do that On Wed, Jun 3, 2015 at 8:56 AM, Rob Stradling rob.stradl...@comodo.com wrote: Hi. I thought folks here might find this useful. It's a web interface that lets you search for certs that have been logged by CT. https://crt.sh Pronounced search. :-) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Wednesday 10 June 2015 07:28:06 Rick Andrews wrote: I don't understand. The domain owner/admin is not a third party. the third party in question was an entity running the CT service and since they can produce a certificate signed by a trusted CA as a proof of misissuance, the data itself is also trusted. Independent of your trust of the third party. -Rick On Jun 10, 2015, at 4:01 AM, Hubert Kario hka...@redhat.com wrote: On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote: On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote: True, OTOH, if a third party says that there was a misissuance, that means there was one. I disagree. Only the domain owner knows for sure what is a misissuance, and what isn't. It seems likely that I might turn over all known certs for my domain to the third party, but they might find another one, and I might say oh, yeah, I forgot about that one. So a third party can only report to the domain owner, but cannot know if the cert is legitimate. the implied situation was that the tool is run by the domain owner/admin -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New certificate search tool - crt.sh
On Wednesday 03 June 2015 09:43:23 Eric Mill wrote: This is outstanding - simple, but totally what people need to start getting the idea and benefit of CT. One high ROI addition might be RSS feeds for search terms. That way, I could create e.g. an IFTTT alert that emails me whenever a certificate is publicly logged as being issued for my domains. -- Eric +1 on the awesome tool and I would like to propose to extend the RSS to a general web API (JSON) On Wed, Jun 3, 2015 at 8:56 AM, Rob Stradling rob.stradl...@comodo.com wrote: Hi. I thought folks here might find this useful. It's a web interface that lets you search for certs that have been logged by CT. https://crt.sh Pronounced search. :-) -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
On Monday 23 February 2015 18:55:34 Richard Barnes wrote: On Mon, Feb 23, 2015 at 5:28 PM, Matt Palmer mpal...@hezmatt.org wrote: On Mon, Feb 23, 2015 at 02:14:13PM -0800, Clint Wilson wrote: Lots of Enterprises and organizations have very legitimate requirements to add their own internal root CA to the NSS store. I suspect John's point is that lots of enterprises and organisations (I remember a time when those were the same thing...) have very legitimate requirements to add their own internal add-ons to Firefox, and he is simply calling out an apparent inconsistency in Mozilla's policies on these two object types. (John, if I'm misrepresenting your position, please feel free to correct me). If I understand correctly (dveditz CC'ed to correct me), the current add-on signing tool has a provision for signing add-ons that are not published through AMO. They still need to be submitted to AMO to be scanned and signed, but they're not published. However, the two situations aren't the same, and thus can't be compared so simplistically. Mozilla's signature on an add-on says, we're reasonably sure this add-on isn't going to do Bad Things to your browser, because they can wave automated scanning tools over the code to look for dodgy stuff. The closest thing I can think of for CA certificates would be if Mozilla OK'd only technically-constrained CA certs -- say, only for domains and IP ranges which the applicant was known to own. However, that is exactly the sort of thing that existing trusted root CAs do. I suspect that existing trusted root CAs would be unhappy if Mozilla took on this task. It would also be a significant cost to Mozilla, because determining authority to issue certs for an entire portion of the DNS space is a lot more manual effort than running a code analysis tool over an add-on. I think the benefit here would be more transparency than quality. If we only allowed changes to the root store by signed add-ons, then (1) Mozilla would at least have internal visibility into all the MitM roots being deployed, and (2) we could use the add-on blacklist facility to block things like Superfish once they were detected. These both seem beneficial in terms of mitigating risk due to MitM. However, it could be challenging to implement this control. In addition to the in-browser UI for adding roots (which could easily be disabled), certs can also be added to the NSS databases directly, even while the browser isn't active. To counter this risk, we would have to periodically snapshot the database and check that nothing else had changed it. I'm not sure the incremental benefit merits the level of development required. Nonetheless, if we can reinforce the idea that addons are the way to install roots by simply turning off the UI that exists, that could be beneficial. (Also, this is more of a Firefox discussion than a CA program discussion, so it might be more appropriate for dev.tech.crypto.) This is doubly problematic, as some people may want to preserve roots that were removed (see the recent removals of 1024 bit roots)... It's a big can of worms no matter how you approach it. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cert spam, or certs with huge numbers of hosts.
On Thursday 23 October 2014 14:30:59 John Nagle wrote: On 10/23/2014 02:00 PM, Richard Barnes wrote: illa and the CA/Browser Forum. And I suspect it is related to this: http://blog.cloudflare.com/introducing-universal-ssl/ You're probably right. What Cloudflare provides by default is Flexible SSL, in which Cloudflare acts as a MITM: For a site that did not have SSL before, we will default to our Flexible SSL mode, which means traffic from browsers to CloudFlare will be encrypted, but traffic from CloudFlare to a site's origin server will not. It's a form of security theater. Just enough to turn on the lock icon. To use Cloudflare you need to transfer the domain to Cloudflare. So it's hardly a MITM. It's a forward proxy service. And while it doesn't tell you if the servers themselves are securely configured, it does help against skriptkiddies riding on your local coffee shop wifi. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: HSTS
- Original Message - From: fhw...@gmail.com To: dev-security-policy@lists.mozilla.org Sent: Thursday, 25 September, 2014 7:39:33 PM Subject: Re: HSTS I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is About 2% of sites advertise HSTS, see https://www.trustworthyinternet.org/ssl-pulse/ -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Security Blog about SHA-1
- Original Message - From: Chris Palmer pal...@google.com To: Chris Egeland ch...@chrisegeland.com Cc: mozilla-dev-security-pol...@lists.mozilla.org dev-security-policy@lists.mozilla.org Sent: Wednesday, 24 September, 2014 11:53:58 PM Subject: Re: Security Blog about SHA-1 Also, there's no problem (from a Chrome UX perspective) because Mozilla's certificate expires on 7 December 2015 — well before that bad 1 Jan 2017 date, and even before the dodgy 1 Jan 2016 date. http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html SHA-1 signature algorithms are not per se bad right now; what's bad is certificate chains using SHA-1 that will/would be valid too far in the future. Between now and 1 Jan 2016, and between then and 1 Jan 2017, there is plenty of time to get a new certificate, signed with a SHA-256-based signature function. It's debatable if the 2016 date is good. NIST doesn't agree but yes, as far as Internet certs go, mozilla one is not so bad -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
- Original Message - From: s...@gmx.ch To: dev-security-policy@lists.mozilla.org Sent: Monday, 22 September, 2014 9:28:39 PM Subject: Re: Indicators for high-security features Am 22.09.2014 um 14:56 schrieb Henri Sivonen: On Wed, Sep 17, 2014 at 6:20 PM, Richard Barnes rbar...@mozilla.com wrote: -- Use of ciphersuites with forward secrecy Yes, but I think it makes sense to go further with ciphersuites. At minimum, RC4 should not qualify, but given how easy it is to enable AES-GCM if you can enable TLS 1.2 per the earlier point, why not require an AEAD suite (i.e. AES-GCM or an upcoming ChaCha20 suite) and set aside all perceived or actual CBC problems while at it? I think 3DES should not qualify, too. It's just the less worse alternative of RC4 to support IE 8. If we accept sha-1 signed certs, then 3DES is less of a concern. If we clean up everything and require 128 bit security through and through for high-sec indication, then yes, 3DES needs to get cut. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Indicators for high-security features
- Original Message - From: Anne van Kesteren ann...@annevk.nl To: Chris Palmer pal...@google.com Cc: Patrick McManus mcma...@ducksong.com, mozilla-dev-security-pol...@lists.mozilla.org, Richard Barnes rbar...@mozilla.com Sent: Friday, 19 September, 2014 1:52:18 PM Subject: Re: Indicators for high-security features On Thu, Sep 18, 2014 at 8:23 PM, Chris Palmer pal...@google.com wrote: Assuming we don't expand the definition of the origin, unless we implement mixed-everything blocking — mixed EV non-EV, mixed TLS 1.2 1.1, mixed AES-128 AES-256, mixed pinned keys non-pinned, et c. — then I don't think we should make any increased promise to the user. After all, the promise wouldn't be true. I'm not sure I follow. If there's mixed content you no longer get a lock at all in Firefox. Obviously we should not revert that. AFAIK, images do not trigger mixed content The hair I'd much rather split, by the way, is making each cryptographic identity a separate origin. Ponder for a moment how enjoyably impossible that will be... What are the issues? the vast majority of sites use external resources, CDNs, external APIs, google script hosting for popular libraries, etc. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 1024 bit root removal in the news
- Original Message - From: Kurt Roeckx k...@roeckx.be To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Monday, 8 September, 2014 10:48:35 AM Subject: 1024 bit root removal in the news In case nobody saw it yet, those things were in the news: https://community.rapid7.com/community/infosec/sonar/blog/2014/09/04/107000-web-sites-no-longer-trusted-by-mozilla http://threatpost.com/mozilla-1024-bit-cert-deprecation-leaves-107000-sites-untrusted/108114 I think those are misleading: - They count certificates that already expired - They probably count certificates seen on multiple IPs multiple Well, my scan also includes them: you can have sites with multiple SANs serving different content depending on IP or hostname... So depreciation of single certificate may actually cause problems for multiple /different/ sites. - They don't take into account that the site might send an alternative root that is not 1024 bit. or even be able to link to a different root provided the browser has a different intermediate certificate cached... But I'd say there's even bigger problem: they used historic data. Many sites were contacted by CAs to change their certificates to use different roots, they will still be counted towards the 107000 total even when their current configuration uses good roots (and was detected as such in their most recent scan)! So yes, the numbers were artificially inflated a bit. Hubert Kario stats posted here are way more useful. Thank you :) -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Phillip Hallam-Baker ph...@hallambaker.com To: Gervase Markham g...@mozilla.org Cc: Rob Stradling rob.stradl...@comodo.com, mozilla-dev-security-pol...@lists.mozilla.org, Hubert Kario hka...@redhat.com Sent: Friday, September 5, 2014 2:11:09 PM Subject: Re: Short-lived certs We probably need to mark them in some way as being intended to be short lived. And we certainly need to fix the problem of getting them renewed efficiently. I'd say that this is purely CA problem. Since the short lived certs are supposed to be a replacement for the revocation checking, using the same key for those certs is not a problem. As such, the CA may just re-sign the certificate on a daily basis and publish it in a non-obvious directory (e.g. SHA-1 hash of the certificate public key) if they don't want to make it easy to compute how many certificate they issue. Then the server downloads the certificate over HTTP, FTP, or gets it in email, validates if it matches the key it has, validates the signature and issuer and then starts serving it to clients. If you want to use new key for every certificate you'll have to use Simple Certificate Enrollment Protocol (SCEP), Certificate Management Protocol (CMP) or something similar. So it is possible to have a full spectrum between trivial and very complex as far as certificate re-issuance and management goes. I don't think it is good idea to mandate one specific implementation over another... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Gervase Markham g...@mozilla.org To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, September 4, 2014 12:21:50 PM Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. I'm not sure what gives us the removal of revocation info from certificate. I mean, if the recommendation for PKIX is to not check revocation info for certificates that have total validity period of less than, say 2 days, then inclusion or exclusion of AIA extension is secondary. There's also the must-staple extension in the works, which can be part of the plan: you either get short lived certs or you get a long lived with must-staple. They would provide the same security guarantees. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Gervase Markham g...@mozilla.org To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, September 4, 2014 3:04:33 PM Subject: Re: Short-lived certs On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of short-lived is something I want to declare out of scope for this particular discussion. I'm not sure what gives us the removal of revocation info from certificate. Because there are lots of clients out there who check revocation info always if the pointers are present. The only way to stop them doing that (and so realise the speed advantage) is by not putting revocation info in the cert. From what I heard (and my limited personal experience matches), is that the vast majority of clients not only completely ignore failures in OCSP retrieval (soft-fail) but completely lack any mechanism for revocation checking (be it OCSP or CRL). In fact, that is the main driver behind must-staple. Can you provide examples to the contrary? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit roots - Thawte and GTE CyberTrust
- Original Message - From: Kathleen Wilson kwil...@mozilla.com To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, September 2, 2014 10:43:56 PM Subject: Re: Removal of 1024 bit roots - Thawte and GTE CyberTrust On 9/2/14, 10:53 AM, Hubert Kario wrote: Removing the Thawte 1024 bit roots[1] causes following changes: Untrusted: +33 sites. Incomplete chain: +153, -2 sites. Complete chain: -184 sites. Sites that become untrusted: aclens.com@199.242.144.30 brillenplatz.de@83.141.56.30 copagloja.com.br@54.225.100.66 cqccms.com.cn@124.207.135.23 datatilsynet.no@80.232.122.99 drewag.de@77.75.249.212 easy-forex.com@64.14.56.6 fachverlag-computerwissen.de@78.111.65.215 foreverwedstore.com@208.77.51.191 gold-super-markt.de@94.186.152.196 gold-to-go.com@94.186.152.196 golf.de@194.97.154.131 gumball3000.com@134.0.19.106 jokerit.com@89.250.52.17 loytec.com@88.198.4.4 madeindesign.de@194.213.124.118 meventi.com@78.47.246.235 motor-talk.de@94.198.62.121 nct.ie@193.120.166.32 ncts.ie@193.120.166.32 now.cn@119.146.222.146 pctonline.com@66.181.99.28 recyclingtoday.com@66.181.99.26 santander.be@212.78.166.49 showoffimports.nl@91.216.34.51 slotastic.com@54.204.19.24 tcd.ie@134.226.14.90 todaynic.com@119.146.222.146 whitireia.ac.nz@202.2.11.59 www.cqccms.com.cn@125.35.1.213 www.now.cn@119.146.222.153 www.todaynic.com@119.146.222.153 www.uri.edu@131.128.1.19 Looks like those SSL certs are 5 year certs that were issued in 2010, so those site administrators will be needing to update their certs within the next year. The change is currently targeted for Firefox 35 (early January). That gives Thawte/Symantec time to contact these customers, and get their certs updated. OK, I'll definitely will do another scan before that time. Removal of the GTE root has bigger impact: complete -86 incomplete +17, -8 untrusted +77 since the list is so large I won't be quoting it here. Would you please attach the list to the bug? done -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Removal of 1024 bit roots - Thawte and GTE CyberTrust
I've finally found some time to analyse the data from last months scan to see what happens when additional roots are removed[1,2]. The scan took place between 11th and 19th of July 2014. Sites scanned are taken from Alexa top 1 million sites as of 11th of July. Overall, the certificate stats look like this: Statistics from 440559 chains provided by 585568 hosts Server provided chainsCount Percent -+-+--- complete 36329662.0416 incomplete29441 5.0278 untrusted 19283132.9306 Trusted chain statistics Chain length Count Percent -+-+--- 2 2385 0.5414 3 42883997.3397 4 9314 2.1141 5 210.0048 CA key size in chains Count -+- ECDSA 256 3 ECDSA 384 3 RSA 1024 1718 RSA 2045 1 RSA 2048 868749 RSA 4096 17615 Chains with CA keyCount Percent -+-+--- ECDSA 256 3 0.0007 ECDSA 384 3 0.0007 RSA 1024 1708 0.3877 RSA 2045 1 0.0002 RSA 2048 43888999.6209 RSA 4096 17235 3.9121 Signature algorithm (ex. root) Count --+- ecdsa-with-SHA384 3 sha1WithRSAEncryption 384856 sha256WithRSAEncryption49903 sha384WithRSAEncryption12768 Eff. host cert chain LoS Count Percent -+-+--- 8038570487.5488 112 54852 12.4505 128 3 0.0007 Removing the Thawte 1024 bit roots[1] causes following changes: Untrusted: +33 sites. Incomplete chain: +153, -2 sites. Complete chain: -184 sites. Sites that become untrusted: aclens.com@199.242.144.30 brillenplatz.de@83.141.56.30 copagloja.com.br@54.225.100.66 cqccms.com.cn@124.207.135.23 datatilsynet.no@80.232.122.99 drewag.de@77.75.249.212 easy-forex.com@64.14.56.6 fachverlag-computerwissen.de@78.111.65.215 foreverwedstore.com@208.77.51.191 gold-super-markt.de@94.186.152.196 gold-to-go.com@94.186.152.196 golf.de@194.97.154.131 gumball3000.com@134.0.19.106 jokerit.com@89.250.52.17 loytec.com@88.198.4.4 madeindesign.de@194.213.124.118 meventi.com@78.47.246.235 motor-talk.de@94.198.62.121 nct.ie@193.120.166.32 ncts.ie@193.120.166.32 now.cn@119.146.222.146 pctonline.com@66.181.99.28 recyclingtoday.com@66.181.99.26 santander.be@212.78.166.49 showoffimports.nl@91.216.34.51 slotastic.com@54.204.19.24 tcd.ie@134.226.14.90 todaynic.com@119.146.222.146 whitireia.ac.nz@202.2.11.59 www.cqccms.com.cn@125.35.1.213 www.now.cn@119.146.222.153 www.todaynic.com@119.146.222.153 www.uri.edu@131.128.1.19 Adding certificate from comment 13 from bugzilla[1] changes the stats compared to above results in very small way, only 6 hosts loose untrusted status: aclens.com@199.242.144.30 cqccms.com.cn@124.207.135.23 easy-forex.com@64.14.56.6 madeindesign.de@194.213.124.118 santander.be@212.78.166.49 www.cqccms.com.cn@125.35.1.213 So in total, removal of certificates referenced in [1] makes at least 27 hosts untrusted. Removal of the GTE root has bigger impact: complete -86 incomplete +17, -8 untrusted +77 since the list is so large I won't be quoting it here. As such, I'd say that removing those roots now would be premature. 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=986014 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.comg Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
- Original Message - From: Kurt Roeckx k...@roeckx.be To: Hubert Kario hka...@redhat.com Cc: Kathleen Wilson kwil...@mozilla.com, mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, August 5, 2014 12:44:13 AM Subject: Re: Removal of 1024 bit CA roots - interoperability On Mon, Aug 04, 2014 at 10:03:13AM -0400, Hubert Kario wrote: So I've analysed the data. Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 So this is in the order of 0.05% of the sites that would break? I'm happy to ignore that and just do it. 0.05% of sites doesn't mean 0.05% of users, especially if we look at local, not global, user share. Some of them are high profile sites, e.g.: volkswagen.at, dell.com, cadillaceurope.com, www.portaldasfinancas.gov.pt -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
- Original Message - From: David Huang linshunghu...@gmail.com To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Saturday, August 2, 2014 1:21:58 AM Subject: Re: New wiki page on certificate revocation plans This is great news! Regarding the max lifetime threshold of short-lived certificates, we ran study [1] a while back that indicated the average OCSP validity time was 4 days (while 87.14% were equal to or less than 7 days). Thus, FWIW, we suggested a certificate lifetime of 4 days in our paper [2] advocating short-lived certificates for revocation. [1] http://www.internetsociety.org/sites/default/files/12_4.pdf [2] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf Very interesting, thanks for sharing! This results are a bit scary though: OCSP responder: Max Validity lifetime http://EVIntl-ocsp.verisign.com 86 days 7 hours http://ocsp.verisign.com 20 days 21 hours How often did they provide responses valid for over a week? -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
- Original Message - From: Hubert Kario hka...@redhat.com - Original Message - From: Kathleen Wilson kwil...@mozilla.com == For this batch of root changes == We are still investigating if we should use this possible solution for this batch of root changes. Please stay tuned and continue to share data and test results that should be considered. So I've analysed the data. I simulated removal of 11 roots mentioned in bugs linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1021967: Entrust.net Secure Server Certification Authority 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39 GTE CyberTrust Global Root 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74 ValiCert Class 1 Policy Validation Authority E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E ValiCert Class 2 Policy Validation Authority 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6 ValiCert Class 3 Policy Validation Authority 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB NetLock Uzleti (Class B) Tanusitvanykiado 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF NetLock Uzleti (Class C) Tanusitvanykiado E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B VeriSign, Inc. / Class 3 Public Primary Certification Authority A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2 Sociedad Cameral de Certificacion Digital CB:A1:C5:F8:B0:E3:5E:B8:B9:45:12:D3:F9:34:A2:E9:06:10:D3:36 TDC Internet Root CA 21:FC:BD:8E:7F:6C:AF:05:1B:D1:B3:43:EC:A8:E7:61:47:F2:0F:8A The data (and as such, the certificates) were collected between 11th and 19th of July 2014 and did include Alexa top 1 million domain names as of 10th of July. With the above certificates: Server provided chainsCount Percent -+-+--- complete 35948461.6908 incomplete29543 5.0699 untrusted 19369233.2393 Without the above certificates: Server provided chainsCount Percent -+-+--- complete 35926561.6532 incomplete29663 5.0904 untrusted 19379133.2563 Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 Attached are the lists of those servers. (disclaimer: trust chain building did ignore host names, extended key usage limitations, and used OpenSSL for chain building) I've also gathered a bit extra statistics. The use of key sizes in CA certificates (count is number of chains that use them): With the 1024 bit roots: Chains with CA keyCount Percent -+-+--- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1776 0.399 RSA 2045 1 0.0002 RSA 2048 44339999.619 RSA 4096 16134 3.6248 Without the 1024 bit roots: Chains with CA keyCount Percent -+-+--- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1539 0.3459 RSA 2045 1 0.0002 RSA 2048 44330899.6229 RSA 4096 16121 3.6228 it has limited effect on overall security of connection (if we assume 80 bit level of security for both SHA1 and 1024 bit RSA and ignore signature algorithm on the root certs): With weak roots: Eff. host cert chain LoS Count Percent -+-+--- 8039841389.5119 112 46680 10.4876 128 2 0.0004 Without weak roots: Eff. host cert chain LoS Count Percent -+-+--- 8039830489.5093 112 46680 10.4902 128 2 0.0004 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Dynamic Path Resolution in AIA CA Issuers
- Original Message - From: Kurt Roeckx k...@roeckx.be To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, 31 July, 2014 9:54:45 AM Subject: Re: Dynamic Path Resolution in AIA CA Issuers On 2014-07-31 01:29, Ondrej Mikle wrote: I should probably add that a MitM attacker like an ISP can generally tamper with certificate chains sent in TLS handshake anyway, but AIA fetching would allow an adversary more hops away on a different continent to tamper with the connection. How would an ISP tamper with the certificates send in TLS without TLS giving an error that the packets were tampered with? Because until you parse the certificates and validate the signatures you have no way of knowing if the packets you receive are coming from the server or the MitM box at the ISP. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: Chris Palmer pal...@google.com To: Hubert Kario hka...@redhat.com Cc: David E. Ross nobody@nowhere.invalid, mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, 22 July, 2014 1:08:57 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario hka...@redhat.com wrote: and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections I'm pretty sure Firefox merely remembers your decision to click through the warning, not that it pins the keys/certificates in the chain you clicked through on. Although I have proposed that for certain use-cases, its applicability is limited — will people know how to recover if the key(s) change(s)? No, I'm sure it remembers the certificate. I have setup a SNI-enabled server that returns one certificate for two different virtual hosts. When the certificate was about to expire, I changed it to a new one signed by a trusted CA, for the site for which the CN matched, the Firefox didn't even bat an eye, for the site for which I had to waive the mismatched CN in the past, I had to waive the certificate again. I can retests with self signed certificates, but I'd be very surprised if it didn't work exactly the same. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: diaf...@gmail.com To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Monday, 21 July, 2014 4:08:30 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites So the general top criticism I'm seeing to this proposal is that it's too expensive (in both time and money) get an SSL certificate. I'm feeling a general consensus that HTTPS is desired, but it's too difficult to attain for many sysadmins. So what can be done to lower the threshold to get sysadmins to start serving over HTTPS? Allowing self-signed certs is one proposal. What are some others? This is actually what most Linux distributions do by default, so I'd say that any other solutions should be *in addition* to accepting self signed certs. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: David E. Ross nobody@nowhere.invalid To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Sunday, 20 July, 2014 4:39:09 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. I was able to get a certificate for a year for $3 that links up to COMODO CA. That was without any promotions or coupons - regular price. You need to pay few times more for hosting than you need to pay for certificates. Also, while you might have marked them as untrusted, I'm sure that the vast majority (over 99%) of users didn't. Rightfully so. They are not supposed to thwart any and all attacks. They are there so that trivial attacks can't be launched. There are about 1000 CA's that are trusted by Firefox (by linking up to root CA certs or by being in the root store directly), how many of them have you marked as untrustworthy? +1 on the idea of starting treating HTTP as insecure and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Removal of 1024 bit CA roots - interoperability
The newly released NSS 3.16.3 doesn't include 1024 bit CA certificates any more[1]. This will of course impact users of servers that still use it. Interestingly, some intermediate CA certificates that were originally signed by those 1024 bit CA certificates got cross signed using different roots that will remain trusted[2]. In particular I mean the USERTrust Legacy Secure Server CA certificate. Problem is, that some administrators haven't updated their servers to provide the new intermediate certificate for 3 years. As such, I don't think we can realistically expect all of them to update their configuration now. While testing found just 217 sites as of 2014-05-30 that are impacted by this change[2], it did test only top 200 000 SSL enabled servers. I'd estimate the total number in Alexa top 1M alone at over 373k. Moreover, some of those sites include sites that are in the top 1 sites, like groupon.my[3]. So loss of connectivity to them may have bigger impact than the above quoted 217 could lead us to believe. That's why I think that we should ship the intermediate CA certificates to make Firefox continue to interoperate with such sites. I don't mean only the USERTrust certificate, but others too, if they exist. 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1021967 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=936304 3 - https://www.ssllabs.com/ssltest/analyze.html?d=groupon.my -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
