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