help-gnutls
[Top][All Lists]
Advanced

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

Re: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning GNUTLS_E_CONSTRAIN


From: Nikos Mavrogiannopoulos
Subject: Re: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning GNUTLS_E_CONSTRAINT_ERROR
Date: Sun, 17 Feb 2008 16:11:17 +0200
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

O/H Nikos Mavrogiannopoulos έγραψε:
O/H Daniel Stenberg έγραψε:
On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:

The culprit here for you is the -101. That's
gnutls_certificate_verify_peers2() returning GNUTLS_E_CONSTRAINT_ERROR.

I can see two cases where this can be returned.
1. the verify depth of the certificate is quite high (ie the chain
being verified is long).
The default maximum depth is 6. Although it is possible to have such
long chain, it is most probably
a configuration error if the server sends more than 6 certificates.
- this limit can be adjusted by gnutls_certificate_set_verify_limits()

2. the key bits of the certificates are longer than the maximum allowed (8200). this limit can also be adjusted by the same function.

But seeing this is a live server used by mere mortals out there (it is a bank after all), wouldn't it perhaps be an indication that the defaults are a bit too restrictive? Also, both OpenSSL and Firefox (NSS) deal with it by default.

However, I tried adding this:

gnutls_certificate_set_verify_limits(conn->ssl[sockindex].cred,
20200, 18);

Is there any way for me to figure out sensible values for me to set to this function? I just upped them a couple of times until the function worked!

And yes, it now makes gnutls_certificate_verify_peers2() return success but then... verify_status still contained the GNUTLS_CERT_INVALID bit. So something still isn't liking this server!
I'm really loaded to check it right now, thus I've added a ticket at:
http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/17#preview

The original idea was to avoid denial of service attacks by a server (sending you 9999 certificates of 99999 bits). That would make the client unresponsive. Using more sensible defaults is an option. (Patches are always accepted! :)

It seems my time wasn't that limited and the fix was quite easy.
The fix is in this commit:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=36bc9d48a807e303a5fe3c459ebd89389298d787


regards,
Nikos





reply via email to

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