From sam at robots.org.uk  Fri Aug 10 14:29:44 2007
From: sam at robots.org.uk (Sam Morris)
Date: Fri, 10 Aug 2007 13:29:44 +0100
Subject: [Help-gnutls] GnuTLS generating invalid/corrupt certificates? (was:
	Re: CA certificates -- root vs intermediate)
In-Reply-To: <87wt0qwncn.fsf@mocca.josefsson.org>
References: <1175702845.30604.9.camel@xerces>
	<87wt0qwncn.fsf@mocca.josefsson.org>
Message-ID: <1186748984.3665.20.camel@tycho.robots.org.uk>

On Thu, 2007-04-05 at 22:57 +0200, Simon Josefsson wrote:
> Sam Morris <sam at robots.org.uk> writes:
> 
> > I've been using my own CA certificate to secure my access (with SSL/TLS)
> > to my personal email & web server for a while now. I originally
> > generated the CA certificate with gnutls' certtool program. I now need
> > to get the certificate working on a client running Mac OS X.
> >
> > It's fairly straightforward to import the certificate into OS X's
> > Keychain application; however, Keychain insists that my CA is only an
> > "intermediate certificate authority", and therefore OS X refuses to
> > trust the certificate.
> >
> > I have gone through the output of 'certtool --info' and 'openssl x509
> > -text', and have done quite some Googling by now, but I can't find any
> > way to determine the criteria by which Keychain decides that my
> > certificate is that of a root authority, or an intermediate authority.
> >
> > So my question is: is this root/intermediate setting actually in the
> > certificate itself (in which case it's something I can fix by generating
> > a new certificate--although I can't find any options for this in
> > certtol's documentation; is it possible, or will I have to use openssl?)
> > or is it something I need to do in the Keychain application?
> 
> Basically, root certificates have subject==issuer, intermediate
> certificates have subject!=issuer.
> 
> > The certificate is available from
> > https://crypt.ethx.net/robots.org.uk-CA.crt in case anyone wants a copy.
> 
> The certificate is missing the 'key usage' bits of certificate
> signing, and a subject key ID.  But that doesn't seem relevant to the
> error message you got.  And, many commercial CAs also lack those
> fields so you aren't alone in this.
> 
> I think you'll need to debug this as a Keychain problem further, to
> understand exactly why it is complaining.  Can you add any other
> certificate as a new trusted root CA?

So, I finally had some time to look into this. I asked on the Apple-cdsa
mailing list[0] and recieved a reply from someone who seems to work for
Apple[1] that indicated that the problem is with my certificate; the
Apple crypto libraries cannot parse it for some reason.

 [0] http://lists.apple.com/archives/Apple-cdsa/2007/Aug/msg00009.html
 [1] http://lists.apple.com/archives/Apple-cdsa/2007/Aug/msg00016.html

I also had problems trying to get my certificate to import into a Sony
Ericsson K800i mobile phone. For months I assumed it was a limitation of
the phone itself (it would only bleat, "invalid certificate" at me, and
Sony Ericsson's tech support service was worse than useless)...

... but today I sat down and generated a root certificate with OpenSSL,
which imported fine into both the Mac OS Keychain software, and the
K800i phone.

So my conclusion is that GnuTLS is generating invalid/corrupt
certificates, or at least, that it is using some part of the certificate
that other X509 implementations don't commonly implement (although my
original certificate did function correctly with OpenSSL, NSS and
whatever Windows uses).

To double-check, I generated a new root certificate with GnuTLS 1.4.4,
and tried to import it into the Mac OS Keychain; I had exactly the same
problem again. The command I used was:

        certtool --generate-self-signed --load-privkey private-key --template CA.cfg

Whereas CA.cfg contained:

        organization = "Test Org"
        country = GB
        cn = "Test Org certificate authority"
        serial = 0
        expiration_days = 1825
        ca
        cert_signing_key
        ocsp_signing_key

I would file a bug about this, but I see that newer versions of GnuTLS
are now available, and so it is possible that this bug has been fixed in
a subsequent version. I no longer have the Mac to perform further
testing with, so I can't currently create a certificate with 1.6 or 1.7
and test with that instead. :(

Anyway, thanks for your help!

> /Simon

-- 
Sam Morris <sam at robots.org.uk>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20070810/9fbb3c35/attachment.pgp>

From simon at josefsson.org  Fri Aug 10 15:35:22 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 10 Aug 2007 15:35:22 +0200
Subject: [Help-gnutls] Re: GnuTLS generating invalid/corrupt certificates?
In-Reply-To: <1186748984.3665.20.camel@tycho.robots.org.uk> (Sam Morris's
	message of "Fri, 10 Aug 2007 13:29:44 +0100")
References: <1175702845.30604.9.camel@xerces>
	<87wt0qwncn.fsf@mocca.josefsson.org>
	<1186748984.3665.20.camel@tycho.robots.org.uk>
Message-ID: <87ps1vpl5x.fsf@mocca.josefsson.org>

Sam Morris <sam at robots.org.uk> writes:

> So, I finally had some time to look into this. I asked on the Apple-cdsa
> mailing list[0] and recieved a reply from someone who seems to work for
> Apple[1] that indicated that the problem is with my certificate; the
> Apple crypto libraries cannot parse it for some reason.
>
>  [0] http://lists.apple.com/archives/Apple-cdsa/2007/Aug/msg00009.html
>  [1] http://lists.apple.com/archives/Apple-cdsa/2007/Aug/msg00016.html
>
> I also had problems trying to get my certificate to import into a Sony
> Ericsson K800i mobile phone. For months I assumed it was a limitation of
> the phone itself (it would only bleat, "invalid certificate" at me, and
> Sony Ericsson's tech support service was worse than useless)...
>
> ... but today I sat down and generated a root certificate with OpenSSL,
> which imported fine into both the Mac OS Keychain software, and the
> K800i phone.
>
> So my conclusion is that GnuTLS is generating invalid/corrupt
> certificates, or at least, that it is using some part of the certificate
> that other X509 implementations don't commonly implement (although my
> original certificate did function correctly with OpenSSL, NSS and
> whatever Windows uses).
>
> To double-check, I generated a new root certificate with GnuTLS 1.4.4,
> and tried to import it into the Mac OS Keychain; I had exactly the same
> problem again. The command I used was:
>
>         certtool --generate-self-signed --load-privkey private-key --template CA.cfg
>
> Whereas CA.cfg contained:
>
>         organization = "Test Org"
>         country = GB
>         cn = "Test Org certificate authority"
>         serial = 0
>         expiration_days = 1825
>         ca
>         cert_signing_key
>         ocsp_signing_key
>
> I would file a bug about this, but I see that newer versions of GnuTLS
> are now available, and so it is possible that this bug has been fixed in
> a subsequent version. I no longer have the Mac to perform further
> testing with, so I can't currently create a certificate with 1.6 or 1.7
> and test with that instead. :(

Hi!  We did fix a problem that may have lead to problems like that in
1.6.2:

 ** Fix X.509 signing with RSA-PKCS#1 to set a NULL parameters fields.
 Before, we remove the parameters field, which resulted in a slightly
 different DER encoding which in turn caused signature verification
 failures of GnuTLS-generated RSA certificates in some other
 implementations (e.g., GnuPG 2.x's gpgsm).  Depending on which RFCs you
 read, this may or may not be correct, but our new behaviour appear to
 be consistent with other widely used implementations.

Essentially, earlier 'certtool' generated incorrect signatures on
certificates, although some libraries (e.g., OpenSSL) didn't notice it.
Your error messages aren't detailed enough to tell whether this is the
same problem, but there is a possibility that it is.

So, please try 1.6.2, and if the problem persist, please debug it
further, comparing all details of the working and non-working
certificates.

Thanks,
Simon




From simon at josefsson.org  Fri Aug 10 16:02:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 10 Aug 2007 16:02:47 +0200
Subject: [Help-gnutls] Re: GnuTLS generating invalid/corrupt certificates?
In-Reply-To: <87ps1vpl5x.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 10 Aug 2007 15:35:22 +0200")
References: <1175702845.30604.9.camel@xerces>
	<87wt0qwncn.fsf@mocca.josefsson.org>
	<1186748984.3665.20.camel@tycho.robots.org.uk>
	<87ps1vpl5x.fsf@mocca.josefsson.org>
Message-ID: <878x8jpjw8.fsf@mocca.josefsson.org>

I just realized: you could try using a DSA key instead, to find out
whether the bug solved in 1.6.2 was your problem.  Our bug only affected
RSA, so if you get it to work by switching to DSA, then chances are good
that switching to 1.6.2 or later will solve it for RSA as well.

/Simon




From simon at josefsson.org  Wed Aug 15 01:18:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 15 Aug 2007 01:18:17 +0200
Subject: [Help-gnutls] GnuTLS 1.7.17 -- Last call for next stable major
	release v2.0!
Message-ID: <87sl6lso1y.fsf@mocca.josefsson.org>

This is scheduled to be the last release on the development branch.
Unless I hear anything, I will release this as v2.0 on September 1th.
Test this release as you would a new stable release!  All feedback is
welcome... is the documentation ok?  Do the examples work?  Is
everything ready for a new stable release?  Compare this to v1.6.3.

If you sent me a bug report that I haven't responded to, now is the time
to re-send it!  Preferably to the gnutls-dev list.

This release also comes with an updated binary Windows installer, please
test it as well.

Below is the regular release announcement...

* Version 1.7.17 (released 2007-08-15)

** New functions to perform external signing.
Set the signing callback function (of the gnutls_sign_func prototype)
using the gnutls_sign_callback_set function.  In the callback, you may
find the new functions gnutls_x509_privkey_sign_hash and
gnutls_openpgp_privkey_sign_hash useful.  A new function
gnutls_sign_callback_get is also added, to retrieve the function
pointer.  Thanks to "Alon Bar-Lev" <alon.barlev at gmail.com> for
comments and testing.

** New self test of client and server authenticated X.509 TLS sessions.
See tests/x509self.c and tests/x509signself.c.  The latter also tests
the new external signing callback interface.

** New errors GNUTLS_E_APPLICATION_ERROR_MIN..GNUTLS_E_APPLICATION_ERROR_MAX.
These two actually describe the outer limits of a range of error codes
reserved to the application.  All of the errors are treated as fatal
by the library (it has to since it doesn't know the semantics of the
error codes).  This can be useful in callbacks, to signal some
application-specific error condition, which will usually eventually
cause some gnutls API to return the same error code as the callback,
which then can be inspected by the application.  Note that error codes
are negative.

** gnutls_set_default_priority now disable TLS 1.2 by default.
The RFC is not released yet, and we're approaching a major release so
let's not enable it just yet.

** Fix namespace so that gnutls_*_t is used consistently.
Before, many places in the GnuTLS code used the old deprecated type
names without the '_t' suffix.

** Build fixes for Guile code.
Patch from Ludovic Courtes <ludovic.courtes at laas.fr>.

** More documentation fixes.
In particular, the section headings were modified for casing.  By
Ludovic Courtes <ludovic.courtes at laas.fr>.

** Updated Polish and Swedish translations.
Thanks to Jakub Bogusz <qboosh at pld-linux.org> and Daniel Nylander
<po at danielnylander.se>.

** API and ABI modifications:
gnutls_sign_func: ADD, new type for sign callback.
gnutls_sign_callback_set: ADD, new function to set sign callback.
gnutls_sign_callback_get: ADD, new function to retrieve sign callback.
gnutls_x509_privkey_sign_hash,
gnutls_openpgp_privkey_sign_hash: ADD, new functions useful in sign callback.
GNUTLS_E_APPLICATION_ERROR_MIN,
GNUTLS_E_APPLICATION_ERROR_MAX: ADD, new CPP #defines for error codes.

Here are the compressed sources (4.6MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.17.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.7.17.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.17.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.7.17.tar.bz2.sig

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-1.7.17.exe (24MB)
  http://josefsson.org/gnutls4win/gnutls-1.7.17.exe.sig

Here are the SHA-1 and SHA-224 checksums:

3d961c86aafc17555f23b21d749c25379cd2c388  gnutls-1.7.17.tar.bz2
5f990656e6a97329d0810cbfd7aabe9706286af2  gnutls-1.7.17.tar.bz2.sig

86e8dd9083aeffadbc4782c682e3d16ae8d278d27ffa0a31ef231c8b  gnutls-1.7.17.tar.bz2
a6c81ba03814d7b4255e4ef939e5d5df2327484c095359645e988062  gnutls-1.7.17.tar.bz2.sig

0f0897a343a636137e426a4ac1057e3dfe7c8de9  gnutls-1.7.17.exe
7caaabb2ad3e238e25334554c52dd0c15a4d41b5  gnutls-1.7.17.exe.sig

ac0101436e8e906f84fabd75f376a765ba6b32f0ae6c93db51ce9879  gnutls-1.7.17.exe
4cf3a9550883ca7ee9dd70bae72782e1412582a225ff77bcd3097dfe  gnutls-1.7.17.exe.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20070815/e295c4c0/attachment.pgp>

From himself at frank-eberle.de  Wed Aug 15 20:30:49 2007
From: himself at frank-eberle.de (Frank Eberle)
Date: Wed, 15 Aug 2007 20:30:49 +0200
Subject: [Help-gnutls] Question regarding TLS with PSK
Message-ID: <46C34659.70803@frank-eberle.de>

Hello,

I've to write an application which requires a secured communication 
channel. To keep the user's effort minimal I want to use pre-shared keys 
for authentication.
Now my question: In my understanding when using PSK-DH the client is 
authenticated when connecting to the server, but is the server also 
authenticated against the client?
Or in other words: When an attacker replaces the server by his own 
implementation is the client able to recognize this? Or do I have to use 
a server certificate to achieve this.

Best regards

Frank




From simon at josefsson.org  Thu Aug 16 11:40:12 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 16 Aug 2007 11:40:12 +0200
Subject: [Help-gnutls] Re: Question regarding TLS with PSK
In-Reply-To: <46C34659.70803@frank-eberle.de> (Frank Eberle's message of "Wed, 
	15 Aug 2007 20:30:49 +0200")
References: <46C34659.70803@frank-eberle.de>
Message-ID: <87fy2jvmv7.fsf@mocca.josefsson.org>

Frank Eberle <himself at frank-eberle.de> writes:

> Hello,
>
> I've to write an application which requires a secured communication
> channel. To keep the user's effort minimal I want to use pre-shared
> keys for authentication.
> Now my question: In my understanding when using PSK-DH the client is
> authenticated when connecting to the server, but is the server also
> authenticated against the client?

The PSK handshake will not succeed unless both sides know the same
pre-shared key.  A theorist may say that it is not the same thing as
cryptographic authentication, but in practice people traditionally do
not care about the difference.

> Or in other words: When an attacker replaces the server by his own
> implementation is the client able to recognize this? Or do I have to
> use a server certificate to achieve this.

Yes, the client should notice this because the handshake will fail.  You
could try this.

/Simon




From jesse at teranetworks.de  Sun Aug 19 16:30:47 2007
From: jesse at teranetworks.de (jesse keys)
Date: Sun, 19 Aug 2007 16:30:47 +0200
Subject: [Help-gnutls] Unknown type '0' for SNI: 'foo.domain.bar'
Message-ID: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>

Hi there,
first of all: thanks for making SNI possible!

So far it's working great. However, i find
        [crit] GnuTLS: Unknown type '0' for SNI: 'my.domain.org'
errors in my apache error_log.

Is it just because I use a bad (no wildcard) cert? Should I bother?
Couldn't find anything in the archives about it.

Thanks in advance,
jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070819/60eceab0/attachment.htm>

From simon at josefsson.org  Mon Aug 20 22:43:03 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 20 Aug 2007 22:43:03 +0200
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	(jesse keys's message of "Sun, 19 Aug 2007 16:30:47 +0200")
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
Message-ID: <87643a2azs.fsf@mocca.josefsson.org>

"jesse keys" <jesse at teranetworks.de> writes:

> Hi there,
> first of all: thanks for making SNI possible!
>
> So far it's working great. However, i find
>         [crit] GnuTLS: Unknown type '0' for SNI: 'my.domain.org'
> errors in my apache error_log.
>
> Is it just because I use a bad (no wildcard) cert? Should I bother?
> Couldn't find anything in the archives about it.

I can't find anything close to that error message in GnuTLS.  How do you
use GnuTLS together with Apache?  Possibly the problem can be found in
that glue layer.  I'd be happy to review that code if you provide a
pointer.

/Simon




From jesse at teranetworks.de  Mon Aug 20 23:20:27 2007
From: jesse at teranetworks.de (jesse keys)
Date: Mon, 20 Aug 2007 23:20:27 +0200
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <9dad5ea50708201418l6289645j17fc44c5b2497f00@mail.gmail.com>
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<87643a2azs.fsf@mocca.josefsson.org>
	<9dad5ea50708201418l6289645j17fc44c5b2497f00@mail.gmail.com>
Message-ID: <9dad5ea50708201420w56a5c8dapd0fa6c6067834ac9@mail.gmail.com>

(screwed that previus mail... -.-)


Thanks for your reply,
here we go with some background information:

2.6.20-cks1-r1 on a gentoo x86_64 box, 3700+, 2GB RAM

Apache: 2.2.4
> ldap ssl -debug -doc -mpm-event -mpm-itk -mpm-peruser -mpm-prefork -mpm-worker -no-suexec (-selinux) -static-modules -threads

Gnutls: 1.6.3
> zlib -doc -nls

mod_gnutls 0.2.0
> ssl

I start apache with:
-D SUEXEC -D PHP5 -D USERDIR -D INFO -D GNUTLS

and the vhosts look like that:


<IfDefine GNUTLS>
<VirtualHost ip:443>
        ServerName foo.bar.com
        DocumentRoot "/var/www/localhost/htdocs/foo"

        <Directory "/var/www/localhost/htdocs/foo">
                 Options FollowSymLinks -SymLinksIfOwnerMatch Indexes
                 Order allow,deny
                 Allow from all
                 AllowOverride All
        </Directory>

        <IfDefine SUEXEC>
                SuexecUserGroup apache apache
        </IfDefine>

        CustomLog /var/log/apache2/foo_log combined

        GnuTLSEnable on
        GnuTLSCertificateFile /etc/apache2/ssl/server.crt
        GnuTLSKeyFile /etc/apache2/ssl/server.key

</VirtualHost>
</IfDefine>


I even found this piece of code in the source

if (sni_type != GNUTLS_NAME_DNS) {
  ap_log_error(APLOG_MARK, APLOG_CRIT, 0,
  ctxt->c->base_server,
  "GnuTLS: Unknown type '%d' for SNI: " "'%s'", sni_type, sni_name);
  return NULL;
}

but can't figure out what it means or how I could fix it.

Thanks again,
jesse




From simon at josefsson.org  Mon Aug 20 23:22:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 20 Aug 2007 23:22:33 +0200
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <87643a2azs.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 20 Aug 2007 22:43:03 +0200")
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<87643a2azs.fsf@mocca.josefsson.org>
Message-ID: <871wdx3nqe.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> "jesse keys" <jesse at teranetworks.de> writes:
>
>> Hi there,
>> first of all: thanks for making SNI possible!
>>
>> So far it's working great. However, i find
>>         [crit] GnuTLS: Unknown type '0' for SNI: 'my.domain.org'
>> errors in my apache error_log.
>>
>> Is it just because I use a bad (no wildcard) cert? Should I bother?
>> Couldn't find anything in the archives about it.
>
> I can't find anything close to that error message in GnuTLS.  How do you
> use GnuTLS together with Apache?  Possibly the problem can be found in
> that glue layer.  I'd be happy to review that code if you provide a
> pointer.

I found the error message, it is from mod_gnutls.  The cause is a
bug... and I'm not sure if it is in mod_gnutls or GnuTLS.  The code in
mod_gnutls is:

    rv = gnutls_server_name_get(ctxt->session, sni_name, 
                                &data_len, &sni_type, 0);
    
    if (rv != 0) {
        return NULL;
    }
    
    if (sni_type != GNUTLS_NAME_DNS) {
        ap_log_error(APLOG_MARK, APLOG_CRIT, 0,
                     ctxt->c->base_server,
                     "GnuTLS: Unknown type '%d' for SNI: "
                     "'%s'", sni_type, sni_name);
        return NULL;
    }

This looks correct, but unfortunately, the value of GNUTLS_NAME_DNS is
1, and the RFC uses the value 0 for this, and that is the value that is
returned in the type variable from the gnutls_server_name_get function.

I think the simplest solution here is to fix the gnutls_server_name_get
function to +1 the type variable before returning it.  See patch below.
I haven't installed this yet, because I'm not sure we should solve it
this way.

Thanks for the report.  I'm happy to hear that people are trying to get
mod_gnutls to work.  Btw, some instructions that help new users:
http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

/Simon

diff --git a/lib/ext_server_name.c b/lib/ext_server_name.c
index f9ca429..3effb57 100644
--- a/lib/ext_server_name.c
+++ b/lib/ext_server_name.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
@@ -250,7 +250,7 @@ gnutls_server_name_get (gnutls_session_t session, void *data,
       return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE;
     }
 
-  *type = session->security_parameters.extensions.server_names[indx].type;
+  *type = session->security_parameters.extensions.server_names[indx].type + 1;
 
   if (*data_length >		/* greater since we need one extra byte for the null */
       session->security_parameters.extensions.server_names[indx].name_length)




From simon at josefsson.org  Mon Aug 20 23:30:40 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 20 Aug 2007 23:30:40 +0200
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <9dad5ea50708201418l6289645j17fc44c5b2497f00@mail.gmail.com>
	(jesse keys's message of "Mon, 20 Aug 2007 23:18:29 +0200")
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<87643a2azs.fsf@mocca.josefsson.org>
	<9dad5ea50708201418l6289645j17fc44c5b2497f00@mail.gmail.com>
Message-ID: <87veb928sf.fsf@mocca.josefsson.org>

FYI, I cc'ed the list.  Please keep the cc, it may help others with the
same problem in the future.

"jesse keys" <jessekeys at googlemail.com> writes:

> Thanks for your reply,
> here we go with some background information:
>
> 2.6.20-cks1-r1 on a gentoo x86_64 box, 3700+, 2GB RAM
>
> Apache: 2.2.4
>> ldap ssl -debug -doc -mpm-event -mpm-itk -mpm-peruser -mpm-prefork -mpm-worker -no-suexec (-selinux) -static-modules -threads
>
> Gnutls: 1.6.3
>> zlib -doc -nls
>
> mod_gnutls 0.2.0
>> ssl
>
> I start apache with:
> -D SUEXEC -D PHP5 -D USERDIR -D INFO -D GNUTLS
>
> and the vhosts look like that:
>
>
> <IfDefine GNUTLS>
> <VirtualHost ip:443>
>         ServerName foo.bar.com
>         DocumentRoot "/var/www/localhost/htdocs/foo"
>
>         <Directory "/var/www/localhost/htdocs/foo">
>                  Options FollowSymLinks -SymLinksIfOwnerMatch Indexes
>                  Order allow,deny
>                  Allow from all
>                  AllowOverride All
>         </Directory>
>
>         <IfDefine SUEXEC>
>                 SuexecUserGroup apache apache
>         </IfDefine>
>
>         CustomLog /var/log/apache2/foo_log combined
>
>         GnuTLSEnable on
>         GnuTLSCertificateFile /etc/apache2/ssl/server.crt
>         GnuTLSKeyFile /etc/apache2/ssl/server.key
>
> </VirtualHost>
> </IfDefine>
>
>
> I even found this piece of code in the source
>
> if (sni_type != GNUTLS_NAME_DNS) {
>   ap_log_error(APLOG_MARK, APLOG_CRIT, 0,
>   ctxt->c->base_server,
>   "GnuTLS: Unknown type '%d' for SNI: " "'%s'", sni_type, sni_name);
>   return NULL;
> }
>
> but can't figure out what it means or how I could fix it.

Try changing the first line into:

 if ((sni_type + 1) != GNUTLS_NAME_DNS) {

and recompile mod_gnutls.  That should make it work.

I don't understand how anyone could get the current code to work
though.  If someone is actually successfully using mod_gnutls with SNI,
it would help if s/he could test whether the patch in my last e-mail
breaks anything.

/Simon




From nmav at gnutls.org  Mon Aug 20 23:43:55 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 21 Aug 2007 00:43:55 +0300
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <871wdx3nqe.fsf@mocca.josefsson.org>
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<87643a2azs.fsf@mocca.josefsson.org>
	<871wdx3nqe.fsf@mocca.josefsson.org>
Message-ID: <200708210043.55447.nmav@gnutls.org>

On Tuesday 21 August 2007, Simon Josefsson wrote:

> I found the error message, it is from mod_gnutls.  The cause is a
> bug... and I'm not sure if it is in mod_gnutls or GnuTLS.  The code in
> mod_gnutls is:
>
>     rv = gnutls_server_name_get(ctxt->session, sni_name,
>                                 &data_len, &sni_type, 0);
>
>     if (rv != 0) {
>         return NULL;
>     }
>
>     if (sni_type != GNUTLS_NAME_DNS) {
>         ap_log_error(APLOG_MARK, APLOG_CRIT, 0,
>                      ctxt->c->base_server,
>                      "GnuTLS: Unknown type '%d' for SNI: "
>                      "'%s'", sni_type, sni_name);
>         return NULL;
>     }
>
> This looks correct, but unfortunately, the value of GNUTLS_NAME_DNS is
> 1, and the RFC uses the value 0 for this, and that is the value that is
> returned in the type variable from the gnutls_server_name_get function.

Hi,
 It seems that the type is set properly in _gnutls_server_name_recv_params():

          switch (type)  
            {
            case 0:             /* NAME_DNS */
              if (len <= MAX_SERVER_NAME_SIZE)
                {
                  memcpy (session->security_parameters.extensions.
                          server_names[i].name, p, len);
                  session->security_parameters.extensions.
                    server_names[i].name_length = len;
                  session->security_parameters.extensions.
                    server_names[i].type = GNUTLS_NAME_DNS;
                  break;
                }
            }

So this error should be from a case where server name is set and type is not 
updated for some reason (maybe is left uninitialized because of a long server 
name?). I'm checking it but so far no clue :)

Nikos




From simon at josefsson.org  Tue Aug 21 00:00:06 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 21 Aug 2007 00:00:06 +0200
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <200708210042.15986.n.mavrogiannopoulos@gmail.com> (Nikos
	Mavrogiannopoulos's message of "Tue, 21 Aug 2007 00:42:15 +0300")
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<87643a2azs.fsf@mocca.josefsson.org>
	<871wdx3nqe.fsf@mocca.josefsson.org>
	<200708210042.15986.n.mavrogiannopoulos@gmail.com>
Message-ID: <87r6lx27fd.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> On Tuesday 21 August 2007, Simon Josefsson wrote:
>
>> I found the error message, it is from mod_gnutls.  The cause is a
>> bug... and I'm not sure if it is in mod_gnutls or GnuTLS.  The code in
>> mod_gnutls is:
>>
>>     rv = gnutls_server_name_get(ctxt->session, sni_name,
>>                                 &data_len, &sni_type, 0);
>>
>>     if (rv != 0) {
>>         return NULL;
>>     }
>>
>>     if (sni_type != GNUTLS_NAME_DNS) {
>>         ap_log_error(APLOG_MARK, APLOG_CRIT, 0,
>>                      ctxt->c->base_server,
>>                      "GnuTLS: Unknown type '%d' for SNI: "
>>                      "'%s'", sni_type, sni_name);
>>         return NULL;
>>     }
>>
>> This looks correct, but unfortunately, the value of GNUTLS_NAME_DNS is
>> 1, and the RFC uses the value 0 for this, and that is the value that is
>> returned in the type variable from the gnutls_server_name_get
>> function.

Never mind, my analysis was bogus.  Please don't bother trying my patch.
>
> Hi,
>  It seems that the type is set properly in _gnutls_server_name_recv_params():
>
>           switch (type)  
>             {
>             case 0:             /* NAME_DNS */
>               if (len <= MAX_SERVER_NAME_SIZE)
>                 {
>                   memcpy (session->security_parameters.extensions.
>                           server_names[i].name, p, len);
>                   session->security_parameters.extensions.
>                     server_names[i].name_length = len;
>                   session->security_parameters.extensions.
>                     server_names[i].type = GNUTLS_NAME_DNS;
>                   break;
>                 }
>             }
>
> So this error should be from a case where server name is set and type is not 
> updated for some reason (maybe is left uninitialized because of a long server 
> name?). I'm checking it but so far no clue :)

Yeah, if the code receives a type!=0, the type stored in gnutls will be
0, and no part of the string is stored.  That seems sub-optimal.  How
about this patch?

/Simon

diff --git a/lib/ext_server_name.c b/lib/ext_server_name.c
index f9ca429..2ef7905 100644
--- a/lib/ext_server_name.c
+++ b/lib/ext_server_name.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
@@ -93,26 +93,22 @@ _gnutls_server_name_recv_params (gnutls_session_t session,
       p = data + 2;
       for (i = 0; i < server_names; i++)
 	{
-	  type = *p;
+	  uint16_t trunc_len;
+
+	  session->security_parameters.extensions.
+	    server_names[i].type = *p + 1;
 	  p++;
 
-	  len = _gnutls_read_uint16 (p);
+	  trunc_len = len = _gnutls_read_uint16 (p);
 	  p += 2;
 
-	  switch (type)
-	    {
-	    case 0:		/* NAME_DNS */
-	      if (len <= MAX_SERVER_NAME_SIZE)
-		{
-		  memcpy (session->security_parameters.extensions.
-			  server_names[i].name, p, len);
-		  session->security_parameters.extensions.
-		    server_names[i].name_length = len;
-		  session->security_parameters.extensions.
-		    server_names[i].type = GNUTLS_NAME_DNS;
-		  break;
-		}
-	    }
+	  if (trunc_len > MAX_SERVER_NAME_SIZE)
+	    trunc_len = MAX_SERVER_NAME_SIZE;
+
+	  memcpy (session->security_parameters.extensions.
+		  server_names[i].name, p, trunc_len);
+	  session->security_parameters.extensions.
+	    server_names[i].name_length = trunc_len;
 
 	  /* move to next record */
 	  p += len;




From nmav at gnutls.org  Tue Aug 21 09:27:17 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 21 Aug 2007 10:27:17 +0300
Subject: [Help-gnutls] Re: Unknown type '0' for SNI: 'foo.domain.bar'
In-Reply-To: <87r6lx27fd.fsf@mocca.josefsson.org>
References: <9dad5ea50708190730u695d60c1g8195617e8761d48e@mail.gmail.com>
	<200708210042.15986.n.mavrogiannopoulos@gmail.com>
	<87r6lx27fd.fsf@mocca.josefsson.org>
Message-ID: <200708211027.18065.nmav@gnutls.org>

On Tuesday 21 August 2007, Simon Josefsson wrote:

> Yeah, if the code receives a type!=0, the type stored in gnutls will be
> 0, and no part of the string is stored.  That seems sub-optimal.  How
> about this patch?

Should solve this problem... but still the dns name is truncated. It seems in 
that case the MAX_SERVER_NAME_SIZE is not adequate (maybe it is a utf-8 
name?). I don't know how many utf-8 dns names are there but it might be 
useful to increase it on the first next binary incompatible release.

regards,
Nikos




From simon at josefsson.org  Tue Aug 21 13:14:43 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 21 Aug 2007 13:14:43 +0200
Subject: [Help-gnutls] Building libgpg-error/libgcrypt/libtasn1/gnutls/gsasl
	without autoconf on uClinux
Message-ID: <87sl6dyw9o.fsf@mocca.josefsson.org>

Hi all,

Sometimes it can be useful to build things without the autoconf
./configure machinery, and just use a simple and hand-maintained
makefile and config.h.  This is needed to build things in older uClinux
environments.

I wrote some instructions on how to achieve this, see:

http://josefsson.org/uclinux/old/

The makefile/config.h aren't specific to uClinux, so if you for some
reason need to build these projects in some other environment, without
autoconf, the files may be useful.

Note that instructions for how to get these projects to work under a
modern uClinux (which supports the autoconf-machinery) is still
available, and is the preferred way to build under uClinux, see:

http://josefsson.org/uclinux/

Thanks,
Simon




From leny.thangiah at siemens.com  Thu Aug 23 07:50:14 2007
From: leny.thangiah at siemens.com (Thangiah, Leny IN BLR SISL)
Date: Thu, 23 Aug 2007 11:20:14 +0530
Subject: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?
Message-ID: <2671BA11C726674C82107DFF092A37DAF62A5F@inblrk999msx.in002.siemens.net>

Hi,
 
I 'm new to the world of SSL. I am evaluating various SSL implementations for using in one of our products. I found that GnuTLS is more portable, scalable and flexible than any other implementations.
 
Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
SSL_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_MD5

Thanks.
Leny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070823/1e2ecbca/attachment.htm>

From simon at josefsson.org  Thu Aug 23 11:03:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 23 Aug 2007 11:03:39 +0200
Subject: [Help-gnutls] Re: GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <2671BA11C726674C82107DFF092A37DAF62A5F@inblrk999msx.in002.siemens.net>
	(Leny Thangiah's message of "Thu, 23 Aug 2007 11:20:14 +0530")
References: <2671BA11C726674C82107DFF092A37DAF62A5F@inblrk999msx.in002.siemens.net>
Message-ID: <87odgyd3mc.fsf@mocca.josefsson.org>

"Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:

> Hi,
>  
> I 'm new to the world of SSL. I am evaluating various SSL
> implementations for using in one of our products. I found that GnuTLS
> is more portable, scalable and flexible than any other
> implementations.

Hi, and welcome!

> Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
> SSL_RSA_WITH_RC4_128_MD5
>
> TLS_RSA_WITH_RC4_128_MD5

As far as I know, those are the same cipher, RFC 4346 says:

    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };

and on http://support.microsoft.com/kb/245030 I see that

SSL_RSA_WITH_RC4_128_MD5	{ 0x00,0x04 }

Anyway, yes, GnuTLS supports that cipher suite.

You may want to look into this comparison between some implementations:

http://www.gnu.org/software/gnutls/comparison.html

It may not be complete (additions are most welcome), but should give you
some indication on what is supported.

Note that GnuTLS does not support SSL version 2.0 since it has been
broken security-wise.

/Simon




From leny.thangiah at siemens.com  Thu Aug 23 12:23:27 2007
From: leny.thangiah at siemens.com (Thangiah, Leny IN BLR SISL)
Date: Thu, 23 Aug 2007 15:53:27 +0530
Subject: [Help-gnutls] RE: GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <87odgyd3mc.fsf@mocca.josefsson.org>
Message-ID: <2671BA11C726674C82107DFF092A37DAF8CD2E@inblrk999msx.in002.siemens.net>

Thanks, Simon. 
It's motivating me further towards using the GnuTLS. 

I have one more question. Is there any possibility to hook my file operation functions (fopen, fread...) with the GnuTLS. 
Basically, I want GnuTLS to call my functions for the file operations.

I saw such callbacks for the socket and memory operations.

Leny

-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org]
Sent: Thursday, August 23, 2007 2:34 PM
To: Thangiah, Leny IN BLR SISL
Cc: help-gnutls at gnu.org
Subject: Re: GnuTLS supports RSA_WITH_RC4_128_MD5?


"Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:

> Hi,
>  
> I 'm new to the world of SSL. I am evaluating various SSL
> implementations for using in one of our products. I found that GnuTLS
> is more portable, scalable and flexible than any other
> implementations.

Hi, and welcome!

> Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
> SSL_RSA_WITH_RC4_128_MD5
>
> TLS_RSA_WITH_RC4_128_MD5

As far as I know, those are the same cipher, RFC 4346 says:

    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };

and on http://support.microsoft.com/kb/245030 I see that

SSL_RSA_WITH_RC4_128_MD5	{ 0x00,0x04 }

Anyway, yes, GnuTLS supports that cipher suite.

You may want to look into this comparison between some implementations:

http://www.gnu.org/software/gnutls/comparison.html

It may not be complete (additions are most welcome), but should give you
some indication on what is supported.

Note that GnuTLS does not support SSL version 2.0 since it has been
broken security-wise.

/Simon




From simon at josefsson.org  Thu Aug 23 17:07:44 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 23 Aug 2007 17:07:44 +0200
Subject: [Help-gnutls] Re: GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <2671BA11C726674C82107DFF092A37DAF8CD2E@inblrk999msx.in002.siemens.net>
	(Leny Thangiah's message of "Thu, 23 Aug 2007 15:53:27 +0530")
References: <87odgyd3mc.fsf@mocca.josefsson.org>
	<2671BA11C726674C82107DFF092A37DAF8CD2E@inblrk999msx.in002.siemens.net>
Message-ID: <87sl6aqofz.fsf@mocca.josefsson.org>

"Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:

> Thanks, Simon. 
> It's motivating me further towards using the GnuTLS. 

Great!

> I have one more question. Is there any possibility to hook my file operation functions (fopen, fread...) with the GnuTLS. 
> Basically, I want GnuTLS to call my functions for the file operations.

There aren't many file operations in the GnuTLS library:

jas at mocca:~/src/gnutls/lib$ rgrep fopen *
auth_psk_passwd.c:  fd = fopen (cred->password_file, "r");
auth_srp_passwd.c:  fd = fopen (pconf_file, "r");
auth_srp_passwd.c:  fd = fopen (cred->password_file, "r");
gnutls_helper.c:  fd = fopen (file, "r");
minitasn1/structure.c:  file = fopen (output_file_name, "w");
jas at mocca:~/src/gnutls/lib$ rgrep read_binary_file *
gnutls_x509.c:  char *data = read_binary_file (certfile, &size);
gnutls_x509.c:  char *data = read_binary_file (keyfile, &size);
gnutls_x509.c:  char *data = read_binary_file (cafile, &size);
gnutls_x509.c:  char *data = read_binary_file (crlfile, &size);
gnutls_x509.c:  p12blob.data = read_binary_file (pkcs12file, &size);
jas at mocca:~/src/gnutls/lib$ 

The usage in minitasn1/structure.c is never invoked from GnuTLS.

The usage in gnutls_helper.c is in the function _gnutls_file_exists and
that function is only used from PSK/SRP:

jas at mocca:~/src/gnutls/lib$ rgrep _gnutls_file_exists *
gnutls_helper.c:_gnutls_file_exists (const char *file)
gnutls_helper.h:int _gnutls_file_exists (const char *file);
gnutls_psk.c:  if (_gnutls_file_exists (password_file) != 0)
gnutls_srp.c:  if (_gnutls_file_exists (password_file) != 0)
gnutls_srp.c:  if (_gnutls_file_exists (password_conf_file) != 0)
jas at mocca:~/src/gnutls/lib$ 

Thus, only the SRP/PSK and the X.509 APIs ever opens any files.

For TLS-PSK, this is the password file, and the functionality is only
used in the server if you use the
gnutls_psk_set_server_credentials_file() API.  If you avoid it and use
gnutls_psk_set_server_credentials_function() instead, you will have a
callback into your application for the necessary data.

Similar for TLS-SRP, it is only used in the server when you use the
gnutls_srp_set_server_credentials_file() API.  Use
gnutls_srp_set_server_credentials_function() instead.

For X.509 the file operations are used when you use some of the APIs
that takes a filename:

gnutls_certificate_set_x509_key_file
gnutls_certificate_set_x509_trust_file
gnutls_certificate_set_x509_crl_file
gnutls_certificate_set_x509_simple_pkcs12_file

You don't need to use those APIs to set X.509 key/trust/crl files, just
make sure you use other APIs that doesn't involve reading files:

gnutls_certificate_set_x509_key_mem
gnutls_certificate_set_x509_trust_mem
gnutls_certificate_set_x509_crl_mem

For PKCS#12 there isn't a equivalent memory-based API, but if you need
one added, let me know and I can add it easily for you.

Is this sufficient for what you need?

> I saw such callbacks for the socket and memory operations.

Right.

/Simon

>
> Leny
>
> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org]
> Sent: Thursday, August 23, 2007 2:34 PM
> To: Thangiah, Leny IN BLR SISL
> Cc: help-gnutls at gnu.org
> Subject: Re: GnuTLS supports RSA_WITH_RC4_128_MD5?
>
>
> "Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:
>
>> Hi,
>>  
>> I 'm new to the world of SSL. I am evaluating various SSL
>> implementations for using in one of our products. I found that GnuTLS
>> is more portable, scalable and flexible than any other
>> implementations.
>
> Hi, and welcome!
>
>> Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
>> SSL_RSA_WITH_RC4_128_MD5
>>
>> TLS_RSA_WITH_RC4_128_MD5
>
> As far as I know, those are the same cipher, RFC 4346 says:
>
>     CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
>
> and on http://support.microsoft.com/kb/245030 I see that
>
> SSL_RSA_WITH_RC4_128_MD5	{ 0x00,0x04 }
>
> Anyway, yes, GnuTLS supports that cipher suite.
>
> You may want to look into this comparison between some implementations:
>
> http://www.gnu.org/software/gnutls/comparison.html
>
> It may not be complete (additions are most welcome), but should give you
> some indication on what is supported.
>
> Note that GnuTLS does not support SSL version 2.0 since it has been
> broken security-wise.
>
> /Simon




From leny.thangiah at siemens.com  Thu Aug 23 14:43:39 2007
From: leny.thangiah at siemens.com (Thangiah, Leny IN BLR SISL)
Date: Thu, 23 Aug 2007 18:13:39 +0530
Subject: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <E1IOAcO-0006ZK-PI@www6.emo.freenet-rz.de>
Message-ID: <2671BA11C726674C82107DFF092A37DAF8CEF9@inblrk999msx.in002.siemens.net>

Hi Kris,
 
Thanks for the clarification. Do you know if the GnuTLS team has any plan to do this in future?
 
Leny

-----Original Message-----
From: k.sail at bossmail.de [mailto:k.sail at bossmail.de]
Sent: Thursday, August 23, 2007 4:43 PM
To: Thangiah, Leny IN BLR SISL
Cc: help-gnutls at gnu.org
Subject: Re: RE: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?


Leny,

as far as I know it is not possible to register file operation functions. It is only possible to overwrite (via callback) communication/transport functions (gnutls transport set push function, gnutls transport set pull function).

Kris

----- original Nachricht --------

Betreff: RE: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?
Gesendet: Do 23 Aug 2007 10:56:29 CEST
Von: "Thangiah,Leny IN BLR SISL"<leny.thangiah at siemens.com>


Thanks, Kris. Is there any way I could register my own file operation functions with the GnuTLS? (Just like the transport push/pull function callbacks) I don't want GnuTLS to directly call these functions (fopen, fread...)
 
Leny

-----Original Message-----
From: oku.martens at freenet.de [mailto:oku.martens at freenet.de]
Sent: Thursday, August 23, 2007 1:48 PM
To: Thangiah, Leny IN BLR SISL
Subject: Re: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?


Hi Leny,

the GnuTLS library supports TLS V1.0 and SSL V3.0 (not lower versions).
The hash algorithm MD5 (128 bit key output), cipher algorithm (A)RC4, and RSA algorithm are supported.

Regards,
Kris

----- original Nachricht --------

Betreff: [Help-gnutls] GnuTLS supports RSA_WITH_RC4_128_MD5?
Gesendet: Do 23 Aug 2007 07:51:43 CEST
Von: "Thangiah,Leny IN BLR SISL"<leny.thangiah at siemens.com>


Hi,
 
I 'm new to the world of SSL. I am evaluating various SSL implementations for using in one of our products. I found that GnuTLS is more portable, scalable and flexible than any other implementations.
 
Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
SSL_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_MD5


Thanks.
Leny


--- original Nachricht Ende ----

--
 <http://adserver.freenet.de/click.ng/site=fn&prod=chetools&kat=rub&tbl=webmail&ppos=14&TransactionID=1187857064610981&rgtg=256>  



--- original Nachricht Ende ----

--
 <http://adserver.freenet.de/click.ng/site=fn&prod=chetools&kat=rub&tbl=webmail&ppos=14&TransactionID=1187867572724647&rgtg=256>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070823/555a945b/attachment.htm>

From leny.thangiah at siemens.com  Thu Aug 23 16:18:15 2007
From: leny.thangiah at siemens.com (Thangiah, Leny IN BLR SISL)
Date: Thu, 23 Aug 2007 19:48:15 +0530
Subject: [Help-gnutls] RE: GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <2671BA11C726674C82107DFF092A37DAF8CD2E@inblrk999msx.in002.siemens.net>
Message-ID: <2671BA11C726674C82107DFF092A37DAF8CF75@inblrk999msx.in002.siemens.net>

Please ignore this. I already have got the reply from Kris. This mail has been delayed in delivery.

Leny

-----Original Message-----
From: help-gnutls-bounces+leny.thangiah=siemens.com at gnu.org
[mailto:help-gnutls-bounces+leny.thangiah=siemens.com at gnu.org]On Behalf
Of Thangiah, Leny IN BLR SISL
Sent: Thursday, August 23, 2007 3:53 PM
To: Simon Josefsson
Cc: help-gnutls at gnu.org
Subject: [Help-gnutls] RE: GnuTLS supports RSA_WITH_RC4_128_MD5?


Thanks, Simon. 
It's motivating me further towards using the GnuTLS. 

I have one more question. Is there any possibility to hook my file operation functions (fopen, fread...) with the GnuTLS. 
Basically, I want GnuTLS to call my functions for the file operations.

I saw such callbacks for the socket and memory operations.

Leny

-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org]
Sent: Thursday, August 23, 2007 2:34 PM
To: Thangiah, Leny IN BLR SISL
Cc: help-gnutls at gnu.org
Subject: Re: GnuTLS supports RSA_WITH_RC4_128_MD5?


"Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:

> Hi,
>  
> I 'm new to the world of SSL. I am evaluating various SSL
> implementations for using in one of our products. I found that GnuTLS
> is more portable, scalable and flexible than any other
> implementations.

Hi, and welcome!

> Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
> SSL_RSA_WITH_RC4_128_MD5
>
> TLS_RSA_WITH_RC4_128_MD5

As far as I know, those are the same cipher, RFC 4346 says:

    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };

and on http://support.microsoft.com/kb/245030 I see that

SSL_RSA_WITH_RC4_128_MD5	{ 0x00,0x04 }

Anyway, yes, GnuTLS supports that cipher suite.

You may want to look into this comparison between some implementations:

http://www.gnu.org/software/gnutls/comparison.html

It may not be complete (additions are most welcome), but should give you
some indication on what is supported.

Note that GnuTLS does not support SSL version 2.0 since it has been
broken security-wise.

/Simon


_______________________________________________
Help-gnutls mailing list
Help-gnutls at gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnutls




From leny.thangiah at siemens.com  Thu Aug 23 17:15:46 2007
From: leny.thangiah at siemens.com (Thangiah, Leny IN BLR SISL)
Date: Thu, 23 Aug 2007 20:45:46 +0530
Subject: [Help-gnutls] RE: GnuTLS supports RSA_WITH_RC4_128_MD5?
In-Reply-To: <87sl6aqofz.fsf@mocca.josefsson.org>
Message-ID: <2671BA11C726674C82107DFF092A37DAF8CF87@inblrk999msx.in002.siemens.net>

Simon,

You are rocking! I 'm really amazed by your support. Let me analyze the code with your input and come back.

Thanks a lot!
Leny



-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org]
Sent: Thursday, August 23, 2007 8:38 PM
To: Thangiah, Leny IN BLR SISL
Cc: help-gnutls at gnu.org
Subject: Re: GnuTLS supports RSA_WITH_RC4_128_MD5?


"Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:

> Thanks, Simon. 
> It's motivating me further towards using the GnuTLS. 

Great!

> I have one more question. Is there any possibility to hook my file operation functions (fopen, fread...) with the GnuTLS. 
> Basically, I want GnuTLS to call my functions for the file operations.

There aren't many file operations in the GnuTLS library:

jas at mocca:~/src/gnutls/lib$ rgrep fopen *
auth_psk_passwd.c:  fd = fopen (cred->password_file, "r");
auth_srp_passwd.c:  fd = fopen (pconf_file, "r");
auth_srp_passwd.c:  fd = fopen (cred->password_file, "r");
gnutls_helper.c:  fd = fopen (file, "r");
minitasn1/structure.c:  file = fopen (output_file_name, "w");
jas at mocca:~/src/gnutls/lib$ rgrep read_binary_file *
gnutls_x509.c:  char *data = read_binary_file (certfile, &size);
gnutls_x509.c:  char *data = read_binary_file (keyfile, &size);
gnutls_x509.c:  char *data = read_binary_file (cafile, &size);
gnutls_x509.c:  char *data = read_binary_file (crlfile, &size);
gnutls_x509.c:  p12blob.data = read_binary_file (pkcs12file, &size);
jas at mocca:~/src/gnutls/lib$ 

The usage in minitasn1/structure.c is never invoked from GnuTLS.

The usage in gnutls_helper.c is in the function _gnutls_file_exists and
that function is only used from PSK/SRP:

jas at mocca:~/src/gnutls/lib$ rgrep _gnutls_file_exists *
gnutls_helper.c:_gnutls_file_exists (const char *file)
gnutls_helper.h:int _gnutls_file_exists (const char *file);
gnutls_psk.c:  if (_gnutls_file_exists (password_file) != 0)
gnutls_srp.c:  if (_gnutls_file_exists (password_file) != 0)
gnutls_srp.c:  if (_gnutls_file_exists (password_conf_file) != 0)
jas at mocca:~/src/gnutls/lib$ 

Thus, only the SRP/PSK and the X.509 APIs ever opens any files.

For TLS-PSK, this is the password file, and the functionality is only
used in the server if you use the
gnutls_psk_set_server_credentials_file() API.  If you avoid it and use
gnutls_psk_set_server_credentials_function() instead, you will have a
callback into your application for the necessary data.

Similar for TLS-SRP, it is only used in the server when you use the
gnutls_srp_set_server_credentials_file() API.  Use
gnutls_srp_set_server_credentials_function() instead.

For X.509 the file operations are used when you use some of the APIs
that takes a filename:

gnutls_certificate_set_x509_key_file
gnutls_certificate_set_x509_trust_file
gnutls_certificate_set_x509_crl_file
gnutls_certificate_set_x509_simple_pkcs12_file

You don't need to use those APIs to set X.509 key/trust/crl files, just
make sure you use other APIs that doesn't involve reading files:

gnutls_certificate_set_x509_key_mem
gnutls_certificate_set_x509_trust_mem
gnutls_certificate_set_x509_crl_mem

For PKCS#12 there isn't a equivalent memory-based API, but if you need
one added, let me know and I can add it easily for you.

Is this sufficient for what you need?

> I saw such callbacks for the socket and memory operations.

Right.

/Simon

>
> Leny
>
> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org]
> Sent: Thursday, August 23, 2007 2:34 PM
> To: Thangiah, Leny IN BLR SISL
> Cc: help-gnutls at gnu.org
> Subject: Re: GnuTLS supports RSA_WITH_RC4_128_MD5?
>
>
> "Thangiah, Leny IN BLR SISL" <leny.thangiah at siemens.com> writes:
>
>> Hi,
>>  
>> I 'm new to the world of SSL. I am evaluating various SSL
>> implementations for using in one of our products. I found that GnuTLS
>> is more portable, scalable and flexible than any other
>> implementations.
>
> Hi, and welcome!
>
>> Please let me know if GnuTLS supports the following ciphering algorithms. These are the crucial requirements for my evaluation.
>> SSL_RSA_WITH_RC4_128_MD5
>>
>> TLS_RSA_WITH_RC4_128_MD5
>
> As far as I know, those are the same cipher, RFC 4346 says:
>
>     CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
>
> and on http://support.microsoft.com/kb/245030 I see that
>
> SSL_RSA_WITH_RC4_128_MD5	{ 0x00,0x04 }
>
> Anyway, yes, GnuTLS supports that cipher suite.
>
> You may want to look into this comparison between some implementations:
>
> http://www.gnu.org/software/gnutls/comparison.html
>
> It may not be complete (additions are most welcome), but should give you
> some indication on what is supported.
>
> Note that GnuTLS does not support SSL version 2.0 since it has been
> broken security-wise.
>
> /Simon




From simon at josefsson.org  Fri Aug 31 16:06:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 31 Aug 2007 16:06:36 +0200
Subject: [Help-gnutls] Libtasn1 1.0
Message-ID: <878x7rn6hf.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.0 (released 2007-08-31)
- The self-tests, command line tools and build infrastructure have
  been re-licensed from GPLv2 to GPLv3.
- Doc fixes.
- Update gnulib files.

Commercial support contracts for Libtasn1 are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a Stockholm
based privately held company, is currently funding Libtasn1 maintenance.
We are always looking for interesting development projects.  See
http://josefsson.org/ for more details.

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.5MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.0.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.0.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.0.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.0.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

43d4fcc225f6de052cd4129095add79d2730193c  libtasn1-1.0.tar.gz
04a9bfd6828ade4d1b3f7a6a7df6adb1f3645b7f  libtasn1-1.0.tar.gz.sig

7ec5dd2dabcc1c13b04993aa62511925823d6a56b86a80648eb65edc  libtasn1-1.0.tar.gz
a3264070511cce9f94a61fd6c0d480a7f36479bd30167d7c87fbd988  libtasn1-1.0.tar.gz.sig

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20070831/2f66fdff/attachment.pgp>

From simon at josefsson.org  Fri Aug 31 17:32:46 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 31 Aug 2007 17:32:46 +0200
Subject: [Help-gnutls] Libtasn1 1.1
Message-ID: <873axzlnxd.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.1 (released 2007-08-31)
- Fix bug that made asn1_check_version believe that 1.0 is older than 0.3.10.

Commercial support contracts for Libtasn1 are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a Stockholm
based privately held company, is currently funding Libtasn1 maintenance.
We are always looking for interesting development projects.  See
http://josefsson.org/ for more details.

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.5MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.1.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.1.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.1.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.1.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

acfee90d4b3b4eafe8626283040930d7770ccf9f  libtasn1-1.1.tar.gz
3021aa472b3c55c22fc95f2d58dfa8c597ee0f4d  libtasn1-1.1.tar.gz.sig

f762d71a0bdff08c253420b8d82c0f6e2643bb8e6ed9ba5cc77c1a46  libtasn1-1.1.tar.gz
0689663ccb096fa0d1d3106a49cb80eb5bf8ba2cac3afca32198d3b3  libtasn1-1.1.tar.gz.sig

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20070831/48a285a3/attachment.pgp>