Announcing Mozilla::PKIX, a New Certificate Verification Library

3282 views
Skip to first unread message

Kathleen Wilson

unread,
Apr 7, 2014, 6:33:50 PM4/7/14
to mozilla-dev...@lists.mozilla.org
All,

We have been working on a new certificate verification library for
Gecko, and would greatly appreciate it if you will test this new library
and review the new code.

Background

NSS currently has two code paths for doing certificate verification.
"Classic" verification has been used for verification of non-EV
certificates, and libPKIX has been used for verification of EV
certificates.

As many of you are aware, the NSS team has wanted to replace the
"classic" verification with libPKIX for a long time. However, the
current libPKIX code was auto-translated from Java to C, and has proven
to be very difficult to maintain and use. Therefore, Mozilla has created
a new certificate verification library called mozilla::pkix.

Request for Testing

Replacing the certificate verification library can only be done after
gaining sufficient confidence in the new code by having as many people
and organizations test it as possible.

We ask that all of you help us test this new library as described here:
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing

Testing Window: The mozilla::pkix certificate verification library is
available for testing now in Nightly Firefox builds. We ask that you
test as soon as possible, and that you complete your testing before
Firefox 31 exits the Aurora branch in June.
(See https://wiki.mozilla.org/RapidRelease/Calendar)

Request for Code Review

The more people who code review the new code, the better. So we ask all
of you C++ programmers out there to review the code and let us know if
you see any potential issues.
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review


We look forward to your help in testing and reviewing this new
certificate verification library.

Mozilla Security Engineering Team

Kathleen Wilson

unread,
Apr 24, 2014, 2:07:28 PM4/24/14
to mozilla-dev...@lists.mozilla.org
On 4/7/14, 3:33 PM, Kathleen Wilson wrote:
> All,
>
> We have been working on a new certificate verification library for
> Gecko, and would greatly appreciate it if you will test this new library
> and review the new code.


A special Bug Bounty program has been announced regarding this:
https://blog.mozilla.org/security/2014/04/24/10000-security-bug-bounty-for-certificate-verification/

Also, we added a section to the wiki page to list some behavior changes
that could cause a website certificate to no longer validate with
Firefox 31.
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

Kathleen

Martin Paljak

unread,
Apr 25, 2014, 7:46:51 AM4/25/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> Also, we added a section to the wiki page to list some behavior changes that
> could cause a website certificate to no longer validate with Firefox 31.
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

What is the rationale for this:

4. Mozilla::pkix performs chaining based on issuer name alone, and
does not require that issuer's subject key match the authority key
info (AKI) extension in the certificate. Classic verification enforces
the AKI restriction.

?
--
Martin
+372 515 6495

Martin Paljak

unread,
Apr 25, 2014, 7:46:51 AM4/25/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

Erwann Abalea

unread,
Apr 25, 2014, 9:59:36 AM4/25/14
to mozilla-dev...@lists.mozilla.org
AKI is only a helper for certificate path building.
It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match.

Zack Weinberg

unread,
Apr 25, 2014, 12:18:27 PM4/25/14
to mozilla-dev...@lists.mozilla.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/25/2014 09:59 AM, Erwann Abalea wrote:
> Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a �crit :
>>
>> What is the rationale for this:
>>
>> 4. Mozilla::pkix performs chaining based on issuer name alone,
>> and does not require that issuer's subject key match the
>> authority key info (AKI) extension in the certificate. Classic
>> verification enforces the AKI restriction.
>
> AKI is only a helper for certificate path building. It's mandatory
> for CAs to issue certificates with matching keyIdentifiers
> (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory
> for relying parties to verify that the values match.

That doesn't seem like enough of a justification to me. It may not be
mandatory, but please explain why it is not *necessary* (i.e. why no
security guarantees depend on it).

zw

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWorRAAoJEJH8wytnaapkkO8QAI4IrF43KkSBzkN6YcZ6gvUu
2xqzkZGSJJDHJkrJJCIEAlcpLPWlXfrhCuhhr5+tXQ6hgKm+i5HCCsE+vkd9bqHx
FQO+Qg/pG+Y1UWfJ57/0FuUwffl42ox+6zXeQPSEVDmB3nXaVxpJuLgIQpU6Pvp2
E/pc8E6FHJ1Ua6SHqSNFYj8qirtu8wnKu2ubhnbYfNJKRqgLjufe6bAPjunnwj/5
TbABPSkgll9drHtc5KzNyG6zWlboVdyNLZEVOkzsmXAusy0fRYiqK5U05BexGPdZ
m7lsfmj78hvSe1Un+C6h4scvi9MLs851HBiJopAV0rltvZBryZZxE0nmYswZp3bo
GrHylX/Yxx5AddQl8A3BDR5HfI/xSFej0VgAhSChNmkSVLROAFpSlK0IuYfhtxd6
OkxfDhBDgCVY/tB89kXmu0vzW9xwjsgmFQ0vvHHVJwdOfJXs8Cky1LWextIdUc5y
zEmiM5pfd/GRutTHKjK7dWNqj1mpK6uJbM8QIG0tMOcpJ41Ja8rXYhKem9LIBjf6
s2j19puGw0Vgi9mmSfqrRL4IiW677m3vizXHMgeFkyKwMkJHRNU7IVN+8N+KTQ7n
flhjXTf/A8OJWpcQWIdiQrx73ul/jxGoROsQ+HkcfWhTQWa/ZHdPxd2ivyl3xGc0
yxo93+ET5uXRGoY24EVx
=dTnD
-----END PGP SIGNATURE-----

Camilo Viecco

unread,
Apr 25, 2014, 1:09:31 PM4/25/14
to dev-tec...@lists.mozilla.org

On 4/25/14, 9:18 AM, Zack Weinberg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 04/25/2014 09:59 AM, Erwann Abalea wrote:
>> Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a �crit :
>>> What is the rationale for this:
>>>
>>> 4. Mozilla::pkix performs chaining based on issuer name alone,
>>> and does not require that issuer's subject key match the
>>> authority key info (AKI) extension in the certificate. Classic
>>> verification enforces the AKI restriction.
>> AKI is only a helper for certificate path building. It's mandatory
>> for CAs to issue certificates with matching keyIdentifiers
>> (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory
>> for relying parties to verify that the values match.
> That doesn't seem like enough of a justification to me. It may not be
> mandatory, but please explain why it is not *necessary* (i.e. why no
> security guarantees depend on it).
Lets pretend for the sake of the argument that you are an attacker and
can modify the value of the AKI (assume that the AKI is not signed by
the CA). You will notice that this field is NOT used to determine your
identity (like the name or subject-alt-names) you or the determine
capabilites of your cert (and private key) (like the basic constraints,
KU, EKU, Cert Policies, name constraints extensions).

Is it more clear now?

Camilo

Martin Paljak

unread,
Apr 25, 2014, 3:09:58 PM4/25/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Fri, Apr 25, 2014 at 4:59 PM, Erwann Abalea <eab...@gmail.com> wrote:
> AKI is only a helper for certificate path building.
> It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match.


While I might agree to the reasoning behind why it doesn't matter, I
don't see why a cautious implementation (not to call it *paranoid*
which might have a different meaning to some) does not *check* what
others are *required to do*. And do that *by default*. Not doing it
under some more relaxed conditions ("export cipher" anyone ?).

Best,

Martin Paljak

unread,
Apr 25, 2014, 3:09:58 PM4/25/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

Erwann Abalea

unread,
Apr 26, 2014, 4:44:41 AM4/26/14
to mozilla-dev...@lists.mozilla.org
Priorities. Let them first do their mandatory duties, and *then* add some paranoid checks.
Took a quick look at the code, it looks like KU/EKU checks is ok, BasicConstraints checks are weirdly done, NameConstraints checks are hard to follow, CertificatePolicies checks is a joke. I now notice that I didn't see date checks (I may have missed it). Init part of the validation code follows RFC5280 algorithm, but that's all.
Revocation checking is done by OCSP only.
And there's a LOT of magic values everywhere; I noticed them first for OID comparisons, but there's little to no use of an ASN.1/DER parser (IIRC, there's already 2 implementations in NSS).

David Keeler

unread,
Apr 28, 2014, 12:11:30 PM4/28/14
to dev-tec...@lists.mozilla.org
On 04/26/2014 01:44 AM, Erwann Abalea wrote:
> Took a quick look at the code, it looks like KU/EKU checks is ok, BasicConstraints checks are weirdly done, NameConstraints checks are hard to follow, CertificatePolicies checks is a joke. I now notice that I didn't see date checks (I may have missed it). Init part of the validation code follows RFC5280 algorithm, but that's all.
> Revocation checking is done by OCSP only.
> And there's a LOT of magic values everywhere; I noticed them first for OID comparisons, but there's little to no use of an ASN.1/DER parser (IIRC, there's already 2 implementations in NSS).

Erwann,

It would be a great help if you could either expand on the issues you
found here or file bugs in bugzilla. The sooner we catch and deal with
issues the better.

Date checks are done here:
https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#29
There's a minimal DER decoder here:
https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixder.h
that implements what is needed for this library and nothing more (for
example,
https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp
makes heavy use of it).

Thank you,
David

Kyle Hamilton

unread,
Apr 28, 2014, 7:10:19 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Fri, Apr 25, 2014 at 6:59 AM, Erwann Abalea <eab...@gmail.com> wrote:
> AKI is only a helper for certificate path building.
> It's mandatory for CAs to issue certificates with matching keyIdentifiers
(issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying
parties to verify that the values match.

Erwann (and all),

AKI is necessary for multiple public keys used by the same Subject
certifier. It's particularly useful for a "rolling chain" of public keys,
each one used to sign certificates within a given period of months, but
with overlapping validity periods.

0 3 6 9 12 15 18 21 24 27
|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....|.....|.....|
|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....|.....|
|.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....|
|.....|.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|
|.....|.....|.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|

In this diagram, 'u' means "in use". 'v' means "valid". The numbers at
the top refer to 'counted months'. So, in this case, the private keys are
used for 3 months while their issued certificates are valid for up to 12
months. There are 5 potential keys, identifiable only through the use of
the AKID extension.

Yes, the certified entity is supposed to provide its verifiable chain, back
to the root (but not including the root)... at least, according to TLS, and
other IETF Security working-area client protocols. But, it's not mandatory
per PKIX, and it's also not mandatory per X.509, either.

I believe this to be a poor design decision on the part of Mozilla.

-Kyle H

Kyle Hamilton

unread,
Apr 28, 2014, 7:10:19 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Fri, Apr 25, 2014 at 6:59 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit :

Kyle Hamilton

unread,
Apr 28, 2014, 7:13:40 PM4/28/14
to mozilla's crypto code discussion list
(quick correction to my prior email: the certificates issued by the
intermediate are valid for up to 15 months in that example, and the
key is retired when it cannot sign anything with a validity less than
12 months.)

-Kyle H


On Mon, Apr 28, 2014 at 4:10 PM, Kyle Hamilton <aero...@gmail.com> wrote:


On Fri, Apr 25, 2014 at 6:59 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit :
Edited to add:
(quick correction to my prior email: the certificates issued by the
intermediate are valid for up to 15 months in that example, and the
key is retired when it cannot sign anything with a validity less than
12 months.)<div class="gmail_extra"><br><br><div
class="gmail_quote">On Mon, Apr 28, 2014 at 4:10 PM, Kyle Hamilton
<span dir="ltr">&lt;<a href="mailto:aero...@gmail.com"
target="_blank">aero...@gmail.com</a>&gt;</span>
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir="ltr"><br><div><div><div><div class=""><div><span
style="font-family:arial,helvetica,sans-serif">On Fri, Apr 25, 2014 at
6:59 AM, Erwann Abalea &lt;eabalea@gm</span><a href="http://ail.com"
target="_blank">ail.com</a>&gt; wrote:<br>&gt; Le vendredi 25 avril
2014 13:46:51 UTC+2, Martin Paljak a écrit :<br>
&gt;&gt; On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson &lt;<a
href="mailto:kwi...@mozilla.com"
target="_blank">kwi...@mozilla.com</a>&gt; wrote:<br>&gt;&gt; &gt;
Also, we added a section to the wiki page to list some behavior
changes that<br>
&gt;&gt; &gt; could cause a website certificate to no longer validate
with Firefox 31.<br>&gt;&gt; &gt; <a
href="https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes"
target="_blank">https://wiki.mozilla.org/<wbr>SecurityEngineering/mozpkix-<wbr>testing#Behavior_Changes</a><br>
&gt;&gt;<br>&gt;&gt; What is the rationale for
this:<br>&gt;&gt;<br>&gt;&gt; 4. Mozilla::pkix performs chaining based
on issuer name alone, and<br>&gt;&gt; does not require that issuer's
subject key match the authority key<br>
&gt;&gt; info (AKI) extension in the certificate. Classic verification
enforces<br>&gt;&gt; the AKI restriction.<br>&gt;<br>&gt; AKI is only
a helper for certificate path building.<br>&gt; It's mandatory for CAs
to issue certificates with matching keyIdentifiers
(issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for
relying parties to verify that the values match.<br>
<br></div></div><div>Erwann (and
all),<br></div><div><br><div><div><div><div><div><div><span
style="font-family:courier new,monospace"><span
style="font-family:arial,helvetica,sans-serif">AKI is necessary for
multiple public keys used by the same
Subject certifier. &nbsp;It's particularly useful for a "rolling chain" of
public keys, each one used to sign certificates within a given period of
months, but with overlapping validity periods.<br></span><br>0 &nbsp;
&nbsp; 3 &nbsp; &nbsp; 6 &nbsp; &nbsp; 9 &nbsp; &nbsp;12 &nbsp;
&nbsp;15 &nbsp; &nbsp;18 &nbsp; &nbsp;21 &nbsp;
&nbsp;24&nbsp;&nbsp;&nbsp;
27<br>|uuuuu|vvvvv|vvvvv|vvvvv|<wbr>vvvvv|.....|.....|.....|.....|<br></span></div><span
style="font-family:courier
new,monospace">|.....|uuuuu|vvvvv|vvvvv|<wbr>vvvvv|vvvvv|.....|.....|.....|<br>
</span></div><span style="font-family:courier
new,monospace">|.....|.....|uuuuu|vvvvv|<wbr>vvvvv|vvvvv|vvvvv|.....|.....|<br></span></div><span
style="font-family:courier
new,monospace">|.....|.....|.....|uuuuu|<wbr>vvvvv|vvvvv|vvvvv|vvvvv|.....|<br>
</span></div><div><span style="font-family:courier
new,monospace">|.....|.....|.....|.....|<wbr>uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|<br></span></div><div><span
style="font-family:courier new,monospace"><br></span></div><span
style="font-family:arial,helvetica,sans-serif">In
this diagram, 'u' means "in use".&nbsp; 'v' means "valid".&nbsp; The
numbers at
the top refer to 'counted months'.&nbsp; So, in this case, the private keys
are used for 3 months while their issued certificates are valid for up
to 12 months.&nbsp; There are 5 potential keys, identifiable only through the
use of the AKID extension.<br><br></span></div><span
style="font-family:arial,helvetica,sans-serif">Yes,
the certified entity is supposed to provide its verifiable chain, back
to the root (but not including the root)... at least, according to
TLS, and other IETF Security
working-area client protocols.&nbsp; But, it's not mandatory per PKIX, and
it's also not mandatory per X.509, either.<br><br></span></div><span
style="font-family:courier new,monospace"><span
style="font-family:arial,helvetica,sans-serif">I believe this to be a
poor design decision on the part of Mozilla.<br>
</span></span><div><span
style="font-family:arial,helvetica,sans-serif"><br></span></div><span
style="font-family:arial,helvetica,sans-serif">-Kyle H<br></span><span
style="font-family:arial,helvetica,sans-serif"><br></span></div>
</div></div></div></div>
</blockquote></div><br></div>

Erwann Abalea

unread,
Apr 28, 2014, 7:29:59 PM4/28/14
to mozilla-dev...@lists.mozilla.org
Bonjour,
I know DER tools is only a decoder, and from https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921 the construction of the request makes heavy use of hex magic to build a request.
Quick bug: on the same function, line 945, the test against issuerCert->serialNumber.len should be against cert->serialNumber.len instead.

Logic at https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#107 doesn't follow RFC5280 algorithm, and will probably fail with FBCA and other large cross-certification constructions such as CertiPath (I'm sure they use PolicyMappings, they may use PolicyConstraints, it has slipped off my memory). Current code is sufficient for webPKI, even EV. The normalized algorithms are clearly a torture to read (both X.509 and RFC5280, logic is slightly different but the result is identical), but it's necessary.

Same file, #229 (CheckBasicConstraints) doesn't take into account potential self-issued certificates in the chain (they don't account for a "level" in the pathLenConstraint).

Same file, #370 (CheckExtendedKeyUsage), if encodedEKUs is NULL and a requiredEKU is asked for, it ends with a success. If encodedEKUs is present and contains the anyExtendedKeyUsage OID, it isn't recognized as valid. And I'm not sure it allows full support for technically constrained CAs (this is done with EKUs used as constraints, which is contrary to X.509/RFC5280, but it was pushed by Mozilla).

Erwann Abalea

unread,
Apr 28, 2014, 7:45:57 PM4/28/14
to mozilla-dev...@lists.mozilla.org
Bonjour Kyle,
The chain builder can test all possible issuers until it finds a valid one (that's what OpenSSL does, for example). The AKI is only here to say "pssst, this is most probably the certificate you should try first".

There's another missing check on the new PKIX lib, PrivateKeyUsagePeriod extension. It's been declared as deprecated in RFC2459 and 3280, isn't mentioned anymore in RFC5280, but it's still defined in X.509, and used on some places, such as CSCA (e-passports, where CA renewal with rekey also happen on a regular basis).

> Yes, the certified entity is supposed to provide its verifiable chain, back
> to the root (but not including the root)... at least, according to TLS, and
> other IETF Security working-area client protocols. But, it's not mandatory
> per PKIX, and it's also not mandatory per X.509, either.

I agree, it's not mandatory at all. And even if a bunch of certificates is sent along the EE cert, the RP is supposed to take them as potential candidates for its chain building algorithm. Potential candidates only.

Brian Smith

unread,
Apr 28, 2014, 10:08:37 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Mon, Apr 28, 2014 at 4:29 PM, Erwann Abalea <eab...@gmail.com> wrote:

> I know DER tools is only a decoder, and from
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921the construction of the request makes heavy use of hex magic to build a
> request.
>

Right. OCSP requests are the only thing we *encode* in ASN.1 and so it
would be overkill to write a generic ASN.1 DER encoding library .


> Quick bug: on the same function, line 945, the test against
> issuerCert->serialNumber.len should be against cert->serialNumber.len
> instead..
>

Thanks for this bug report. David Keeler already filed a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1002814

if you like money I suggest you read
https://blog.mozilla.org/security/2014/04/24/10000-security-bug-bounty-for-certificate-verification/and
follow the directions.


> Logic at
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#107doesn't follow RFC5280 algorithm, and will probably fail with FBCA and
> other large cross-certification constructions such as CertiPath (I'm sure
> they use PolicyMappings, they may use PolicyConstraints, it has slipped off
> my memory). Current code is sufficient for webPKI, even EV. The normalized
> algorithms are clearly a torture to read (both X.509 and RFC5280, logic is
> slightly different but the result is identical), but it's necessary.
>

The mozilla::pkix code is NOT intended to be a complete implementation of
RFC 5280 and friends. Regarding certificate policy processing in
particular, the *entire* purpose of mozilla::pkix's certificate policy
support is the determination of whether to show the green site identity
block in a browser's address bar. We (I) specifically omitted any part of
certificate policy processing that is unnecessary for that purpose.

As I said in another thread, I'm hoping we will create a new,
much-simplified WebPKI profile of X.509 based on what we learn from
mozilla::pkix: no policy mapping, no policy constraints extension
(mozilla::pkix enforces requireExplicitPolicy=true and
inhibitPolicyMapping=true at all times anyway), no CRLs, etc.


> Same file, #229 (CheckBasicConstraints) doesn't take into account
> potential self-issued certificates in the chain (they don't account for a
> "level" in the pathLenConstraint).
>

Thanks. This is a known issue; see
https://bugzilla.mozilla.org/show_bug.cgi?id=926265. Interestingly, we've
not encountered any websites that are negatively affected by this bug yet.
Perhaps we will be able to remove the special cases for self-issued
certificates in the WebPKI profile.


> Same file, #370 (CheckExtendedKeyUsage), if encodedEKUs is NULL and a
> requiredEKU is asked for, it ends with a success. If encodedEKUs is present
> and contains the anyExtendedKeyUsage OID, it isn't recognized as valid. And
> I'm not sure it allows full support for technically constrained CAs (this
> is done with EKUs used as constraints, which is contrary to X.509/RFC5280,
> but it was pushed by Mozilla).
>

We do intend for mozilla::pkix to enforce the EKU extension in
intermediates in the way that we pushed for (and which we understand that
Microsoft's implementation also enforces).

We do not support anyExtendedKeyUsage and the NSS code we were using before
did not support it either. See
https://bugzilla.mozilla.org/show_bug.cgi?id=970750 (for mozilla::pkix) and
https://bugzilla.mozilla.org/show_bug.cgi?id=279845 (for NSS). Since NSS
has been working fine for at least one decade without support for
anyExtendedKeyUsage, we can almost definitely omit anyExtendedKeyUsage from
the WebPKI profile of X.509.

Cheers,
Brian

Brian Smith

unread,
Apr 28, 2014, 10:08:37 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

Brian Smith

unread,
Apr 28, 2014, 10:17:38 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea <eab...@gmail.com> wrote:

> The chain builder can test all possible issuers until it finds a valid one
> (that's what OpenSSL does, for example). The AKI is only here to say
> "pssst, this is most probably the certificate you should try first".
>

Right. We need to measure whether our lack of support for AKI/SKI, which
causes us to do such a brute-force search, actually causes real-world
performance concerns. I am hoping that it doesn't matter so that we can
remove AKI/SKI from the WebPKI X.509 profile.

There's another missing check on the new PKIX lib, PrivateKeyUsagePeriod
> extension. It's been declared as deprecated in RFC2459 and 3280, isn't
> mentioned anymore in RFC5280, but it's still defined in X.509, and used on
> some places, such as CSCA (e-passports, where CA renewal with rekey also
> happen on a regular basis).
>

CSCA is out of scope for mozilla::pkix, at least at this time. More
generally, PrivateKeyUsagePeriodand other deprecated features, including
*all* of the proprietary Netscape/NSS extensions like "Netscape Cert Type,"
are also out of scope. Note that new features like the Must-Staple
extension *are* within scope and can/should/will be added.


> I agree, it's not mandatory at all. And even if a bunch of certificates
> is sent along the EE cert, the RP is supposed to take them as potential
> candidates for its chain building algorithm. Potential candidates only.
>

Exactly. (In the code, the candidate issuer is called potentialIssuer.)

Thanks for looking so closely at the code. Please let me know if you have
any questions that would help with your investigation of it.

Cheers,
Brian

Brian Smith

unread,
Apr 28, 2014, 10:17:38 PM4/28/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

jugal...@gmail.com

unread,
Jul 25, 2014, 12:26:54 AM7/25/14
to mozilla-dev...@lists.mozilla.org
Team

After upgrade to Firefox 31, I am not able to request any https link through my firewall and getting certificate failure. I tried re-import of firewall certificate but in vein.

Please suggest.

David Keeler

unread,
Jul 25, 2014, 7:51:07 PM7/25/14
to dev-tec...@lists.mozilla.org
Hi Jugal,

For issues with mozilla::pkix, the following might be helpful:
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes
If that doesn't resolve the issue, please file a bug here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security:%20PSM&short_desc=%28mozilla::pkix%29
It would be helpful if you could include either a link to a
publicly-accessible site that exhibits the problem or post a copy of the
certificate chain that is problematic. The error code (something like
"sec_error_...") would also be helpful.

Thanks,
David

On 07/24/2014 09:26 PM, jugal...@gmail.com wrote:
> Team
>
> After upgrade to Firefox 31, I am not able to request any https link through my firewall and getting certificate failure. I tried re-import of firewall certificate but in vein.
>
> Please suggest.
>
>
> On Tuesday, 8 April 2014 04:03:50 UTC+5:30, Kathleen Wilson wrote:

colinh...@gmail.com

unread,
Aug 2, 2014, 11:39:31 AM8/2/14
to mozilla-dev...@lists.mozilla.org
Since the latest update 3 days ago I have been unable to log in to any of my Netgear equipment using Firefox. I get the error: (Error code: sec_error_extension_value_invalid. I can access my equipment using Explorer so I can only assume it might be something to do with this access list.

David Keeler

unread,
Aug 4, 2014, 12:23:18 PM8/4/14
to dev-tec...@lists.mozilla.org
On 08/02/2014 08:39 AM, colinh...@gmail.com wrote:
> Since the latest update 3 days ago I have been unable to log in to any of my Netgear equipment using Firefox. I get the error: (Error code: sec_error_extension_value_invalid. I can access my equipment using Explorer so I can only assume it might be something to do with this access list.
>

That sounds like bug 1044441 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1044441 ).

mjl...@gmail.com

unread,
Aug 5, 2014, 12:51:08 PM8/5/14
to mozilla-dev...@lists.mozilla.org
Since updating to 31, I have not been able to log into a self signed web page:

Secure Connection Failed

An error occurred during a connection to taiserver:444. Certificate key usage inadequate for attempted operation. (Error code: sec_error_inadequate_key_usage)

How do I get this corrected?

Mike

Brian Smith

unread,
Aug 5, 2014, 1:25:18 PM8/5/14
to mozilla's crypto code discussion list
Please file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security:%20PSM
(Product: Core, Component: PSM) and attach the certificate in question
to the bug report.

Cheers,
Brian

Richard Barnes

unread,
Aug 7, 2014, 5:01:09 PM8/7/14
to mozilla's crypto code discussion list
Of course, it sounds likely to be related to the new key usage checks listed in the relevant wiki page:
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

You might check to see if that's the case before filing a bug.

--Richard



>
> Cheers,
> Brian
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

br...@consultbruce.com

unread,
Aug 11, 2014, 3:58:47 PM8/11/14
to mozilla-dev...@lists.mozilla.org
Yup - having a problem. Novell ZENworks optionally uses an internal CA and with FF 31 I can no longer connect to the management console or any of the other web services. I'll try turning off the new CA checker to see if that works. I like the idea of better security, but you just pissed off a lot of my customers.

Bruce McDowell
McDowell Consulting LLC
br...@consultbruce.com

Richard Barnes

unread,
Aug 12, 2014, 2:48:30 PM8/12/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
Hey Bruce,

It appears the Novell certs have run afoul of a couple of the new checks in mozilla::pkix. It should be noted that this is because they are violating the X.509/PKIX specifications, e.g., by setting an invalid version number.

https://bugzilla.mozilla.org/show_bug.cgi?id=1042889
https://bugzilla.mozilla.org/show_bug.cgi?id=1047177
https://bugzilla.mozilla.org/show_bug.cgi?id=1045973

We're looking at how we should adapt the verification process to deal with these. In the mean time, you can revert to classic validation by setting security.use_mozillapkix_verification to false.

--Richard

Richard Barnes

unread,
Aug 12, 2014, 2:48:30 PM8/12/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

Julien Pierre

unread,
Aug 15, 2014, 3:47:16 AM8/15/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
Brian,

I just ran into the Netscape Cert Type critical extension issue with an
internal cert.
Is there an override setting to allow this cert to work in Firefox still ?

IMO, the Firefox behavior is particularly bad, because Firefox won't
even let you look at the cert details to see what the problematic
extension is. I had to look at the cert details in Chrome (which still
uses libpkix) .

Julien

Julien Pierre

unread,
Aug 15, 2014, 3:47:16 AM8/15/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

David Keeler

unread,
Aug 15, 2014, 12:55:25 PM8/15/14
to dev-tec...@lists.mozilla.org
Hi Julien,

Currently there is no way to override that behavior. We're working on
improving the situation in bug 1009161.
See also bug 1054368 regarding a way to view the certificate for
non-overridable errors.
If you can get in touch with whoever administers the internal
certificates, I would encourage them to take a look at
https://wiki.mozilla.org/SecurityEngineering/x509Certs for information
on how to create a certificate hierarchy that is compatible with RFC 5280.

David

davp...@ozemail.com.au

unread,
Oct 5, 2014, 11:46:09 AM10/5/14
to mozilla-dev...@lists.mozilla.org
I am accessing pfSense router/s that have self-generated certificates so obviously they do not validate publicly. Prior to Firefox 31 I had the security warning and had clicked through to add the certificate for a number of these routers on our internal networks.
The list of certificates in Firefox then included a bunch under the name "CompanyName".
After upgrade to Firefox 31 it started taking a long time (15-20 seconds) to bring up the login page to these routers. During that time the CPU was running 100%. Then after login, every few minutes Firefox would use 100% CPU for a minute or 2, becoming effectively unresponsive in any tab.
I tried Firefox 24, 28, 29, 30 - none of these had the symptoms.
Tried Firefox 31, 32, 33 (beta) and 34 (aurora). They all had the symptoms described.
Looking in pfSense forums I discovered this post - https://forum.pfsense.org/index.php?topic=82295.0
I deleted the certificates under "CompanyName".
Now display time for the Login page is back to normal, and Firefox CPU time is not going crazy every few minutes.
Maybe there is something that can be done to help this situation? Maybe these old "private" certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these "private" certificates needs to be fixed?

davp...@ozemail.com.au

unread,
Oct 2, 2014, 12:03:34 PM10/2/14
to mozilla-dev...@lists.mozilla.org
I am accessing pfSense router/s that have self-generated certificates so obviously they do not validate publicly. Prior to Firefox 31 I had the security warning and had clicked through to add the certificate for a number of these routers on our internal networks.
The list of certificates in Firefox then included a bunch under the name "CompanyName".
After upgrade to Firefox 31 it started taking a long time (15-20 seconds) to bring up the login page to these routers. During that time the CPU was running 100%. Then after login, every few minutes Firefox would use 100% CPU for a minute or 2, becoming effectively unresponsive in any tab.
I tried Firefox 24, 28, 29, 30 - none of these had the symptoms.
Tried Firefox 31, 32, 33 (beta) and 34 (aurora). They all had the symptoms described.
Looking in pfSense forums I discovered this post - https://forum.pfsense.org/index.php?topic=82295.0 - and added to it.
I deleted the certificates under "CompanyName".
Now display time for the Login page is back to normal, and Firefox CPU time is not going crazy every few minutes.
Maybe there is something that can be done to hep this situation? Maybe these old "private" certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these "private" certificates needs to be fixed?

Brian Smith

unread,
Oct 5, 2014, 1:04:37 PM10/5/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
On Thu, Oct 2, 2014 at 9:03 AM, <davp...@ozemail.com.au> wrote:
> Maybe there is something that can be done to hep this situation? Maybe these old "private" certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these "private" certificates needs to be fixed?

There is already a bug report about this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056341

Cheers,
Brian

Brian Smith

unread,
Oct 5, 2014, 1:04:36 PM10/5/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

treb...@gmail.com

unread,
Oct 16, 2014, 4:04:59 PM10/16/14
to mozilla-dev...@lists.mozilla.org
Mozilla::pkix includes some changes in support of current best practices and policies, as listed below. If you notice an issue due to any of these changes, please feel free to let us know. However, we believe that in most cases, the simplest resolution will be to update the SSL certificate in your webserver.


YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT..

WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES


**** BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE!

WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK?

F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war!

Erwann Abalea

unread,
Oct 17, 2014, 5:30:50 AM10/17/14
to mozilla-dev...@lists.mozilla.org
Le jeudi 16 octobre 2014 22:04:59 UTC+2, treb...@gmail.com a écrit :
[...]

> YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT..

[...]

> F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war!

All this could have been written using less capital letters and less bad words. That doesn't help your cause.
Next time you're angry, find a wall and hit it, or go run outside while yelling. Then come back positive-minded.

Kiss.

crode...@gmail.com

unread,
Nov 6, 2014, 11:52:32 AM11/6/14
to mozilla-dev...@lists.mozilla.org
I agree with the opinion this user is trying to get across. We end users must have an option to completely circumvent security measures when we know a connection is trusted. Otherwise, like the poster indicated, we have to ditch Firefox and use a browser that gives us that capability.

We, the end users, don't want to make a statement of how global security practices should theoretically work. We want to use a browser that we have control of and can use as a tool to accomplish a task. Removing some of the functionality of the browser and forcing us into a rigid security model only makes us install a second browser. Over time, I can imagine that the second browser would usurp Firefox's position as "Preferred browser".

Just an opinion, from an end-user.

Richard Barnes

unread,
Nov 6, 2014, 2:20:38 PM11/6/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

> On Nov 5, 2014, at 3:43 PM, crode...@gmail.com wrote:
>
> On Thursday, October 16, 2014 3:04:59 PM UTC-5, treb...@gmail.com wrote:
> I agree with the opinion this user is trying to get across. We end users must have an option to completely circumvent security measures when we know a connection is trusted. Otherwise, like the poster indicated, we have to ditch Firefox and use a browser that gives us that capability.
>
> We, the end users, don't want to make a statement of how global security practices should theoretically work. We want to use a browser that we have control of and can use as a tool to accomplish a task. Removing some of the functionality of the browser and forcing us into a rigid security model only makes us install a second browser. Over time, I can imagine that the second browser would usurp Firefox's position as "Preferred browser".
>
> Just an opinion, from an end-user.

Just to let you know, we hear you. We're having some internal discussions about how to better balance the considerations here.

On the one hand, for most people in most situations, the browser needs to make an intelligent choice on behalf of the user. Sometimes, that's going to involve not connecting at all.

On the other hand, we also need to enable power users, who have done their homework, to get their work done.

Look for some proposals here soon.

--Richard

Richard Barnes

unread,
Nov 6, 2014, 2:20:40 PM11/6/14
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

> On Nov 5, 2014, at 3:43 PM, crode...@gmail.com wrote:
>
> On Thursday, October 16, 2014 3:04:59 PM UTC-5, treb...@gmail.com wrote:

1992....@gmail.com

unread,
Mar 3, 2015, 3:02:28 AM3/3/15
to mozilla-dev...@lists.mozilla.org
Hi,

I am facing some difficulty with a particular website. I cannot log in to my college account.(my.rutgers.edu) I get these errors
"The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem."

I have not changed any setting. It was working fine before I updated firefox. Please let me know what should I do to get rid of the problem. Thanks in advance

David Keeler

unread,
Mar 3, 2015, 2:05:01 PM3/3/15
to dev-tec...@lists.mozilla.org
my.rutgers.edu only offers a single cipher suite
(TLS_RSA_WITH_RC4_128_SHA) and is TLS 1.1/1.2 intolerant [0]. We
essentially disabled RC4 and insecure fallback to TLS 1.0 by default,
which is why you're unable to connect with recent (i.e. pre-release)
versions of Firefox.
I filed bug 1139065 [1] as a tech evangelism bug to hopefully reach out
to the server administrators so they can fix their site.
In the meantime, if you set the pref
"security.tls.insecure_fallback_hosts" to "my.rutgers.edu" in
about:config, it should work.

Cheers,
David

[0] https://www.ssllabs.com/ssltest/analyze.html?d=my.rutgers.edu
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1139065

David Keeler

unread,
Jul 7, 2015, 12:07:10 PM7/7/15
to dev-tec...@lists.mozilla.org
Please file a new bug here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM
It would be helpful if you attached the certificate the device is sending.

On 07/01/2015 08:15 AM, pavel.s...@gmail.com wrote:
> Hello guys.
>
> Just updated firmware in my Sonicwall TZ210W
> Now unable to sign in to management page.
>
> Secure Connection Failed
> The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
> Please contact the website owners to inform them of this problem.
> What is the workaround to fix this?
>
> Certificate information.
>
> HTTPS Management Certificate
> Certificate Issuer: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management Certificate for SonicWALL (self-signed)/CN=192.168.168.168
> Subject Distinguished Name: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management C
> ertificate for SonicWALL (self-signed)/CN=192.168.168.168
> Certificate Serial Number: 4F50DAE9
> Valid from: Jan 1 00:00:01 1970 GMT
> Expires On: Jan 19 03:14:07 2038 GMT
> Status: Not Verified - Self-signed
>
>

signature.asc
Reply all
Reply to author
Forward
0 new messages