About the Cybertrust Educational CA certificate
Fabio Spelta
Many educational institutions, among which there are various Italian
universities, are using X.509 certificates issued by the "Cybertrust
Educational CA" for their websites.
In Italy such certificates are obtained mainly through the GARR Italian
Academic & Research Network, www.garr.it.
The Cybertrust Educational certificate can be found at
http://secure.globalsign.net/cacert/sureserverEDU.pem.
That's in turn signed by the "GTE CyberTrust Global Root" certificate.
Please refer to http://secure.globalsign.net/cacert/ct_root.pem.
While certificates signed by that authority are trusted and seamlessly
accepted by the default installations of Internet Explorer (since
version 6) and now also by Google Chrome, Mozilla Firefox still doesn't
trust them (not even the latest 3.1 alpha2).
I'm writing to kindly ask you to consider to insert the Cybertrust
Educational certificate in the list of the trusted certificate authorities.
That would be very helpful to all the organizations which use such
certificates for they websites, expecially in view of the growing user
base of Firefox in Italy.
Should you need further details, don' t hesitate to get in touch with me.
Thank you very much for your attention.
--
Fabio
David Stutzman
Nelson B Bolyard
> I'm writing to kindly ask you to consider to insert the Cybertrust
> Educational certificate in the list of the trusted certificate authorities.
Fabio,
Mozilla doesn't add any CA certificates to Firefox unless and until the
CA itself requests the addition of its own certificates. There is a
procedure by which the CA makes a formal request and supplies a lot of
information that Mozilla verifies and evaluates before deciding whether
or not to include the CA. Only the CA (and its official representatives)
may make this request. Requests are not accepted from other parties, such
as subscribers who have gotten certificates from the CA.
More information about the procedures for making application and supplying
the necessary information may be found on the web pages listed below, and
the pages to which they link.
https://wiki.mozilla.org/CA:Overview
http://www.mozilla.org/projects/security/certs/
Eddy Nigg
> Hello everybody and thanks for reading.
>
> Many educational institutions, among which there are various Italian
> universities, are using X.509 certificates issued by the "Cybertrust
> Educational CA" for their websites.
> In Italy such certificates are obtained mainly through the GARR Italian
> The Cybertrust Educational certificate can be found at
> http://secure.globalsign.net/cacert/sureserverEDU.pem.
> That's in turn signed by the "GTE CyberTrust Global Root" certificate.
> Please refer to http://secure.globalsign.net/cacert/ct_root.pem.
>
> While certificates signed by that authority are trusted and seamlessly
> accepted by the default installations of Internet Explorer (since
> version 6) and now also by Google Chrome, Mozilla Firefox still doesn't
> trust them (not even the latest 3.1 alpha2).
>
> I'm writing to kindly ask you to consider to insert the Cybertrust
> Educational certificate in the list of the trusted certificate authorities.
> That would be very helpful to all the organizations which use such
> certificates for they websites, expecially in view of the growing user
> base of Firefox in Italy.
>
> Should you need further details, don' t hesitate to get in touch with me.
>
The CA certificate you referred above is signed by a CA root which is
included in NSS. Therefore the error you are seeing is a server side
installation failure and the server doesn't send the complete chain.
This has been a known issue with Mozilla based products and servers are
required to send the chain up to the root. Please contact the
administrator of the site and ask to correct this issue.
By having a look at this root I realized that the purposes of the
certificate show in in Firefox for:
SSL Server Certificate
Email Signer Certificate
Email Recipient Certificate
SSL Certificate Authority
Status Responder Certificate
This is a builtin root! Nelson...can you check out those usages?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Wan-Teh Chang
>
> By having a look at [GTE CyberTrust Global Root] I realized that the purposes of the
> certificate show in in Firefox for:
>
> SSL Server Certificate
> Email Signer Certificate
> Email Recipient Certificate
> SSL Certificate Authority
> Status Responder Certificate
>
> This is a builtin root! Nelson...can you check out those usages?
I believe this is a variant of this PSM bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=289988
Wan-Teh
Eddy Nigg
Not sure. The root works as expected, but some of the key usages seem to
be not appropriate for a CA certificate, at least NSS shouldn't know
about them.
Nelson Bolyard
> The CA certificate you referred above is signed by a CA root which is
> included in NSS. Therefore the error you are seeing is a server side
> installation failure and the server doesn't send the complete chain.
Thanks for noticing that, Eddy.
> This has been a known issue with Mozilla based products and servers are
> required to send the chain up to the root.
I wouldn't call it a "known issue with Mozilla based products".
It's a requirement of the SSL/TLS specifications.
It's an issue with servers that are not configured to conform to those
specifications.
> Please contact the administrator of the site and ask to correct this
> issue.
Yes, that's the right solution.
> By having a look at this root I realized that the purposes of the
> certificate show in in Firefox for:
>
> SSL Server Certificate
> Email Signer Certificate
> Email Recipient Certificate
> SSL Certificate Authority
> Status Responder Certificate
>
> This is a builtin root! Nelson...can you check out those usages?
That's what PSM shows for roots, Eddy. I imagine you're expecting it
to say something like "Email Certificate Authority" and "Object Signing
Certificate Authority". I agree it should. But it's a PSM UI issue,
I believe.
Eddy Nigg
> I wouldn't call it a "known issue with Mozilla based products".
> It's a requirement of the SSL/TLS specifications.
That's correct.
> It's an issue with servers that are not configured to conform to those
> specifications.
Right, but as I mentioned elsewhere, this educational exercise costs
some of the CAs using chained CA certificates (as recommended by
Mozilla) to loose customers (just watch for some promotional adds like
"issued directly from CA root" and such stuff...some users just turn
away and use a different CA instead because it "doesn't work" and shows
"not trusted")
>>
>> SSL Server Certificate
>> Email Signer Certificate
>> Email Recipient Certificate
>> SSL Certificate Authority
>> Status Responder Certificate
>
> That's what PSM shows for roots, Eddy. I imagine you're expecting it
> to say something like "Email Certificate Authority" and "Object Signing
> Certificate Authority". I agree it should. But it's a PSM UI issue,
> I believe.
I expect to see "SSL Certificate Authority" as then only purpose, the
same which I see for the StartCom roots.
Francisco Puentes
I have got into my code a pair of RSA keys generated and now I need
encrypt/decrypt binary data.
Something like:
RSA_encrypt([public or private]key, void*in_data, long in_length,
void*out_data, long*out_length);
Does it exist?
Fabio Spelta
It was, indeed.
Testing it with other browser worked flawlessly, thus the misunderstanding.
Thank you very much,
--
Fabio
Nelson Bolyard
In practice, RSA encryption is never used to encrypt user data directly.
It's too slow, and the results are too bulky for such use.
It is used to encrypt other encryption keys, keys for use with other
encryption algorithms that are better suited to data encryption, such as
AES.
Francisco Puentes
Precisely I need RSA to encrypt a buffer to exchange sessions keys (very
small xml document), which will be used to encrypt the session with AES.
So :-) Can NSS encrypt raw data?
-----Mensaje original-----
De: dev-tech-crypto-bounces+fpuentes=udc...@lists.mozilla.org
[mailto:dev-tech-crypto-bounces+fpuentes=udc...@lists.mozilla.org] En nombre
de Nelson Bolyard
Enviado el: miércoles, 17 de septiembre de 2008 22:20
Para: dev-tec...@lists.mozilla.org
Asunto: Re: How to encript raw data
_______________________________________________
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Nelson B Bolyard
> Yes, I know.
>
> Precisely I need RSA to encrypt a buffer to exchange sessions keys (very
> small xml document), which will be used to encrypt the session with AES.
>
With RSA?
NSS was designed around the FIPS 140 model of cryptography, in which
all symmetric and private keys are kept within the boundaries of a
"cryptographic module". They are generated or derived inside the
module, and as a rule, they do not come out of the module except
when in "wrapped" (encrypted) form.
So, the typical expected sequence of events might follow one of these
models:
Model 1:
System A:
- generates a new symmetric session key in the module. This can be a
key for a specific algorithm, or a generic secret value.
- wraps the symmetric key with the RSA public key of its peer, outputting
the wrapped result to the program memory outside of the module.
- sends the wrapped session key to System B
System B:
- unwraps the received wrapped session key with its RSA private key, with
the unwrapped result becoming a new key inside the module
Then both systems
- derive any other keys (encryption keys, MAC keys) from the session key,
with all the newly derived keys remaining inside their respective modules,
- use the newly derived keys, still inside the module, to do the bulk data
encryption and MACing.
That's essentially a description of RSA SSL with a few details left out. :)
Model 2:
- Rather than System A generating the new session key, System A and System B
both generate keys of some other form, such as Diffie Hellman key pairs,
in the respective modules, and then output & exchange the DH public keys.
Each system inputs the other system's public value, and then do a DH key
derivation inside their respective modules, yielding a new session key,
which is then used as in Model 1.
In practice, numerous other steps must be done to avoid MITM attacks on
those DH values, such as signing them, and verifying the signatures,
or doing a double-DH exchange using both certified and ephemeral DH values,
as in NIST's KEA (used in Clipper), also implemented in NSS. :)
SSL offers either model.
Anyway, NSS is quite capable of
- generating or deriving symmetric session keys,
- wrapping symmetric session keys with RSA public keys, and outputting
the wrapped result,
- inputting and unwrapping the received wrapped session key,
- deriving other keys from the unwrapped session key (or just using it
directly as an encryption key).
Here are some functions to look at for wrapping and unwrapping.
- PK11_PubWrapSymKey
- PK11_PubUnwrapWithFlagsPerm
You'll probably find most of the functions you need in this file:
http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11pub.h
I might suggest using SSL, and let all that heavy lifting be done for you.
That gives you the advantage of using a well designed and thoroughly
analyzed crypto protocol.
Kyle Hamilton
Authority. Did you not include a request for Email or Software
Development bits?
-Kyle H
Eddy Nigg
> Perhaps, Eddy, StartCom's roots were only approved for SSL Certificate
> Authority. Did you not include a request for Email or Software
> Development bits?
>
StartCom roots have currently email and server trust bits set on. There
is currently a bug for enabling code signing:
https://bugzilla.mozilla.org/show_bug.cgi?id=451298
However the trust bits aren't related to the issue below, because any
root is nevertheless supposed to be a CA only. Perhaps lets analyze the
key usages below:
>>
>>>> SSL Server Certificate
>>>> Email Signer Certificate
>>>> Email Recipient Certificate
>>>> SSL Certificate Authority
>>>> Status Responder Certificate
>>
This root may be used for securing a SSL server...
This root may be used to sign email messages...
This root may be used to decrypt email messages...
The later two are fine, not sure about the status responder though. In
any case this requires some cleaning up...
David E. Ross
While the certificate authority (CA) involved here is NOT Verisign, the
information at
<https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657>
is very relevant. Indeed, it's relevant to ALL CAs. You should bring
this Web page to the attention of the host Web server for their action.
Note that this is not a unique situation. See bug #390835 at
<https://bugzilla.mozilla.org/show_bug.cgi?id=390835>. Unfortunately,
Internet Explorer (IE) works around this situation by searching the
Internet for missing intermediate certificates. I consider this a
security vulnerability in IE. However, because of IE's behavior, many
Web server hosts ignore this problem (e.g., Canon, per bug #390835).
I'm beginning to believe that the CAs are not communicating clearly with
their customers on the proper way to setup a secure server.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg
> Note that this is not a unique situation. See bug #390835 at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=390835>. Unfortunately,
> Internet Explorer (IE) works around this situation by searching the
> Internet for missing intermediate certificates. I consider this a
> security vulnerability in IE. However, because of IE's behavior, many
> Web server hosts ignore this problem (e.g., Canon, per bug #390835).
>
Please note that IE isn't "searching" the Internet for missing certs,
but is using the AIA CA Issuers extension of the server certificate to
download the missing certificates. If the fetched CA certificate doesn't
chain to a CA root it will not use it. If there is no AIA extension IE
will also report an error (as with FF).
There is absolutely no security issue at all with following the AIA CA
Issuer extension, otherwise FF could not use the same extension to find
the OCSP responder URL either. Nevertheless NSS does exactly that...uses
the OCSP URL listed in the AIA extension.
I've been banging my head against a wall here because of this FUD and
about misinformation which is absolutely incorrect. Sad, because there
are many FF users running into it. And it doesn't help to ignore the
fact that web site admins don't install their certs correctly - it works
in IE and that's it.
Similar tweaks and corrections were made for FF if major sites didn't
play nicely with standards in order to make FF usable. With the new
error reporting for invalid certificates, this issue should have been
solved beforehand. :-(
Wan-Teh Chang
>
> I've been banging my head against a wall here because of this FUD and
> about misinformation which is absolutely incorrect. Sad, because there
> are many FF users running into it. And it doesn't help to ignore the
> fact that web site admins don't install their certs correctly - it works
> in IE and that's it.
It would be nice to contribute a patch for Apache/mod_ssl to validate
its own certificate chain at startup.
Wan-Teh
Eddy Nigg
> It would be nice to contribute a patch for Apache/mod_ssl to validate
> its own certificate chain at startup.
>
Perhaps then you should also offer a patch for IIS ;-)
Ironic as it may sound, but as a matter of fact, Windows servers serve
more secured web sites than Apache (AFAIK).
But all the finger-pointing doesn't help, FF hasn't got its act together
on this very issue -refusal for the purpose of being on the right side...
Nelson B Bolyard
> There is absolutely no security issue at all with following the AIA CA
> Issuer extension, otherwise FF could not use the same extension to find
> the OCSP responder URL either. Nevertheless NSS does exactly that...uses
> the OCSP URL listed in the AIA extension.
There's one very important difference between AIA cert fetching and AIA OCSP
fetching that makes one a potential security risk and the other not.
OCSP fetching is done only AFTER the entire chain has been validated to
the extent that every cert in the chain has a valid signature, the chain
goes up to a trusted root, and no certs are expired. At the point where
the only question remaining is that of revocation, OCSP fetching is done.
At that time, we have confidence that the URL in the AIA extension was
issued by a CA that we trust by direct or inherited (transitive) trust.
In the case of AIA cert fetching, we have a cert for which we have no
issuer cert. We cannot know that the the cert we are trying to validate
was signed by a real trusted CA. Even if its issuer name matches that of
a known and trusted CA, it may be a cert crafted by an attacker, for the
specific purpose of getting the program that is attempting to validate
the cert to do a fetch from a URL that is entirely under the control of
the attacker.
Now, it has been pointed out that, for BROWSERS, this is a very tiny
incremental threat. Browsers ROUTINELY go and fetch URLs that they
received in a web page from some server, without knowing anything about
where that URL is going. You don't need a cert's AIA extension to get a
browser to go fetch some URL of your choosing. You just need an ordinary
http web page. Attackers won't go to the bother of using a phony server
cert's AIA extension when they can use the much easier and more effective
ordinary http page. So, the risk to a browser of doing AIA cert fetching
is relatively small.
But that logic applies only to browsers. Very few other applications
routinely go out and fetch URLs that come from outsiders. Most go to
servers that have been explicitly configured into the application by
the user or admin. Examples of this include email clients that are
configured to know about certain specific POP, IMAP and SMTP servers,
and never go off and visit other mail servers due to the content of
something they receive. LDAPS clients are like that, too. For those
other types of applications, the incremental risk is much higher (when
seen as a percentage of total risk).
The type of application that is most likely to be the target of an
attack using phony certs with attacker-chosen AIA extensions is a
server that requests client authentication. The server may be
behind a firewall, and still be accessible by systems outside the
firewall. Other corporate systems behind the firewall are accessible
to that server but are not directly accessible to other systems outside
of the firewall. The server in that position becomes an attack target
because the attacker can get that server to act as the attacker's proxy, and
probe other servers located behind that firewall. The attacker does
that by connecting to the server, and when the server requests client
authentication, the client sends a bogus certificate constructed to
contain an AIA cert extension that contains a URL that might go to
another server also behind the firewall. When the server fetches that
URL, it is acting as a proxy for the attacker.
It is probably best for all applications other than browsers to not honor
AIA cert extensions for the purpose of fetching issuer certs. Servers
can be even more efficient by disabling the automatic fetching of OCSP
and CRLs based on the extensions in an incoming cert, and instead
periodically preloading the CRLs from any and all CAs that they trust to
issue client certs.
> I've been banging my head against a wall here because of this FUD and
> about misinformation which is absolutely incorrect.
Are you sure? It would be relatively trivial to construct an attack
client like the one I described above using NSS.
> Sad, because there are many FF users running into it. And it doesn't help
> to ignore the fact that web site admins don't install their certs
> correctly - it works in IE and that's it.
I think it would be interesting to survey the web's misconfigured servers
to see which CAs' certs are most commonly left uninstalled by admins.
I suspect that we would find that some fairly large CAs are
disproportionately low in those standings, that is, some large CAs' certs
are rarely left out. It's not difficult to imagine why that might be.
> Similar tweaks and corrections were made for FF if major sites didn't
> play nicely with standards in order to make FF usable. With the new
> error reporting for invalid certificates, this issue should have been
> solved beforehand. :-(
Firefox 3 does something to compensate for misconfigured servers that is
without risk. When it validates a server cert chain and finds that it
is valid, Firefox remembers each of the certs in the chain. Thereafter,
if it visits a misconfigured server, it may be able to fill in the
missing cert from its store of previously received and validated CA certs.
Taking certs from its own store is safe because it has previously
validated those cert.
Eddy Nigg
> In the case of AIA cert fetching, we have a cert for which we have no
> issuer cert. We cannot know that the the cert we are trying to validate
> was signed by a real trusted CA.
But you trust the CA certificates the server send to you, do you?
> Even if its issuer name matches that of
> a known and trusted CA, it may be a cert crafted by an attacker
Really? Please enlighten me how...I would like to see a real example!
But in that case the server can send also such a specially crafted CA
certificate which chains to a builtin root, right? There is no
difference between relying on a server sending the missing chain or NSS
fetching it. In the end it must in both case validate up to a known root.
> for the
> specific purpose of getting the program that is attempting to validate
> the cert to do a fetch from a URL that is entirely under the control of
> the attacker.
Or from the server...
> So, the risk to a browser of doing AIA cert fetching
> is relatively small.
There is no higher risk that relying on the CA chain the server sends.
In moth cases the parties might be interesting in spoofing....
>
> Are you sure?
Yes
> It would be relatively trivial to construct an attack
> client like the one I described above using NSS.
Please construct such an attack for me...
>
> Firefox 3 does something to compensate for misconfigured servers that is
> without risk. When it validates a server cert chain and finds that it
> is valid, Firefox remembers each of the certs in the chain.
I'm aware of that, but it requires to have visited at least once a
correctly installed certificate at a site. It's actually very good to
lower the traffic when fetching via AIA would be working. It would very
efficiently fetch those needed and not bother when it has it already in
the store.
David E. Ross
Okay, I chose the wrong words. The vulnerability arises because IE
enables hosts to be sloppy in how they configure their Web servers. If
they won't include the required intermediate certificates, what else are
they not doing properly? Is the server host machine physically secure?
Are databases with personal data about customers (e.g., entered through
secure Web pages) encrypted?
Just slap this site certificate into the server. Don't worry about what
secure Web browsing really means.
Eddy Nigg
>> Even if its issuer name matches that of
>> a known and trusted CA, it may be a cert crafted by an attacker
>
I wanted to add here, that if this were true, than this would apply for
any certificate, including server certs, CA certs and anything in the
path. I sincerely believe that creating such a certificate which would
appear and understood by NSS as being issued by a CA root NSS trusts is
nearly impossible. Otherwise we'll have to look into this more in detail
as it would mean that NSS might be fooled by a specially crafted
certificate. It would literally mean, that somebody could play CA...
Kyle Hamilton
If there are buffer overflows in ASN.1 parsing (there have been in at
the least OpenSSL and Microsoft's), anyone who can provide a
certificate that points to an AIA that ultimately wouldn't be trusted
could provide malicious data that could compromise the issue.
In addition, if there were an MD5-like hash collision in such a way
that an attacker could forge an apparently-valid (the signature
matches what was signed, though the data does not) CA:true
certificate, then all hell breaks loose.
Do not trust input from the user (unless obtained through a secure means).
Trust input from potential attackers even less (since you cannot
obtain it through a secure means).
Only once the trust protocol has been completed should the trust be extended.
-Kyle H
Eddy Nigg
> There's another, more pressing issue:
>
> If there are buffer overflows in ASN.1 parsing (there have been in at
> the least OpenSSL and Microsoft's), anyone who can provide a
> certificate that points to an AIA that ultimately wouldn't be trusted
> could provide malicious data that could compromise the issue.
>
Very interesting Kyle. So how do you propose to solve the problem? Any
server can send a server certificate including the chain which could
provide malicious data! This isn't unique to the AIA extension
obviously. A rough server can do that as well? And perhaps gain EV
status even? Shouldn't be a problem then...right?
> Do not trust input from the user (unless obtained through a secure means).
Does that mean, do not trust a server (which is user input after all)
and his certificate and supplied chain of CA certificates?
Nelson B Bolyard
> On 09/18/2008 07:22 AM, Nelson B Bolyard:
>> In the case of AIA cert fetching, we have a cert for which we have no
>> issuer cert. We cannot know that the the cert we are trying to validate
>> was signed by a real trusted CA.
>
> But you trust the CA certificates the server send to you, do you?
After verifying that the signatures are valid in the chain, all the
way to a trusted root, then yes. If the signatures don't pass the test,
then no. The crucial difference is that when using certs from the SSL
server, we can construct the chain, and validate all its signatures,
without doing fetches from URLs in the certs first. But when trying to
complete a chain by fetching certs from URLs in AIA extensions, we cannot
validate the signature in the cert from which the URL is taken until
after we've gone and attempted to fetch certs from the URL in the
unvalidated cert, a URL supplied by the (potential) attacker.
>> Even if its issuer name matches that of
>> a known and trusted CA, it may be a cert crafted by an attacker
>
> Really? Please enlighten me how...I would like to see a real example!
Isn't this obvious?
Think about this. Using certutil, I can construct a certificate that
has an issuer name that exactly matches (every bit) the subject name
of one of your CA's CA certs, but that has an AIA extension containing
a URL that does not go to the server your real AIA's use, but goes to
a completely different server. The cert I create will not have a
signature that can be validated with your real CA cert, but as an attacker,
I don't care because the damage will be done before the relying party
discovers that my cert was not really issued by your CA.
I can provide a more detailed description, and even a live example, if
necessary, but really, by now this should be obvious.
> But in that case the server can send also such a specially crafted CA
> certificate which chains to a builtin root, right?
Not unless it has the private key of the builtin root. It can create a
cert that has an issuer name that matches a built-in root, but the signature
will not validate. The security or vulnerability is all
controlled by which operation is done first, the signature verification
of the chain, or the fetching or external data (certs, CRLs, OCSP) based
on the contents of those certs.
> There is no difference between relying on a server sending the missing
> chain or NSS fetching it.
Again the obvious difference is that in once case, the relying party
goes out and fetches from URLs in a cert of unknown origin, and in the
other case, it does not.
> In the end it must in both case validate up to a known root.
[snip]
> There is no higher risk that relying on the CA chain the server sends.
> In moth cases the parties might be interesting in spoofing....
Let me try to clarify the nature of the vulnerability.
The concern is NOT that the relying party will be fooled into accepting
a bogus cert as legitimate. The concern is that, before the relying
party determines that the cert is bogus, it will have acted as a proxy
for the attacker by fetching from an attacker-supplied URL. Being able
to be tricked into acting as such a proxy is a vulnerability.
Nelson B Bolyard
> There's another, more pressing issue:
>
> If there are buffer overflows in ASN.1 parsing (there have been in at
> the least OpenSSL and Microsoft's), anyone who can provide a
> certificate that points to an AIA that ultimately wouldn't be trusted
> could provide malicious data that could compromise the issue.
About 5-6 years ago, NISCC, an office of the UK government, made available
to software developers an enormous set of test data, over 1 million certs,
each crafted to detect buffer potential buffer overflows. The set was
produced at the University of Oulu (IIRC) for NISCC. There were also
test cases for PKCS#7 and numerous other common BER/DER message/file
formats. There were SSL server certs and client auth certs, IIRC.
A major part of the work done for NSS 3.9.0 in late 2003 was that we
devised test programs and test scripts to test with all those files of
test data. I devised an SSL server and SSL client that would serve up a
different one of those test certs in each full handshake. We enhanced
certutil and our PKCS7 and SMIME test tools to facilitate this testing.
We found a lot of bugs, and fixed them all. We now run the NISCC tests
periodically (nightly or weekly, IIRC) to ensure no regressions there.
Consequently, since the release of NSS 3.9.0, our confidence level in the
"bullet proof" nature of our ASN.1 decoder, and the higher level decoders
that use it (such as PKCS7) is very high.
Eddy Nigg
>
> After verifying that the signatures are valid in the chain, all the
> way to a trusted root, then yes.
And what exactly prevents you from verifying the signatures of the
received chain (by whatever means you constructed the chain) all the way
to a trusted root? What does it matter if you received the sub-ordinate
CA certificate from:
1.) The Server
2.) The AIA CA Issuer URL
3.) Previously stored in authorities
4.) UI input box from the user
5.) International Space Station
> If the signatures don't pass the test,
> then no.
Exactly!
> The crucial difference is that when using certs from the SSL
> server, we can construct the chain, and validate all its signatures,
YES!
> without doing fetches from URLs in the certs first.
What does that matter? Seriously! Who cares?
> But when trying to
> complete a chain by fetching certs from URLs in AIA extensions, we cannot
> validate the signature in the cert from which the URL is taken until
> after we've gone and attempted to fetch certs from the URL in the
> unvalidated cert
Of course...so discharge the received invalid obtained CA certificate
and proceed with the error.
> a URL supplied by the (potential) attacker.
I call that nonsense! If you believe what you are saying you can't rely
on any server sending a certificate chain, because every server can be a
(potential) attacker!
> Isn't this obvious?
No
>
> Think about this. Using certutil, I can construct a certificate that
> has an issuer name that exactly matches (every bit) the subject name
> of one of your CA's CA certs,
So? Does it match the signature as well?
> but that has an AIA extension containing
> a URL that does not go to the server your real AIA's use, but goes to
> a completely different server.
Of course...but it doesn't matter, the signature never matches.
> The cert I create will not have a
> signature that can be validated with your real CA cert
Right
> but as an attacker,
> I don't care because the damage will be done before the relying party
> discovers that my cert was not really issued by your CA.
More nonsense! If the signature doesn't match you can't construct a
valid chain up to a trusted root and you return an error. The same error
you return today when the certificate can't be validated up to a trusted
root. EXACTLY the same thing!
> Not unless it has the private key of the builtin root. It can create a
> cert that has an issuer name that matches a built-in root, but the signature
> will not validate.
EXACTLY! You are saying it yourself!
> The security or vulnerability is all
> controlled by which operation is done first, the signature verification
> of the chain, or the fetching or external data (certs, CRLs, OCSP) based
> on the contents of those certs.
Fist you try to construct a valid chain - being it with the certificates
the server supplied, by the AIA extensions or by looking at the local
auth store...
>
> Again the obvious difference is that in once case, the relying party
> goes out and fetches from URLs in a cert of unknown origin, and in the
> other case, it does not.
That's wrong! Not the relying party is doing it, but the software is
doing it! The software fetches those missing certificates, tries to
build the chain and validate this chain. The software returns the either
the error and continues the process (of validating the CRL, OCSP etc).
The relying party is absolutely passive at this stage, there is nothing
to do at this stage then wait for the site to appear.
> The concern is NOT that the relying party will be fooled into accepting
> a bogus cert as legitimate. The concern is that, before the relying
> party determines that the cert is bogus, it will have acted as a proxy
> for the attacker by fetching from an attacker-supplied URL.
WHAT? You are fetching most likely a certificate...but even if it's
something else, the software can perform its usual checks as it should
do with anything which is supplied - including the CA chain from the server.
> Being able
> to be tricked into acting as such a proxy is a vulnerability.
Nonono...this proxy-thing has nothing to do with it. Where is this
proxy? Where is the vulnerability exactly?
Kyle Hamilton
Client Alice connects to server Mary. Mary sends a certificate with
an AIA, no chain.
Mary happens to be a honeypot.
Alice looks up AIA, makes connection to Mallory to retrieve the certificate.
Mallory is looking for people who are looking at Mary.
Mallory knows, beyond a shadow of a doubt, that Alice is looking at Mary.
-Kyle H
Eddy Nigg
> Client Alice connects to server Mary. Mary sends a certificate with
> an AIA, no chain.
Cute :-)
> Mary happens to be a honeypot.
>
> Alice looks up AIA, makes connection to Mallory to retrieve the certificate.
>
> Mallory is looking for people who are looking at Mary.
>
> Mallory knows, beyond a shadow of a doubt, that Alice is looking at Mary.
>
Since Mary and Mallory are under the same control it doesn't matter.
Whoever controls Mary knows that Alice is looking at Mary anyway...Even
in the scenario of Mary being compromised doesn't matter anymore...
Kyle Hamilton
Mary has a site with a cert with AIA. Mallory can take control over
that location for the AIA, without Mary being able to do a thing to
stop it.
-Kyle H
Eddy Nigg
> Mary and Mallory may not be the same control.
>
> Mary has a site with a cert with AIA. Mallory can take control over
> that location for the AIA, without Mary being able to do a thing to
> stop it.
>
Mary knows that she has a cert, because she installed it. If the cert is
from a CA, than the CA knows about that Alice visited Mary already by
other means (CRL,OCSP).
Supposed Mallory isn't the CA and has no control over Mary, than Mallory
has perhaps control (by whatever means) over the DNS server Alice is
using. Now the CA issuer URL of the AIA extension of the cert installed
at Mary will point to a different IP instead of that of the CA. Now
Mallory knows that Alice (and whoever else) visited Mary. But wait, he
can do the same with the CLR DP and OCSP URL. The CA Issuer URL doesn't
introduce anything new here.
However in all those cases, the connection to the secured site of Mary
may not succeed because
- the issuer certificate doesn't validate to a trusted root
- the CRL isn't valid
- the OCSP response is certainly not valid
Now Alice might realize that maybe something isn't quite right. However
in any of the cases above there is no vulnerability - there might be a
problem in case the DNS is poisoned and Alice reveals unwillingly that
she tried to visit Mary. There is a big difference!
Now the impact of that scenario is by far, far smaller than some want us
to believe. In any case, the CA Issuer and fetching of the certificate
doesn't introduce ANYTHING new - otherwise get rid of CRL and OCSP
checking as well. It's the same attack vector.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
> There's another, more pressing issue:
>
> If there are buffer overflows in ASN.1 parsing (there have been in at
> the least OpenSSL and Microsoft's), anyone who can provide a
> certificate that points to an AIA that ultimately wouldn't be trusted
> could provide malicious data that could compromise the issue.
We took care of such issues in our ASN.1 parsing years ago. It was a
large effort and many problems were found, and resolved in NSS 3.9, in
2004. Currently, we run test cases of millions of malformed certs from
NISCC against every nightly build of NSS, FYI, to make sure that the
code in that area doesn't regress. I'm not saying there are no
remaining bugs - some may be found eventually - but we take the code in
our ASN.1 decoders/encoder very seriously.
> In addition, if there were an MD5-like hash collision in such a way
> that an attacker could forge an apparently-valid (the signature
> matches what was signed, though the data does not) CA:true
> certificate, then all hell breaks loose.
Currently nothing of the sort has been shown to be possible, however.
Eddy Nigg
>
> We took care of such issues in our ASN.1 parsing years ago. It was a
> large effort and many problems were found, and resolved in NSS 3.9, in
> 2004. Currently, we run test cases of millions of malformed certs from
> NISCC against every nightly build of NSS, FYI, to make sure that the
> code in that area doesn't regress. I'm not saying there are no remaining
> bugs - some may be found eventually - but we take the code in our ASN.1
> decoders/encoder very seriously.
Julien, can we assume that by trying to construct a valid chain up to a
trusted root - even by fetching intermediate CAs via the AIA CA Issuer
extension - doesn't present a risk we can not take? During this
discussion I've found that only a very minimal privacy concern exists -
if at all. I'd very much like to see the arguments against the
implementation of fetching intermediate CA certificates declared null
and void. At least to the extend which would allow us for such an
implementation.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
>
> Julien, can we assume that by trying to construct a valid chain up to a
> trusted root - even by fetching intermediate CAs via the AIA CA Issuer
> extension - doesn't present a risk we can not take? During this
> discussion I've found that only a very minimal privacy concern exists -
> if at all. I'd very much like to see the arguments against the
> implementation of fetching intermediate CA certificates declared null
> and void. At least to the extend which would allow us for such an
> implementation.
I'm only saying it's safe to try to decode anything you have in memory
within the application with one of the NSS ASN.1 decoders, and it
doesn't present a risk to the integrity risk of the rest of the process.
Issues of privacy related to downloads having been performed are
separate. I must say that I haven't been following that part of the
discussion closely enough to have an opinion on that topic.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
> Mary and Mallory may not be the same control.
>
> Mary has a site with a cert with AIA. Mallory can take control over
> that location for the AIA, without Mary being able to do a thing to
> stop it.
If Mallory was able to replace Mary's cert with a fake one, then they
effectively have control already, and they might as well save themselves
the trouble and just download Mary's server log file. It will be much
more discreet, and less trouble.
The other case is an MITM . Mallory is intercepting Mary's incoming
connections somehow, and sending their own fake cert (MITM) with an AIA,
that phones back home. However in that case, why bother even phoning
back home ? Mallory is in the middle, and already knows that Alice is
trying to connect to Mary.
It's a little hard to see what Mallory is gaining from using an AIA that
they can't already get by other means.
Eddy Nigg
>
> I'm only saying it's safe to try to decode anything you have in memory
> within the application with one of the NSS ASN.1 decoders, and it
> doesn't present a risk to the integrity risk of the rest of the process.
Thank you! This was my understanding on this subject. Similar I believe
that NSS can try to construct a valid chain by using different input
sources including server supplied, AIA and local authority DB. This will
result in either a failure or success, for both situation NSS has a
defined process.
Eddy Nigg
>
> It's a little hard to see what Mallory is gaining from using an AIA that
> they can't already get by other means.
And besides that, there are precedents with OCSP URI, to which any of
the mentioned scenarios would also apply. However as you mentioned, I
believe that the argument isn't really of concern for the reason you
outlined.
Joe Orton
> On Wed, Sep 17, 2008 at 4:52 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> >
> > I've been banging my head against a wall here because of this FUD and
> > about misinformation which is absolutely incorrect. Sad, because there
> > are many FF users running into it. And it doesn't help to ignore the
> > fact that web site admins don't install their certs correctly - it works
> > in IE and that's it.
>
> its own certificate chain at startup.
[catching up on some old e-mail!]
This would be quite simple to do, but mod_ssl doesn't necessarily have
access to a set of trusted CA certs against which to validate a server
cert, so it couldn't be universally applied. It might be possible for
mod_ssl to determine whether OpenSSL has in fact been configured with a
set of default CAs (many Linux distributions do set this up), and
perform validation only in that case.
Regards, Joe