Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Daniel Kahn Gillmor
for gnutls in etch and/or lenny), and i do think that it is potentially
quite serious.
For example, the certificate used by https://mail.google.com/ appears to
be rooted in a v1 CA certificate:
0 dkg@pip:~$ echo | gnutls-cli --print-cert -p https mail.google.com |
> certtool -i | egrep '(Issuer|Subject):' | tr -d '\t'
Issuer: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
Subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=mail.google.com
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification
Authority
Subject: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
0 dkg@pip:~$ cd /usr/share/ca-certificates/mozilla/
0 dkg@pip:.../mozilla$ for foo in Verisign_Class_3_*.crt; do
> printf "%s %d\n" $foo \
> $(certtool -i <$foo | grep Version: | tr -d -c '13')
> done
Verisign_Class_3_Public_Primary_Certification_Authority.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt 1
0 dkg@pip:.../mozilla$
I have two alternate proposals that could be considered for etch and/or
Lenny. So including the current state of the package and a full revert,
i see 4 options, and i'd be really happy to get feedback:
---------------
0) Leave the library as it is; tools must use GnuTLS in the documented
way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
trust V1 certificates as certificate authorities.
1) same as 0, but we special-case the limited set of publically-known
V1 CA certificates shipped in the ca-certificates package: if any of
those exact certificates are included in the trusted certificates list,
they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is not set.
2) same as 1, but rather than test exact matches against the specific
V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
if they meet the following requirements:
a) The V1 certificate must not have any SubjectAltName extensions (i
think extensions in general require X.509v3, so this may be moot)
b) If the V1 certificate Subject has a CN, the CN must not be a
syntactically-valid hostname. For example, it should have spaces or
slashes or some other character that is forbidden A RR labels in DNS.
3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set (this may
mean that there is *no way* to turn this flag off -- hopefully people
who know gnutls better than myself can say if this is the case)
---------------
2a and 2b are intended to weed out certificates that were originally
issued with the intent of being an end-entity certificate for a host or
public service. I tried to come up with some limit 2c, to reject
certificates that had been issued to non-host end entities (usually end
user client certificates), or to come up with some other matching rule
(e.g. "the Subject should contain the string 'Authority'") but i haven't
come up with anything satisfactory. Suggestions are welcome.
These are listed in the order that i personally prefer them (that is, i
prefer 0 to the others, 1 over 2 and 3, and 2 over 3). Do other people
have opinions here? I have no code ready to implement 1 or 2, but i
would be happy to try to help folks generate or assess such a patch if
there are people willing to advocate for it.
Also: maybe we want to use one approach for etch, and a different one
for lenny. With a well-thought out transition strategy, we could
minimize some of the potential pain.
Thoughts?
--dkg
PS i really don't like the monopolistic/money-grubbing/unethical
behavior of most of the dominant commercial CAs; i feel like their
general motives are at odds with my personal goals of having end-to-end
secure connections available for any netizen. So explicitly
grandfathering these groups into gnutls X.509 verification (option 1)
irks me not a little bit. However, newer CAs can (and do) use V3 root
certs, so i don't feel that we would be further entrenching the
800-pound gorillas.
Simon Josefsson
> For example, the certificate used by https://mail.google.com/ appears to
> be rooted in a v1 CA certificate:
Sigh, one would have hoped they had more clue.
> 0) Leave the library as it is; tools must use GnuTLS in the documented
> way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
> trust V1 certificates as certificate authorities.
This appears to be the Right Thing in general, and happens to also be
the simplest for me as GnuTLS maintainer, so it is what the upstream
GnuTLS package will use. Or rather, it is what upstream will continue
to use, nothing in the documentation or intended behaviour has changed
in the last few years here.
I realize 0) may not be ideal from a systems perspective, in particular
for etch, but I'm not the best person to judge that.
> 1) same as 0, but we special-case the limited set of publically-known
> V1 CA certificates shipped in the ca-certificates package: if any of
> those exact certificates are included in the trusted certificates list,
> they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
> is not set.
Sounds pragmatic to me, although somewhat complex and I suspect we'll
see increasing requests to add to that list of exceptions. I won't
produce a patch for this, it seems somewhat messy.
> 2) same as 1, but rather than test exact matches against the specific
> V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
> if they meet the following requirements:
>
> a) The V1 certificate must not have any SubjectAltName extensions (i
> think extensions in general require X.509v3, so this may be moot)
I think you are correct, extensions require V3. If there are any
extensions in a V1 cert, the cert should be rejected as invalid.
> b) If the V1 certificate Subject has a CN, the CN must not be a
> syntactically-valid hostname. For example, it should have spaces or
> slashes or some other character that is forbidden A RR labels in DNS.
Nice idea. Sounds like it could work.
> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
This is essentially the (untested) patch I proposed earlier.
> (this may mean that there is *no way* to turn this flag off --
> hopefully people who know gnutls better than myself can say if this is
> the case)
Applications can still call gnutls_certificate_set_verify_flags to
override the default.
While I was negative initially, I think there are some arguments for
this solution: it only enables V1 CAs that the user has _explicitly_
marked as trusted. So the user could be informed through documentation
that if he adds V1 CAs as a trusted certs, they may lead to the security
problems with V1 certs. I don't think we'll make this change upstream,
the risks associated doesn't seem negligible and I think V1 certs should
just go away.
> These are listed in the order that i personally prefer them (that is, i
> prefer 0 to the others, 1 over 2 and 3, and 2 over 3). Do other people
> have opinions here? I have no code ready to implement 1 or 2, but i
> would be happy to try to help folks generate or assess such a patch if
> there are people willing to advocate for it.
>
> Also: maybe we want to use one approach for etch, and a different one
> for lenny. With a well-thought out transition strategy, we could
> minimize some of the potential pain.
Yes, I am beginning to think that possibly 3) may be appropriate for
etch, although I'm not sure how large of a problem this actually is. If
it is not a large problem, maybe the answer should just be that they
need to renew their certificates with a better CA (or set up their own
CA).
Personally, I don't have time to develop and maintain patches for 1) or
2), and prefer choosing between 0) and 3) -- however, that opinion is
biased because I'm a gnutls developer rather than a debian developer
with a focus on the behaviour of the entire distribution.
> PS i really don't like the monopolistic/money-grubbing/unethical
> behavior of most of the dominant commercial CAs; i feel like their
> general motives are at odds with my personal goals of having end-to-end
> secure connections available for any netizen. So explicitly
> grandfathering these groups into gnutls X.509 verification (option 1)
> irks me not a little bit. However, newer CAs can (and do) use V3 root
> certs, so i don't feel that we would be further entrenching the
> 800-pound gorillas.
This is one of the reasons why I am for option 0) in the official GnuTLS
package, and strongly against any other option in the official package.
However, I realize that Debian may chose to patch the etch version of
GnuTLS differently.
/Simon
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Kahn Gillmor
On 02/19/2009 05:02 PM, Simon Josefsson wrote:
> Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>
> This is essentially the (untested) patch I proposed earlier.
>
>> (this may mean that there is *no way* to turn this flag off --
>> hopefully people who know gnutls better than myself can say if this is
>> the case)
>
> Applications can still call gnutls_certificate_set_verify_flags to
> override the default.
Good point. I appreciate the clarification.
> While I was negative initially, I think there are some arguments for
> this solution: it only enables V1 CAs that the user has _explicitly_
> marked as trusted. So the user could be informed through documentation
> that if he adds V1 CAs as a trusted certs, they may lead to the security
> problems with V1 certs.
My understanding is that the security problem is with adding V1
*end-entity* certificates to the trusted certificate list. If you do
so, and we go with option 3, those EE certificates would be able to act
as certificate authorities because GnuTLS is unable to distinguish the
two classes of certificate. But this doesn't indicate any problems with
adding V1 CA certs, only EE certs, no? Are there other security
problems with V1 certificates for CAs? I certainly don't understand all
the issues here as well as i wish i did.
I've added Nikos to the Cc list here in case he can clarify.
> I don't think we'll make this change upstream,
> the risks associated doesn't seem negligible and I think V1 certs should
> just go away.
I agree that V1 certs should just go away, if only to avoid this sort of
confusion.
--dkg
Andreas Metzler
> I've done a bit of research on this bug (dealing with V1 CA certificates
> for gnutls in etch and/or lenny), and i do think that it is potentially
> quite serious.
> For example, the certificate used by https://mail.google.com/ appears to
> be rooted in a v1 CA certificate:
[...]
Shouldn't gnutls-cli mark the certificate as unverified in that case?
----------------------
ametzler@argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem -p https mail.google.com
Processed 1 CA certificate(s).
Resolving 'mail.google.com'...
Connecting to '66.249.91.83:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
# The hostname in the certificate matches 'mail.google.com'.
# valid since: Fri May 2 18:32:54 CEST 2008
# expires at: Sat May 2 18:32:54 CEST 2009
# fingerprint: C3:36:8D:8C:7F:27:45:78:E5:A5:08:40:D3:EF:16:67
# Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc,CN=mail.google.com
# Issuer's DN: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
- Certificate[1] info:
# valid since: Thu May 13 02:00:00 CEST 2004
# expires at: Tue May 13 01:59:59 CEST 2014
# fingerprint: 84:84:03:56:10:85:53:ED:9A:CA:60:B5:FA:99:D3:31
# Subject's DN: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
# Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
- Peer's certificate is trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: SHA1
- Compression: NULL
- Handshake was completed
- Simple Client Mode:
----------------------
ametzler@argenau:/etc/ssl/certs$ certtool -i < /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem
X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
[...]
Signature Algorithm: RSA-MD2
warning: signed using a broken signature algorithm that can be forged.
[...]
----------------------
cu and- mystified -reas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Nikos Mavrogiannopoulos
> Thanks for the feedback, Simon.
>
> On 02/19/2009 05:02 PM, Simon Josefsson wrote:
>> Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
>>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>> This is essentially the (untested) patch I proposed earlier.
>>
>>> (this may mean that there is *no way* to turn this flag off --
>>> hopefully people who know gnutls better than myself can say if this is
>>> the case)
>> Applications can still call gnutls_certificate_set_verify_flags to
>> override the default.
>
> Good point. I appreciate the clarification.
>
>> While I was negative initially, I think there are some arguments for
>> this solution: it only enables V1 CAs that the user has _explicitly_
>> marked as trusted. So the user could be informed through documentation
>> that if he adds V1 CAs as a trusted certs, they may lead to the security
>> problems with V1 certs.
>
> My understanding is that the security problem is with adding V1
> *end-entity* certificates to the trusted certificate list. If you do
> so, and we go with option 3, those EE certificates would be able to act
> as certificate authorities because GnuTLS is unable to distinguish the
> two classes of certificate. But this doesn't indicate any problems with
> adding V1 CA certs, only EE certs, no?
Indeed it affects end entity certs. I missed the discussion though I
understand it is about V1 CAs and being disabled by default. To be
honest although V1 certificates have been deprecated for more than a
decade CAs still use the V1 format for their certificates
(ca-certificates contains more than 10 of these).
However allowing them by default will make applications that rely on
adding end-entity certificates to the trusted certificate list insecure.
Thus it might be better for applications to explicitly enable this flag
if they do not use end-entity certificates there.
regards,
Nikos
Daniel Kahn Gillmor
> On 2009-02-19 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
>> I've done a bit of research on this bug (dealing with V1 CA certificates
>> for gnutls in etch and/or lenny), and i do think that it is potentially
>> quite serious.
>
>> For example, the certificate used by https://mail.google.com/ appears to
>> be rooted in a v1 CA certificate:
> [...]
>
> Shouldn't gnutls-cli mark the certificate as unverified in that case?
I believe gnutls-cli (appropriately) sets
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, because the semantics of its
invocation indicate that the certificates passed to the trusted store
are explicitly limited to CA certificates, and cannot possibly be
end-entity certificates.
> ametzler@argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem -p https mail.google.com
> Processed 1 CA certificate(s).
Your invocation told gnutls-cli that the certificate *was* a CA, so it
didn't have to guess whether you'd intended to use the attached
certificate as an end-entity certificate or not.
> cu and- mystified -reas
Hope this helps de-mystify somewhat. Frankly, the V1 vs. V3 business
seems to me to be as much a problem with the GnuTLS API as it does with
the crusty old X.509v1 specification. If GnuTLS certificate validation
were to use two different user-provided lists of certificates: one of
explicit CAs and one of potential peers (End Entities), this whole
discussion would be moot.
But of course, that's not what it does: applications provide the
verification code with a single list of pre-verified "trusted"
certificates, and GnuTLS distinguishes between End Entities and CAs
based on attributes *within* each cert in the list (and apparently V1
certs have no such distinguishing attributes). In practice, i suspect
that many software authors who use GnuTLS haven't been aware of this
subtle distinction.
hth,
--dkg
Edward Allcutt
> Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
>
>> 0) Leave the library as it is; tools must use GnuTLS in the documented
>> way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
>> trust V1 certificates as certificate authorities.
>
> This appears to be the Right Thing in general, and happens to also be
> the simplest for me as GnuTLS maintainer, so it is what the upstream
> GnuTLS package will use. Or rather, it is what upstream will continue
> to use, nothing in the documentation or intended behaviour has changed
> in the last few years here.
it's too disruptive a change. For lenny... well I'm not sure. It may be
possible to patch all the relevant apps for the first point release but:
a) I don't know if this is an acceptable "fix" now that lenny is stable.
b) A number of systems will break on upgrade until the fixes get out.
c) This should probably be added to the release notes, is that still
possible?
>> 1) same as 0, but we special-case the limited set of publically-known
>> V1 CA certificates shipped in the ca-certificates package: if any of
>> those exact certificates are included in the trusted certificates list,
>> they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>> is not set.
>
> Sounds pragmatic to me, although somewhat complex and I suspect we'll
> see increasing requests to add to that list of exceptions. I won't
> produce a patch for this, it seems somewhat messy.
Too messy to get into etch certainly. Probably too messy for lenny too.
>> 2) same as 1, but rather than test exact matches against the specific
>> V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
>> if they meet the following requirements:
Sounds reasonable, but I'm suspicious that these special case rules
won't turn out to match the exact set of certs that we'd wish. It also
sounds less messy than 1) but still adding a big chunk of new code.
>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>
> This is essentially the (untested) patch I proposed earlier.
I have tested it. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=144;bug=514807
I've had no issues in my (limited) testing. I'm going to deploy it to a
more heavily used system and see if anything crops up.
>> Also: maybe we want to use one approach for etch, and a different one
>> for lenny. With a well-thought out transition strategy, we could
>> minimize some of the potential pain.
>
> Yes, I am beginning to think that possibly 3) may be appropriate for
> etch, although I'm not sure how large of a problem this actually is. If
> it is not a large problem, maybe the answer should just be that they
> need to renew their certificates with a better CA (or set up their own
> CA).
I think my views for etch are clear. I should add that this is not
simply an issue with checking my own organization's certificates. Some
libgnutls-linked apps need to verify 3rd-party certificates which I (and
other Debian users) have no control over. I think mail.google.com was
mentioned as an example.
For lenny I'm far more flexible. So long as the issue gets resolved
(soon) I don't particularly mind how. Whether 0) or 3) or some
compromise is chosen will depend more on what changes are acceptable now
that lenny is stable.
>> PS i really don't like the monopolistic/money-grubbing/unethical
>> behavior of most of the dominant commercial CAs; i feel like their
>> general motives are at odds with my personal goals of having end-to-end
>> secure connections available for any netizen. So explicitly
>> grandfathering these groups into gnutls X.509 verification (option 1)
>> irks me not a little bit. However, newer CAs can (and do) use V3 root
>> certs, so i don't feel that we would be further entrenching the
>> 800-pound gorillas.
I don't disagree with your views of the big players, however I think
this is a red herring. There does seem to be an ongoing transition away
from v1 certs but it appears to be rather a slow process. I don't think
GnuTLS is really in a position to strong-arm the big players into
hurrying things along.
--
Edward Allcutt