From stronguser2003 at yahoo.fr  Mon Jul 19 22:20:25 2004
From: stronguser2003 at yahoo.fr (=?iso-8859-1?q?momo=20bob?=)
Date: Mon, 19 Jul 2004 22:20:25 +0200 (CEST)
Subject: [Help-gnutls] gnutls guideline
Message-ID: <20040719202025.22665.qmail@web50102.mail.yahoo.com>

Dear all,
 
Is there any guideline help to compile gnutls under lunix?
 
Thank you in advance.
FR

		
---------------------------------
Cr?ez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Cr?ez votre Yahoo! Mail

Dialoguez en direct avec vos amis gr?ce ? Yahoo! Messenger !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20040719/e262fba3/attachment.htm>

From smurf at smurf.noris.de  Wed Jul 21 18:44:22 2004
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Wed, 21 Jul 2004 18:44:22 +0200
Subject: [Help-gnutls] The "Could not negotiate a supported cipher suite."
	problem again
Message-ID: <20040721164422.GF6949@kiste>

Hi,

@kiste tex $ ldapwhoami -ZZ -D "<your login DN>" -w "<password>"
ldap_start_tls: Connect error (91)
	additional info: A TLS packet with unexpected length was received.

Past emails say that the problem's fixed with current versions,
but apparently it's not ..?

I'm using gnutls_1_0_16, gcrypt-1-2-0. Help appreciated.


The server (slapd, debugging with "-d 65535") reports:

daemon: activity on 1 descriptors
daemon: new connection on 13
ldap_pvt_gethostbyname_a: host=kiste, r=0
str2filter "(objectclass=*)"
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
begin get_filter
PRESENT
ber_scanf fmt (m) ber:
ber_dump: buf=0x08121d58 ptr=0x08121d58 end=0x08121d65 len=13
  0000:  87 0b 6f 62 6a 65 63 74  63 6c 61 73 73            ..objectclass
end get_filter 0
conn=0 fd=13 ACCEPT from IP=127.0.0.1:43063 (IP=0.0.0.0:389)
daemon: added 13r
daemon: activity on:
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: select: listen=8 active_threads=0 tvp=NULL
daemon: select: listen=9 active_threads=0 tvp=NULL
daemon: select: listen=10 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 13r
daemon: read activity on 13
connection_get(13)
connection_get(13): got connid=0
connection_read(13): checking for input on id=0
ber_get_next
ldap_read: want=8, got=8
  0000:  30 1d 02 01 01 77 18 80                            0....w..
ldap_read: want=23, got=23
  0000:  16 31 2e 33 2e 36 2e 31  2e 34 2e 31 2e 31 34 36   .1.3.6.1.4.1.146
  0010:  36 2e 32 30 30 33 37                               6.20037
ber_get_next: tag 0x30 len 29 contents:
ber_dump: buf=0x08121c88 ptr=0x08121c88 end=0x08121ca5 len=29
  0000:  02 01 01 77 18 80 16 31  2e 33 2e 36 2e 31 2e 34   ...w...1.3.6.1.4
  0010:  2e 31 2e 31 34 36 36 2e  32 30 30 33 37            .1.1466.20037
