From anw at gen3t.com  Fri Mar  4 20:22:30 2005
From: anw at gen3t.com (Allen Williams)
Date: Fri, 4 Mar 2005 14:22:30 -0500
Subject: [Help-gnutls] Alerts?
In-Reply-To: <20050222211927.GA8083@false>
References: <3278.217.231.59.209.1109031280.squirrel@217.231.59.209>
	<20050222211927.GA8083@false>
Message-ID: <200503041422.30132.anw@gen3t.com>

When doing the handshake, I'm getting a return that is a non-fatal alert.  
When I go to check the alert, it is either 64 or 131, both of which seem to 
be undocumented, then I do a gnutls_record_send (which, according to the 
return value, sends all the data I give it), then a gnutls_record_recv, which 
gives an error whose string is "A TLS packet with unexpected length was 
received", which is fatal.

Any ideas?

TIA,
anw




From nmav at gnutls.org  Fri Mar  4 21:48:27 2005
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Mar 2005 21:48:27 +0100
Subject: [Help-gnutls] Alerts?
In-Reply-To: <200503041422.30132.anw@gen3t.com>
References: <3278.217.231.59.209.1109031280.squirrel@217.231.59.209>
	<20050222211927.GA8083@false> <200503041422.30132.anw@gen3t.com>
Message-ID: <200503042148.27560.nmav@gnutls.org>

On Friday 04 March 2005 20:22, Allen Williams wrote:
> When doing the handshake, I'm getting a return that is a non-fatal alert.
> When I go to check the alert, it is either 64 or 131, both of which seem to
> be undocumented, then I do a gnutls_record_send (which, according to the
> return value, sends all the data I give it), then a gnutls_record_recv,
> which gives an error whose string is "A TLS packet with unexpected length
> was received", which is fatal.
This is not normal. Are you experimenting with gnutls being both the server 
and client? It's better to check the output of ssldump or at least of the 
debug level 2.

> TIA,
> anw

-- 
Nikos Mavrogiannopoulos




From jas at extundo.com  Sat Mar  5 16:24:09 2005
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 05 Mar 2005 16:24:09 +0100
Subject: [Help-gnutls] Re: How to turn off optimization
In-Reply-To: <200502260305.54041.bronson@rinspin.com> (Scott Bronson's message
	of "Sat, 26 Feb 2005 03:05:53 -0800")
References: <200502260305.54041.bronson@rinspin.com>
Message-ID: <ilu4qfqjeue.fsf@latte.josefsson.org>

Scott Bronson <bronson at rinspin.com> writes:

> I want to compile gnutls without any compiler optimizations.  How do I do 
> this?
>
> There's no parameter to control optimization in the configuration file
> Deleteing the 3 occurrences of O2 from the config file doesn't work.
> ./configure CFLAGS=-O0 doesn't work (it appends -O2 after -O0).
> CFLAGS=-O0 ./configure doesn't work.
> ./configure --disable-optimization doesn't work.
> ... etc.
>
> I'm out of ideas.  Can anyone give me a hint?  Thanks,

Hello, and thanks for the report.  The configure script added "-O2
-finline-functions" to CFLAGS unconditionally, which seem wrong.  I
have reverted this, so gnutls behave like any autoconf based project.
The NEWS entry reads:

