From nmav at gnutls.org Thu Sep 1 10:23:00 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 Sep 2011 10:23:00 +0200 Subject: gnutls 2.12.10 Message-ID: <4E5F40E4.5080306@gnutls.org> Hello, I've just released gnutls 2.12.10. This is a bugfix release on the 2.12.x branch. * Version 2.12.10 (released 2011-09-01) ** libgnutls: OpenPGP certificate type is not enabled by default. ** libgnutls: Corrected issue in gnutls_record_recv() triggered on encryption or compression error. ** libgnutls: Corrected parsing of XMPP subject alternative names. ** libgnutls: gnutls_certificate_set_x509_key() and gnutls_certificate_set_openpgp_key() operate as in 2.10.x and allow the release of the private key during the lifetime of the certificate structure. ** API and ABI modifications: GNUTLS_PRIVKEY_IMPORT_COPY: new gnutls_privkey_import() flag Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.10.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.10.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.10.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.10.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Thu Sep 1 10:42:13 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 Sep 2011 10:42:13 +0200 Subject: gnutls 3.0.2 Message-ID: <4E5F4565.6000803@gnutls.org> Hello, I've just released gnutls 3.0.2 It includes bug fixes and few feature additions. * Version 3.0.2 (released 2011-09-01) ** libgnutls: OpenPGP certificate type is not enabled by default. ** libgnutls: Added %NO_EXTENSIONS priority string. ** libgnutls: Corrected issue in gnutls_record_recv() triggered on encryption or compression error. ** libgnutls: Compatibility fixes in CPU ID detection for i386 and old GCC. ** gnutls-cli: Benchmark applications were incorporated with it. ** libgnutls: Corrected parsing of XMPP subject alternative names. ** libgnutls: Allow for out-of-order ChangeCipherSpec message in DTLS. ** libgnutls: gnutls_certificate_set_x509_key() and gnutls_certificate_set_openpgp_key() operate as in 2.10.x and allow the release of the private key during the lifetime of the certificate structure. ** API and ABI modifications: GNUTLS_PRIVKEY_IMPORT_COPY: new gnutls_privkey_import() flag Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.2.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.2.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.2.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.2.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.2.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.2.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From leguilly.thibaut at gmail.com Fri Sep 9 10:11:08 2011 From: leguilly.thibaut at gmail.com (Thibaut Le Guilly) Date: Fri, 9 Sep 2011 10:11:08 +0200 Subject: gnutls_handshake trouble with Chrome Message-ID: Hello everybody, I just wanted to report a strange error that I had when I was using libmicrohttpd with the SSL/TLS feature. In fact, the secure communication with my server are working well when using cUrl or Firefox to perform the request, but when using Chrome, the function gnutls_handshake fails. I don't know if this problem comes from GNUtls or Chrome, but I thought that it could be interesting to report this error. Best regards, -- Thibaut Le Guilly -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Sep 9 10:22:32 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 9 Sep 2011 10:22:32 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: References: Message-ID: Could it be related with the following? http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5335 On Fri, Sep 9, 2011 at 10:11 AM, Thibaut Le Guilly wrote: > Hello everybody, > I just wanted to report a strange error that I had when I was using > libmicrohttpd with the SSL/TLS feature. > In fact, the secure communication with my server are working well when using > cUrl or Firefox to perform the request, but when using Chrome, the function > gnutls_handshake fails. I don't know if this problem comes from GNUtls or > Chrome, but I thought that it could be interesting to report this error. > Best regards, > > -- > Thibaut Le Guilly > > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls > > From leguilly.thibaut at gmail.com Fri Sep 9 10:33:03 2011 From: leguilly.thibaut at gmail.com (Thibaut Le Guilly) Date: Fri, 9 Sep 2011 10:33:03 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: References: Message-ID: Hello Nikos, I don't think that it is the same issue, because I am still able to connect to the server, and that this issue is only happening with Chrome. I tried with several versions of GNUtls (until the 2.10.3 because I have issues configuring nettle with my x64 architecture). Here is the thread that I posted on the libmicrohttpd mailing list, the problem I encountered is better described : https://lists.gnu.org/archive/html/libmicrohttpd/2011-09/msg00003.html. Thanks for your help, Best regards, On Fri, Sep 9, 2011 at 10:22 AM, Nikos Mavrogiannopoulos wrote: > Could it be related with the following? > http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5335 > > On Fri, Sep 9, 2011 at 10:11 AM, Thibaut Le Guilly > wrote: > > Hello everybody, > > I just wanted to report a strange error that I had when I was using > > libmicrohttpd with the SSL/TLS feature. > > In fact, the secure communication with my server are working well when > using > > cUrl or Firefox to perform the request, but when using Chrome, the > function > > gnutls_handshake fails. I don't know if this problem comes from GNUtls or > > Chrome, but I thought that it could be interesting to report this error. > > Best regards, > > > > -- > > Thibaut Le Guilly > > > > > > > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > https://lists.gnu.org/mailman/listinfo/help-gnutls > > > > -- Thibaut Le Guilly -------------- next part -------------- An HTML attachment was scrubbed... URL: From leguilly.thibaut at gmail.com Fri Sep 9 11:40:22 2011 From: leguilly.thibaut at gmail.com (Thibaut Le Guilly) Date: Fri, 9 Sep 2011 11:40:22 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: References: Message-ID: Sorry the attachement did'nt work the first time! On Fri, Sep 9, 2011 at 11:24 AM, Thibaut Le Guilly < leguilly.thibaut at gmail.com> wrote: > Hello, > > I did a Wireshark analyze to compare the behaviour of Chrome vs. Firefox > and cUrl, and Chrome is doing some weird things, like re-sending a "client > hello" after the "server hello done", instead of sending the client key. I > attached the wireshark files, may be it can help you determine if the > problem is Chrome and not GNUtls? > > Best regards, > > > On Fri, Sep 9, 2011 at 10:33 AM, Thibaut Le Guilly < > leguilly.thibaut at gmail.com> wrote: > >> Hello Nikos, >> >> I don't think that it is the same issue, because I am still able to >> connect to the server, and that this issue is only happening with Chrome. I >> tried with several versions of GNUtls (until the 2.10.3 because I have >> issues configuring nettle with my x64 architecture). Here is the thread that >> I posted on the libmicrohttpd mailing list, the problem I encountered is >> better described : >> https://lists.gnu.org/archive/html/libmicrohttpd/2011-09/msg00003.html. >> >> Thanks for your help, >> >> Best regards, >> >> >> On Fri, Sep 9, 2011 at 10:22 AM, Nikos Mavrogiannopoulos > > wrote: >> >>> Could it be related with the following? >>> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5335 >>> >>> On Fri, Sep 9, 2011 at 10:11 AM, Thibaut Le Guilly >>> wrote: >>> > Hello everybody, >>> > I just wanted to report a strange error that I had when I was using >>> > libmicrohttpd with the SSL/TLS feature. >>> > In fact, the secure communication with my server are working well when >>> using >>> > cUrl or Firefox to perform the request, but when using Chrome, the >>> function >>> > gnutls_handshake fails. I don't know if this problem comes from GNUtls >>> or >>> > Chrome, but I thought that it could be interesting to report this >>> error. >>> > Best regards, >>> > >>> > -- >>> > Thibaut Le Guilly >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Help-gnutls mailing list >>> > Help-gnutls at gnu.org >>> > https://lists.gnu.org/mailman/listinfo/help-gnutls >>> > >>> > >> >> >> -- >> Thibaut Le Guilly >> >> >> >> > > > -- > Thibaut Le Guilly > Research Assistant at Aalborg University > Embedded System Engineer (ECE Paris) > Software System Engineer (Aalborg University) > > > -- Thibaut Le Guilly Research Assistant at Aalborg University Embedded System Engineer (ECE Paris) Software System Engineer (Aalborg University) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome Type: application/octet-stream Size: 14871 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: curl Type: application/octet-stream Size: 3902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox Type: application/octet-stream Size: 4227 bytes Desc: not available URL: From leguilly.thibaut at gmail.com Fri Sep 9 11:24:45 2011 From: leguilly.thibaut at gmail.com (Thibaut Le Guilly) Date: Fri, 9 Sep 2011 11:24:45 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: References: Message-ID: Hello, I did a Wireshark analyze to compare the behaviour of Chrome vs. Firefox and cUrl, and Chrome is doing some weird things, like re-sending a "client hello" after the "server hello done", instead of sending the client key. I attached the wireshark files, may be it can help you determine if the problem is Chrome and not GNUtls? Best regards, On Fri, Sep 9, 2011 at 10:33 AM, Thibaut Le Guilly < leguilly.thibaut at gmail.com> wrote: > Hello Nikos, > > I don't think that it is the same issue, because I am still able to connect > to the server, and that this issue is only happening with Chrome. I tried > with several versions of GNUtls (until the 2.10.3 because I have issues > configuring nettle with my x64 architecture). Here is the thread that I > posted on the libmicrohttpd mailing list, the problem I encountered is > better described : > https://lists.gnu.org/archive/html/libmicrohttpd/2011-09/msg00003.html. > > Thanks for your help, > > Best regards, > > > On Fri, Sep 9, 2011 at 10:22 AM, Nikos Mavrogiannopoulos wrote: > >> Could it be related with the following? >> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5335 >> >> On Fri, Sep 9, 2011 at 10:11 AM, Thibaut Le Guilly >> wrote: >> > Hello everybody, >> > I just wanted to report a strange error that I had when I was using >> > libmicrohttpd with the SSL/TLS feature. >> > In fact, the secure communication with my server are working well when >> using >> > cUrl or Firefox to perform the request, but when using Chrome, the >> function >> > gnutls_handshake fails. I don't know if this problem comes from GNUtls >> or >> > Chrome, but I thought that it could be interesting to report this error. >> > Best regards, >> > >> > -- >> > Thibaut Le Guilly >> > >> > >> > >> > >> > _______________________________________________ >> > Help-gnutls mailing list >> > Help-gnutls at gnu.org >> > https://lists.gnu.org/mailman/listinfo/help-gnutls >> > >> > > > > -- > Thibaut Le Guilly > > > > -- Thibaut Le Guilly Research Assistant at Aalborg University Embedded System Engineer (ECE Paris) Software System Engineer (Aalborg University) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Sep 9 17:30:45 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 09 Sep 2011 17:30:45 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: References: Message-ID: <4E6A3125.4010700@gnutls.org> On 09/09/2011 11:24 AM, Thibaut Le Guilly wrote: > Hello, > > I did a Wireshark analyze to compare the behaviour of Chrome vs. Firefox and > cUrl, and Chrome is doing some weird things, like re-sending a "client > hello" after the "server hello done", instead of sending the client key. I > attached the wireshark files, may be it can help you determine if the > problem is Chrome and not GNUtls? Which version of chrome and gnutls do you use? I've tested gnutls-serv (in gnutls 3.0.2) with chromium 13.0 and it seems they are able to communicate. I notice though that chromium makes multiple connections to the server and some of them fail. This looks like some kind of probing of the server to discover its capabilities, but a chromium developer might be more helpful. Do you actually have issues with chromium displaying the correct content? regards, Nikos From nmav at gnutls.org Sat Sep 10 12:42:19 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Sep 2011 12:42:19 +0200 Subject: dropping export ciphersuites Message-ID: <4E6B3F0B.5040905@gnutls.org> Hello, I'm thinking into dropping completely the RSA-EXPORT ciphersuites. These are deliberately weak ciphersuites intended to be used in US-export products in the 90's. Today they serve no purpose. Can somebody come up with any reasons for not removing them? regards, Nikos From neuromancer at dash.za.net Sun Sep 11 06:19:30 2011 From: neuromancer at dash.za.net (Dash Shendy) Date: Sun, 11 Sep 2011 06:19:30 +0200 Subject: dropping export ciphersuites In-Reply-To: References: Message-ID: <4E6C36D2.6050503@dash.za.net> Hi Nikos, I think the only Browser that uses the Export Ciphersuits is IE6, it is also the only browser that still uses (the now obsolete) SSL version 2.0 protocol. Looking at: http://www.w3schools.com/browsers/browsers_explorer.asp Doesn't seem like a lot of people are still using it, and besides if they are they should really upgrade! I think removing support of the Export Ciphersuits is a good idea. Ciao, Dash Shendy http://dash.za.net/?smtpsig gtalk: dash.za.net at gmail.com skype: dashula2006 mopho: (+27) 72 23 75 199 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1F109B38.asc Type: application/pgp-keys Size: 1887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From leguilly.thibaut at gmail.com Mon Sep 12 09:32:48 2011 From: leguilly.thibaut at gmail.com (Thibaut Le Guilly) Date: Mon, 12 Sep 2011 09:32:48 +0200 Subject: gnutls_handshake trouble with Chrome In-Reply-To: <4E6A3125.4010700@gnutls.org> References: <4E6A3125.4010700@gnutls.org> Message-ID: Hello, I am using gnutls 2.8.6 and chromium 13.0, and they are in fact able to communicate, but I was worrying about where did this issue was comming from. I will try to find some information about what Chrome is actually doing, and let you know if I find anything. Thank you for your time and your help, Best regards, On Fri, Sep 9, 2011 at 5:30 PM, Nikos Mavrogiannopoulos wrote: > On 09/09/2011 11:24 AM, Thibaut Le Guilly wrote: > >> Hello, >> >> I did a Wireshark analyze to compare the behaviour of Chrome vs. Firefox >> and >> cUrl, and Chrome is doing some weird things, like re-sending a "client >> hello" after the "server hello done", instead of sending the client key. I >> attached the wireshark files, may be it can help you determine if the >> problem is Chrome and not GNUtls? >> > > Which version of chrome and gnutls do you use? I've tested gnutls-serv (in > gnutls 3.0.2) with chromium 13.0 and it seems they are able to communicate. > I notice though that chromium makes multiple connections to the server and > some of them fail. This looks like some kind of probing of the server to > discover its capabilities, but a chromium developer might be more helpful. > Do you actually have issues with chromium displaying the correct content? > > regards, > Nikos > > -- Thibaut Le Guilly -------------- next part -------------- An HTML attachment was scrubbed... URL: From steamx.cn at gmail.com Thu Sep 15 10:42:57 2011 From: steamx.cn at gmail.com (steamx) Date: Thu, 15 Sep 2011 16:42:57 +0800 Subject: gnutls 2.10.1 doest't compile using MinGW Message-ID: Hi all, I am trying to get gnutls-2.10.1 compiled on Windows XP SP2 with mingw (Gcc 4.5.2 + Msys 1.0.11). zlib1.2.3,libgpg-error1.8,libgcrypt 1.4.6,and libtasn1-2.7 all are compiled success. static version of gnutls-2.10.1 also compiled success,compiled steps are 1: ./configure --build=i686-pc-mingw32 --prefix=/mingw --enable-shared=no --enable-static=yes 2: make 3: make install but when i compiled shared version of gnutls-2.10.1,i got some error message after make. 1: ./configure --build=i686-pc-mingw32 --prefix=/mingw --enable-shared=yes --enable-static=no 2: make error message are here: libtool: link: g++ -shared -nostdlib c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../.. /../dllcrt2.o c:/mingw/bin/../lib/gcc/mingw32/4.5.2/crtbegin.o .libs/libgnutlsx x_la-gnutlsxx.o -L/mingw/lib -L/mingw/lib/.libs -Lc:/mingw/bin/../lib/gcc/ming w32/4.5.2 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.5.2/../. ./../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../.. /mingw/lib/ gcc/mingw32/4.5.2/libstdc++.dll.a -L/projetos/gcc/bld/452/build/mingw32/libstdc+ +-v3/src -L/projetos/gcc/bld/452/build/mingw32/libstdc++-v3/src/.libs -L/projeto s/gcc/bld/452/build/mingw32/winsup/mingw -L/projetos/gcc/bld/452/build/mingw32/w insup/w32api/lib -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lm svcrt c:/mingw/bin/../lib/gcc/mingw32/4.5.2/crtend.o -Wl,--version-script=./lib gnutlsxx.map -o .libs/libgnutlsxx-26.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgnutlsxx.dll.a Creating library file: .libs/libgnutlsxx.dll.a .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:881: undefined reference to `gnutls_strerror' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~psk_client_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:833: undefined reference t o `gnutls_psk_free_client_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~psk_server_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:798: undefined reference t o `gnutls_psk_free_server_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~srp_client_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:756: undefined reference t o `gnutls_srp_free_client_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~srp_server_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:744: undefined reference t o `gnutls_srp_free_server_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~anon_client_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:604: undefined reference t o `gnutls_anon_free_client_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~anon_server_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:581: undefined reference t o `gnutls_anon_free_server_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~certificate_credentials': $ \MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:556: undefined reference t o `gnutls_certificate_free_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `~session': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:32: undefined reference to `gnutls_deinit' .libs/libgnutlsxx_la-gnutlsxx.o: In function `session': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:27: undefined reference to `gnutls_init' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:37: undefined reference to `gnutls_bye' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:42: undefined reference to `gnutls_handshake' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:55: undefined reference to `gnutls_rehandshake' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:66: undefined reference to `gnutls_alert_send' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:71: undefined reference to `gnutls_alert_send_appropriate' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:116: undefined reference to `gnutls_record_send' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:121: undefined reference to `gnutls_record_recv' .libs/libgnutlsxx_la-gnutlsxx.o: In function `RETWRAP_NET': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:12: undefined reference to `gnutls_error_is_fatal' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:126: undefined reference to `gnutls_record_get_direction' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:137: undefined reference to `gnutls_record_set_max_size' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:152: undefined reference to `gnutls_prf' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:160: undefined reference to `gnutls_prf_raw' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:166: undefined reference to `gnutls_cipher_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:171: undefined reference to `gnutls_mac_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:176: undefined reference to `gnutls_compression_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:181: undefined reference to `gnutls_kx_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:186: undefined reference to `gnutls_protocol_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:191: undefined reference to `gnutls_certificate_type_set_priority' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:199: undefined reference to `gnutls_priority_set_direct' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:204: undefined reference to `gnutls_priority_set' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:214: undefined reference to `gnutls_session_set_data' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:219: undefined reference to `gnutls_session_get_data' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:224: undefined reference to `gnutls_session_get_data2' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:230: undefined reference to `gnutls_session_get_id' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:235: undefined reference to `gnutls_session_is_resumed' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:260: undefined reference to `gnutls_certificate_get_peers' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:271: undefined reference to `gnutls_certificate_get_ours' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:288: undefined reference to `gnutls_certificate_verify_peers2' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:304: undefined reference to `gnutls_server_name_set' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:309: undefined reference to `gnutls_certificate_client_get_request_status' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:317: undefined reference to `gnutls_server_name_get' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:380: undefined reference to `gnutls_db_set_ptr' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:381: undefined reference to `gnutls_db_set_store_function' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:382: undefined reference to `gnutls_db_set_retrieve_function' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:398: undefined reference to `gnutls_db_check_entry' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:417: undefined reference to `gnutls_credentials_set' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:497: undefined reference to `gnutls_dh_get_secret_bits' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:502: undefined reference to `gnutls_dh_get_peers_public_bits' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:507: undefined reference to `gnutls_dh_get_prime_bits' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:513: undefined reference to `gnutls_dh_get_group' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:518: undefined reference to `gnutls_dh_get_pubkey' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:524: undefined reference to `gnutls_rsa_export_get_pubkey' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx x.cpp:529: undefined reference to `gnutls_rsa_export_get_modulus_bits' .libs/libgnutlsxx_la-gnutlsxx.o: In function `certificate_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:562: undefined reference t o `gnutls_certificate_allocate_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `anon_server_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:575: undefined reference t o `gnutls_anon_allocate_server_credentials' .libs/libgnutlsxx_la-gnutlsxx.o: In function `anon_client_credentials': C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsxx.cpp:598: undefined reference t o `gnutls_anon_allocate_client_credentials' .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx [libgnutlsxx.la] Error 3 make[3]: *** [all-recursive] Interrupt make[2]: *** [all] Interrupt make[1]: *** [all-recursive] Interrupt make: *** [all] Interrupt Any suggestion? Does gnutls compile on MinGW? Any help will be appreciated. Thanks steamx -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at cchtml.com Thu Sep 15 15:20:05 2011 From: mike at cchtml.com (Michael Cronenworth) Date: Thu, 15 Sep 2011 08:20:05 -0500 Subject: gnutls 2.10.1 doest't compile using MinGW In-Reply-To: References: Message-ID: <4E71FB85.7040009@cchtml.com> On 09/15/2011 03:42 AM, steamx wrote: > Any suggestion? Does gnutls compile on MinGW? Any help will be > appreciated. Yes, it certainly compiles on MinGW. There must be something wrong with your MinGW environment. Feel free to study the building done by Fedora or SuSE for their cross-compiling packages. From nmav at gnutls.org Sun Sep 18 23:27:44 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 18 Sep 2011 23:27:44 +0200 Subject: gnutls 2.12.11 Message-ID: <4E766250.1050205@gnutls.org> Hello, I've just released gnutls 2.12.11. This is a bugfix release on the 2.12.x branch. Version 2.12.11 (released 2011-09-18) ** libgnutls: Memory leak fixes in credentials private key deinitialization. Reported by Dan Winship. ** libgnutls: Allow CA importing of 0 certificates to succeed. Reported by Jonathan Nieder in . ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.11.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.11.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.11.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.11.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Sep 18 23:56:04 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 18 Sep 2011 23:56:04 +0200 Subject: gnutls 3.0.3 Message-ID: <4E7668F4.1040108@gnutls.org> Hello, I've just released gnutls 3.0.3. It includes bug fixes and few feature additions. * Version 3.0.3 (released 2011-09-18) ** libgnutls: Added gnutls_record_get_discarded() to return the number of discarded records in a DTLS session. ** libgnutls: All functions related to RSA-EXPORT were deprecated. Support for RSA-EXPORT ciphersuites will be ceased in future versions. ** libgnutls: Memory leak fixes in credentials private key deinitialization. Reported by Dan Winship. ** libgnutls: Memory leak fixes in ECC ciphersuites. ** libgnutls: Do not send an empty extension structure in server hello. This affected old implementations that do not support extensions. Reported by J. Cameijo Cerdeira. ** libgnutls: Allow CA importing of 0 certificates to succeed. Reported by Jonathan Nieder in . ** libgnutls: Added support for VIA padlock AES optimizations. (disabled by default) ** libgnutls: Added support for elliptic curves in PKCS #11. ** libgnutls: Added gnutls_pkcs11_privkey_generate() to allow generating a key in a token. ** p11tool: Added generate-rsa, generate-dsa and generate-ecc options to allow generating private keys in the token. ** libgnutls: gnutls_transport_set_lowat dummy macro was removed. ** API and ABI modifications: gnutls_pkcs11_privkey_generate: Added gnutls_pubkey_import_ecc_raw: Added gnutls_pubkey_import_ecc_x962: Added gnutls_pubkey_get_pk_ecc_x962: Added gnutls_record_get_discarded: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.3.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.3.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.3.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.3.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.3.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.3.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From derleader at abv.bg Mon Sep 19 21:16:42 2011 From: derleader at abv.bg (derleader mail) Date: Mon, 19 Sep 2011 22:16:42 +0300 (EEST) Subject: GnuTLS vs OpenSSL Benchmarks Message-ID: <633742790.6880.1316459802923.JavaMail.apache@mail22.abv.bg> Hi, I'm interested are there resent benchmark tests between GnuTLS and OpenSSL? How bought libraries handle high load? Regards Peter ----------------------------------------------------------------- ?? ?? ???? ????? ?? ??????? ?? ??????????? http://www.pariteni.bg/?tid=20&oid=840 -------------- next part -------------- An HTML attachment was scrubbed... URL: From derleader at abv.bg Tue Sep 20 21:45:29 2011 From: derleader at abv.bg (derleader mail) Date: Tue, 20 Sep 2011 22:45:29 +0300 (EEST) Subject: Compile GnuTLS on Centos 6 Message-ID: <247664323.129710.1316547929413.JavaMail.apache@mail23.abv.bg> Hi, I cannot compile GnuTLS 3.03 on Centos 6. I install the latest version of nettle but still whet I try to compile GnuTLS this error appears: checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking whether to use nettle... yes checking for libnettle... no configure: error: *** *** Libnettle 2.2 was not found. I install Nettle 2.2 but the problem is the same. Any idea how to fix it? Regards Peter ----------------------------------------------------------------- 100 ?? ?????. ???-?????? ???????????. Tempobet.com http://bg.tempobet.com/affiliates/3208311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gallowaymd at ornl.gov Tue Sep 20 21:51:56 2011 From: gallowaymd at ornl.gov (Michael Galloway) Date: Tue, 20 Sep 2011 15:51:56 -0400 Subject: Compile GnuTLS on Centos 6 In-Reply-To: <247664323.129710.1316547929413.JavaMail.apache@mail23.abv.bg> References: <247664323.129710.1316547929413.JavaMail.apache@mail23.abv.bg> Message-ID: <4E78EEDC.1050300@ornl.gov> you have both the nettle and nettle-devel packages installed? ---- michael On 09/20/2011 03:45 PM, derleader mail wrote: > > Hi, > > I cannot compile GnuTLS 3.03 on Centos 6. I install the latest version of nettle but still whet I try to compile GnuTLS this error appears: > > checking for ld used by GCC... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for shared library run path origin... done > checking whether to use nettle... yes > checking for libnettle... no > configure: error: > > *** > > *** Libnettle 2.2 was not found. > > > > I install Nettle 2.2 but the problem is the same. > Any idea how to fix it? > > Regards > Peter > > > ----------------------------------------------------------------- > 100 ?? ?????. ???-?????? ???????????. Tempobet.com > hxxp://bg.tempobet.com/affiliates/3208311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Sep 21 10:25:28 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Sep 2011 10:25:28 +0200 Subject: alleged attack on TLS In-Reply-To: References: Message-ID: There is hype on an alleged attack on the TLS protocol. The authors of the alleged attack took an irresponsible stance by talking to media about an alleged attack without providing any details. I'm not providing any links to them because I don't want to encourage this behavior by providing more publicity. From information gathered here and there it seems the attack is a variation or an implementation of the Bard attack [0]. If you are using GnuTLS and want to prevent such attacks you can do the following: * Make sure that TLS 1.1 or TLS 1.2 are not disabled (gnutls enables them by default, but because of compatibility issues with broken peers they are often disabled) This will ensure that if the peer supports those protocols the attack will not be applicable. If the peer does not support them you'll be vulnerable to Bard-type of attacks. If this is a problem for you then: * Disable SSL 3.0 and TLS 1.0 Datagram TLS 1.0 is not vulnerable to this attack. regards, Nikos [0]. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf From derleader at abv.bg Wed Sep 21 13:05:04 2011 From: derleader at abv.bg (derleader mail) Date: Wed, 21 Sep 2011 14:05:04 +0300 (EEST) Subject: compilation error Message-ID: <900347306.65546.1316603104832.JavaMail.apache@mail22.abv.bg> Hi, When I tried to compile GnuTLS on Ubuntu this error came up: CC version-etc.lo CC version-etc-fsf.lo CC asnprintf.lo CC frexp.lo CC frexpl.lo CC ftell.lo CC ftello.lo ftello.c: In function 'rpl_ftello': ftello.c:45: error: 'fp_' undeclared (first use in this function) ftello.c:45: error: (Each undeclared identifier is reported only once ftello.c:45: error: for each function it appears in.) ftello.c:45: error: '_IOWRT' undeclared (first use in this function) make[4]: *** [ftello.lo] Error 1 make[4]: Leaving directory `/home/rcbandit/Desktop/gnutls-3.0.3/gl' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/rcbandit/Desktop/gnutls-3.0.3/gl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rcbandit/Desktop/gnutls-3.0.3/gl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rcbandit/Desktop/gnutls-3.0.3' make: *** [all] Error 2 rcbandit at ubuntu:~/Desktop/gnutls-3.0.3$ Any idea how to fix it? Regards ----------------------------------------------------------------- 100 ?? ?????. ???-?????? ???????????. Tempobet.com http://bg.tempobet.com/affiliates/3208311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Sep 23 04:59:12 2011 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 23 Sep 2011 04:59:12 +0200 Subject: gnutls 2.10.1 doest't compile using MinGW In-Reply-To: (steamx's message of "Thu, 15 Sep 2011 16:42:57 +0800") References: Message-ID: <87y5xgx8u7.fsf@latte.josefsson.org> steamx writes: > Hi all, > I am trying to get gnutls-2.10.1 compiled on Windows XP SP2 with mingw (Gcc > 4.5.2 + Msys 1.0.11). > zlib1.2.3,libgpg-error1.8,libgcrypt 1.4.6,and libtasn1-2.7 all are compiled > success. > static version of gnutls-2.10.1 also compiled success,compiled steps are > 1: ./configure --build=i686-pc-mingw32 --prefix=/mingw --enable-shared=no > --enable-static=yes > 2: make > 3: make install > but when i compiled shared version of gnutls-2.10.1,i got some error message > after make. > 1: ./configure --build=i686-pc-mingw32 --prefix=/mingw --enable-shared=yes > --enable-static=no > Creating library file: .libs/libgnutlsxx.dll.a > .libs/libgnutlsxx_la-gnutlsxx.o:C:\MinGW\msys\1.0\home\gnutls-2.10.1\lib/gnutlsx > x.cpp:881: undefined reference to `gnutls_strerror' Do you really need the C++ library? Try --disable-cxx. There seems to be some issue building the GnuTLS C++ library with MinGW. /Simon From bortzmeyer at nic.fr Fri Sep 23 14:52:13 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Sep 2011 14:52:13 +0200 Subject: alleged attack on TLS In-Reply-To: References:

