From ben.hutchings at roundpoint.com Mon Jan 7 18:55:01 2002 From: ben.hutchings at roundpoint.com (Ben Hutchings) Date: Mon, 7 Jan 2002 17:55:01 +0000 Subject: [Help-gnutls] Failure to connect from mutt with gnutls Message-ID: <20020107175501.GC14260@zzumbouk.i.decadentplace.org.uk> I'm trying to use the Debian version of mutt (version 1.3.24) with gnutls (version 0.2.11) to connect to an IMAP server with SSL support (provided by stunnel 3.10 and OpenSSL 0.9.4). mutt fails to connect to the server, leaving a status message "gnutls_handshake". stunnel logs an error message like this: Jan 7 01:34:40 halibut stunnel[32346]: SSL_accept: error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len I have made successful IMAP/SSL connections to this server with a variety of other clients, so I don't think stunnel is at fault. So might this be a fault in gnutls, or should I be looking at mutt? From andrew at mcdonald.org.uk Mon Jan 7 20:27:11 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Mon, 7 Jan 2002 19:27:11 +0000 Subject: [Help-gnutls] Failure to connect from mutt with gnutls In-Reply-To: <20020107175501.GC14260@zzumbouk.i.decadentplace.org.uk> References: <20020107175501.GC14260@zzumbouk.i.decadentplace.org.uk> Message-ID: <20020107192711.GA1502@mcdonald.org.uk> On Mon, Jan 07, 2002 at 05:55:01PM +0000, Ben Hutchings wrote: > I'm trying to use the Debian version of mutt (version 1.3.24) with gnutls > (version 0.2.11) to connect to an IMAP server with SSL support (provided by > stunnel 3.10 and OpenSSL 0.9.4). > > mutt fails to connect to the server, leaving a status message > "gnutls_handshake". stunnel logs an error message like this: > > Jan 7 01:34:40 halibut stunnel[32346]: SSL_accept: error:0406506C:rsa > routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len > > I have made successful IMAP/SSL connections to this server with a variety of > other clients, so I don't think stunnel is at fault. So might this be a > fault in gnutls, or should I be looking at mutt? If you want to try a more recent version of gnutls, you can get a newer version of the patch for mutt at: The most recent version of the patch there requires gnutls 0.3.2 (or a current CVS version). (0.2.11 is the most recent packaged version with Debian). Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at hellug.gr Mon Jan 7 21:14:44 2002 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Mon, 7 Jan 2002 22:14:44 +0200 Subject: [Help-gnutls] Failure to connect from mutt with gnutls In-Reply-To: <20020107175501.GC14260@zzumbouk.i.decadentplace.org.uk> References: <20020107175501.GC14260@zzumbouk.i.decadentplace.org.uk> Message-ID: <20020107221444.48b56711.nmav@hellug.gr> On Mon, 7 Jan 2002 17:55:01 +0000 Ben Hutchings wrote: > I'm trying to use the Debian version of mutt (version 1.3.24) with gnutls > (version 0.2.11) to connect to an IMAP server with SSL support (provided by > stunnel 3.10 and OpenSSL 0.9.4). > mutt fails to connect to the server, leaving a status message > "gnutls_handshake". stunnel logs an error message like this: > Jan 7 01:34:40 halibut stunnel[32346]: SSL_accept: error:0406506C:rsa > routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len I've noticed problems when connecting to old openssl servers, and to stronghold (the one that www.amazon.com uses). There was something in the version advertizing of gnutls that made the KX_RSA ciphersuite to fail. If this is the case, you may use gnutls 0.3.2 that operates differently, or define only one version to use (ie only TLS 1.0, or only SSL 3.0). -- Nikos Mavroyanopoulos From andrew at mcdonald.org.uk Sun Jan 27 22:22:37 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Sun, 27 Jan 2002 21:22:37 +0000 Subject: [Help-gnutls] Checking hostname against certificate Message-ID: <20020127212237.GA18461@mcdonald.org.uk> I'm currently making some improvements to my mutt/gnutls patches. One of the things today was to get mutt to check the name of the host it thinks it has connected to against the certificate presented by the server. My procedure is: 1) try to get name from gnutls_x509pki_extract_subject_dns_name 2) if that doesn't work, get common_name from cert 3) compare against hostname used (taking into account wildcard hostnames in the certificate, e.g. "*.mcdonald.org.uk") (Actually, might something along these lines be useful to put into libgnutls itself?) gnutls_x509pki_extract_subject_dns_name doesn't seem to be working. As far as I understand it, this should extract a DNS name from a Subject Alternative Name X.509v3 extension (as described in RFC2549, section 4.2.1.7). For this I created a certificate with openssl, and I see the appropriate extension: X509v3 extensions: Netscape Cert Type: SSL Server X509v3 Subject Alternative Name: email:root at mcdonald.org.uk, DNS:wompom.mcdonald.org.uk extract_subject_dns_name returns 56 (GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) Looking at the code for the gnutls function, I see: if ((result = _gnutls_get_extension(cert, "2 5 29 17", &dnsname)) < 0) { return result; } 2.5.29.17 is the OID for an AltName extension. How does _gnutls_get_extension know you want the dNSName? (extract_subject_dns_name doesn't seem to do any further processing on it). And why can't it find the extension anyway? (Also, what would happen if there were multiple dNSNames in there?) Any ideas or hints? (I can supply the certificate or conf file used to generate the certificate if it helps). Many thanks, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From nmav at gnutls.org Mon Jan 28 09:13:08 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon, 28 Jan 2002 10:13:08 +0200 Subject: [Help-gnutls] Checking hostname against certificate In-Reply-To: <20020127212237.GA18461@mcdonald.org.uk> References: <20020127212237.GA18461@mcdonald.org.uk> Message-ID: <20020128101308.07d395a3.nmav@gnutls.org> On Sun, 27 Jan 2002 21:22:37 +0000 Andrew McDonald wrote: Hello Andrew, > I'm currently making some improvements to my mutt/gnutls patches. One > of the things today was to get mutt to check the name of the host it > thinks it has connected to against the certificate presented by the > server. > My procedure is: > 1) try to get name from gnutls_x509pki_extract_subject_dns_name > 2) if that doesn't work, get common_name from cert > 3) compare against hostname used (taking into account wildcard > hostnames in the certificate, e.g. "*.mcdonald.org.uk") This is right. > (Actually, might something along these lines be useful to put into > libgnutls itself?) Well X.509 is a REALLY bloated protocol. There are a lot of things that we should handle. An X.509 certificate may even contain videos, photographs and anything that can get an OID. For gnutls I intend to add only basic functionality required to work. (Hopefully there is aegypten, but I don't know how far it can go yet.) > gnutls_x509pki_extract_subject_dns_name doesn't seem to be working. > As far as I understand it, this should extract a DNS name from a > Subject Alternative Name X.509v3 extension (as described in RFC2549, > section 4.2.1.7). This function was never tested.. Please, send me the certificate that contains the dnsname, email extensions, so I can give it a test (and a fix). > 2.5.29.17 is the OID for an AltName extension. How does > _gnutls_get_extension know you want the dNSName? it does not :) > (extract_subject_dns_name doesn't seem to do any further processing on > it). And why can't it find the extension anyway? > (Also, what would happen if there were multiple dNSNames in there?) This is tricky to handle. I'll see what I can do. > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From andrew at mcdonald.org.uk Mon Jan 28 20:29:36 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Mon, 28 Jan 2002 19:29:36 +0000 Subject: [Help-gnutls] Checking hostname against certificate In-Reply-To: <20020128101308.07d395a3.nmav@gnutls.org> References: <20020127212237.GA18461@mcdonald.org.uk> <20020128101308.07d395a3.nmav@gnutls.org> Message-ID: <20020128192935.GA8505@mcdonald.org.uk> On Mon, Jan 28, 2002 at 10:13:08AM +0200, Nikos Mavroyanopoulos wrote: > On Sun, 27 Jan 2002 21:22:37 +0000 Andrew McDonald wrote: > > > (Actually, might something along these lines be useful to put into > > libgnutls itself?) > Well X.509 is a REALLY bloated protocol. There are a lot of things that > we should handle. An X.509 certificate may even contain videos, photographs > and anything that can get an OID. So I discovered on reading Peter Gutmann's X.509 Style Guide. > For gnutls I intend to add only basic functionality required to work. > (Hopefully there is aegypten, but I don't know how far it can go > yet.) Yes, this does seem more to belong in libksba since it is purely an 'X.509 thing' rather than doing any TLS. > > gnutls_x509pki_extract_subject_dns_name doesn't seem to be working. > > As far as I understand it, this should extract a DNS name from a > > Subject Alternative Name X.509v3 extension (as described in RFC2549, > > section 4.2.1.7). > This function was never tested.. Please, send me the certificate that > contains the dnsname, email extensions, so I can give it a test (and a fix). > > > 2.5.29.17 is the OID for an AltName extension. How does > > _gnutls_get_extension know you want the dNSName? > it does not :) Ah. Good. I was a bit worried that I couldn't see how it could possibly do what it was supposed to. :-) I've attached imapd.pem, a test certificate (since this is a test key I've included the private part as well to give you maximum flexibility in testing). This was generated from the attached imapd.cnf using the command: openssl req -new -x509 -days 365 -nodes -out imapd.pem -keyout imapd.pem -config imapd.cnf Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC/0ZV1yf22o0eSqWDXUztGb7peEiVq/XsUQcPs1PwmRmnVunJv uaACB4a/8PYfixk9YpJYAHK/Ebwt/cacY0yt3lr08Yp5q9gRu5Xu+RGskRyZW5sf eQWCghMZZZgfr+OX39Usme4HTfA5+Ta53wlHmERPoB9XMtOwyNxHZxeVgwIDAQAB AoGAO00rHMg+tMkT5oaQ1uD3cVY3Ur/fa41EEMYoMT7DWX3pWFcU6++CRT5YbVys aqIRQoYH4kb5MpLkD3/meBDG8mzHAtRWzC1Km86APwSllNWuF9EewyCjvxfb1jhl qYHvflIWvYs4K7+UEDxc8AOebnaUGrStEMVp/r2DltitDTECQQDffGFexZnMo/o+ y/rad13nYP3kENE+IHHLBZPj9eGSGtREj5zrR+T+q1EgnbIBIQUZZTZL9Oupef/n SqcyB9b7AkEA27nGfQdam7Wc8CjPu1VwmP4C231DVWErtWlAXTVNzTXKCwdM0VYA pyLY/wtSvEeT93dpX/68HgFh15IAFEMVGQJAHScXeIpkPqqhSTHInlj12enwFKEQ +n62+VnX6eO4Mhvn1q25NYPiXkowwgVwI++Pv7lRNOVVHH16oUw+tSsKowJBAKNG vZSTLmWe42wjJ5qRtwY5W242+x4rAwvflpCs14+ydN0VI6Q7QGjyoEWF6Ik4t1+h QJCw/qFdbZN/Tse/waECQQCXMNSZVjQwvVCWu98kH3SGywCQK6sbV4mn0tK+fKSx 1y0lxumvFxUAgfsAVrJ1caPXH2dJ5sbjlyu2h6UNSOnr -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC9jCCAl+gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBmDELMAkGA1UEBhMCVUsx DzANBgNVBAgTBlN1cnJleTESMBAGA1UEBxMJQ3JhbmxlaWdoMRgwFgYDVQQKEw9t Y2RvbmFsZC5vcmcudWsxFjAUBgNVBAsTDU1haWwgU2VydmljZXMxDTALBgNVBAMT BGltYXAxIzAhBgkqhkiG9w0BCQEWFHJvb3RAbWNkb25hbGQub3JnLnVrMB4XDTAy MDEyODE5MjA0N1oXDTAzMDEyODE5MjA0N1owgZgxCzAJBgNVBAYTAlVLMQ8wDQYD VQQIEwZTdXJyZXkxEjAQBgNVBAcTCUNyYW5sZWlnaDEYMBYGA1UEChMPbWNkb25h bGQub3JnLnVrMRYwFAYDVQQLEw1NYWlsIFNlcnZpY2VzMQ0wCwYDVQQDEwRpbWFw MSMwIQYJKoZIhvcNAQkBFhRyb290QG1jZG9uYWxkLm9yZy51azCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAv9GVdcn9tqNHkqlg11M7Rm+6XhIlav17FEHD7NT8 JkZp1bpyb7mgAgeGv/D2H4sZPWKSWAByvxG8Lf3GnGNMrd5a9PGKeavYEbuV7vkR rJEcmVubH3kFgoITGWWYH6/jl9/VLJnuB03wOfk2ud8JR5hET6AfVzLTsMjcR2cX lYMCAwEAAaNOMEwwEQYJYIZIAYb4QgEBBAQDAgZAMDcGA1UdEQQwMC6BFHJvb3RA bWNkb25hbGQub3JnLnVrghZ3b21wb20ubWNkb25hbGQub3JnLnVrMA0GCSqGSIb3 DQEBBAUAA4GBACZEPj79xugPLUxuJ7u1TtSVErp9jjCABhngrpVONM7DskQOHLAr x3j0CSyxQxhKSxaU9c5fnieJ2Ku40A5CXTg203VL29mmAs5KBWouvAZh+cTzKjBl otBbGAxCX2hl0DIlc6ZbLh7ox4+eoNZTy5L60d2f8C3OGAt9RdJbRX9p -----END CERTIFICATE----- -------------- next part -------------- [ req ] default_bits = 1024 encrypt_key = yes distinguished_name = req_dn x509_extensions = cert_type prompt = no [ req_dn ] C=UK ST=Surrey L=Cranleigh O=mcdonald.org.uk OU=Mail Services CN=imap emailAddress=root at mcdonald.org.uk [ cert_type ] nsCertType = server subjectAltName=email:copy,DNS:wompom.mcdonald.org.uk