- Optimizations ("-O2 -finline-functions") are not enabled by default,
  instead the standard autoconf defaults are used.  Use `./configure
  CFLAGS="-O2 -finline-functions"' to get the old optimizations.

Try a daily snapshot until 1.2.1 is released.

Thanks,
Simon




From stefan at damp.homeip.net  Fri Mar 18 02:48:58 2005
From: stefan at damp.homeip.net (Stefan D)
Date: Fri, 18 Mar 2005 02:48:58 +0100
Subject: [Help-gnutls] Problems with unclosed file descriptors
Message-ID: <d1dbv8$b85$1@sea.gmane.org>

Hi there

I'm having some problems with an app I'm developing using gnutls 1.1.22. 
It works like a charm, but I'm getting some problems after the app has 
been running for a while. Then I get the "Too many open files" error. 
I've commented out everything other than the code for the ssl-socket, so 
it can't be any other socket/file causing it. The weird thing is that an 
"lsof | grep <appname>" shows a huge list with lines like:

<appname> 22554    stefan  351u  sock     0,0             7419429 can't 
identify protocol

where "351u" goes from low values up to ~1000, and an "lsof | grep 
<appname> | wc -l" jumps around a bit and the settles at 2075 every time 
and gets stuck there only returning "Too many open files" (which is 
after, not 2000 connections, but a lot). I was wondering if I'm doing 
anything wrong when I close the sockets. I've tried lots of different 
stuff, but nothing has worked so far. This is what I do:
---------------
if(useSSL && sessionInited) {
	gnutls_bye(session, GNUTLS_SHUT_WR);
	close(sockfd);
	gnutls_deinit(session);
	sessionInited = false;
}
---------------

Is there anything I've forgotten? Any ideas? Really irritating problem 
because everything else works great, except that it stops working after 
a few hundred connections :)

/Stefan





From jas at extundo.com  Fri Mar 18 13:28:10 2005
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 18 Mar 2005 13:28:10 +0100
Subject: [Help-gnutls] Re: Problems with unclosed file descriptors
In-Reply-To: <d1dbv8$b85$1@sea.gmane.org> (Stefan D.'s message of "Fri, 18 Mar
	2005 02:48:58 +0100")
References: <d1dbv8$b85$1@sea.gmane.org>
Message-ID: <iluk6o52l5x.fsf@latte.josefsson.org>

Stefan D <stefan at damp.homeip.net> writes:

> Hi there
>
> I'm having some problems with an app I'm developing using gnutls 1.1.22. 
> It works like a charm, but I'm getting some problems after the app has 
> been running for a while. Then I get the "Too many open files" error. 
> I've commented out everything other than the code for the ssl-socket, so 
> it can't be any other socket/file causing it. The weird thing is that an 
> "lsof | grep <appname>" shows a huge list with lines like:
>
> <appname> 22554    stefan  351u  sock     0,0             7419429 can't 
> identify protocol
>
> where "351u" goes from low values up to ~1000, and an "lsof | grep 
> <appname> | wc -l" jumps around a bit and the settles at 2075 every time 
> and gets stuck there only returning "Too many open files" (which is 
> after, not 2000 connections, but a lot). I was wondering if I'm doing 
> anything wrong when I close the sockets. I've tried lots of different 
> stuff, but nothing has worked so far. This is what I do:
> ---------------
> if(useSSL && sessionInited) {
> 	gnutls_bye(session, GNUTLS_SHUT_WR);
> 	close(sockfd);
> 	gnutls_deinit(session);
> 	sessionInited = false;
> }
> ---------------
>
> Is there anything I've forgotten? Any ideas? Really irritating problem 
> because everything else works great, except that it stops working after 
> a few hundred connections :)

Maybe you need close(sockfd) when useSSL is false?  Assuming your
application work both with/without SSL.  Just an idea.

I recall some issues with writing servers that accept many
connections.  I am not sure if you are running into them, or if this
is something simpler.  Perhaps you need to increase some OS limit.

Regards,
Simon




From stefan at damp.homeip.net  Fri Mar 18 15:40:25 2005
From: stefan at damp.homeip.net (Stefan D)
Date: Fri, 18 Mar 2005 15:40:25 +0100
Subject: [Help-gnutls] Re: Problems with unclosed file descriptors
In-Reply-To: <iluk6o52l5x.fsf@latte.josefsson.org>
References: <d1dbv8$b85$1@sea.gmane.org> <iluk6o52l5x.fsf@latte.josefsson.org>
Message-ID: <d1ep5g$tg3$1@sea.gmane.org>

Thanks for your reply.

Simon Josefsson wrote:
> Stefan D <stefan at damp.homeip.net> writes:
> 
> 
>>Hi there
>>
>>I'm having some problems with an app I'm developing using gnutls 1.1.22. 
>>It works like a charm, but I'm getting some problems after the app has 
>>been running for a while. Then I get the "Too many open files" error. 
>>I've commented out everything other than the code for the ssl-socket, so 
>>it can't be any other socket/file causing it. The weird thing is that an 
>>"lsof | grep <appname>" shows a huge list with lines like:
>>
>><appname> 22554    stefan  351u  sock     0,0             7419429 can't 
>>identify protocol
>>
>>where "351u" goes from low values up to ~1000, and an "lsof | grep 
>><appname> | wc -l" jumps around a bit and the settles at 2075 every time 
>>and gets stuck there only returning "Too many open files" (which is 
>>after, not 2000 connections, but a lot). I was wondering if I'm doing 
>>anything wrong when I close the sockets. I've tried lots of different 
>>stuff, but nothing has worked so far. This is what I do:
>>---------------
>>if(useSSL && sessionInited) {
>>	gnutls_bye(session, GNUTLS_SHUT_WR);
>>	close(sockfd);
>>	gnutls_deinit(session);
>>	sessionInited = false;
>>}
>>---------------
>>
>>Is there anything I've forgotten? Any ideas? Really irritating problem 
>>because everything else works great, except that it stops working after 
>>a few hundred connections :)
> 
> 
> Maybe you need close(sockfd) when useSSL is false?  Assuming your
> application work both with/without SSL.  Just an idea.

That was just a typo when I removed some #ifdefs, close() is always called.

> I recall some issues with writing servers that accept many
> connections.  I am not sure if you are running into them, or if this
> is something simpler.  Perhaps you need to increase some OS limit.

Well, sorry for taking your time, but I solved it :) It was a small 
error that made the app open a socket and then overwrite the fd with the 
one from accept(). Ooops. Thanks anyway!

> Regards,
> Simon





From daniel at haxx.se  Sat Mar 19 01:08:13 2005
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 19 Mar 2005 01:08:13 +0100 (CET)
Subject: [Help-gnutls] GNUTLS ERROR: A TLS fatal alert
Message-ID: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr>

Hi good people.

I've been playing with gnutls a bit, and I'm a bit puzzled. I need some 
pointers on how to persue this. I'm a complete GnuTLS newbie.

Lemme give you some initial details:

* Linux i686 2.6.9 kernel
* gnutls 1.0.16 (Debian unstable) as well as 1.2.0
* The example code from "7.3.1 Simple client example with anonymous
   authentication"[*]

How to reproduce:

1. Save the example as 'app.c'.

2. Edit code:

  2a Fix the errors in the example (cut off _t from several variable type
     names).
  2b Add a line that displays what gnutls_check_version() returns.
  2c Make it use gnutls.org's test server (use IP address 62.1.205.36)

3. Build the app. Since I did a custom install next to my system version, I
    have it installed in /usr/local/lib now:

    $ gcc -L/usr/local/lib -lgnutls app.c

4. Verify that we use the latest (1.2.0) lib and not the system one:

    $ ldd a.out
 		libgnutls.so.12 => /usr/local/lib/libgnutls.so.12 (0xb7f69000)
     [cut off the rest]

5. Run the app:

    $ ./a.out
    gnutls: 1.2.0
    *** Handshake failed
    GNUTLS ERROR: A TLS fatal alert has been received.

6. What does this mean? What should I do to track it down? Any pointers
    or advice are appreciated.

Thanks.


[*] = I find it very hard to find the most up-to-date docs on the site, but I 
believe the one at
http://josefsson.org/gnutls/manual/gnutls.html.gz#Simple-client-example-with-anonymous-authentication
is the most recent one?

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




From jas at extundo.com  Sat Mar 19 12:51:38 2005
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 19 Mar 2005 12:51:38 +0100
Subject: [Help-gnutls] Re: GNUTLS ERROR: A TLS fatal alert
In-Reply-To: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Sat, 19 Mar 2005 01:08:13 +0100 (CET)")
References: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr>
Message-ID: <ilumzsz26r9.fsf@latte.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

> Hi good people.

Hello!  Thanks for the report.  It is always useful to get first
reactions from new users, to help smooth the learning curve for
others.

> 2. Edit code:
>
>  2a Fix the errors in the example (cut off _t from several variable type
>     names).

The _t are for 1.2.0; if you use the GnuTLS 1.2.0 header files it
should build without modifications.

For reference, I applied these changes:

    const char *PORT = "443";
    const char *SERVER = "62.1.205.36";

> 5. Run the app:
>
>    $ ./a.out
>    gnutls: 1.2.0
>    *** Handshake failed
>    GNUTLS ERROR: A TLS fatal alert has been received.

This is not what I get, I get:

jas at latte:~/src/gnutls/doc/examples$ gcc -L/usr/local/lib -lgnutls ex-client1.c
jas at latte:~/src/gnutls/doc/examples$ ./a.out
- Handshake was completed
- Received 1024 bytes: HTTP/1.1 200 OK
Date: Sat, 19 Mar 2005 11:41:15 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-8 mod_ssl/2.8.22 OpenSSL/0.9.7d
X-Powered-By: PHP/4.3.10-8
Set-Cookie: Horde2=acb24c193175d6e64d7935bf2f08af7e; path=/horde2; domain=mail.hellug.gr
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<!-- IMP: Copyright 2001-2004, The Horde Project. IMP is under the GPL. -->
<!--   Horde Project: http://horde.org/ | IMP: http://horde.org/imp/    -->
<!--      GNU Public License: http://www.fsf.org/copyleft/gpl.html      -->
<html lang="en-US"><head>
<title>Mail :: Welcome to Horde</title>
<link rel="SHORTCUT ICON" href="/horde2/imp/graphics/favicon.ico" type="image/x-icon" />
<link href="/horde2/css.php?app=imp" rel="stylesheet" type="text/css" />
</head>

<body
jas at latte:~/src/gnutls/doc/examples$ ldd a.out

> 6. What does this mean? What should I do to track it down? Any pointers
>    or advice are appreciated.

Perhaps you were using GnuTLS 1.0 headers with the GnuTLS 1.2 library?

Perhaps you'll find 'src/gnutls-cli' more useful, it is also a simple
client, but can print debugging info if you specify the -d parameter.
The code is not very readable, though, IMHO.  Or you can add the debug
code to the example code, stolen from src/cli.c:

static void tls_log_func(int level, const char *str)
{
    fprintf(stderr, "|<%d>| %s", level, str);
}
...

    gnutls_global_set_log_function(tls_log_func);
    gnutls_global_set_log_level(4711);

> [*] = I find it very hard to find the most up-to-date docs on the site, but I 
> believe the one at
> http://josefsson.org/gnutls/manual/gnutls.html.gz#Simple-client-example-with-anonymous-authentication
> is the most recent one?

Yes.

They are included in doc/examples in the source package as well.

What page could be improve to make it easier to find up-to-date docs?

The old manual is still available from the "Dcoumentation" page, but
labeled as such.  Is it too confusing?  Perhaps it serve no purpose
now, and should be removed.  OTOH, it applies to 1.0, which is still
widely used, and the current manual apply to 1.2.  I have now added
text that say the new manual is for 1.2 and the old for 1.0, perhaps
it help somewhat.

Thanks,
Simon




From daniel at haxx.se  Sat Mar 19 13:37:01 2005
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 19 Mar 2005 13:37:01 +0100 (CET)
Subject: [Help-gnutls] Re: GNUTLS ERROR: A TLS fatal alert
In-Reply-To: <ilumzsz26r9.fsf@latte.josefsson.org>
References: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr>
	<ilumzsz26r9.fsf@latte.josefsson.org>
Message-ID: <Pine.LNX.4.61.0503191314140.7324@yvahk3.pbagnpgbe.fr>

On Sat, 19 Mar 2005, Simon Josefsson wrote:

> The _t are for 1.2.0; if you use the GnuTLS 1.2.0 header files it should 
> build without modifications.

Aha, sorry. Didn't spot the version mismatch.

>    const char *PORT = "443";
>    const char *SERVER = "62.1.205.36";

Hm. When I try that server + port, it works for me as well. But if I point it 
to sourceforge's HTTPS server at 66.35.250.203:443, I get that TLS fatal alert 
again.

Does it work for you then? gnutls-cli seems to work fine against it.

> Perhaps you'll find 'src/gnutls-cli' more useful, it is also a simple
> client, but can print debugging info if you specify the -d parameter.
> The code is not very readable, though,

Right. I actually started out with the manual and adjusted an existing source 
code to use GnuTLS, and when I got into trouble I thought I'd go back and 
simply use one of the simple apps first to check that the basic concepts work 
as I think they would.

But since the simple app doesn't even work, it is no wonder my own app doesn't 
since I picked lots of inspiration from this sample app. My app also works 
against www.gnutls.org:443, but no others.

>> I believe the one at [URL] is the most recent one?
>
> Yes. They are included in doc/examples in the source package as well.

Okey. I started out without the source package, as I was hoping to get my 
stuff working with the Debian-distributed package.

> What page could be improve to make it easier to find up-to-date docs?

The documentation page on the web site could clearly mention: "docs for 1.0.X 
here" and "docs for 1.2.X here".

> The old manual is still available from the "Dcoumentation" page, but labeled 
> as such.  Is it too confusing?

Using Debian unstable, updated very frequently, I'm not used to looking for 
"old manual" links. I think they would be better if they mentioned version 
numbers/ranges.

> I have now added text that say the new manual is for 1.2 and the old for 
> 1.0, perhaps it help somewhat.

Yes, that is goodness!

Many thanks for your quick and detailed response.

(I am in the progress of making libcurl optionally use GnuTLS for SSL 
support...)

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




From jas at extundo.com  Sat Mar 19 14:22:38 2005
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 19 Mar 2005 14:22:38 +0100
Subject: [Help-gnutls] Re: GNUTLS ERROR: A TLS fatal alert
In-Reply-To: <Pine.LNX.4.61.0503191314140.7324@yvahk3.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Sat, 19 Mar 2005 13:37:01 +0100 (CET)")
References: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr>
	<ilumzsz26r9.fsf@latte.josefsson.org>
	<Pine.LNX.4.61.0503191314140.7324@yvahk3.pbagnpgbe.fr>
Message-ID: <iluekeb22jl.fsf@latte.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

>>    const char *PORT = "443";
>>    const char *SERVER = "62.1.205.36";
>
> Hm. When I try that server + port, it works for me as well. But if I point it 
> to sourceforge's HTTPS server at 66.35.250.203:443, I get that TLS fatal alert 
> again.
>
> Does it work for you then? gnutls-cli seems to work fine against it.

Try ex-client2.c against www.sf.net.

They seem to require that the client support X.509 credentials, even
though it is not used.

I ran into this as well when first starting toying with GnuTLS,
incidentally www.sf.net was one of the first real servers I tried
talking to...

If someone if there is a real reason why sf.net (and others) behave
like this, it would be useful information.  Possibly an OpenSSL quirk?

It seems you typically have to set up a X.509 credential with GnuTLS
even if you aren't using it.

>> The old manual is still available from the "Dcoumentation" page, but
>> labeled as such.  Is it too confusing?
>
> Using Debian unstable, updated very frequently, I'm not used to looking for 
> "old manual" links. I think they would be better if they mentioned version 
> numbers/ranges.

Right.

Thanks,
Simon




From daniel at haxx.se  Sat Mar 19 14:46:46 2005
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 19 Mar 2005 14:46:46 +0100 (CET)
Subject: [Help-gnutls] Re: GNUTLS ERROR: A TLS fatal alert
In-Reply-To: <iluekeb22jl.fsf@latte.josefsson.org>
References: <Pine.LNX.4.61.0503190048080.9825@yvahk3.pbagnpgbe.fr>
	<ilumzsz26r9.fsf@latte.josefsson.org>
	<Pine.LNX.4.61.0503191314140.7324@yvahk3.pbagnpgbe.fr>
	<iluekeb22jl.fsf@latte.josefsson.org>
Message-ID: <Pine.LNX.4.61.0503191445560.7324@yvahk3.pbagnpgbe.fr>

On Sat, 19 Mar 2005, Simon Josefsson wrote:

> They seem to require that the client support X.509 credentials, even though 
> it is not used.

Aha. Thanks a lot! So now I know how to continue this...

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




From daniel at haxx.se  Mon Mar 21 23:10:06 2005
From: daniel at haxx.se (Daniel Stenberg)
Date: Mon, 21 Mar 2005 23:10:06 +0100 (CET)
Subject: [Help-gnutls] handshake with non-blocking sockets?
Message-ID: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr>

Hi

Thanks Simon for the previous answers. I'm now progressing fine!

Here's another question:

When I use non-blocking sockets and call gnutls_handshake(). What happens and 
how should I behave? The manual doesn't mention non-blocking anywhere...

When it returns GNUTLS_E_AGAIN, can I simply do a select() on the socket to 
wait for data to become readable or writable and then call it again? Or could 
it return with one of those return codes while still having data to be 
processed without having to wait for anything on the socket?

Or did I just miss this (too) in the manual?

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




From jas at extundo.com  Mon Mar 21 23:45:06 2005
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 21 Mar 2005 23:45:06 +0100
Subject: [Help-gnutls] Re: handshake with non-blocking sockets?
In-Reply-To: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Mon, 21 Mar 2005 23:10:06 +0100 (CET)")
References: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr>
Message-ID: <iluvf7klitp.fsf@latte.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

> When I use non-blocking sockets and call gnutls_handshake(). What happens and 
> how should I behave? The manual doesn't mention non-blocking anywhere...
>
> When it returns GNUTLS_E_AGAIN, can I simply do a select() on the socket to 
> wait for data to become readable or writable and then call it again? Or could 
> it return with one of those return codes while still having data to be 
> processed without having to wait for anything on the socket?
>
> Or did I just miss this (too) in the manual?

This is written in haste, and probably doesn't answer your
question...  Anyway, is the thread in

http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1267

of any help?

If I understand correctly, though, GnuTLS perform some internal
buffering, so calling select might not be reliable.  But I don't have
much experience with non-blocking I/O and GnuTLS.  Perhaps Nikos can
chime in.  I'm not sure how portable it is for GnuTLS to push data
back into the OS buffers, which would be one way to make select() work
as expected.

Regards,
Simon




From daniel at haxx.se  Tue Mar 22 10:38:39 2005
From: daniel at haxx.se (Daniel Stenberg)
Date: Tue, 22 Mar 2005 10:38:39 +0100 (CET)
Subject: [Help-gnutls] Re: handshake with non-blocking sockets?
In-Reply-To: <iluvf7klitp.fsf@latte.josefsson.org>
References: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr>
	<iluvf7klitp.fsf@latte.josefsson.org>
Message-ID: <Pine.LNX.4.61.0503221029240.24251@yvahk3.pbagnpgbe.fr>

On Mon, 21 Mar 2005, Simon Josefsson wrote:

> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1267
>
> of any help?

Thanks. This helps me a bit but more for the non-blocking case with send/recv, 
which I haven't really gotten to yet. I don't see how this helps me for the 
handshake case.

> If I understand correctly, though, GnuTLS perform some internal buffering, 
> so calling select might not be reliable.  But I don't have much experience 
> with non-blocking I/O and GnuTLS.  Perhaps Nikos can chime in.  I'm not sure 
> how portable it is for GnuTLS to push data back into the OS buffers, which 
> would be one way to make select() work as expected.

It doesn't sound like the proper way to proceed.

In my simple-minded view, it would be better if there is a function we could 
use to ask gnutls if there is more data in its buffers or not (compare with 
SSL_pending() in OpenSSL) so that we then can call gnutls again without doing 
select() and only if gnutls can't do more we wait for more socket actions.

You may take this question as a request for some clarification in the docs on 
how gnutls behaves when using blocking vs non-blocking sockets.

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




From nmav at gnutls.org  Tue Mar 22 16:02:36 2005
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 Mar 2005 16:02:36 +0100
Subject: [Help-gnutls] handshake with non-blocking sockets?
In-Reply-To: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr>
References: <Pine.LNX.4.61.0503212251490.28484@yvahk3.pbagnpgbe.fr>
Message-ID: <200503221602.36278.nmav@gnutls.org>

On Monday 21 March 2005 23:10, Daniel Stenberg wrote:
> Hi
Hello,

> Thanks Simon for the previous answers. I'm now progressing fine!
> Here's another question:
> When I use non-blocking sockets and call gnutls_handshake(). What happens
> and how should I behave? The manual doesn't mention non-blocking
> anywhere...
> When it returns GNUTLS_E_AGAIN, can I simply do a select() on the socket to
> wait for data to become readable or writable and then call it again?
Yes. In order to see whether you have to check for readability or writability
use the gnutls_record_get_direction() function.

> Or  could it return with one of those return codes while still having data 
to
> be processed without having to wait for anything on the socket? 
No. Non-blocking is on the sockets part, not in gnutls. Gnutls will always
process as much as possible permitted by the data available.


-- 
Nikos Mavrogiannopoulos




From andreas at dicp.ghb.fh-furtwangen.de  Wed Mar 30 18:19:40 2005
From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann)
Date: Wed, 30 Mar 2005 18:19:40 +0200 (CEST)
Subject: [Help-gnutls] Problems with Key usage violation
Message-ID: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>

Hi,

I'm having a problem with programs linked agains gnutls 1.0.20 (and other 
version).

When connecting to our servers these tools fail the Handshake with the 
following message:

#### snip ####
## [root at bla /tmp]# gnutls-cli 
## ca.bawue.net
## Resolving 'ca.bawue.net'...
## Connecting to '193.7.176.6:443'...
## *** Fatal error: Key usage violation in certificate has been detected.
## *** Handshake has failed
## GNUTLS ERROR: Key usage violation in certificate has been detected.
#### snip ####

>From my understanding of x509 keys, this means that the certificate is 
used in a way which does not correspond with the allowed usage cases.

However, checking the cert with the openssl command gives the following 
info, which shows that there shouldn't be any problems as the key is 
cert is defined to be used as a SSL Server.

#### snip ####
## [root at bla /tmp]# openssl x509 -noout -purpose -in server.crt
## Certificate purposes:
## SSL client : No
## SSL client CA : No
## SSL server : Yes
## SSL server CA : No
## Netscape SSL server : Yes
## Netscape SSL server CA : No
## S/MIME signing : No
## S/MIME signing CA : No
## S/MIME encryption : No
## S/MIME encryption CA : No
## CRL signing : No
## CRL signing CA : No
## Any Purpose : Yes
## Any Purpose CA : Yes
## OCSP helper : Yes
## OCSP helper CA : No
#### snip ####

Thus I do not see a reason why the GNUTLS_E_KEY_USAGE_VIOLATION should be 
triggered.

Furthermore, openssl seems to have no problem connecting to the server as 
can be seen by the following snippet.

[root at bla /tmp]# openssl s_client -CAfile /tmp/bawue-ca-bundle.crt 
-connect ca.bawue.net:443
CONNECTED(00000003)
depth=2 /C=DE/L=Boeblingen/O=Bawue.Net e.V./OU=Bawue.Net CA/CN=Bawue.Net 
Root CA
verify return:1
depth=1 /C=DE/L=Boeblingen/O=Bawue.Net e.V./OU=Bawue.Net CA/CN=Bawue.Net 
ServerCerts CA
verify return:1
depth=0 /C=DE/ST= /L=Boeblingen/O=Bawue.Net e.V./CN=ca.bawue.net
verify return:1
---
Certificate chain
  0 s:/C=DE/ST= /L=Boeblingen/O=Bawue.Net e.V./CN=ca.bawue.net
    i:/C=DE/L=Boeblingen/O=Bawue.Net e.V./OU=Bawue.Net CA/CN=Bawue.Net 
ServerCerts CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE4zCCBEygAwIBAgIBHDANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJERTET
MBEGA1UEBxMKQm9lYmxpbmdlbjEXMBUGA1UEChMOQmF3dWUuTmV0IGUuVi4xFTAT
BgNVBAsTDEJhd3VlLk5ldCBDQTEhMB8GA1UEAxMYQmF3dWUuTmV0IFNlcnZlckNl
cnRzIENBMB4XDTA1MDMxMTE4MDM0NloXDTA3MDIwOTE4MDM0NlowXjELMAkGA1UE
BhMCREUxCjAIBgNVBAgTASAxEzARBgNVBAcTCkJvZWJsaW5nZW4xFzAVBgNVBAoT
DkJhd3VlLk5ldCBlLlYuMRUwEwYDVQQDEwxjYS5iYXd1ZS5uZXQwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALwzFRbWttiE8JIL2KcgyfOJAUlyTbXg/5RlGgFp
aXLQHRi4g5gK+c5iz32NgZp82kWP0tFBDagi3jSZXj0MHD1JBV3iwnNlhBKQiWFW
UR5u7XLt6ggOBZLseW1P3jiSg2XG02LLJeKAyFInjc+kITlF58a0acotn7G7zOGM
+iGjAgMBAAGjggKYMIIClDAdBgNVHQ4EFgQUoknB2TYfCyQQoNN0p5CZWoHvCKww
gZgGA1UdIwSBkDCBjYAU0hR5ci6rLzZlgGqDip3w+eBcnxShcqRwMG4xCzAJBgNV
BAYTAkRFMRMwEQYDVQQHEwpCb2VibGluZ2VuMRcwFQYDVQQKEw5CYXd1ZS5OZXQg
ZS5WLjEVMBMGA1UECxMMQmF3dWUuTmV0IENBMRowGAYDVQQDExFCYXd1ZS5OZXQg
Um9vdCBDQYIBBDBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY2EuYmF3dWUubmV0
L2NnaS1iaW4vZ2V0LWNlcnQucHkvU2VydmVyQ2VydHMvY3JsLmNybDALBgNVHQ8E
BAMCBSAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYBBAGCNwoD
AzA8BglghkgBhvhCAQ0ELxYtVGhpcyBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBT
U0wgU2VydmVyQ2VydHMuMCQGCWCGSAGG+EIBAgQXFhVodHRwczovL2NhLmJhd3Vl
Lm5ldC8wNgYJYIZIAYb4QgEEBCkWJ2NnaS1iaW4vZ2V0LWNlcnQucHkvU2VydmVy
Q2VydHMvY3JsLmNybDAzBglghkgBhvhCAQMEJhYkY2dpLWJpbi9ucy1jaGVjay1y
ZXYucHkvU2VydmVyQ2VydHM/MDEGCWCGSAGG+EIBBwQkFiJjZ2ktYmluL25zLXJl
bmV3YWwucHkvU2VydmVyQ2VydHM/MDoGCWCGSAGG+EIBCAQtFitCYXd1ZS5OZXQt
Q0EvcG9saWN5L1NlcnZlckNlcnRzLXBvbGljeS5odG1sMBEGCWCGSAGG+EIBAQQE
AwIGQDANBgkqhkiG9w0BAQUFAAOBgQBCqiKTxj2cDDF/uUSBInYsOBbF9qinktRF
zZHQAcjtfB/N0Y/Qt4+FhZoASsiSPULRuNJ6G4USZJj5J4LI3eEW0zVGj5Cvr/pc
vRrQO0VkWGilS0x8HHw+mg4gZKVETYpVCKMEjXk8iOByoAFlT/Bi0stHwVEyKgYP
ekvsmy8bDQ==
-----END CERTIFICATE-----
subject=/C=DE/ST= /L=Boeblingen/O=Bawue.Net e.V./CN=ca.bawue.net
issuer=/C=DE/L=Boeblingen/O=Bawue.Net e.V./OU=Bawue.Net CA/CN=Bawue.Net 
ServerCerts CA
---
No client certificate CA names sent
---
SSL handshake has read 1819 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
     Protocol  : TLSv1
     Cipher    : DHE-RSA-AES256-SHA
     Session-ID: 
DC333450AF65FFA0ABB83D591455B6535B9670365A16FF26CB6B3B878B1B6078
     Session-ID-ctx:
     Master-Key: 
E38DC474ECD3CF343A27CF7CDFC71C9823D23CBB16B465CD4CC66628FB1C1EC68C903581C43FAACC6731E6CA5EE8BA6E
     Key-Arg   : None
     Krb5 Principal: None
     Start Time: 1112202855
     Timeout   : 300 (sec)
     Verify return code: 0 (ok)
---


Any ideas where to look for the problem?

thanks,
  andreas




From nmav at gnutls.org  Wed Mar 30 20:29:05 2005
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Mar 2005 20:29:05 +0200
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
Message-ID: <200503302029.06426.nmav@gnutls.org>

On Wednesday 30 March 2005 18:19, Andreas Thienemann wrote:
> Hi,

> I'm having a problem with programs linked agains gnutls 1.0.20 (and other
> version).
> When connecting to our servers these tools fail the Handshake with the
> following message:
> #### snip ####
> ## [root at bla /tmp]# gnutls-cli
> ## ca.bawue.net
> ## Resolving 'ca.bawue.net'...
> ## Connecting to '193.7.176.6:443'...
> ## *** Fatal error: Key usage violation in certificate has been detected.
> ## *** Handshake has failed
> ## GNUTLS ERROR: Key usage violation in certificate has been detected.
> #### snip ####

> >From my understanding of x509 keys, this means that the certificate is
> used in a way which does not correspond with the allowed usage cases.
Correct. Gnutls checks the key usage X.509 certificate extension.
That is, for example, if the RSA key is marked encrypt only, you cannot use 
the DHE_RSA  algorithm that requires signing.

> However, checking the cert with the openssl command gives the following
> info, which shows that there shouldn't be any problems as the key is
> cert is defined to be used as a SSL Server.
Use the output of certtool or the -text output of openssl x509. Try
./certtool -i <server.crt

> #### snip ####
> ## [root at bla /tmp]# openssl x509 -noout -purpose -in server.crt
> ## Certificate purposes:
gnutls does not check the purpose, but rather the key usage.

> thanks,
>   andreas

-- 
Nikos Mavrogiannopoulos




From andreas at dicp.ghb.fh-furtwangen.de  Wed Mar 30 20:01:19 2005
From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann)
Date: Wed, 30 Mar 2005 20:01:19 +0200 (CEST)
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <200503302029.06426.nmav@gnutls.org>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
	<200503302029.06426.nmav@gnutls.org>
Message-ID: <Pine.LNX.4.60.0503301947500.18368@dicp.ghb.fh-furtwangen.de>

On Wed, 30 Mar 2005, Nikos Mavrogiannopoulos wrote:

>> From my understanding of x509 keys, this means that the certificate is
>> used in a way which does not correspond with the allowed usage cases.
> Correct. Gnutls checks the key usage X.509 certificate extension.
> That is, for example, if the RSA key is marked encrypt only, you cannot use
> the DHE_RSA  algorithm that requires signing.
Which extension exactly is checked?
key usage and extended key usage?

> Use the output of certtool or the -text output of openssl x509. Try
> ./certtool -i <server.crt
Okay. certtool seems to have some problems recognizing some extensions as 
only numbers are shown and to have some problems with the DER parsing.
But one of the recognized key purpose seems okay to me: TLS WWW Server.
Besides the fact that this should be valid for all kind of TLS servers, it 
looks okay to me.

Additionally the key usage "Key encipherment" should be okay as well, that 
is if I understand the different usages correctly.

### snip ###
[root at bla /root]# certtool -i < /tmp/server.crt


X.509 certificate info:

Version: 3
Serial Number (hex): 1c
Subject: C=DE,ST= ,L=Boeblingen,O=Bawue.Net e.V.,CN=ca.bawue.net
Issuer: C=DE,L=Boeblingen,O=Bawue.Net e.V.,OU=Bawue.Net CA,CN=Bawue.Net 
ServerCerts CA
Signature Algorithm: RSA-SHA
Validity:
         Not Before: Fri Mar 11 19:03:00 2005
         Not After: Fri Feb  9 19:03:00 2007
Subject Public Key Info:
         Public Key Algorithm: RSA (1024 bits)

X.509 Extensions:
         CRL Distribution points:
                 URI: 
http://ca.bawue.net/cgi-bin/get-cert.py/ServerCerts/crl.crl
         Key usage:
                 Key encipherment.
         Key purpose OIDs:
                 TLS WWW Server.
                 2.16.840.1.113730.4.1
                 1.3.6.1.4.1.311.10.3.3
         Subject Key ID:
                 a2 49 c1 d9 36 1f 0b 24 10 a0 d3 74 a7 90 99 5a 81 ef 08 
ac
Error getting authority key id: ASN1 parser: Error in DER parsing.
         2.16.840.1.113730.1.13:
                 DER Data: 
162d54686973206365727469666963617465206973207573656420666f722053534c2053657276657243657274732e
         2.16.840.1.113730.1.2:
                 DER Data: 161568747470733a2f2f63612e62617775652e6e65742f
         2.16.840.1.113730.1.4:
                 DER Data: 
16276367692d62696e2f6765742d636572742e70792f53657276657243657274732f63726c2e63726c
         2.16.840.1.113730.1.3:
                 DER Data: 
16246367692d62696e2f6e732d636865636b2d7265762e70792f53657276657243657274733f
         2.16.840.1.113730.1.7:
                 DER Data: 
16226367692d62696e2f6e732d72656e6577616c2e70792f53657276657243657274733f
         2.16.840.1.113730.1.8:
                 DER Data: 
162b42617775652e4e65742d43412f706f6c6963792f53657276657243657274732d706f6c6963792e68746d6c
         2.16.840.1.113730.1.1:
                 DER Data: 03020640

Other information:
         Fingerprint: 68 6e 87 46 1b 7f c9 52 5f b7 5e 21 6d 14 b4 25
         Public Key ID: e1 ee 9e fd 2c 71 fc e3 83 3c fa 6f 46 52 5e 1d 4b 
c2 37 42


-----BEGIN CERTIFICATE-----
MIIE4zCCBEygAwIBAgIBHDANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJERTET
MBEGA1UEBxMKQm9lYmxpbmdlbjEXMBUGA1UEChMOQmF3dWUuTmV0IGUuVi4xFTAT
BgNVBAsTDEJhd3VlLk5ldCBDQTEhMB8GA1UEAxMYQmF3dWUuTmV0IFNlcnZlckNl
cnRzIENBMB4XDTA1MDMxMTE4MDM0NloXDTA3MDIwOTE4MDM0NlowXjELMAkGA1UE
BhMCREUxCjAIBgNVBAgTASAxEzARBgNVBAcTCkJvZWJsaW5nZW4xFzAVBgNVBAoT
DkJhd3VlLk5ldCBlLlYuMRUwEwYDVQQDEwxjYS5iYXd1ZS5uZXQwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALwzFRbWttiE8JIL2KcgyfOJAUlyTbXg/5RlGgFp
aXLQHRi4g5gK+c5iz32NgZp82kWP0tFBDagi3jSZXj0MHD1JBV3iwnNlhBKQiWFW
UR5u7XLt6ggOBZLseW1P3jiSg2XG02LLJeKAyFInjc+kITlF58a0acotn7G7zOGM
+iGjAgMBAAGjggKYMIIClDAdBgNVHQ4EFgQUoknB2TYfCyQQoNN0p5CZWoHvCKww
gZgGA1UdIwSBkDCBjYAU0hR5ci6rLzZlgGqDip3w+eBcnxShcqRwMG4xCzAJBgNV
BAYTAkRFMRMwEQYDVQQHEwpCb2VibGluZ2VuMRcwFQYDVQQKEw5CYXd1ZS5OZXQg
ZS5WLjEVMBMGA1UECxMMQmF3dWUuTmV0IENBMRowGAYDVQQDExFCYXd1ZS5OZXQg
Um9vdCBDQYIBBDBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY2EuYmF3dWUubmV0
L2NnaS1iaW4vZ2V0LWNlcnQucHkvU2VydmVyQ2VydHMvY3JsLmNybDALBgNVHQ8E
BAMCBSAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYBBAGCNwoD
AzA8BglghkgBhvhCAQ0ELxYtVGhpcyBjZXJ0aWZpY2F0ZSBpcyB1c2VkIGZvciBT
U0wgU2VydmVyQ2VydHMuMCQGCWCGSAGG+EIBAgQXFhVodHRwczovL2NhLmJhd3Vl
Lm5ldC8wNgYJYIZIAYb4QgEEBCkWJ2NnaS1iaW4vZ2V0LWNlcnQucHkvU2VydmVy
Q2VydHMvY3JsLmNybDAzBglghkgBhvhCAQMEJhYkY2dpLWJpbi9ucy1jaGVjay1y
ZXYucHkvU2VydmVyQ2VydHM/MDEGCWCGSAGG+EIBBwQkFiJjZ2ktYmluL25zLXJl
bmV3YWwucHkvU2VydmVyQ2VydHM/MDoGCWCGSAGG+EIBCAQtFitCYXd1ZS5OZXQt
Q0EvcG9saWN5L1NlcnZlckNlcnRzLXBvbGljeS5odG1sMBEGCWCGSAGG+EIBAQQE
AwIGQDANBgkqhkiG9w0BAQUFAAOBgQBCqiKTxj2cDDF/uUSBInYsOBbF9qinktRF
zZHQAcjtfB/N0Y/Qt4+FhZoASsiSPULRuNJ6G4USZJj5J4LI3eEW0zVGj5Cvr/pc
vRrQO0VkWGilS0x8HHw+mg4gZKVETYpVCKMEjXk8iOByoAFlT/Bi0stHwVEyKgYP
ekvsmy8bDQ==
-----END CERTIFICATE-----

Just for completeness, here is the openssl output, which looks similiar. 
The only difference is that the two additional OIDs are recognized as the 
netscape and microsoft ones.


### snip ###
[root at bla /root]# openssl x509 -in /tmp/server.crt -noout -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 28 (0x1c)
         Signature Algorithm: sha1WithRSAEncryption
         Issuer: C=DE, L=Boeblingen, O=Bawue.Net e.V., OU=Bawue.Net CA, 
CN=Bawue.Net ServerCerts CA
         Validity
             Not Before: Mar 11 18:03:46 2005 GMT
             Not After : Feb  9 18:03:46 2007 GMT
         Subject: C=DE, ST= , L=Boeblingen, O=Bawue.Net e.V., 
CN=ca.bawue.net
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
             RSA Public Key: (1024 bit)
                 Modulus (1024 bit):
                     00:bc:33:15:16:d6:b6:d8:84:f0:92:0b:d8:a7:20:
                     c9:f3:89:01:49:72:4d:b5:e0:ff:94:65:1a:01:69:
                     69:72:d0:1d:18:b8:83:98:0a:f9:ce:62:cf:7d:8d:
                     81:9a:7c:da:45:8f:d2:d1:41:0d:a8:22:de:34:99:
                     5e:3d:0c:1c:3d:49:05:5d:e2:c2:73:65:84:12:90:
                     89:61:56:51:1e:6e:ed:72:ed:ea:08:0e:05:92:ec:
                     79:6d:4f:de:38:92:83:65:c6:d3:62:cb:25:e2:80:
                     c8:52:27:8d:cf:a4:21:39:45:e7:c6:b4:69:ca:2d:
                     9f:b1:bb:cc:e1:8c:fa:21:a3
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Subject Key Identifier:
             A2:49:C1:D9:36:1F:0B:24:10:A0:D3:74:A7:90:99:5A:81:EF:08:AC
             X509v3 Authority Key Identifier:

keyid:D2:14:79:72:2E:AB:2F:36:65:80:6A:83:8A:9D:F0:F9:E0:5C:9F:14
             DirName:/C=DE/L=Boeblingen/O=Bawue.Net e.V./OU=Bawue.Net 
CA/CN=Bawue.Net Root CA
             serial:04

             X509v3 CRL Distribution Points:

URI:http://ca.bawue.net/cgi-bin/get-cert.py/ServerCerts/crl.crl

             X509v3 Key Usage:
             Key Encipherment
             X509v3 Extended Key Usage:
             TLS Web Server Authentication, Netscape Server Gated Crypto, 
Microsoft Server Gated Crypto
             Netscape Comment:
             This certificate is used for SSL ServerCerts.
             Netscape Base Url:
             https://ca.bawue.net/
             Netscape CA Revocation Url:
             cgi-bin/get-cert.py/ServerCerts/crl.crl
             Netscape Revocation Url:
             cgi-bin/ns-check-rev.py/ServerCerts?
             Netscape Renewal Url:
             cgi-bin/ns-renewal.py/ServerCerts?
             Netscape CA Policy Url:
             Bawue.Net-CA/policy/ServerCerts-policy.html
             Netscape Cert Type:
             SSL Server
     Signature Algorithm: sha1WithRSAEncryption
         42:aa:22:93:c6:3d:9c:0c:31:7f:b9:44:81:22:76:2c:38:16:
         c5:f6:a8:a7:92:d4:45:cd:91:d0:01:c8:ed:7c:1f:cd:d1:8f:
         d0:b7:8f:85:85:9a:00:4a:c8:92:3d:42:d1:b8:d2:7a:1b:85:
         12:64:98:f9:27:82:c8:dd:e1:16:d3:35:46:8f:90:af:af:fa:
         5c:bd:1a:d0:3b:45:64:58:68:a5:4b:4c:7c:1c:7c:3e:9a:0e:
         20:64:a5:44:4d:8a:55:08:a3:04:8d:79:3c:88:e0:72:a0:01:
         65:4f:f0:62:d2:cb:47:c1:51:32:2a:06:0f:7a:4b:ec:9b:2f:
         1b:0d


> gnutls does not check the purpose, but rather the key usage.
_ONLY_ the key usage?

Then I do not understand the problem.
According to 
http://www.dfn-pca.de/certify/ssl/handbuch/ossl095/ossl095-4.html#s-gebr-keyusage 
(german stuff about the dfc cert) ssl servers need "key encipherment" set.

This conforms with our openssl configuration which is used for signing the 
server keys.

>From my understanding, everything should work. ;-D

bye,
  andreas




From nmav at gnutls.org  Wed Mar 30 21:50:57 2005
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Mar 2005 21:50:57 +0200
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <Pine.LNX.4.60.0503301947500.18368@dicp.ghb.fh-furtwangen.de>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
	<200503302029.06426.nmav@gnutls.org>
	<Pine.LNX.4.60.0503301947500.18368@dicp.ghb.fh-furtwangen.de>
Message-ID: <200503302150.57685.nmav@gnutls.org>

On Wednesday 30 March 2005 20:01, Andreas Thienemann wrote:
> On Wed, 30 Mar 2005, Nikos Mavrogiannopoulos wrote:
> >> From my understanding of x509 keys, this means that the certificate is
> >> used in a way which does not correspond with the allowed usage cases.
> > Correct. Gnutls checks the key usage X.509 certificate extension.
> > That is, for example, if the RSA key is marked encrypt only, you cannot
> > use the DHE_RSA  algorithm that requires signing.
> Which extension exactly is checked?
> key usage and extended key usage?
Key usage.

> > Use the output of certtool or the -text output of openssl x509. Try
> > ./certtool -i <server.crt
> Okay. certtool seems to have some problems recognizing some extensions as
They are private extensions.

> only numbers are shown and to have some problems with the DER parsing.
I will try to check this problem.

> But one of the recognized key purpose seems okay to me: TLS WWW Server.
The key purpose is ok. The key usage is not.
>          Key usage:
>                  Key encipherment.
This only works with plain RSA cipher suites. That means that your server
MUST NOT use DHE_RSA, which is a signing ciphersuite.

> Besides the fact that this should be valid for all kind of TLS servers, it
> looks okay to me.
No this is not valid for all TLS servers. Only for the ones that use plain 
RSA.

> Additionally the key usage "Key encipherment" should be okay as well, that
> is if I understand the different usages correctly.
You need the digital signature flag in order to use the DHE_RSA and RSA_EXPORT 
ciphersuites.

> > gnutls does not check the purpose, but rather the key usage.
> _ONLY_ the key usage?
Only the key usage. The key purpose is quite high level and should be checked
at the application level.

> Then I do not understand the problem.
> According to
> http://www.dfn-pca.de/certify/ssl/handbuch/ossl095/ossl095-4.html#s-gebr-ke
>yusage (german stuff about the dfc cert) ssl servers need "key encipherment"
> set.
I didn't read it but probably they talk about the RSA ciphersuites. So just 
disable the DHE_RSA ciphersuites in your server. Usually it is a good 
practice to limit the scope of the key to signature or encryption only to
avoid certain kind of attacks.


> bye,
>   andreas

-- 
Nikos Mavrogiannopoulos




From andreas at dicp.ghb.fh-furtwangen.de  Wed Mar 30 21:01:40 2005
From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann)
Date: Wed, 30 Mar 2005 21:01:40 +0200 (CEST)
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <200503302150.57685.nmav@gnutls.org>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
	<200503302029.06426.nmav@gnutls.org>
	<Pine.LNX.4.60.0503301947500.18368@dicp.ghb.fh-furtwangen.de>
	<200503302150.57685.nmav@gnutls.org>
Message-ID: <Pine.LNX.4.60.0503302058170.18368@dicp.ghb.fh-furtwangen.de>

On Wed, 30 Mar 2005, Nikos Mavrogiannopoulos wrote:

>>          Key usage:
>>                  Key encipherment.
> This only works with plain RSA cipher suites. That means that your server
> MUST NOT use DHE_RSA, which is a signing ciphersuite.
Off the top of my head I can't think of a good reason to use DHE_RSA for 
an SSL server as it doesn't have to sign anything, right?

So disabling it wouldn't pose a problem.

>> Besides the fact that this should be valid for all kind of TLS servers, it
>> looks okay to me.
> No this is not valid for all TLS servers. Only for the ones that use plain
> RSA.
I see.

[ gnutls checking scope ]
> Only the key usage.
Is is really a good idea to be more strict here than e.g. openssl?
Because I do know of several servers which do have this problem when being 
used by clients which are linked agains gnutls.

bye,
  andreas




From nmav at gnutls.org  Wed Mar 30 22:18:05 2005
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Mar 2005 22:18:05 +0200
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <Pine.LNX.4.60.0503302058170.18368@dicp.ghb.fh-furtwangen.de>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
	<200503302150.57685.nmav@gnutls.org>
	<Pine.LNX.4.60.0503302058170.18368@dicp.ghb.fh-furtwangen.de>
Message-ID: <200503302218.05910.nmav@gnutls.org>

On Wednesday 30 March 2005 21:01, Andreas Thienemann wrote:

> > This only works with plain RSA cipher suites. That means that your server
> > MUST NOT use DHE_RSA, which is a signing ciphersuite.
> Off the top of my head I can't think of a good reason to use DHE_RSA for
> an SSL server as it doesn't have to sign anything, right?
> So disabling it wouldn't pose a problem.
In DHE_RSA the RSA certificate is used to sign a diffie hellman key exchange.
This offers perfect forward secrecy, which means that if the certificate
is compromised at a future date, the old session data are still safe. This
property is not available in the plain RSA ciphersuite.

Other than that, and given that all clients support plain RSA, it shouldn't
pose a problem.

> Is is really a good idea to be more strict here than e.g. openssl?
> Because I do know of several servers which do have this problem when being
> used by clients which are linked agains gnutls.
Well it would be useless for a certificate to have the key usage bits set when
nobody actually checks them. If you use them, it's probably because you want
to limit the key's scope, and gnutls is just enforcing it. If you don't want 
these checks, you shouldn't put such extensions to your certificates.

> bye,
>   andreas

-- 
Nikos Mavrogiannopoulos




From andreas at dicp.ghb.fh-furtwangen.de  Wed Mar 30 23:29:55 2005
From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann)
Date: Wed, 30 Mar 2005 23:29:55 +0200 (CEST)
Subject: [Help-gnutls] Problems with Key usage violation
In-Reply-To: <200503302218.05910.nmav@gnutls.org>
References: <Pine.LNX.4.60.0503301802560.18368@dicp.ghb.fh-furtwangen.de>
	<200503302150.57685.nmav@gnutls.org>
	<Pine.LNX.4.60.0503302058170.18368@dicp.ghb.fh-furtwangen.de>
	<200503302218.05910.nmav@gnutls.org>
Message-ID: <Pine.LNX.4.60.0503302310400.18368@dicp.ghb.fh-furtwangen.de>

On Wed, 30 Mar 2005, Nikos Mavrogiannopoulos wrote:

> In DHE_RSA the RSA certificate is used to sign a diffie hellman key exchange.
> This offers perfect forward secrecy, which means that if the certificate
> is compromised at a future date, the old session data are still safe. This
> property is not available in the plain RSA ciphersuite.
I see.

Okay, I changed the CA setup so that key usage is now Digital Signature 
and Key Encipherment.

Now connecting with gnutls-cli works.

However, I am still seeing problems with another smtpd which is linked 
against gnutls.

Connecting with gnutls-cli --x509certfile /etc/ssl/certs/ca-certificates.crt --x509keyfile 
/etc/exim4/smtp_client.key -s -p 25 mail2.bawue.de
still gives:

*** Fatal error: Key usage violation in certificate has been detected.
*** Handshake has failed

As this only happens when the x509keyfile is used, I checked the keyfile 
for the allowed usages and is has Digital Signature and Key Encipherment 
as well.
Reading http://www.ietf.org/rfc/rfc2459.txt it is not exactly clear if 
this is correct or not.
keyAgreement and decipherOnly might be okay as well.

Any suggestions?

> Well it would be useless for a certificate to have the key usage bits set when
> nobody actually checks them. If you use them, it's probably because you want
> to limit the key's scope, and gnutls is just enforcing it. If you don't want
> these checks, you shouldn't put such extensions to your certificates.
True. But it might be considered a bad idea for programs which worked 
previously to fail as soon as they are linked against gnutls.

bye,
  andreas