Message-ID: <20110923125213.GA18671@nic.fr> On Wed, Sep 21, 2011 at 10:25:28AM +0200, Nikos Mavrogiannopoulos wrote a message of 28 lines which said: > * Disable SSL 3.0 and TLS 1.0 So, with mod_gnutls, you suggest: GnuTLSPriorities NORMAL:!VERS-TLS1.0:!VERS-SSL3.0 ? From nmav at gnutls.org Fri Sep 23 16:30:11 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Sep 2011 16:30:11 +0200 Subject: alleged attack on TLS In-Reply-To: <20110923125213.GA18671@nic.fr> References:

<20110923125213.GA18671@nic.fr> Message-ID: <4E7C97F3.8000500@gnutls.org> On 09/23/2011 02:52 PM, Stephane Bortzmeyer wrote: > a message of 28 lines which said: >> * Disable SSL 3.0 and TLS 1.0 > So, with mod_gnutls, you suggest: > GnuTLSPriorities NORMAL:!VERS-TLS1.0:!VERS-SSL3.0 Indeed. From nmav at gnutls.org Fri Sep 23 21:37:48 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Sep 2011 21:37:48 +0200 Subject: alleged attack on TLS In-Reply-To: <20110923125213.GA18671@nic.fr> References:

<20110923125213.GA18671@nic.fr> Message-ID: <4E7CE00C.9030606@gnutls.org> On 09/23/2011 02:52 PM, Stephane Bortzmeyer wrote: >> * Disable SSL 3.0 and TLS 1.0 > So, with mod_gnutls, you suggest: > GnuTLSPriorities NORMAL:!VERS-TLS1.0:!VERS-SSL3.0 As I said this before this would enforce the secure modes and if cannot be negotiated will fail. An alternative approach would be to all the "NORMAL" priorities and if TLS1.0 or SSL3.0 are negotiated warn the peer with an application protocol message (i.e. in case of a web server with a special web page) and close the connection. regards, Nikos From mrsam at courier-mta.com Sat Sep 24 17:14:32 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 24 Sep 2011 11:14:32 -0400 Subject: Protocol for renewing CA certs Message-ID: A logistical question occured to me, while I was browsing through the code that verifies certificates. _gnutls_verify_certificate2() locates a certificate's signing CA by invoking find_issuer(), which searches the list of trusted CAs. The search simply compares each CA's entire DN against the certificate's issuer's DN. Once a matching DN is found, _gnutls_verify_certificate2() tries that CA cert, and if it doesn't work it does not look for any other DNs that match. When a particular's CA cert's expiration time approaches, naturally the CA would generate a new cert and begin signing new certificates using its new cert. But because there are still valid certificates signed by the expiring certs, both the old and the new certs must be on the trusted list, until the old cert expires. So, that means that the new cert must have a different DN? I originally thought that it's sufficient to generate a new cert with the same DN, and a new expiration, but this doesn't seem to be the case, and the new cert has to have a different DN, correct? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Sun Sep 25 18:03:27 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Sep 2011 18:03:27 +0200 Subject: Protocol for renewing CA certs In-Reply-To: References: Message-ID: <4E7F50CF.90000@gnutls.org> On 09/24/2011 05:14 PM, Sam Varshavchik wrote: > A logistical question occured to me, while I was browsing through the > code that verifies certificates. > > _gnutls_verify_certificate2() locates a certificate's signing CA by > invoking find_issuer(), which searches the list of trusted CAs. The > search simply compares each CA's entire DN against the certificate's > issuer's DN. > Once a matching DN is found, _gnutls_verify_certificate2() tries that CA > cert, and if it doesn't work it does not look for any other DNs that match. In gnutls 3.0.x _gnutls_verify_certificate2() will only check against the latest valid issuer. Check the find_issuer() function in the same file. > When a particular's CA cert's expiration time approaches, naturally the > CA would generate a new cert and begin signing new certificates using > its new cert. But because there are still valid certificates signed by > the expiring certs, both the old and the new certs must be on the > trusted list, until the old cert expires. > So, that means that the new cert must have a different DN? No. I'd expect it to have the same DN. regards, Nikos From mrsam at courier-mta.com Sun Sep 25 20:52:24 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 25 Sep 2011 14:52:24 -0400 Subject: Protocol for renewing CA certs References: <4E7F50CF.90000@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On 09/24/2011 05:14 PM, Sam Varshavchik wrote: >> A logistical question occured to me, while I was browsing through the >> code that verifies certificates. >> >> _gnutls_verify_certificate2() locates a certificate's signing CA by >> invoking find_issuer(), which searches the list of trusted CAs. The >> search simply compares each CA's entire DN against the certificate's >> issuer's DN. >> Once a matching DN is found, _gnutls_verify_certificate2() tries that CA >> cert, and if it doesn't work it does not look for any other DNs that match. > > In gnutls 3.0.x _gnutls_verify_certificate2() will only check against the > latest valid issuer. Check the find_issuer() function in the same file. I'll look it up, but I'm also trying to work this out in my head. It seems to me that it shouldn't be merely the latest valid issuer, but rather a strict match against the activation and expiration time range, so that a certificate should get checked against a CA cert whose activation/expiration time includes the certificate's expiration time. That's because new CA certs must be distributed in advance of the expiration of existing CA certs, so there would be a transition period where both certs are placed in trusted chains, and existing certs won't validate, of course, against the new cert. Additionally, for this to work, I think that the CAs must generate new certs whose activation time is specified to be exactly the expiration time of the expiring cert, and continue to sign certificates with the expiring cert up until it actually expires, then immediately switch to the new cert. I don't know if this is exactly what the CAs do, or whether they activate new CA certs in advance of the existing CA cert's expiration, and sign new certs using the new CA cert. If they do that, then it seems to me that even the logic of using just the latest CA cert wouldn't work, because both CA certs will overlap, and certs signed by the expiring CA cert won't validate against the new CA cert. Also, is it only the cert's activation time must fall within the activation/expiration time of the signing cert? Or that both activation and expiration time of a cert must fall within the signing cert's range? Because if clients validate the entire cert's activation/expiration range against the signing cert's range, CAs would be forced to generate new certs whose activation/expiration range overlaps with their expiring cert, so that certs signed by the expiring cert remain valid, and new certs would have to be signed by the new CA cert, since the new certs' expiration time would fall outside of the expiring CA cert's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Mon Sep 26 11:56:57 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Sep 2011 11:56:57 +0200 Subject: Protocol for renewing CA certs In-Reply-To: References: <4E7F50CF.90000@gnutls.org> Message-ID: On Sun, Sep 25, 2011 at 8:52 PM, Sam Varshavchik wrote: >> In gnutls 3.0.x _gnutls_verify_certificate2() will only check against the >> latest valid issuer. Check the find_issuer() function in the same file. > I'll look it up, but I'm also trying to work this out in my head. It seems > to me that it shouldn't be merely the latest valid issuer, but rather a > strict match against the activation and expiration time range, so that a > certificate should get checked against a CA cert whose activation/expiration > time includes the certificate's expiration time. That's because new CA certs > must be distributed in advance of the expiration of existing CA certs, so > there would be a transition period where both certs are placed in trusted > chains, and existing certs won't validate, of course, against the new cert. I don't understand why is that. If the latest valid CA is found (valid according to activation and expiration time) why wouldn't it be used, and check using a relative time to the certificate? Do you expect a new CA to change their private and public key pair? > I don't know if this is exactly what the CAs do, or whether they activate > new CA certs in advance of the existing CA cert's expiration, and sign new > certs using the new CA cert. If they do that, then it seems to me that even > the logic of using just the latest CA cert wouldn't work, because both CA > certs will overlap, and certs signed by the expiring CA cert won't validate > against the new CA cert. I suppose you assume that a new CA certificate would also replace the private and public key pair. I'd expect in that case for their DN to also be changed. Otherwise the DN would not be sufficient to determine the signer certificate. > Also, is it only the cert's activation time must fall within the > activation/expiration time of the signing cert? We don't do strict matching of that. We only make sure that both certificates are activated at the time of checking. According to PKIX the "basic" algorithm for certificate validation is that: http://tools.ietf.org/html/rfc5280#section-6.1 regards, Nikos From derleader at abv.bg Mon Sep 26 13:58:22 2011 From: derleader at abv.bg (derleader mail) Date: Mon, 26 Sep 2011 14:58:22 +0300 (EEST) Subject: GnuTLS examples Message-ID: <891696422.155727.1317038302078.JavaMail.apache@mail22.abv.bg> Hi, I compiled the GnuTLS 3.0.3 examples in /doc/examples directory. The problem is that when I try to start the examples ./ex-serv1 and ./ex-client1 on the same computer this error message appears: - connection from 127.0.0.1, port 39788 *** Handshake has failed (Could not negotiate a supported cipher suite.) Any idea where I'm wrong? Can you give me some information how to run the examples? Regards ----------------------------------------------------------------- 100 ?? ?????. ???-?????? ???????????. Tempobet.com http://bg.tempobet.com/affiliates/3208311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Sep 26 16:10:31 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Sep 2011 16:10:31 +0200 Subject: GnuTLS examples In-Reply-To: <891696422.155727.1317038302078.JavaMail.apache@mail22.abv.bg> References: <891696422.155727.1317038302078.JavaMail.apache@mail22.abv.bg> Message-ID: On Mon, Sep 26, 2011 at 1:58 PM, derleader mail wrote: > ?Hi, > ?? I compiled the GnuTLS 3.0.3 examples in /doc/examples directory. > The problem is that when I try to start the examples ./ex-serv1 and > ./ex-client1 on the same computer this error message appears: > - connection from 127.0.0.1, port 39788 > *** Handshake has failed (Could not negotiate a supported cipher suite.) > Any idea where I'm wrong? Can you give me some information how to run the > examples? Please read the documentation [0] first before using the examples. If you check the documentation of the two examples you mention you'll understand why they don't interoperate. [0]. http://www.gnu.org/software/gnutls/documentation.html regards, Nikos