From simon+gnutls-dev at josefsson.org Sun Feb 3 19:11:02 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Sun Feb 3 19:11:02 2002 Subject: [gnutls-dev] API comment Message-ID: typedef int gnutls_certificate_client_callback_func(GNUTLS_STATE, const gnutls_datum *, int, const gnutls_datum *, int); typedef int gnutls_certificate_server_callback_func(GNUTLS_STATE, const gnutls_datum *, int); ... void gnutls_certificate_client_set_select_func( GNUTLS_CERTIFICATE_CREDENTIALS, gnutls_certificate_client_callback_func *); void gnutls_certificate_server_set_select_func( GNUTLS_CERTIFICATE_CREDENTIALS, gnutls_certificate_server_callback_func *); It is difficult to use these callbacks in a multithreaded application, and even single threaded applications with multiple connections, since it is difficult for the invoked callback to know from where it was called. You need a global variable, containing e.g. GNUTLS_STATE*, mapping to the application-specific structure for each connections that the callback should use as context. Solution: Do like all other TLS libraries, add a `void*' argument to the callback, which is passed unmodified from the set-callback function back to the calling application. The application can use it to store whatever context information it wants: typedef int gnutls_certificate_client_callback_func(GNUTLS_STATE, const gnutls_datum *, int, const gnutls_datum *, int, void *); typedef int gnutls_certificate_server_callback_func(GNUTLS_STATE, const gnutls_datum *, int, void *); ... void gnutls_certificate_client_set_select_func( GNUTLS_CERTIFICATE_CREDENTIALS, gnutls_certificate_client_callback_func *, void *); void gnutls_certificate_server_set_select_func( GNUTLS_CERTIFICATE_CREDENTIALS, gnutls_certificate_server_callback_func *, void *); From andrew at mcdonald.org.uk Fri Feb 8 22:52:01 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Fri Feb 8 22:52:01 2002 Subject: [gnutls-dev] Building gnutls from CVS without opencdk Message-ID: <20020208215022.GB13072@mcdonald.org.uk> Nikos et al., I built gnutls from CVS without opencdk support. However, I ended up with some unresolved symbols when linking my program. The attached diff fixes these. Also, I had some trouble with x509_ASN.y: gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -pipe -Wp,-MD,.deps/x509_ASN.pp -c x509_ASN.c -fPIC -DPIC -o .libs/x509_ASN.lo x509_ASN.y: In function `yyparse': x509_ASN.y:279: parse error before }' x509_ASN.y:339: parse error before }' x509_ASN.y:341: parse error before }' x509_ASN.y:382: parse error before `const' x509_ASN.y:410: `c' undeclared (first use in this function) x509_ASN.y:410: (Each undeclared identifier is reported only once x509_ASN.y:410: for each function it appears in.) x509_ASN.y:421: `counter' undeclared (first use in this function) x509_ASN.y:428: `string' undeclared (first use in this function) x509_ASN.y:440: `k' undeclared (first use in this function) x509_ASN.y:449: `key_word' undeclared (first use in this function) x509_ASN.y:450: `key_word_token' undeclared (first use in this function) x509_ASN.y:475: parse error before `int' x509_ASN.y:477: `pointer' undeclared (first use in this function) x509_ASN.y:480: `file_name' undeclared (first use in this function) x509_ASN.y:527: parse error before `int' x509_ASN.y:551: `result' undeclared (first use in this function) Somehow I eventually created a x509_ASN.tab.c. Copying this to x509_ASN.c solved it. I'm using Debian unstables bison 1.32-3. Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- Index: lib/auth_cert.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/auth_cert.c,v retrieving revision 2.9 diff -u -r2.9 auth_cert.c --- lib/auth_cert.c 2002/02/07 20:58:47 2.9 +++ lib/auth_cert.c 2002/02/08 21:38:07 @@ -795,6 +795,7 @@ return 0; } +#ifdef HAVE_LIBOPENCDK #define CLEAR_CERTS for(x=0;xsecurity_parameters.cert_type) { +#ifdef HAVE_LIBOPENCDK case GNUTLS_CRT_OPENPGP: return _gnutls_proc_openpgp_server_certificate(state, data, data_size); +#endif /* HAVE_LIBOPENCDK */ case GNUTLS_CRT_X509: return _gnutls_proc_x509_server_certificate(state, data, data_size); @@ -1119,6 +1122,7 @@ info-> raw_certificate_list[0]); break; +#ifdef HAVE_LIBOPENCDK case GNUTLS_CRT_OPENPGP: ret = _gnutls_openpgp_cert2gnutls_cert(&peer_cert, @@ -1126,7 +1130,7 @@ raw_certificate_list [0]); break; - +#endif /* HAVE_LIBOPENCDK */ default: gnutls_assert(); return GNUTLS_E_UNKNOWN_ERROR; Index: lib/auth_dhe.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/auth_dhe.c,v retrieving revision 1.4 diff -u -r1.4 auth_dhe.c --- lib/auth_dhe.c 2002/02/03 18:30:25 1.4 +++ lib/auth_dhe.c 2002/02/08 21:38:08 @@ -341,6 +341,7 @@ return ret; } break; +#ifdef HAVE_LIBOPENCDK case GNUTLS_CRT_OPENPGP: if ((ret = _gnutls_openpgp_cert2gnutls_cert( &peer_cert, @@ -349,7 +350,7 @@ return ret; } break; - +#endif /* HAVE_LIBOPENCDK */ default: gnutls_assert(); return GNUTLS_E_UNKNOWN_ERROR; Index: lib/auth_rsa.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/auth_rsa.c,v retrieving revision 2.54 diff -u -r2.54 auth_rsa.c --- lib/auth_rsa.c 2002/02/03 18:30:25 2.54 +++ lib/auth_rsa.c 2002/02/08 21:38:09 @@ -86,6 +86,7 @@ return ret; } break; +#ifdef HAVE_LIBOPENCDK case GNUTLS_CRT_OPENPGP: if ((ret = _gnutls_openpgp_cert2gnutls_cert( &peer_cert, @@ -94,7 +95,7 @@ return ret; } break; - +#endif /* HAVE_LIBOPENCDK */ default: gnutls_assert(); return GNUTLS_E_UNKNOWN_ERROR; Index: lib/gnutls_cert.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_cert.c,v retrieving revision 2.81 diff -u -r2.81 gnutls_cert.c --- lib/gnutls_cert.c 2002/02/05 12:18:47 2.81 +++ lib/gnutls_cert.c 2002/02/08 21:38:10 @@ -296,6 +296,7 @@ state->gnutls_internals.server_cert_callback = func; } +#ifdef HAVE_LIBOPENCDK /*- * _gnutls_openpgp_cert_verify_peers - This function returns the peer's certificate status * @state: is a gnutls state @@ -353,6 +354,7 @@ return verify; } +#endif /* HAVE_LIBOPENCDK */ /** * gnutls_certificate_verify_peers - This function returns the peer's certificate verification status @@ -382,8 +384,10 @@ switch( gnutls_cert_type_get( state)) { case GNUTLS_CRT_X509: return _gnutls_x509_cert_verify_peers( state); +#ifdef HAVE_LIBOPENCDK case GNUTLS_CRT_OPENPGP: return _gnutls_openpgp_cert_verify_peers( state); +#endif /* HAVE_LIBOPENCDK */ default: return GNUTLS_E_INVALID_REQUEST; } From nmav at gnutls.org Fri Feb 8 23:40:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Feb 8 23:40:01 2002 Subject: [gnutls-dev] Building gnutls from CVS without opencdk In-Reply-To: <20020208215022.GB13072@mcdonald.org.uk> References: <20020208215022.GB13072@mcdonald.org.uk> Message-ID: <20020208223647.GA4613@gnutls.org> On Fri, Feb 08, 2002 at 09:50:22PM +0000, Andrew McDonald wrote: > Nikos et al., > I built gnutls from CVS without opencdk support. However, I ended up > with some unresolved symbols when linking my program. The attached diff > fixes these. > Also, I had some trouble with x509_ASN.y: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -pipe -Wp,-MD,.deps/x509_ASN.pp -c > x509_ASN.c -fPIC -DPIC -o .libs/x509_ASN.lo > x509_ASN.y: In function `yyparse': [...] > Somehow I eventually created a x509_ASN.tab.c. Copying this to > x509_ASN.c solved it. I'm using Debian unstables bison 1.32-3. Hello Andrew, Concerning x509_ASN.c, there might be a conflict with bison 1.32. I use bison 1.28 and works fine. I've added the .c file in the cvs for convenience, but Fabio should have the last word for this. Concerning the patch. I've applied it, and thank you. > Regards, > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Sun Feb 10 12:05:01 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Sun Feb 10 12:05:01 2002 Subject: [gnutls-dev] Building gnutls from CVS without opencdk In-Reply-To: <20020208223647.GA4613@gnutls.org> References: <20020208215022.GB13072@mcdonald.org.uk> <20020208223647.GA4613@gnutls.org> Message-ID: <20020210110256.GA668@mcdonald.org.uk> On Sat, Feb 09, 2002 at 12:36:47AM +0200, Nikos Mavroyanopoulos wrote: > > Concerning x509_ASN.c, there might be a conflict with bison 1.32. > I use bison 1.28 and works fine. I've added the .c file in the cvs > for convenience, but Fabio should have the last word for this. FYI, bison 1.33 also appears to have problems, while going back to 1.28 does seem to solve the problem. Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From Fabio.Fiorina at alcatel.it Tue Feb 12 12:29:01 2002 From: Fabio.Fiorina at alcatel.it (Fabio.Fiorina at alcatel.it) Date: Tue Feb 12 12:29:01 2002 Subject: R: [gnutls-dev] Building gnutls from CVS without opencdk Message-ID: Hi Andrew, the first three errors in x509_ASN.y were easy to find, but for the others I have to use bison 1.32 or newer. I hope to send you some news tomorrow. regards, fabio -------------------------------------------------------- Name: Fabio Fiorina E-mail: Fabio Fiorina Telephone:+39 039 686 7503 Fax :+39 039 686 3590 internal mail stop: 90 -------------------------------------------------------- -----Messaggio originale----- Da: andrew [SMTP:andrew at mcdonald.org.uk] Inviato: venerd? 8 febbraio 2002 22.50 A: gnutls-dev Cc: andrew Oggetto: [gnutls-dev] Building gnutls from CVS without opencdk Nikos et al., I built gnutls from CVS without opencdk support. However, I ended up with some unresolved symbols when linking my program. The attached diff fixes these. Also, I had some trouble with x509_ASN.y: gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -pipe -Wp,-MD,.deps/x509_ASN.pp -c x509_ASN.c -fPIC -DPIC -o .libs/x509_ASN.lo x509_ASN.y: In function `yyparse': x509_ASN.y:279: parse error before }' x509_ASN.y:339: parse error before }' x509_ASN.y:341: parse error before }' x509_ASN.y:382: parse error before `const' x509_ASN.y:410: `c' undeclared (first use in this function) x509_ASN.y:410: (Each undeclared identifier is reported only once x509_ASN.y:410: for each function it appears in.) x509_ASN.y:421: `counter' undeclared (first use in this function) x509_ASN.y:428: `string' undeclared (first use in this function) x509_ASN.y:440: `k' undeclared (first use in this function) x509_ASN.y:449: `key_word' undeclared (first use in this function) x509_ASN.y:450: `key_word_token' undeclared (first use in this function) x509_ASN.y:475: parse error before `int' x509_ASN.y:477: `pointer' undeclared (first use in this function) x509_ASN.y:480: `file_name' undeclared (first use in this function) x509_ASN.y:527: parse error before `int' x509_ASN.y:551: `result' undeclared (first use in this function) Somehow I eventually created a x509_ASN.tab.c. Copying this to x509_ASN.c solved it. I'm using Debian unstables bison 1.32-3. Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ << File: gnutlsdiff >> -------------- next part -------------- A non-text attachment was scrubbed... Name: WINMAIL.DAT Type: application/ms-tnef Size: 2444 bytes Desc: not available URL: From Fabio.Fiorina at alcatel.it Wed Feb 13 09:18:02 2002 From: Fabio.Fiorina at alcatel.it (Fabio.Fiorina at alcatel.it) Date: Wed Feb 13 09:18:02 2002 Subject: R: [gnutls-dev] Building gnutls from CVS without opencdk Message-ID: Hello, the problem with bison 1.32 will be solved with next x509_ASN.y version, that I'll try to check in the CVS this evening (last evening I had some connection problems). Attached you can find the new file. Regards, fabio -------------------------------------------------------- Name: Fabio Fiorina E-mail: Fabio Fiorina Telephone:+39 039 686 7503 Fax :+39 039 686 3590 internal mail stop: 90 -------------------------------------------------------- -----Messaggio originale----- Da: andrew [SMTP:andrew at mcdonald.org.uk] Inviato: venerd? 8 febbraio 2002 22.50 A: gnutls-dev Cc: andrew Oggetto: [gnutls-dev] Building gnutls from CVS without opencdk Nikos et al., I built gnutls from CVS without opencdk support. However, I ended up with some unresolved symbols when linking my program. The attached diff fixes these. Also, I had some trouble with x509_ASN.y: gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -pipe -Wp,-MD,.deps/x509_ASN.pp -c x509_ASN.c -fPIC -DPIC -o .libs/x509_ASN.lo x509_ASN.y: In function `yyparse': x509_ASN.y:279: parse error before }' x509_ASN.y:339: parse error before }' x509_ASN.y:341: parse error before }' x509_ASN.y:382: parse error before `const' x509_ASN.y:410: `c' undeclared (first use in this function) x509_ASN.y:410: (Each undeclared identifier is reported only once x509_ASN.y:410: for each function it appears in.) x509_ASN.y:421: `counter' undeclared (first use in this function) x509_ASN.y:428: `string' undeclared (first use in this function) x509_ASN.y:440: `k' undeclared (first use in this function) x509_ASN.y:449: `key_word' undeclared (first use in this function) x509_ASN.y:450: `key_word_token' undeclared (first use in this function) x509_ASN.y:475: parse error before `int' x509_ASN.y:477: `pointer' undeclared (first use in this function) x509_ASN.y:480: `file_name' undeclared (first use in this function) x509_ASN.y:527: parse error before `int' x509_ASN.y:551: `result' undeclared (first use in this function) Somehow I eventually created a x509_ASN.tab.c. Copying this to x509_ASN.c solved it. I'm using Debian unstables bison 1.32-3. Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ << File: gnutlsdiff >> -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_ASN.y Type: application/octet-stream Size: 21097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WINMAIL.DAT Type: application/ms-tnef Size: 6135 bytes Desc: not available URL: From nmav at gnutls.org Thu Feb 14 11:12:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu Feb 14 11:12:01 2002 Subject: [gnutls-dev] netscape enterprise server 3.6 Message-ID: <20020214100916.GA14502@gnutls.org> I've been unable to connect with gnutls[0] to www.verisign.com:443. It seem they are using the Netscape Enterprise server 3.6 SP3, and it's rejecting us for some reason, after the client key exchange message is sent. The alert it sends is the generic handshake failure alert and does not help at all. If anyone has access to a netscape server 3.6 sp3 or close to it I'd appreciate if he could help, by providing the output of the log files. Newer enterprise servers seem to work fine (ssl.netscape.com works fine). [0]. 0.3.5 had some bugs with ssl 3.0, which are fixed in the cvs. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Thu Feb 14 21:23:02 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Thu Feb 14 21:23:02 2002 Subject: [gnutls-dev] netscape enterprise server 3.6 In-Reply-To: <20020214100916.GA14502@gnutls.org> References: <20020214100916.GA14502@gnutls.org> Message-ID: <20020214202042.GC719@mcdonald.org.uk> On Thu, Feb 14, 2002 at 12:09:16PM +0200, Nikos Mavroyanopoulos wrote: > > [0]. 0.3.5 had some bugs with ssl 3.0, which are fixed in the cvs. Might this have been a reason that some people seem to get an UNEXPECTED_PACKET_LENGTH in the handshake? See Debian bug #133403 There is also a report of problems against 'some proprietary program': He doesn't seem to have filed a bug in the Debian BTS, but I'll see if can find some more details. Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at gnutls.org Fri Feb 15 04:05:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Feb 15 04:05:01 2002 Subject: [gnutls-dev] netscape enterprise server 3.6 In-Reply-To: <20020214202042.GC719@mcdonald.org.uk> References: <20020214100916.GA14502@gnutls.org> <20020214202042.GC719@mcdonald.org.uk> Message-ID: <20020215030155.GA1269@gnutls.org> On Thu, Feb 14, 2002 at 08:20:42PM +0000, Andrew McDonald wrote: > > [0]. 0.3.5 had some bugs with ssl 3.0, which are fixed in the cvs. > Might this have been a reason that some people seem to get an > UNEXPECTED_PACKET_LENGTH in the handshake? > See Debian bug #133403 I don't know, there is not much information included. However, I noticed that starttls is not used when the server does not advertize it. This is not good. If starttls is enabled it should connect using TLS and fail (or ask the user to continue), otherwise. If this is the current behaviour then ignore this. > There is also a report of problems against 'some proprietary program': > > > He doesn't seem to have filed a bug in the Debian BTS, but I'll see if > can find some more details. The problem with these proprietary implementations is that we cannot easily check against. > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Fri Feb 15 18:07:02 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Fri Feb 15 18:07:02 2002 Subject: [gnutls-dev] netscape enterprise server 3.6 In-Reply-To: <20020215030155.GA1269@gnutls.org> References: <20020214100916.GA14502@gnutls.org> <20020214202042.GC719@mcdonald.org.uk> <20020215030155.GA1269@gnutls.org> Message-ID: <20020215170419.GB2642@mcdonald.org.uk> On Fri, Feb 15, 2002 at 05:01:55AM +0200, Nikos Mavroyanopoulos wrote: > On Thu, Feb 14, 2002 at 08:20:42PM +0000, Andrew McDonald wrote: > However, I noticed that starttls is not used when the > server does not advertize it. This is not good. If starttls is > enabled it should connect using TLS and fail (or ask the user > to continue), otherwise. If this is the current behaviour > then ignore this. It's slightly more complicated than that. I'm not too keen on it, but it's what the mutt with OpenSSL behaviour is, and I'll probably try to change some of it in the future. The ssl_starttls setting essentially gives opportunistic encryption - if we use imap (port 143) and the server advertises STARTTLS we try to do it. If you want to be sure of using TLS/SSL then you can specify imaps (IMAP over SSL/TLS on port 993). There is also an imap_force_ssl setting. If you have this set and then specify imap it essentially changes it to imaps (IMAP over SSL on port 993 unless another port is specified). If you work this through you'll realise that it is not possible to make sure it uses TLS and use STARTTLS on port 143. :-( I think an improved behaviour would be that if imap_force_ssl is set with 'imap' as the protocol and ssl_starttls set then it should do STARTTLS or fail (or maybe try imaps on port 993). > > There is also a report of problems against 'some proprietary program': > > > > > > He doesn't seem to have filed a bug in the Debian BTS, but I'll see if > > can find some more details. > The problem with these proprietary implementations is that we cannot > easily check against. Indeed. It appears that he gets a fatal alert and that it is a problem with both SSLv3 and TLSv1, but that's as much as I've found out. Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at gnutls.org Fri Feb 15 19:32:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Feb 15 19:32:01 2002 Subject: [gnutls-dev] starttls In-Reply-To: <20020215170419.GB2642@mcdonald.org.uk> References: <20020214100916.GA14502@gnutls.org> <20020214202042.GC719@mcdonald.org.uk> <20020215030155.GA1269@gnutls.org> <20020215170419.GB2642@mcdonald.org.uk> Message-ID: <20020215182940.GA5873@gnutls.org> On Fri, Feb 15, 2002 at 05:04:20PM +0000, Andrew McDonald wrote: > > enabled it should connect using TLS and fail (or ask the user > > to continue), otherwise. If this is the current behaviour > > then ignore this. > It's slightly more complicated than that. I'm not too keen on it, but > it's what the mutt with OpenSSL behaviour is, and I'll probably try to > change some of it in the future. > The ssl_starttls setting essentially gives opportunistic encryption - > if we use imap (port 143) and the server advertises STARTTLS we try to > do it. The STARTTLS mechanism is vulnerable to man in the middle attack. It's easy for somebody to make the client see a different IMAP hello message, which does not contain the starttls capability. In IMAPS the obvious attack is to send RSTs and make the client think that there is no server in this port. In the first case (starttls), if the client continues, without tls, and without asking the actual user, then the user's password is sent in the clear. This does not happen in the imaps case, and since these starttls replaces imaps, these two methods should be equally strong. > If you work this through you'll realise that it is not possible to make > sure it uses TLS and use STARTTLS on port 143. :-( This is true... but if the user has chosen to use starttls, and starttls is not available, he should be asked if he wishes to continue. > I think an improved behaviour would be that if imap_force_ssl is set > with 'imap' as the protocol and ssl_starttls set then it should do > STARTTLS or fail (or maybe try imaps on port 993). Yes this is much better. > > The problem with these proprietary implementations is that we cannot > > easily check against. > Indeed. It appears that he gets a fatal alert and that it is a problem > with both SSLv3 and TLSv1, but that's as much as I've found out. An other thing that might help here, is that DHE_RSA works with any server i've tried, while the most compatibility problems exist in RSA key exchange. The drawback is that DHE_RSA requires more calculations, than plain RSA, thus many servers disable it. > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Fri Feb 15 20:17:02 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Fri Feb 15 20:17:02 2002 Subject: [gnutls-dev] starttls In-Reply-To: <20020215182940.GA5873@gnutls.org> References: <20020214100916.GA14502@gnutls.org> <20020214202042.GC719@mcdonald.org.uk> <20020215030155.GA1269@gnutls.org> <20020215170419.GB2642@mcdonald.org.uk> <20020215182940.GA5873@gnutls.org> Message-ID: <20020215191454.GD2642@mcdonald.org.uk> On Fri, Feb 15, 2002 at 08:29:40PM +0200, Nikos Mavroyanopoulos wrote: > The STARTTLS mechanism is vulnerable to man in the middle attack. It's > easy for somebody to make the client see a different IMAP hello message, > which does not contain the starttls capability. In IMAPS the > obvious attack is to send RSTs and make the client think that there > is no server in this port. > > In the first case (starttls), if the client continues, without tls, and > without asking the actual user, then the user's password is sent in the > clear. This does not happen in the imaps case, and since these starttls > replaces imaps, these two methods should be equally strong. I agree in full. The current implementation as opportunistic encryption gives some protection against passive attackers when a server advertises STARTTLS, but it is no way as useful as being able to insist on a TLS connection. I think it's time I made some comments on mutt-dev.... > > > The problem with these proprietary implementations is that we cannot > > > easily check against. > > Indeed. It appears that he gets a fatal alert and that it is a problem > > with both SSLv3 and TLSv1, but that's as much as I've found out. > An other thing that might help here, is that DHE_RSA works with > any server i've tried, while the most compatibility problems exist in > RSA key exchange. The drawback is that DHE_RSA requires more > calculations, than plain RSA, thus many servers disable it. Well, the mutt/gnutls patch gives: const int kx_priority[] = {GNUTLS_KX_X509PKI_DHE_RSA, GNUTLS_KX_X509PKI_RSA, 0}; as the priority, is it worth suggesting he tries swapping them? Some more info (he's using gnutls 0.3.5 AFAIK): --X--X-- I've gdb'd a little bit through the thing today, and it seems the server is closing the connection quite after getting the first helo. Activating debugging in the code I get: mutt_gnutls_socket_setup: 0 Looking up HOSTNAME... Connecting to HOSTNAME... *** Keeping ciphersuite: X509PKI_DHE_RSA_3DES_EDE_CBC_SHa *** Keeping ciphersuite: X509PKI_DHE_RSA_RIJNDAEL_128_CBC_SHA *** Keeping ciphersuite: X509PKI_RSA_3DES_EDE_CBC_SHA *** Keeping ciphersuite: X509PKI_RSA_RIJNDAEL_128_CBC_SHA Handshake: CLIENT HELLO was send [52 bytes] GNUTLS_ASSERT: gnutls_buffers.c:853 GNUTLS_ASSERT: gnutls_handshake.c:752 GNUTLS_ASSERT: gnutls_handshake.c:880 GNUTLS_ASSERT: gnutls_handshake.c:1757 GNUTLS Error: recv hello (-12) gnutls_handshake: FATAL_ALERT_RECEIVED The Assert seems to be just the receive-rotine, which does not like the connection already terminated. --X--X-- I haven't looked at the asserts in any detail. Apparently it works ok with openssl - though it might just be openssl working round bugs in the server. Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at gnutls.org Sat Feb 16 00:42:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat Feb 16 00:42:01 2002 Subject: [gnutls-dev] starttls In-Reply-To: <20020215191454.GD2642@mcdonald.org.uk> References: <20020214100916.GA14502@gnutls.org> <20020214202042.GC719@mcdonald.org.uk> <20020215030155.GA1269@gnutls.org> <20020215170419.GB2642@mcdonald.org.uk> <20020215182940.GA5873@gnutls.org> <20020215191454.GD2642@mcdonald.org.uk> Message-ID: <20020215233924.GA10299@gnutls.org> On Fri, Feb 15, 2002 at 07:14:54PM +0000, Andrew McDonald wrote: > > RSA key exchange. The drawback is that DHE_RSA requires more > > calculations, than plain RSA, thus many servers disable it. > Well, the mutt/gnutls patch gives: > const int kx_priority[] = > {GNUTLS_KX_X509PKI_DHE_RSA, GNUTLS_KX_X509PKI_RSA, 0}; > as the priority, is it worth suggesting he tries swapping them? They are fine, no need for swap. > Looking up HOSTNAME... > Connecting to HOSTNAME... > *** Keeping ciphersuite: X509PKI_DHE_RSA_3DES_EDE_CBC_SHa > *** Keeping ciphersuite: X509PKI_DHE_RSA_RIJNDAEL_128_CBC_SHA > *** Keeping ciphersuite: X509PKI_RSA_3DES_EDE_CBC_SHA > *** Keeping ciphersuite: X509PKI_RSA_RIJNDAEL_128_CBC_SHA > Handshake: CLIENT HELLO was send [52 bytes] > GNUTLS_ASSERT: gnutls_buffers.c:853 > GNUTLS_ASSERT: gnutls_handshake.c:752 > GNUTLS_ASSERT: gnutls_handshake.c:880 > GNUTLS_ASSERT: gnutls_handshake.c:1757 > GNUTLS Error: recv hello (-12) > gnutls_handshake: FATAL_ALERT_RECEIVED Wow that's strange. I can think some reasons though: 1. The server only accepts SSLv2 hellos - If this is the case (i wouldn't vote for this), the server is broken. Try connecting with openssl s_client -tls1 to check this. 2. The server has one certificate with DSS parameters - This can be solved only by updating to gnutls 0.4.0 (when it's released) 3. The server does not like our extensions. - can be solved by disabling SRP and not using the max_record_size extension. 4. We send a broken hello message - Can be tested by enabling WRITE_DEBUG and sending me the output. > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Thu Feb 21 20:51:01 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Thu Feb 21 20:51:01 2002 Subject: [gnutls-dev] Re: Bug#134584: noch ein gnutls problem In-Reply-To: <20020221063616.H16920@ch.lugn.nu> References: <20020218155552.M1104@ch.lugn.nu> <20020218190356.GA640@mcdonald.org.uk> <20020218233422.C4360@ch.lugn.nu> <20020219195556.GA6386@mcdonald.org.uk> <20020221063616.H16920@ch.lugn.nu> Message-ID: <20020221194921.GA717@mcdonald.org.uk> I'm Cc'ing gnutls-dev on this to get some more ideas. (See http://bugs.debian.org/134584 for info). Main symptom is a "FATAL_ALERT_RECEIVED" - mutt now suggests RC4/ARCFOUR so that shouldn't be the problem. On Thu, Feb 21, 2002 at 06:36:17AM +0100, Martin Samuelsson wrote: > On Tue, Feb 19, 2002 at 07:55:56PM +0000, Andrew McDonald wrote: > > Next thing to try, does the server only accepts SSLv2 hellos? > > (The server's broken if this is the case). Try connecting to the > > IMAP/SSL port (tcp 993) with > > openssl s_client -tls1 -connect host:port > > to check this. (If this fails you might want to try -no_tls or -ssl2 as > > well). > > as far as i can understand, it works ok. Yes, that looks like TLS1 is OK for it. > > Does the server have a DSS certificate? (Not supported in gnutls 0.3.5, > > but will be in some future releases). If you control the server you > > might be able to try: > > openssl x509 -in certificate_file -text -noout > > I don't think I have the priviliges needed. I thought the OpenSSL s_client connection might have shown whether it was using RSA or DSS, but didn't. Anyway, try copying the certificate sent as part of the exchange into a file and running openssl x509 on it. > > Other testing is likely to require recompiling gnutls with debugging > > enabled. > > Tell me what to do, and it'll be done. Recompiling gnutls with some of the DEBUGs in lib/gnutls_int.h #defined will print out lots of information. I think WRITE_DEBUG is probably the main one of interest. Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at gnutls.org Thu Feb 21 22:04:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu Feb 21 22:04:01 2002 Subject: [gnutls-dev] Re: Bug#134584: noch ein gnutls problem In-Reply-To: <20020221194921.GA717@mcdonald.org.uk> References: <20020218155552.M1104@ch.lugn.nu> <20020218190356.GA640@mcdonald.org.uk> <20020218233422.C4360@ch.lugn.nu> <20020219195556.GA6386@mcdonald.org.uk> <20020221063616.H16920@ch.lugn.nu> <20020221194921.GA717@mcdonald.org.uk> Message-ID: <20020221210154.GB14820@gnutls.org> On Thu, Feb 21, 2002 at 07:49:21PM +0000, Andrew McDonald wrote: Hello Andrew, > I'm Cc'ing gnutls-dev on this to get some more ideas. (See > http://bugs.debian.org/134584 for info). Main symptom is a > "FATAL_ALERT_RECEIVED" - mutt now suggests RC4/ARCFOUR so that I've just added a function which prints the actual alert... see gnutls_alert_str() and gnutls_alert_get_last(). This will help produce a more helpful output in the next versions. A prerelease will be available this weekend. > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From cosis at lysator.liu.se Fri Feb 22 10:31:02 2002 From: cosis at lysator.liu.se (Martin Samuelsson) Date: Fri Feb 22 10:31:02 2002 Subject: [gnutls-dev] Re: Bug#134584: noch ein gnutls problem In-Reply-To: <20020221194921.GA717@mcdonald.org.uk>; from andrew@mcdonald.org.uk on Thu, Feb 21, 2002 at 07:49:21PM +0000 References: <20020218155552.M1104@ch.lugn.nu> <20020218190356.GA640@mcdonald.org.uk> <20020218233422.C4360@ch.lugn.nu> <20020219195556.GA6386@mcdonald.org.uk> <20020221063616.H16920@ch.lugn.nu> <20020221194921.GA717@mcdonald.org.uk> Message-ID: <20020221224258.W16920@ch.lugn.nu> On Thu, Feb 21, 2002 at 07:49:21PM +0000, Andrew McDonald wrote: > I thought the OpenSSL s_client connection might have shown whether it > was using RSA or DSS, but didn't. k. openssl x509 -text < cert bla bla bla Signature Algorithm: md5WithRSAEncryption bla bla blah Public Key Algorithm: rsaEncryption blah bla Signature Algorithm: md5WithRSAEncryption bla blah bla nothing about dss as far as i can tell. > Recompiling gnutls with some of the DEBUGs in lib/gnutls_int.h #defined > will print out lots of information. I think WRITE_DEBUG is probably the > main one of interest. WRITE_DEBUG defined and dpkg-buildpackage is running. From andrew at mcdonald.org.uk Sun Feb 24 16:55:02 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Sun Feb 24 16:55:02 2002 Subject: [gnutls-dev] Minor gnutls CVS fixes Message-ID: <20020224155049.GA6114@mcdonald.org.uk> A couple of minor fixes. In gnutls.h.in.in the prototype for gnutls_record_send is missing a 'const' in the second parameter, should be: -X- ssize_t gnutls_record_send( GNUTLS_STATE state, const void *data, size_t sizeofdata); -X- as it is in gnutls_record.c Also, configure seems to fail in src/openpgp since it hasn't got anything to create a makefile from. As in src/x509, a one line Makefile.am would probably do, containing: -X- EXTRA_DIST = cli_pub.asc cli_ring.gpg cli_sec.asc pub.asc sec.asc -X- Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nmav at gnutls.org Sun Feb 24 18:47:02 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun Feb 24 18:47:02 2002 Subject: [gnutls-dev] gnutls 0.3.90 Message-ID: <20020224174446.GB12650@gnutls.org> I've just released gnutls 0.3.90, which is a prerelease of 0.4.0. Changes since 0.3.5: - Handshake messages are not kept in memory any more. Now we use less memory during a handshake - Added support for certificates with DSA parameters - Added DHE_DSS cipher suites - Key exchange methods changed so they do not depend on the certificate type. Added certificate type negotiation TLS extension. - Added openpgp key support (EXPERIMENTAL) - Improved Diffie Hellman key exchange support. - Bug fixes in the RSA key exchange. - Added check for the requested TLS extensions - TLS extensions now use a 16 bit type field. - Added a minimal string library to assist in ASN.1 parsing - Changes in ASN.1 parser to work with the new bison - Added gnutls_x509_extract_subject_alt_name(), which deprecates gnutls_x509_extract_subject_dns_name() - gnutls_x509_set_trust_(file/mem) can now be called multiple times - gnutls_srp_server_set_cred_file() can now be called multiple times -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Sun Feb 24 19:02:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun Feb 24 19:02:01 2002 Subject: [gnutls-dev] gnutls 0.3.90 In-Reply-To: <20020224174446.GB12650@gnutls.org> References: <20020224174446.GB12650@gnutls.org> Message-ID: <20020224180004.GA24615@gnutls.org> On Sun, Feb 24, 2002 at 07:44:46PM +0200, Nikos Mavroyanopoulos wrote: > - Added openpgp key support (EXPERIMENTAL) If you want to help debugging, and improve this part of gnutls, the opencdk library is required. Use the following cvs commands to get it: cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gnutls login cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gnutls checkout opencdk (use the password "anoncvs" at the password prompt) ** ** Note that the openpgp support in gnutls and the opencdk library ** are not ready yet for real world use. In this release gnutls follows the draft-ietf-tls-openpgp-keys, instead of draft-ietf-tls-openpgp[0], due to the lack of flexibility in the latter, and the possible security issues with the use of key IDs. [0]. Used by some pgp products. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From simon+gnutls-dev at josefsson.org Sun Feb 24 19:31:02 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Sun Feb 24 19:31:02 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: <20020224174446.GB12650@gnutls.org> (Nikos Mavroyanopoulos's message of "Sun, 24 Feb 2002 19:44:46 +0200") References: <20020224174446.GB12650@gnutls.org> Message-ID: Nikos Mavroyanopoulos writes: > I've just released gnutls 0.3.90, which is a prerelease of 0.4.0. > Changes since 0.3.5: I haven't been able to compile CVS for awhile, probably due to the OpenPGP stuff. Do I need something else to get it to work? Maybe that should be mentioned in NEWS or README. [jas at localhost gnutls]$ make make all-recursive make[1]: Entering directory `/home/jas/src/gnutls' Making all in lib make[2]: Entering directory `/home/jas/src/gnutls/lib' ../src/asn1c pkix.asn pkix_asn1_tab.c make[2]: ../src/asn1c: Command not found make[2]: [pkix_asn1_tab.c] Error 127 (ignored) source='gnutls_openpgp.c' object='gnutls_openpgp.lo' libtool=yes \ depfile='.deps/gnutls_openpgp.Plo' tmpdepfile='.deps/gnutls_openpgp.TPlo' \ depmode=gcc3 /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -O0 -ggdb3 -Wall -Wpointer-arith -Wstrict-prototypes -pipe -c -o gnutls_openpgp.lo `test -f gnutls_openpgp.c || echo './'`gnutls_openpgp.c rm -f .libs/gnutls_openpgp.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -O0 -ggdb3 -Wall -Wpointer-arith -Wstrict-prototypes -pipe -c gnutls_openpgp.c -MT gnutls_openpgp.lo -MD -MP -MF .deps/gnutls_openpgp.TPlo -fPIC -DPIC -o .libs/gnutls_openpgp.lo gnutls_openpgp.c: In function `pkt_to_datum': gnutls_openpgp.c:271: warning: implicit declaration of function `cdk_iobuf_get_data' gnutls_openpgp.c:271: warning: assignment makes pointer from integer without a cast gnutls_openpgp.c: In function `iobuf_to_datum': gnutls_openpgp.c:324: warning: assignment makes pointer from integer without a cast gnutls_openpgp.c: In function `openpgp_sig_to_gnutls_cert': gnutls_openpgp.c:455: warning: assignment makes pointer from integer without a cast gnutls_openpgp.c: In function `gnutls_certificate_set_openpgp_key_file': gnutls_openpgp.c:805: warning: implicit declaration of function `cdk_iobuf_push_filter' gnutls_openpgp.c: In function `_gnutls_openpgp_get_key_trust': gnutls_openpgp.c:1081: warning: implicit declaration of function `cdk_trustdb_find_ownertrust' gnutls_openpgp.c:1089: `TRUST_FLAG_DISABLED' undeclared (first use in this function) gnutls_openpgp.c:1089: (Each undeclared identifier is reported only once gnutls_openpgp.c:1089: for each function it appears in.) gnutls_openpgp.c:1094: `TRUST_FLAG_REVOKED' undeclared (first use in this function) gnutls_openpgp.c:1096: `TRUST_EXPIRED' undeclared (first use in this function) gnutls_openpgp.c:1100: `TRUST_NEVER' undeclared (first use in this function) gnutls_openpgp.c:1104: `TRUST_UNKNOWN' undeclared (first use in this function) gnutls_openpgp.c:1105: `TRUST_UNDEFINED' undeclared (first use in this function) gnutls_openpgp.c:1106: `TRUST_MARGINAL' undeclared (first use in this function) gnutls_openpgp.c:1108: `TRUST_FULLY' undeclared (first use in this function) gnutls_openpgp.c:1109: `TRUST_ULTIMATE' undeclared (first use in this function) gnutls_openpgp.c:1101: warning: unreachable code at beginning of switch statement gnutls_openpgp.c: In function `gnutls_openpgp_verify_key': gnutls_openpgp.c:1183: warning: implicit declaration of function `cdk_userid_create_hash' gnutls_openpgp.c: In function `gnutls_certificate_set_openpgp_keyring_mem': gnutls_openpgp.c:1399: warning: assignment makes pointer from integer without a cast gnutls_openpgp.c: In function `gnutls_openpgp_recv_key': gnutls_openpgp.c:1478: warning: implicit declaration of function `cdk_iobuf_expand' gnutls_openpgp.c:1496: warning: assignment makes pointer from integer without a cast gnutls_openpgp.c: At top level: gnutls_openpgp.c:340: warning: `openpgp_pkt_to_sig' defined but not used make[2]: *** [gnutls_openpgp.lo] Error 1 make[2]: Leaving directory `/home/jas/src/gnutls/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jas/src/gnutls' make: *** [all] Error 2 [jas at localhost gnutls]$ From simon+gnutls-dev at josefsson.org Sun Feb 24 19:48:01 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Sun Feb 24 19:48:01 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: <20020224180004.GA24615@gnutls.org> (Nikos Mavroyanopoulos's message of "Sun, 24 Feb 2002 20:00:04 +0200") References: <20020224174446.GB12650@gnutls.org> <20020224180004.GA24615@gnutls.org> Message-ID: Nikos Mavroyanopoulos writes: > On Sun, Feb 24, 2002 at 07:44:46PM +0200, Nikos Mavroyanopoulos wrote: > >> - Added openpgp key support (EXPERIMENTAL) > If you want to help debugging, and improve this part of gnutls, > the opencdk library is required. > > Use the following cvs commands to get it: > cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gnutls login > cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gnutls checkout opencdk It doesn't seem to compile. RedHat 7.2 on i386. [jas at localhost opencdk]$ make make all-recursive make[1]: Entering directory `/home/jas/src/opencdk' Making all in src make[2]: Entering directory `/home/jas/src/opencdk/src' /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libopencdk.la -rpath /usr/local/lib -version-info @OPENCDK_LT_CURRENT@:@OPENCDK_LT_AGE@:@OPENCDK_LT_REVISION@ logging.lo new-packet.lo read-packet.lo write-packet.lo error.lo iobuf.lo memory.lo sexp-data.lo pkverify.lo armor.lo key.lo sig-check.lo pksign.lo keydb.lo strgutil.lo pkclist.lo seskey.lo pk.lo seckey.lo misc.lo keyid.lo pkencrypt.lo trustdb.lo -L/usr/local/lib -lgcrypt libtool: link: CURRENT `@OPENCDK_LT_CURRENT@' is not a nonnegative integer libtool: link: `@OPENCDK_LT_CURRENT@:@OPENCDK_LT_AGE@:@OPENCDK_LT_REVISION@' is not valid version information make[2]: *** [libopencdk.la] Error 1 make[2]: Leaving directory `/home/jas/src/opencdk/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jas/src/opencdk' make: *** [all] Error 2 [jas at localhost opencdk]$ From ts at winpt.org Sun Feb 24 19:59:01 2002 From: ts at winpt.org (Timo Schulz) Date: Sun Feb 24 19:59:01 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 Message-ID: <20020224190354.GA9996@daredevil.joesixpack.net> On Sun Feb 24 2002; 19:46, Simon Josefsson wrote: > It doesn't seem to compile. RedHat 7.2 on i386. IIRC Nikos had the same problem and it was caused because he used an older version of autoconf. With autoconf 2.52/2.50 it should work. Timo From nmav at gnutls.org Sun Feb 24 20:12:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun Feb 24 20:12:01 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: References: <20020224174446.GB12650@gnutls.org> Message-ID: <20020224191010.GB688@gnutls.org> On Sun, Feb 24, 2002 at 07:29:09PM +0100, Simon Josefsson wrote: > > I've just released gnutls 0.3.90, which is a prerelease of 0.4.0. > > Changes since 0.3.5: > I haven't been able to compile CVS for awhile, probably due to the > OpenPGP stuff. Do I need something else to get it to work? Maybe > that should be mentioned in NEWS or README. The cvs may have been unusable for some time, because a lot of parallel changes occured. > Making all in lib > make[2]: Entering directory `/home/jas/src/gnutls/lib' > ../src/asn1c pkix.asn pkix_asn1_tab.c This file (pkix_asn1_tab.c) is included in the cvs. The makefile shouldn't try to create it. (try touching them) > source='gnutls_openpgp.c' object='gnutls_openpgp.lo' libtool=yes \ > depfile='.deps/gnutls_openpgp.Plo' tmpdepfile='.deps/gnutls_openpgp.TPlo' \ > depmode=gcc3 /bin/sh ../depcomp \ > /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -O0 -ggdb3 -Wall -Wpointer-arith -Wstrict-prototypes -pipe -c -o gnutls_openpgp.lo `test -f gnutls_openpgp.c || echo './'`gnutls_openpgp.c > rm -f .libs/gnutls_openpgp.lo > gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -O0 -ggdb3 -Wall -Wpointer-arith -Wstrict-prototypes -pipe -c gnutls_openpgp.c -MT gnutls_openpgp.lo -MD -MP -MF .deps/gnutls_openpgp.TPlo -fPIC -DPIC -o .libs/gnutls_openpgp.lo > gnutls_openpgp.c: In function `pkt_to_datum': > gnutls_openpgp.c:271: warning: implicit declaration of function `cdk_iobuf_get_data' > gnutls_openpgp.c:271: warning: assignment makes pointer from integer without a cast This is like you didn't install opencdk (or an older version is present). If you don't want opencdk support remove libopencdk library or comment HAVE_LIBOPENCDK in config.h. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Sun Feb 24 20:15:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun Feb 24 20:15:01 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: <20020224190354.GA9996@daredevil.joesixpack.net> References: <20020224190354.GA9996@daredevil.joesixpack.net> Message-ID: <20020224191250.GC688@gnutls.org> On Sun, Feb 24, 2002 at 08:03:54PM +0100, Timo Schulz wrote: > > It doesn't seem to compile. RedHat 7.2 on i386. > IIRC Nikos had the same problem and it was caused because he > used an older version of autoconf. With autoconf 2.52/2.50 it should work. It didn't and I couldn't figure out why it works for you :) Now, I edit the Makefile manually and add the version numbers by hand. A solution might be to use AC_SUBST() in configure.in to export the version values. > Timo -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From ts at winpt.org Sun Feb 24 20:23:02 2002 From: ts at winpt.org (Timo Schulz) Date: Sun Feb 24 20:23:02 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: <20020224191250.GC688@gnutls.org> References: <20020224190354.GA9996@daredevil.joesixpack.net> <20020224191250.GC688@gnutls.org> Message-ID: <20020224192806.GA10932@daredevil.joesixpack.net> On Sun Feb 24 2002; 21:12, Nikos Mavroyanopoulos wrote: > A solution might be to use AC_SUBST() in configure.in to > export the version values. Now I definitely think that the configure.in was not updated in the CVS. My local configure.in contains the AC_SUBST() commands: AC_SUBST(OPENCDK_LT_CURRENT) AC_SUBST(OPENCDK_LT_AGE) AC_SUBST(OPENCDK_LT_REVISION) I will remove the file from the CVS and then I'll add it again. Timo From simon+gnutls-dev at josefsson.org Sun Feb 24 20:48:02 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Sun Feb 24 20:48:02 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: <20020224190354.GA9996@daredevil.joesixpack.net> (Timo Schulz's message of "Sun, 24 Feb 2002 20:03:54 +0100") References: <20020224190354.GA9996@daredevil.joesixpack.net> Message-ID: Timo Schulz writes: > On Sun Feb 24 2002; 19:46, Simon Josefsson wrote: > >> It doesn't seem to compile. RedHat 7.2 on i386. > > IIRC Nikos had the same problem and it was caused because he > used an older version of autoconf. With autoconf 2.52/2.50 it should work. I'm using autoconf 2.52. I noticed some changes in CVS and now everything compiles. Thanks. From twoaday at freakmail.de Mon Feb 25 10:44:01 2002 From: twoaday at freakmail.de (Timo Schulz) Date: Mon Feb 25 10:44:01 2002 Subject: [gnutls-dev] Re: gnutls 0.3.90 In-Reply-To: References: <20020224174446.GB12650@gnutls.org> <20020224180004.GA24615@gnutls.org> Message-ID: <20020224185848.GA9405@daredevil.joesixpack.net> On Sun Feb 24 2002; 19:46, Simon Josefsson wrote: > It doesn't seem to compile. RedHat 7.2 on i386. IIRC Nikos had the same problem and it was caused because he used an older version of autoconf. With autoconf 2.52/2.50 it should work. Timo From nmav at gnutls.org Tue Feb 26 20:13:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Feb 26 20:13:01 2002 Subject: [gnutls-dev] https server Message-ID: <20020226191022.GA28890@gnutls.org> I've installed a non blocking https server in https://www.gnutls.org:5555/ This uses gnutls 0.3.90 compiled with profiling enabled, so I collect some statistics. Thus don't hesitate to visit it at any time with your favorite browser. The non blocking server was created by Paul Sheer. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Wed Feb 27 21:36:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Feb 27 21:36:01 2002 Subject: [gnutls-dev] tls_test Message-ID: <20020227202920.GA22742@gnutls.org> I've added in the cvs' src/ directory a test program which checks servers for several parameters (few at the moment). This helped me identify some problems with several implementations. Ie. www.verisign.com seem to work fine if we don't add any extension in the Client Hello. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From simon+gnutls-dev at josefsson.org Thu Feb 28 22:42:02 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Thu Feb 28 22:42:02 2002 Subject: [gnutls-dev] Feature request: standalone binary Message-ID: The OpenSSL "openssl s_client" is useful for interactive use from the command line, it would be nice to have this functionality in GNUTLS as well. What do you think? Richard Stallman writes: >> GNUTLS is a library, OpenSSL is both a library and an application. >> William's ssl.el invokes the binary. This is a inflexible method, it >> is complicated to find out what algorithms chosed during the TLS >> handshake, and generally difficult to do anything interactive during >> the TLS handshake. >> >> I see why that method is not as flexible. But it is nonetheless a >> useful alternative. If OpenSSL can do it, why can't we do it? > > I am sure "we" as in the GNUTLS developer can do it. Should I forward > this request to them? Please do. From nspring at cs.washington.edu Thu Feb 28 23:43:01 2002 From: nspring at cs.washington.edu (Neil Spring) Date: Thu Feb 28 23:43:01 2002 Subject: [gnutls-dev] Feature request: standalone binary In-Reply-To: References: Message-ID: <20020228224114.GB9676@cs.washington.edu> On Thu, Feb 28, 2002 at 10:39:11PM +0100, Simon Josefsson wrote: > The OpenSSL "openssl s_client" is useful for interactive use from the > command line, it would be nice to have this functionality in GNUTLS as > well. What do you think? how does that differ from gnutls/src/cli? -neil > Richard Stallman writes: > > >> GNUTLS is a library, OpenSSL is both a library and an application. > >> William's ssl.el invokes the binary. This is a inflexible method, it > >> is complicated to find out what algorithms chosed during the TLS > >> handshake, and generally difficult to do anything interactive during > >> the TLS handshake. > >> > >> I see why that method is not as flexible. But it is nonetheless a > >> useful alternative. If OpenSSL can do it, why can't we do it? > > > > I am sure "we" as in the GNUTLS developer can do it. Should I forward > > this request to them? > > Please do. > > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev