bug report / asn1 parse error

[Neil Spring]

Hi;

I sent the messages below to address@hidden as
recommended on the gnutls web page, but had them rejected
from being forwarded to address@hidden because it
is automatically bcc'd (or some such lackluster sendmail
magic).

In order for a gnutls-linked program to interoperate with a
server using an openssl generated certificate (eg.  those
ssl daemons currently in Debian) the asn1 parser has to be
modified to use a larger buffer when processing extensions.

More robust solutions than simply increasing the size of
the stack-allocated buffer would be to ignore extensions
that are too long, or allocate space to store them
dynamically.

I'd appreciate it if such a change can be made before 
the next release.

thanks,
-neil

On Wed, Oct 03, 2001 at 05:01:32PM -0700, Neil Spring wrote:
> This icky parse error can be fixed by increasing the size
> of the extnValue buffer to 512. I didn't really play around
> with other values between 128 and 512, and it might be
> the case that an even larger buffer is necessary.
> 
> line 210 of x509_extensions.c.   If you can make this
> change before 0.2.4, I'd appreciate it.
> 
> I believe the extension that causes this overflow is the
> following (from 'openssl x509 -in server.pem -text') :
> 
>      X509v3 Authority Key Identifier: 
>        keyid:D6:5D:C0:40:A6:D1:BA:35:D3:C4:4A:A0:26:B3:05:43:3C:FA:69:D5
>        DirName:/C=US/ST=Washington/L=Seattle/O=Univ 
> Washington/CN=poplar.cs.washington.edu/address@hidden
>        serial:00
> 
> thanks, 
> -neil
> 
> On Sun, Sep 30, 2001 at 11:55:12PM -0700, Neil Spring wrote:
> > Hi.
> > 
> > I'm working on adding TLS support to wmbiff's IMAP client.
> > 
> > I've got a successful client talking to my school's IMAP
> > server, but it fails when handshaking with my home IMAP
> > server.  My imap server is either uw-imapd-ssl using the
> > STARTTLS command or the same server behind sslwrap (both
> > from Debian, both of which use openssl).
> > 
> > I uncommented HANDSHAKE_DEBUG and DEBUG, and added
> > an extra gnutls_log call where asn1_read_value fails and
> > see the following output using 0.2.3.  Lines that begin
> > 'zarathustra' were generated by my program.
> > 
> > zarathustra.saavie.org:143: got: a001 OK STARTTLS completed
> > GNUTLS_ASSERT: gnutls_cert.c:231
> > Handshake: CLIENT HELLO was send [50 bytes]
> > Handshake: SERVER HELLO was received [74 bytes]
> > Server's version: 3.1
> > SessionID length: 32
> > SessionID: 2dae0afeb07d804384d399b639836265328d8e962e805075580843e9bc9b8685
> > Selected cipher suite: RSA_3DES_EDE_CBC_SHA
> > Handshake: CERTIFICATE was received [791 bytes]
> > GNUTLS_ASSERT: x509_extensions.c:266
> > asn1_read_value parsing certificate2.tbsCertificate.extensions.?2.extnValue 
> > returned 12
> > GNUTLS_ASSERT: gnutls_cert.c:865
> > GNUTLS_ASSERT: auth_rsa.c:511
> > GNUTLS_ASSERT: gnutls_kx.c:558
> > GNUTLS_ASSERT: gnutls_handshake.c:1311
> > GNUTLS Error: recv server certificate (-42)
> > zarathustra.saavie.org:143: Handshake failed
> > GNUTLS ERROR: ASN1_PARSING_ERROR
> > Failed to initialize TLS
> > 
> > The ASN1 parsing error #12 is apparently ASN_MEM_ERROR.
> > 
> > I assume, without much basis, that this is either an
> > interoperability problem with openssl or a dislike of
> > openssl generated certificates.  If you need any details
> > or have suggestions, please let me know.  It would be
> > great to know I'm invoking the gnutls library correctly.
> > 
> > I don't know if it's possible to gracefully recover from
> > failure to parse the certificate and keep the encrypted
> > association, but that might be handy.
> > 
> > If this belongs instead on gnutls-dev or -help, feel free
> > to forward.
> > 
> > -neil