do_extended
ber_scanf fmt ({m) ber:
ber_dump: buf=0x08121c88 ptr=0x08121c8b end=0x08121ca5 len=26
  0000:  77 18 80 16 31 2e 33 2e  36 2e 31 2e 34 2e 31 2e   w...1.3.6.1.4.1.
  0010:  31 34 36 36 2e 32 30 30  33 37                     1466.20037
do_extended: oid=1.3.6.1.4.1.1466.20037
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
ber_get_next on fd 13 failed errno=11 (Resource temporarily unavailable)
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush: 14 bytes to sd 13
  0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........
ldap_write: want=14, written=14
  0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: select: listen=8 active_threads=0 tvp=NULL
daemon: select: listen=9 active_threads=0 tvp=NULL
daemon: select: listen=10 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 13r
daemon: read activity on 13
connection_get(13)
connection_get(13): got connid=0
connection_read(13): checking for input on id=0
tls_read: want=5, got=5
  0000:  16 03 01 00 44                                     ....D
tls_read: want=68, got=68
  0000:  01 00 00 40 03 01 40 fe  9b d8 bb 41 be 6f 17 9a   ... at ..@....A.o..
  0010:  35 c6 39 2e 42 96 10 20  c2 e7 1f 8c 80 69 f7 03   5.9.B.. .....i..
  0020:  37 53 94 65 23 7b 00 00  18 00 33 00 16 00 39 00   7S.e#{....3...9.
  0030:  2f 00 0a 00 35 00 05 00  04 00 32 00 13 00 38 00   /...5.....2...8.
  0040:  66 02 01 00                                        f...
TLS: can't accept.
TLS: Could not negotiate a supported cipher suite. (null):0
connection_read(13): TLS accept error error=-1 id=0, closing
connection_closing: readying conn=0 sd=13 for close


-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de




From nmav at gnutls.org  Wed Jul 21 20:00:09 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Wed, 21 Jul 2004 21:00:09 +0300
Subject: [Help-gnutls] The "Could not negotiate a supported cipher suite."
	problem again
In-Reply-To: <20040721164422.GF6949@kiste>
References: <20040721164422.GF6949@kiste>
Message-ID: <200407212100.09637.nmav@gnutls.org>

On Wednesday 21 July 2004 19:44, Matthias Urlichs wrote:
> Hi,

> @kiste tex $ ldapwhoami -ZZ -D "<your login DN>" -w "<password>"
> ldap_start_tls: Connect error (91)
> 	additional info: A TLS packet with unexpected length was received.
> Past emails say that the problem's fixed with current versions,
> but apparently it's not ..?
Which past emails are you refering to? Here you don't provide adequate 
information, but anyway the problem here seems obvious.
The server has not enabled the ciphersuites that the client supports. That
would be the case if the client uses DHE-RSA but the server did not generate
DH parameters or something similar. You'd better contact the ldap-tls
developers directly about it since it does not look like a gnutls problem, and
they'll be able to help you.

-- 
Nikos Mavroyanopoulos




From smurf at smurf.noris.de  Wed Jul 21 20:02:48 2004
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Wed, 21 Jul 2004 20:02:48 +0200
Subject: [Help-gnutls] The "Could not negotiate a supported cipher suite."
	problem again
In-Reply-To: <200407212100.09637.nmav@gnutls.org>
References: <20040721164422.GF6949@kiste> <200407212100.09637.nmav@gnutls.org>
Message-ID: <20040721180247.GK6949@kiste>

Hi,

Nikos Mavroyanopoulos:
> > Past emails say that the problem's fixed with current versions,
> > but apparently it's not ..?
> Which past emails are you refering to? Here you don't provide adequate 
> information, but anyway the problem here seems obvious.

The mails on this list, a few weeks ago.

> The server has not enabled the ciphersuites that the client supports. That
> would be the case if the client uses DHE-RSA but the server did not generate
> DH parameters or something similar. You'd better contact the ldap-tls
> developers directly about it since it does not look like a gnutls problem, and
> they'll be able to help you.
> 
Hmm. OK, will do. Thanks.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de




From algernon at bonehunter.rulez.org  Fri Jul 30 23:17:33 2004
From: algernon at bonehunter.rulez.org (Gergely Nagy)
Date: Fri, 30 Jul 2004 23:17:33 +0200
Subject: [Help-gnutls] Need a little help with
	gnutls_certificate_server_set_retrieve_function
Message-ID: <1091222253.8408.19.camel@melkor>

Hi!

In the documentation, one can read this:

gnutls_certificate_server_set_retrieve_function

...

This function sets a callback to be called in order to retrieve the
certificate to be used in the handshake. The callback's function
prototype is: int (*callback)(gnutls_session, const gnutls_datum*
req_ca_dn, int nreqs, gnutls_pk_algorithm* pk_algos, int
pk_algos_length, gnutls_retr_st st);

However, the gnutls/gnutls.h header contains:

typedef int gnutls_certificate_server_retrieve_function(gnutls_session,
        gnutls_retr_st *);

Which is a wee-bit different. I checked the gnutls_retr_st structure,
and to be honest, I cannot figure out how my program is supposed to
select the appropriate certificate - or how to get the information to
begin with..

Maybe, but just maybe, it could work like;

- is the second argument (I'll call it rst for brevity) NULL? If yes,
return -1 (there is no certificate)

- If it is non-NULL, rst[0].ncerts contains the list of certificates,
and rst[0].cert.x509 the certificate itself, and so on 'till
rst[rst[0].ncerts] - from this, one could select the appropriate
certificate and act accordingly.

However, this interface seems to be awfully clumsy, compared to the
other interfaces in GnuTLS, so I doubt this is the intended usage.

If I'm missing something obvious, please tell, and apply LART
appropriately!

Thanks,
-- 
Gergely Nagy





From nmav at gnutls.org  Fri Jul 30 23:59:02 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Sat, 31 Jul 2004 00:59:02 +0300
Subject: [Help-gnutls] Need a little help with
	gnutls_certificate_server_set_retrieve_function
In-Reply-To: <1091222253.8408.19.camel@melkor>
References: <1091222253.8408.19.camel@melkor>
Message-ID: <200407310059.03280.nmav@gnutls.org>

On Saturday 31 July 2004 00:17, Gergely Nagy wrote:
> Hi!

> In the documentation, one can read this:
> gnutls_certificate_server_set_retrieve_function
> ...
> This function sets a callback to be called in order to retrieve the
> certificate to be used in the handshake. The callback's function
> prototype is: int (*callback)(gnutls_session, const gnutls_datum*
> req_ca_dn, int nreqs, gnutls_pk_algorithm* pk_algos, int
> pk_algos_length, gnutls_retr_st st);
Ooops. This is the prototype for the client side. It seems I copied
the above documentation and I missed that.

> However, the gnutls/gnutls.h header contains:
> typedef int gnutls_certificate_server_retrieve_function(gnutls_session,
>         gnutls_retr_st *);
This is the correct one.

> Which is a wee-bit different. I checked the gnutls_retr_st structure,
> and to be honest, I cannot figure out how my program is supposed to
> select the appropriate certificate - or how to get the information to
> begin with..

The gnutls-cli program in the cvs uses this callback.
See 
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/src/cli.c?rev=2.241&cvsroot=GNU+TLS+Library&content-type=text/vnd.viewcvs-markup

In brief to fill the retr_st structure you need to specify
the certificate you're returning in type, the number
of certificates in ncerts, the actual certificate list
in cert.x509 (or cert.pgp), and the corresponding private key
in key.x509 (or key.pgp). 

Note that the certificates are of type gnutls_x509_crt
which means you'll need to import your certificates in this
format using gnutls_x509_crt_import() and gnutls_x509_privkey_import()
for x509.

This is might be more burden, although it does not demand
to load any certificates and keys in the credentials structure.
But the main reason I changed the callback is that this one does not 
force you to parse all the loaded DER encoded certificates
to select one. That is you could have already mapped certain
certificates with hostnames, so once in the callback you send
the appropriate with no DER parsing taking place.

> Thanks,

-- 
Nikos Mavroyanopoulos




From nmav at gnutls.org  Sat Jul 31 00:06:18 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Sat, 31 Jul 2004 01:06:18 +0300
Subject: [Help-gnutls] Need a little help with
	gnutls_certificate_server_set_retrieve_function
In-Reply-To: <200407310059.03280.nmav@gnutls.org>
References: <1091222253.8408.19.camel@melkor>
	<200407310059.03280.nmav@gnutls.org>
Message-ID: <200407310106.18914.nmav@gnutls.org>

On Saturday 31 July 2004 00:59, Nikos Mavroyanopoulos wrote:

> The gnutls-cli program in the cvs uses this callback.
> See
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/src/cli.c?rev=2.241&cvsroot
>=GNU+TLS+Library&content-type=text/vnd.viewcvs-markup

Note that here you'll have to ignore the parameters that are
not used in server side (req_ca_dn, int nreqs, gnutls_pk_algorithm* pk_algos, 
int pk_algos_length).

Also an example is available in the documentation in section 6.3.4 (using
a callback to select the certificate to use).

-- 
Nikos Mavroyanopoulos




From algernon at bonehunter.rulez.org  Sat Jul 31 00:06:45 2004
From: algernon at bonehunter.rulez.org (Gergely Nagy)
Date: Sat, 31 Jul 2004 00:06:45 +0200
Subject: [Help-gnutls] Need a little help with
	gnutls_certificate_server_set_retrieve_function
In-Reply-To: <200407310059.03280.nmav@gnutls.org>
References: <1091222253.8408.19.camel@melkor>
	<200407310059.03280.nmav@gnutls.org>
Message-ID: <1091225205.8408.47.camel@melkor>

> > Which is a wee-bit different. I checked the gnutls_retr_st
> > structure,
> > and to be honest, I cannot figure out how my program is supposed to
> > select the appropriate certificate - or how to get the information >
> > to begin with..
> 
> The gnutls-cli program in the cvs uses this callback.
> See 
>
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/src/cli.c?rev=2.241&cvsroot=GNU+TLS+Library&content-type=text/vnd.viewcvs-markup

Thanks, I'll take a look!

Hrm, that is the client part, I'd need the server part - but I can use
this too, thanks!

> In brief to fill the retr_st structure you need to specify
> the certificate you're returning in type, the number
> of certificates in ncerts, the actual certificate list
> in cert.x509 (or cert.pgp), and the corresponding private key
> in key.x509 (or key.pgp). 
> 
> Note that the certificates are of type gnutls_x509_crt
> which means you'll need to import your certificates in this
> format using gnutls_x509_crt_import() and gnutls_x509_privkey_import()
> for x509.
> 
> This is might be more burden, although it does not demand
> to load any certificates and keys in the credentials structure.
> But the main reason I changed the callback is that this one does not 
> force you to parse all the loaded DER encoded certificates
> to select one. That is you could have already mapped certain
> certificates with hostnames, so once in the callback you send
> the appropriate with no DER parsing taking place.

Mmmmhm... I see. So in the certificate select function, I somehow need
to know the list of available certificates.. *thinking, thinking*

Right, I guess I know how to proceed from here on, and indeed, the
interface now makes sense, very much so! I originally thought that the
second argument is for input, not for the retrieve function to store
stuff in (silly me! it's called retrieve because it can load stuff too,
not just select!)

Thanks for explaining!

-- 
Gergely Nagy