help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-gnutls] Re: Certificate verification failed


From: Simon Josefsson
Subject: [Help-gnutls] Re: Certificate verification failed
Date: Fri, 28 Oct 2005 13:40:09 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Daniel Stenberg <address@hidden> writes:

> Besides, there is no --insecure option to the library libcurl (the
> command line option modifies two options in the library) and even if I
> certainly could introduce an option for this purpose, I'd hesitate to
> do so. Mostly because:
>
>  A) libcurl users will want to be able to use publicly available CA certs such
>     as the Debian one and thus they will want to have MD2/MD5 enabled in a
>     very large extent (my assumption)
>
>  B) OpenSSL supports MD2/MD5 out of the box and when people switch
>     libcurl-openssl to libcurl-gnutls they want them to provide the same
>     feature set, as closely as possible.
>
>  C) OpenSSL doesn't have an option to disable these algorithms, AFAIK.
>     My (new) ambition in libcurl is to provide an SSL-layer agnostic API that
>     should make apps able to use libcurl identically and with the same
>     functionality independent of what SSL-layer it has been built to use.
>
> There are many (I don't know the exact number) packages in Debian that
> depend on libcurl-openssl and judging from public statements, Debian
> aims to move them all over to libcurl-gnutls.
>
> I know all this are headaches of the libcurl project and not really
> concerning the GnuTLS project. I'm mainly filling in some info here to
> give you guys a background on why I ask all these questions and
> stuff. I'll shutup about this now on this list.

I suspect all GnuTLS applications have similar concerns, so I believe
it is useful to have the discussion here.

Given the recent changes in CVS, I don't think there will be much
problems.  RSA-MD2 is supported, so the initial problem with
www2.net.hsbc.com should be fixed.

The only modification that may have negative interoperability impact
is if there are intermediary CAs that use RSA-MD2/MD5.  In the
www2.net.hsbc.com example, the chain was RSA-MD2 -> RSA-SHA1 ->
RSA-SHA1 so it would verify correctly.  If the chain was ?->RSA-MD?->?
there would be a problem, such a chain would not verify in the new
version.  In the old version, ?->RSA-MD5->? would verify correctly,
but ?->RSA-MD2->? would not (because RSA-MD2 wasn't supported).  I'm
not sure how many real-world chains look like ?->RSA-MD5->?.  Sampling
that would be interesting.

If I understand correctly, all the information needed to produce
colliding RSA-MD5 X.509 certificates are publicly available.  It
supposedly only takes hours to do create these certificates.  I don't
think users should be tricked into feeling secure if RSA-MD5 is used
within a chain.

In any case, the hook to re-enable RSA-MD2 and RSA-MD5 are present, so
I think GnuTLS can meet everybody's needs.

Thanks,
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]