From simon at josefsson.org Sun May 2 22:20:35 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 02 May 2010 22:20:35 +0200 Subject: [bug-gnutls] gnutls-2.8.6 build comments In-Reply-To: (Nelson H. F. Beebe's message of "Fri, 30 Apr 2010 08:33:30 -0600 (MDT)") References: Message-ID: <874oiq838s.fsf@mocca.josefsson.org> "Nelson H. F. Beebe" writes: > A build attempt for gnutls-2.8.6 fails on Red Hat 4 AMD64 for two > reasons: incorrect handling of libraries at configure time, and a C++ > error in the doc/examples/ex-cxx.cpp file. > > The library problem arises because the gnutls configure script erroneously > inserts explicit paths to shared libraries, instead of relying on the normal > shared library search mechanism, and the setting of LDFLAGS. > > On both Red Hat and OpenSuSE GNU/Linux on AMD64, the default world is a 64-bit > one, and 64-bit libraries go into /usr/lib64 and /usr/local/lib64. The /usr/lib > and /usr/local/lib directories are reserved for 32-bit libraries. Unfortunately, > the configure puts /usr/local/lib in front of shared library names. Can you post a config.log when that happens? I'd like to understand what part of configure.ac is responsible. > I was able to resolve that problem by temporarily renaming several shared > and static libraries in /usr/local/lib, but that was possible only because > the system on which I did that is a single-user machine over which I have > complete control; it would not be possible on most of our GNU/Linux systems > that are accessible to thousands of our users. Of course, that's never a good solution. > Recommendation: do not insert explicit directory paths for libraries, > but instead, use the LDFLAGS settings to guide the loader to their > proper location. You mean -R or -Wl,-rpath or similar? That is what should be happening, I think. > With the above changes, I was able to get most of the compilations to succeed, > but I'm stymied by a C++ compilation error in doc/examples/ex-cxx.cpp. I have > dozens of versions of the gcc family installed in my environment, and I tried > g++ (4.3.0 20070209), g++-4.3.4, g++-4.4.1, g++-4.5.0, and g++-4.6.0, each > time doing the build in a clean freshly-unpacked gnutls-2.8.6 directory. > > Here is an example of the failures that I see: > > libtool: link: g++-4.6 -g -O2 -Wl,-rpath -Wl,/usr/local/lib64 -o > ex-cxx ex-cxx.o -L/usr/local/lib64 ./.libs/libexamples.a > ../../lib/.libs/libgnutls.so > ../../libextra/.libs/libgnutls-extra.so > ../../gl/.libs/libgnu.a ../../lib/.libs/libgnutlsxx.so > -Wl,-rpath -Wl,/local/build/bare/gnutls-2.8.6/lib/.libs > -Wl,-rpath -Wl,/local/build/bare/gnutls-2.8.6/libextra/.libs > -Wl,-rpath -Wl,/usr/local/lib > > ex-cxx.o(.text+0xa9): In function `main': > > /usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/ostream:513: > undefined reference to `std::basic_ostream std::char_traits >& std::__ostream_insert std::char_traits >(std::basic_ostream std::char_traits >&, char const*, long)' > > ex-cxx.o(.text+0x135):/usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/ostream:513: > undefined reference to `std::basic_ostream std::char_traits >& std::__ostream_insert std::char_traits >(std::basic_ostream std::char_traits >&, char const*, long)' > > ex-cxx.o(.text+0x157):/usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/ostream:513: > undefined reference to `std::basic_ostream std::char_traits >& std::__ostream_insert std::char_traits >(std::basic_ostream std::char_traits >&, char const*, long)' > > ex-cxx.o(.text+0x25c): In function `main': > > /usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/locale_facets.h:868: > undefined reference to `std::ctype::_M_widen_init() > const' > > ex-cxx.o(.text+0x2bc): In function `main': > > /usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/basic_string.h:232: > undefined reference to `std::basic_string std::char_traits, std::allocator > >::_Rep::_S_empty_rep_storage' > > ex-cxx.o(.text+0x324):/usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/basic_string.h:232: > undefined reference to `std::basic_string std::char_traits, std::allocator > >::_Rep::_S_empty_rep_storage' > > ex-cxx.o(.text+0x344): In function `main': > > /usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/locale_facets.h:868: > undefined reference to `std::ctype::_M_widen_init() > const' > > ex-cxx.o(.text+0x364):/usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/locale_facets.h:868: > undefined reference to `std::ctype::_M_widen_init() > const' > > ex-cxx.o(.text+0x3c9): In function `main': > > /usr/local/ashare/x86_64-linux/gcc-4.6-20100416/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/basic_string.h:232: > undefined reference to `std::basic_string std::char_traits, std::allocator > >::_Rep::_S_empty_rep_storage' I don't recognize this and I don't have any suggestions on what to test. Are there any C++ experts out there who can answer this one? /Simon From simon at josefsson.org Mon May 3 15:58:23 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 May 2010 15:58:23 +0200 Subject: gnutls_safe_renegotiation_set? Message-ID: <87ljc12ikg.fsf@mocca.josefsson.org> The new gnutls_safe_renegotiation_set API doesn't seem to influence rehandshakes -- i.e., I cannot first handshake successfully with the extension, call the API with flag=0, and then do a rehandshake that does not use the extension. Is this intentional? See new self test tests/safe-renegotiation/srn2 to reproduce it. I expected that it would fail, but it doesn't. More generally, why do we need this API at all? Isn't the natural thing to use the priority strings to disable the extension? Same question about gnutls_safe_negotiation_set_initial. /Simon From nmav at gnutls.org Mon May 3 16:21:29 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 3 May 2010 16:21:29 +0200 Subject: gnutls_safe_renegotiation_set? In-Reply-To: <87ljc12ikg.fsf@mocca.josefsson.org> References: <87ljc12ikg.fsf@mocca.josefsson.org> Message-ID: On Mon, May 3, 2010 at 3:58 PM, Simon Josefsson wrote: > The new gnutls_safe_renegotiation_set API doesn't seem to influence > rehandshakes -- i.e., I cannot first handshake successfully with the > extension, call the API with flag=0, and then do a rehandshake that does > not use the extension. ?Is this intentional? Never thought of such usage of it. I see no reason to allow such behavior since it will only complicate code without offering new functionality or advantage. > More generally, why do we need this API at all? ?Isn't the natural thing > to use the priority strings to disable the extension? ?Same question > about gnutls_safe_negotiation_set_initial. They are not really needed. We could remove them. They were left there to allow similar behavior with other functions that can also be set with priority strings. regards, Nikos From simon at josefsson.org Mon May 3 16:28:32 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 May 2010 16:28:32 +0200 Subject: safe renegotiation: confirming consensus Message-ID: <87d3xd2h67.fsf@mocca.josefsson.org> Based on recent discussion, here is my perception of what I believe would be the best to implement. Note that this is not what is implemented today, so some of the priority strings below have slightly different meaning now. Client behaviour: Client sends the extension by default. Can be disabled with %DISABLE_SAFE_RENEGOTIATION priority string. Clients will talk to servers that do not support the extension by default, but will refuse any rehandshake attempts against those servers. This would cause operational problems: can we confirm that NSS and/or OpenSSL clients behave like this? Otherwise we probably shouldn't enable it. When %SAFE_RENEGOTIATION is used, the client will never talk to a server that doesn't support the extension. When %UNSAFE_RENEGOTIATION is used, the client will talk to servers that doesn't support the extension including re-handshakes. Server behaviour: Servers sends the extension by default (when the client requested it, of course). Can be disabled with %DISABLE_SAFE_RENEGOTIATION priority string. Servers will accept connections from clients that do not support the extension, but will refuse any rehandshake attempts with that client. This is the important behaviour that closes the security problem for GnuTLS servers. I believe we have confirmed that OpenSSL servers will behave like this. When %SAFE_RENEGOTIATION is used, the server will never talk to anyone who doesn't support the extension. When %UNSAFE_RENEGOTIATION is used, the server will talk to clients that doesn't support the extension including re-handshakes. The %INITIAL_SAFE_RENEGOTIATION is not needed anymore can be removed. Q: should SECURE imply %SAFE_RENEGOTIATION? Q: do we need a priority string to describe the default behaviour? For example %PARTIAL_RENEGOTIATION? The reason would if you want to say something like SECURE:%PARTIAL_RENEGOTIATION to get high-security defaults but still support renegotiation using our normal behaviour wrt renegotiation. I'm not sure the terms of the priority strings are the best, the RFC doesn't use the concept "safe renegotiation", does it? /Simon From simon at josefsson.org Mon May 3 16:33:57 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 May 2010 16:33:57 +0200 Subject: gnutls_safe_renegotiation_set? In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 3 May 2010 16:21:29 +0200") References: <87ljc12ikg.fsf@mocca.josefsson.org> Message-ID: <8763352gx6.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Mon, May 3, 2010 at 3:58 PM, Simon Josefsson wrote: >> The new gnutls_safe_renegotiation_set API doesn't seem to influence >> rehandshakes -- i.e., I cannot first handshake successfully with the >> extension, call the API with flag=0, and then do a rehandshake that does >> not use the extension. ?Is this intentional? > > Never thought of such usage of it. I see no reason to allow such > behavior since it will only complicate code without offering new > functionality or advantage. Agreed, although it is useful to be able to self-test one possible attack vector where the attacker negotiates the extension on initial handshake but the later handshakes do not use the extension. >> More generally, why do we need this API at all? ?Isn't the natural thing >> to use the priority strings to disable the extension? ?Same question >> about gnutls_safe_negotiation_set_initial. > > They are not really needed. We could remove them. They were left there > to allow similar behavior with other functions that can also be set > with priority strings. I understand, but for new code it should be just as easy to use a priority string function, and I see no disadvantage with requiring that. This may even lead more projects to support priority strings which is a good thing... I believe having some projects begin to use the new two APIs above would be bad: then they eventually will need to think about user interfaces for enabling/disabling that know. And priority strings have already solved that. I'll remove these two APIs in a few days unless I hear objections. /Simon From dkg at fifthhorseman.net Mon May 3 18:46:05 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 03 May 2010 12:46:05 -0400 Subject: safe renegotiation: confirming consensus In-Reply-To: <87d3xd2h67.fsf@mocca.josefsson.org> References: <87d3xd2h67.fsf@mocca.josefsson.org> Message-ID: <4BDEFDCD.3080702@fifthhorseman.net> On 05/03/2010 10:28 AM, Simon Josefsson wrote: > Based on recent discussion, here is my perception of what I believe > would be the best to implement. Note that this is not what is > implemented today, so some of the priority strings below have slightly > different meaning now. > > Client behaviour: [...] > Clients will talk to servers that do not support the extension by > default, but will refuse any rehandshake attempts against those > servers. This would cause operational problems: can we confirm that > NSS and/or OpenSSL clients behave like this? Otherwise we probably > shouldn't enable it. NSS appears to be using this approach: https://wiki.mozilla.org/Security:Renegotiation#Control That said, i don't currently see that this approach confers much of a security advantage. The user is already vulnerable just by having made the initial connection (which appears to the client as a negotiation, but might appear to the server as a renegotiation if there was a prefix injection that already happened). Can anyone describe what additional threat we defend against by declining to renegotiate with vulnerable servers? --dkg PS i can imagine that by declining re-negotiation we might alert the server operator (via bug reports or error logs) that they should upgrade their TLS toolkit, but that doesn't seem like a good tradeoff to me if it means that we force our users to lose functionality. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Mon May 3 19:45:26 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 May 2010 19:45:26 +0200 Subject: safe renegotiation: confirming consensus In-Reply-To: <4BDEFDCD.3080702@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 03 May 2010 12:46:05 -0400") References: <87d3xd2h67.fsf@mocca.josefsson.org> <4BDEFDCD.3080702@fifthhorseman.net> Message-ID: <87k4rkzxop.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On 05/03/2010 10:28 AM, Simon Josefsson wrote: >> Based on recent discussion, here is my perception of what I believe >> would be the best to implement. Note that this is not what is >> implemented today, so some of the priority strings below have slightly >> different meaning now. >> >> Client behaviour: > [...] >> Clients will talk to servers that do not support the extension by >> default, but will refuse any rehandshake attempts against those >> servers. This would cause operational problems: can we confirm that >> NSS and/or OpenSSL clients behave like this? Otherwise we probably >> shouldn't enable it. > > NSS appears to be using this approach: > > https://wiki.mozilla.org/Security:Renegotiation#Control Thanks for the pointer! > That said, i don't currently see that this approach confers much of a > security advantage. > > The user is already vulnerable just by having made the initial > connection (which appears to the client as a negotiation, but might > appear to the server as a renegotiation if there was a prefix injection > that already happened). Right. > Can anyone describe what additional threat we defend against by > declining to renegotiate with vulnerable servers? I can't think of any concrete threat. I know that Mandos is using TLS backwards, i.e., the client is running a TLS server and the server is responding as a TLS client. Mandos probably doesn't support renegotiation at all, but maybe there are other designs like this and some that support renegotiation. Still, I'm not certain even these designs would be vulnerable. > PS i can imagine that by declining re-negotiation we might alert the > server operator (via bug reports or error logs) that they should upgrade > their TLS toolkit, but that doesn't seem like a good tradeoff to me if > it means that we force our users to lose functionality. Thanks for your opinion. I don't have a particularly strong opinion here. Maybe others can chime in too. On the one side, I don't want to remove interoperability for security reasons without a clearly described threat, and on the other side, I want to disable as much as possible by default unless there is a reason why it has to be enabled. Given that we don't know of even one GnuTLS client applications that implements renegotiation today (except gnutls-cli) -- I believe we have searched applications if they contained the necessary code to perform renegotiation earlier -- I would be surprised if anyone will notice if we disable client renegotiation against servers without support for the extension. I think we could even disable renegotiation completely and people wouldn't notice (except for mod_gnutls)... it just isn't used by the majority of GnuTLS applications. /Simon From nmav at gnutls.org Mon May 3 22:39:08 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 03 May 2010 22:39:08 +0200 Subject: safe renegotiation: confirming consensus In-Reply-To: <87d3xd2h67.fsf@mocca.josefsson.org> References: <87d3xd2h67.fsf@mocca.josefsson.org> Message-ID: <4BDF346C.5000202@gnutls.org> Simon Josefsson wrote: > Based on recent discussion, here is my perception of what I believe > would be the best to implement. Note that this is not what is > implemented today, so some of the priority strings below have slightly > different meaning now. I don't understand. Why we go again through this? What is the problem with the current implementation that needs to be fixed? The only thing I got from the previous e-mails are about the default server behavior. > Client behaviour: > > Client sends the extension by default. Can be disabled with > %DISABLE_SAFE_RENEGOTIATION priority string. > Clients will talk to servers that do not support the extension by > default, but will refuse any rehandshake attempts against those > servers. This would cause operational problems: can we confirm that > NSS and/or OpenSSL clients behave like this? Otherwise we probably > shouldn't enable it. I'd be happy if this option is not documented at all. It is available for testing purposes only and it is mentioned in the documentation as such. Typical applications shouldn't use this flag. > When %SAFE_RENEGOTIATION is used, the client will never talk to a > server that doesn't support the extension. > > When %UNSAFE_RENEGOTIATION is used, the client will talk to servers > that doesn't support the extension including re-handshakes. As documented now. > Server behaviour: > Servers will accept connections from clients that do not support the > extension, but will refuse any rehandshake attempts with that client. > This is the important behaviour that closes the security problem for > GnuTLS servers. I believe we have confirmed that OpenSSL servers will > behave like this. (1) This is the SAFE_RENEGOTIATION flag now. Why remove the flag for it? > When %SAFE_RENEGOTIATION is used, the server will never talk to anyone > who doesn't support the extension. (2) > When %UNSAFE_RENEGOTIATION is used, the server will talk to clients > that doesn't support the extension including re-handshakes. > > The %INITIAL_SAFE_RENEGOTIATION is not needed anymore can be removed. It is needed since this flag distinguishes the case (1) from case (2). IMO the flag SAFE_RENEGOTIATION is more clear in what it does now. It does safe renegotiation only. Initial negotiation is safe anyway thus it doesn't add in security to require the extension. > Q: should SECURE imply %SAFE_RENEGOTIATION? No. The keywords SECURE/NORMAL/etc apply to ciphersuites. > Q: do we need a priority string to describe the default behaviour? For > example %PARTIAL_RENEGOTIATION? The reason would if you want to say > something like SECURE:%PARTIAL_RENEGOTIATION to get high-security > defaults but still support renegotiation using our normal behaviour wrt > renegotiation. Why not use INITIAL_SAFE_RENEGOTIATION and SAFE_RENEGOTIATION? I have no problem changing the names, but what why do that? Aren't they clear? Are they hard to understand (may be). > I'm not sure the terms of the priority strings are the best, the RFC > doesn't use the concept "safe renegotiation", does it? It mentions renegotiation indication, which is worse as a term to indicate a security fix. regards, Nikos From thoger at redhat.com Tue May 4 09:07:57 2010 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 4 May 2010 09:07:57 +0200 Subject: safe renegotiation: confirming consensus In-Reply-To: <87d3xd2h67.fsf@mocca.josefsson.org> References: <87d3xd2h67.fsf@mocca.josefsson.org> Message-ID: <20100504090757.2bf93bc8@redhat.com> On Mon, 03 May 2010 16:28:32 +0200 Simon Josefsson wrote: > Client behaviour: [ ... ] > Clients will talk to servers that do not support the extension by > default, but will refuse any rehandshake attempts against those > servers. This would cause operational problems: can we confirm that > NSS and/or OpenSSL clients behave like this? Otherwise we probably > shouldn't enable it. Both OpenSSL and NSS allow upgraded clients to connect to unupgraded servers by default. OpenSSL also allows upgraded clients to renegotiate with unupgraded servers, see: http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION NSS does not allow upgraded clients to renegotiate with unupgraded servers, but afaik both firefox and chromium allow renegotiation for now. This documents what options NSS offers: https://developer.mozilla.org/NSS_3.12.6_release_notes > Server behaviour: [ ... ] > Servers will accept connections from clients that do not support the > extension, but will refuse any rehandshake attempts with that > client. This is the important behaviour that closes the security > problem for GnuTLS servers. I believe we have confirmed that > OpenSSL servers will behave like this. Both OpenSSL and NSS servers behave like this by default. > Q: do we need a priority string to describe the default behaviour? > For example %PARTIAL_RENEGOTIATION? The reason would if you want to > say something like SECURE:%PARTIAL_RENEGOTIATION to get high-security > defaults but still support renegotiation using our normal behaviour > wrt renegotiation. Something like this may be desired when the default for servers changes to require safe initial negotiation in the future. %{,UN}SAFE_RENEGOTIATION do not seem to allow specifying current default behavior explicitly. Can it be less confusing to have %{,UN}SAFE_RENEGOTIATION and %{,UN}SAFE_INITIAL_NEGOTIATION, with defaults for client/server set in gnutls_init? th. From thoger at redhat.com Tue May 4 09:14:27 2010 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 4 May 2010 09:14:27 +0200 Subject: safe renegotiation: confirming consensus In-Reply-To: <87k4rkzxop.fsf@mocca.josefsson.org> References: <87d3xd2h67.fsf@mocca.josefsson.org> <4BDEFDCD.3080702@fifthhorseman.net> <87k4rkzxop.fsf@mocca.josefsson.org> Message-ID: <20100504091427.2330a7fd@redhat.com> On Mon, 03 May 2010 19:45:26 +0200 Simon Josefsson wrote: > Given that we don't know of even one GnuTLS client applications that > implements renegotiation today (except gnutls-cli) -- I believe we > have searched applications if they contained the necessary code to > perform renegotiation earlier -- I would be surprised if anyone will > notice if we disable client renegotiation against servers without > support for the extension. This suggests there is at least one: http://lists.gnu.org/archive/html/help-gnutls/2009-01/msg00000.html Previous search was focused on server apps, iirc. th. From ametzler at downhill.at.eu.org Sat May 8 09:29:54 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 8 May 2010 09:29:54 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) Message-ID: <20100508072954.GB3269@downhill.g.la> Hello, introduction of safe (re)negotiation in 2.9.10 has broken TLS for exim4. The interesting bits when running in debug mode seem to be these: --------------------------------------------- 09:01:12 31398 SMTP>> STARTTLS 09:01:12 31398 waiting for data on socket 09:01:12 31398 read response data: size=18 09:01:12 31398 SMTP<< 220 TLS go ahead 09:01:12 31398 initializing GnuTLS as a client 09:01:12 31398 read D-H parameters from file 09:01:12 31398 initialized D-H parameters 09:01:12 31398 no TLS client certificate is specified 09:01:12 31398 initialized certificate stuff 09:01:12 31398 initialized GnuTLS session |<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<2>| EXT[0x8126dd0]: Sending extension SAFE_RENEGOTIATION |<3>| HSK[0x8126dd0]: CLIENT HELLO was sent [74 bytes] |<6>| BUF[HSK]: Inserted 74 bytes of Data |<4>| REC[0x8126dd0]: Sending Packet[0] Handshake(22) with length: 74 |<7>| WRITE: Will write 79 bytes to 0x6. |<7>| WRITE: wrote 79 bytes to 0x6. Left 0 bytes. Total 79 bytes. |<7>| 0000 - 16 03 01 00 4a 01 00 00 46 03 01 4b e5 0c 38 0e |<7>| 0001 - 93 39 29 cb 86 99 68 28 eb 45 82 6c 9a b4 2b c6 |<7>| 0002 - 6d 47 c7 6f b5 a8 72 a4 16 ba 97 00 00 18 00 35 |<7>| 0003 - 00 2f 00 0a 00 05 00 04 00 38 00 32 00 13 00 66 |<7>| 0004 - 00 39 00 33 00 16 01 00 00 05 ff 01 00 01 00 |<4>| REC[0x8126dd0]: Sent Packet[1] Handshake(22) with length: 79 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 00 4a |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126dd0]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x8126dd0]: Received Packet[0] Handshake(22) with length: 74 |<7>| READ: Got 74 bytes from 0x6 |<7>| READ: read 74 bytes from 0x6 |<7>| 0000 - 02 00 00 46 03 01 4b e5 0c 3a dd 97 c9 48 e3 12 |<7>| 0001 - 7f 61 d9 12 53 17 cd 69 94 24 26 34 ce 68 46 ad |<7>| 0002 - 0a c8 8b b9 2d a0 20 d6 25 41 21 ae 93 61 3f 1d |<7>| 0003 - e1 22 7c 86 f0 08 74 55 af ff 2c 60 bc ae 41 b4 |<7>| 0004 - b7 3f 32 76 a9 03 12 00 35 00 |<7>| RB: Have 5 bytes into buffer. Adding 74 bytes. |<7>| RB: Requested 79 bytes |<4>| REC[0x8126dd0]: Decrypted Packet[0] Handshake(22) with length: 74 |<6>| BUF[HSK]: Inserted 74 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126dd0]: SERVER HELLO was received [74 bytes] |<6>| BUF[REC][HD]: Read 70 bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 70 bytes of Data |<3>| HSK[0x8126dd0]: Server's version: 3.1 |<3>| HSK[0x8126dd0]: SessionID length: 32 |<3>| HSK[0x8126dd0]: SessionID: d6254121ae93613f1de1227c86f0087455afff2c60bcae41b4b73f3276a90312 |<3>| HSK[0x8126dd0]: Selected cipher suite: RSA_AES_256_CBC_SHA1 |<2>| ASSERT: gnutls_extensions.c:140 |<2>| ASSERT: gnutls_handshake.c:2404 |<3>| Denying unsafe (re)negotiation. |<2>| ASSERT: gnutls_handshake.c:2776 |<6>| BUF[HSK]: Cleared Data from buffer 09:01:12 31398 LOG: MAIN 09:01:12 31398 TLS error on connection to merkel.debian.org [192.25.206.16] (gnutls_handshake): Safe renegotiation failed. --------------------------------------------- 2.9.9 succeeds (log attached). Counterpart (merkel.debian.org) is running gnutls 2.4.x. I have not managed to reproduce the error with gnutls-cli. When looking at exim's tls code http://git.exim.org/exim.git/blob_plain/HEAD:/exim-src/src/tls-gnu.c one big difference to gnutls-cli is that exim only uses the specific gnutls_*_set_priority() functions while gnutls-cli *always* invokes gnutls_priority_set_direct() in the first place. Perhaps an unintended dependency on gnutls_priority_*() was introduced? This is http://bugs.debian.org/579831 FWIW. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- 09:08:33 31518 SMTP>> STARTTLS 09:08:33 31518 waiting for data on socket 09:08:33 31518 read response data: size=18 09:08:33 31518 SMTP<< 220 TLS go ahead 09:08:33 31518 initializing GnuTLS as a client 09:08:33 31518 read D-H parameters from file 09:08:33 31518 initialized D-H parameters 09:08:33 31518 no TLS client certificate is specified 09:08:33 31518 initialized certificate stuff 09:08:33 31518 initialized GnuTLS session |<3>| HSK[0x8126bf0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x8126bf0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x8126bf0]: CLIENT HELLO was send [67 bytes] |<6>| BUF[HSK]: Inserted 67 bytes of Data |<4>| REC[0x8126bf0]: Sending Packet[0] Handshake(22) with length: 67 |<7>| WRITE: Will write 72 bytes to 0x6. |<7>| WRITE: wrote 72 bytes to 0x6. Left 0 bytes. Total 72 bytes. |<7>| 0000 - 16 03 01 00 43 01 00 00 3f 03 01 4b e5 0d f1 d7 |<7>| 0001 - ad 63 90 9c 0c ab b1 2c 8f 21 5d fa 57 a0 8c 91 |<7>| 0002 - 21 05 dc ec 87 d9 a4 d8 29 81 8e 00 00 18 00 35 |<7>| 0003 - 00 2f 00 0a 00 05 00 04 00 38 00 32 00 13 00 66 |<7>| 0004 - 00 39 00 33 00 16 01 00 |<4>| REC[0x8126bf0]: Sent Packet[1] Handshake(22) with length: 72 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 00 4a |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[0] Handshake(22) with length: 74 |<7>| READ: Got 74 bytes from 0x6 |<7>| READ: read 74 bytes from 0x6 |<7>| 0000 - 02 00 00 46 03 01 4b e5 0d f3 8d 5c 68 19 db b4 |<7>| 0001 - 3e 94 78 f8 77 3d b8 fd fd aa ea c5 e1 c2 c2 12 |<7>| 0002 - 9e ff c7 3a 4a f5 20 2d ab d0 6a ee 83 3b 45 02 |<7>| 0003 - 94 e8 aa 38 e5 e4 09 b1 28 23 f8 46 02 49 7a 81 |<7>| 0004 - e8 ca 19 6c ca ba 16 00 35 00 |<7>| RB: Have 5 bytes into buffer. Adding 74 bytes. |<7>| RB: Requested 79 bytes |<4>| REC[0x8126bf0]: Decrypted Packet[0] Handshake(22) with length: 74 |<6>| BUF[HSK]: Inserted 74 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126bf0]: SERVER HELLO was received [74 bytes] |<6>| BUF[REC][HD]: Read 70 bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 70 bytes of Data |<3>| HSK[0x8126bf0]: Server's version: 3.1 |<3>| HSK[0x8126bf0]: SessionID length: 32 |<3>| HSK[0x8126bf0]: SessionID: 2dabd06aee833b450294e8aa38e5e409b12823f84602497a81e8ca196ccaba16 |<3>| HSK[0x8126bf0]: Selected cipher suite: RSA_AES_256_CBC_SHA1 |<2>| ASSERT: gnutls_extensions.c:137 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 05 42 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[1] Handshake(22) with length: 1346 |<7>| READ: Got 1346 bytes from 0x6 |<7>| READ: read 1346 bytes from 0x6 |<7>| 0000 - 0b 00 05 3e 00 05 3b 00 05 38 30 82 05 34 30 82 |<7>| 0001 - 04 1c a0 03 02 01 02 02 02 00 9b 30 0d 06 09 2a |<7>| 0002 - 86 48 86 f7 0d 01 01 05 05 00 30 81 a6 31 0b 30 |<7>| 0003 - 09 06 03 55 04 06 13 02 4e 41 31 0b 30 09 06 03 |<7>| 0004 - 55 04 08 13 02 4e 41 31 15 30 13 06 03 55 04 07 |<7>| 0005 - 13 0c 41 6e 6b 68 20 4d 6f 72 70 6f 72 6b 31 14 |<7>| 0006 - 30 12 06 03 55 04 0a 13 0b 44 65 62 69 61 6e 20 |<7>| 0007 - 53 4d 54 50 31 17 30 15 06 03 55 04 0b 13 0e 44 |<7>| 0008 - 65 62 69 61 6e 20 53 4d 54 50 20 43 41 31 17 30 |<7>| 0009 - 15 06 03 55 04 03 13 0e 44 65 62 69 61 6e 20 53 |<7>| 000a - 4d 54 50 20 43 41 31 2b 30 29 06 09 2a 86 48 86 |<7>| 000b - f7 0d 01 09 01 16 1c 68 6f 73 74 6d 61 73 74 65 |<7>| 000c - 72 40 70 75 70 70 65 74 2e 64 65 62 69 61 6e 2e |<7>| 000d - 6f 72 67 30 1e 17 0d 31 30 30 33 30 36 30 30 30 |<7>| 000e - 30 30 37 5a 17 0d 31 31 30 33 30 36 30 30 30 30 |<7>| 000f - 30 37 5a 30 81 a9 31 0b 30 09 06 03 55 04 06 13 |<7>| 0010 - 02 4e 41 31 0b 30 09 06 03 55 04 08 13 02 4e 41 |<7>| 0011 - 31 15 30 13 06 03 55 04 07 13 0c 41 6e 6b 68 20 |<7>| 0012 - 4d 6f 72 70 6f 72 6b 31 14 30 12 06 03 55 04 0a |<7>| 0013 - 13 0b 44 65 62 69 61 6e 20 53 4d 54 50 31 17 30 |<7>| 0014 - 15 06 03 55 04 0b 13 0e 44 65 62 69 61 6e 20 53 |<7>| 0015 - 4d 54 50 20 43 41 31 1a 30 18 06 03 55 04 03 13 |<7>| 0016 - 11 6d 65 72 6b 65 6c 2e 64 65 62 69 61 6e 2e 6f |<7>| 0017 - 72 67 31 2b 30 29 06 09 2a 86 48 86 f7 0d 01 09 |<7>| 0018 - 01 16 1c 68 6f 73 74 6d 61 73 74 65 72 40 6d 65 |<7>| 0019 - 72 6b 65 6c 2e 64 65 62 69 61 6e 2e 6f 72 67 30 |<7>| 001a - 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 |<7>| 001b - 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 |<7>| 001c - c5 2f 32 1b 0a 72 72 48 4d ea bb 4e 3b 86 db 90 |<7>| 001d - 96 9b 1e d6 c0 fd cd 65 63 84 2b 93 0b 09 73 ec |<7>| 001e - 37 89 fb 1f 5b 1a 1c 33 d7 f3 5a 98 fd b2 77 6b |<7>| 001f - fb ad 2d ee c5 b6 f5 5d f8 b4 6e 78 bd 12 93 c1 |<7>| 0020 - ff af 06 55 52 1f fc 5b ee 9f d7 37 4e 02 58 7d |<7>| 0021 - 77 9a 02 7b 5b 3b 40 fa f1 20 68 e8 29 d3 91 e8 |<7>| 0022 - e9 64 d5 55 23 89 83 a5 4e a9 d4 23 5b 7e 7b b1 |<7>| 0023 - 44 0e 3d 7f ab f4 3f e3 13 58 8d cc df d8 5b c6 |<7>| 0024 - 51 8f 7d a9 1a 1a 44 67 52 2f 82 42 90 d7 8b 81 |<7>| 0025 - bc 06 97 0f 67 28 b5 cc 16 55 d9 21 c3 d6 51 02 |<7>| 0026 - 9d 54 d6 c0 6a e3 47 f9 07 49 e6 0a 91 e1 5c b2 |<7>| 0027 - 21 ab 59 b0 11 9d 4e a6 a5 47 c2 00 d7 e7 df e2 |<7>| 0028 - 1a 0d 95 8a 6f f3 47 dc 56 54 44 1a f4 7f 35 08 |<7>| 0029 - cc 95 99 32 7c 2a b0 b9 bf 3c ba b2 04 95 39 4d |<7>| 002a - 24 8c 22 db 2e 81 fa 6f d9 af 42 21 a2 ed dd e2 |<7>| 002b - 86 68 0e a3 0b a1 db 01 93 25 b2 13 c6 38 33 e3 |<7>| 002c - 02 03 01 00 01 a3 82 01 65 30 82 01 61 30 09 06 |<7>| 002d - 03 55 1d 13 04 02 30 00 30 11 06 09 60 86 48 01 |<7>| 002e - 86 f8 42 01 01 04 04 03 02 06 40 30 22 06 09 60 |<7>| 002f - 86 48 01 86 f8 42 01 0d 04 15 16 13 44 65 62 69 |<7>| 0030 - 61 6e 20 53 4d 54 50 20 43 41 20 63 65 72 74 30 |<7>| 0031 - 1d 06 03 55 1d 0e 04 16 04 14 40 c6 80 45 60 5f |<7>| 0032 - 90 8a 8c 08 c8 b2 ff b8 51 5b a8 c3 c7 ec 30 81 |<7>| 0033 - db 06 03 55 1d 23 04 81 d3 30 81 d0 80 14 5f 6a |<7>| 0034 - 6c 52 01 d1 e6 9b 45 78 e9 b5 79 41 1b b7 80 ca |<7>| 0035 - d8 c6 a1 81 ac a4 81 a9 30 81 a6 31 0b 30 09 06 |<7>| 0036 - 03 55 04 06 13 02 4e 41 31 0b 30 09 06 03 55 04 |<7>| 0037 - 08 13 02 4e 41 31 15 30 13 06 03 55 04 07 13 0c |<7>| 0038 - 41 6e 6b 68 20 4d 6f 72 70 6f 72 6b 31 14 30 12 |<7>| 0039 - 06 03 55 04 0a 13 0b 44 65 62 69 61 6e 20 53 4d |<7>| 003a - 54 50 31 17 30 15 06 03 55 04 0b 13 0e 44 65 62 |<7>| 003b - 69 61 6e 20 53 4d 54 50 20 43 41 31 17 30 15 06 |<7>| 003c - 03 55 04 03 13 0e 44 65 62 69 61 6e 20 53 4d 54 |<7>| 003d - 50 20 43 41 31 2b 30 29 06 09 2a 86 48 86 f7 0d |<7>| 003e - 01 09 01 16 1c 68 6f 73 74 6d 61 73 74 65 72 40 |<7>| 003f - 70 75 70 70 65 74 2e 64 65 62 69 61 6e 2e 6f 72 |<7>| 0040 - 67 82 09 00 f6 08 13 4a 49 f7 da d3 30 13 06 03 |<7>| 0041 - 55 1d 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 03 |<7>| 0042 - 01 30 0b 06 03 55 1d 0f 04 04 03 02 05 a0 30 0d |<7>| 0043 - 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 82 01 |<7>| 0044 - 01 00 83 96 70 97 ea 14 cc ee d0 f4 d5 62 19 b0 |<7>| 0045 - dd 90 bf 5c 7d f8 34 a7 67 44 65 5f 77 be 24 e5 |<7>| 0046 - b2 23 2b 58 18 b1 4e e7 1f 37 3d 37 f0 32 7c f0 |<7>| 0047 - 04 77 ec 9b ec f0 b0 3e 4d d8 05 ae 3c 5d 54 14 |<7>| 0048 - 33 ea f1 99 8b e8 20 c1 28 ca d5 45 e7 ca d7 96 |<7>| 0049 - 7f 8e e5 65 8e ae 69 14 bf e8 e3 3c 3f 1c 43 ef |<7>| 004a - 5e 14 82 4e c4 db f2 c8 3e f5 f1 e2 b1 f0 16 f5 |<7>| 004b - d5 be 94 cd f4 c6 24 88 0b fe 30 22 7b 96 0a ff |<7>| 004c - a3 cc fc a4 41 e8 9a 86 7a c4 d2 9a 9c 13 54 38 |<7>| 004d - b3 cc 8d 61 6b 8b 8c 1d 96 6b eb 70 9c bc e7 9e |<7>| 004e - ef 9d 96 81 71 04 20 1c 7a e8 e6 20 f5 b4 5f b9 |<7>| 004f - 06 35 fb 01 90 cd cd 5c 30 73 b1 4b db 1d f5 ff |<7>| 0050 - b9 1f 95 f8 87 3b a2 09 38 7b 7f b5 6f e7 c1 5f |<7>| 0051 - 1b 92 ae 17 6d f6 39 7a 3e ed cb a9 05 a6 d3 3b |<7>| 0052 - 1d c8 31 de 0e 62 fa 6e 5f 56 a8 23 b6 e3 f7 8c |<7>| 0053 - 1f 6c 58 24 76 0f 67 18 b4 3a 08 81 b1 5b af 1c |<7>| 0054 - e8 4d |<7>| RB: Have 5 bytes into buffer. Adding 1346 bytes. |<7>| RB: Requested 1351 bytes |<4>| REC[0x8126bf0]: Decrypted Packet[1] Handshake(22) with length: 1346 |<6>| BUF[HSK]: Inserted 1346 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126bf0]: CERTIFICATE was received [1346 bytes] |<6>| BUF[REC][HD]: Read 1342 bytes of Data(22) |<6>| BUF[HSK]: Peeked 141 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 1342 bytes of Data |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 00 b4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[2] Handshake(22) with length: 180 |<7>| READ: Got 180 bytes from 0x6 |<7>| READ: read 180 bytes from 0x6 |<7>| 0000 - 0d 00 00 b0 02 01 02 00 ab 00 a9 30 81 a6 31 0b |<7>| 0001 - 30 09 06 03 55 04 06 13 02 4e 41 31 0b 30 09 06 |<7>| 0002 - 03 55 04 08 13 02 4e 41 31 15 30 13 06 03 55 04 |<7>| 0003 - 07 13 0c 41 6e 6b 68 20 4d 6f 72 70 6f 72 6b 31 |<7>| 0004 - 14 30 12 06 03 55 04 0a 13 0b 44 65 62 69 61 6e |<7>| 0005 - 20 53 4d 54 50 31 17 30 15 06 03 55 04 0b 13 0e |<7>| 0006 - 44 65 62 69 61 6e 20 53 4d 54 50 20 43 41 31 17 |<7>| 0007 - 30 15 06 03 55 04 03 13 0e 44 65 62 69 61 6e 20 |<7>| 0008 - 53 4d 54 50 20 43 41 31 2b 30 29 06 09 2a 86 48 |<7>| 0009 - 86 f7 0d 01 09 01 16 1c 68 6f 73 74 6d 61 73 74 |<7>| 000a - 65 72 40 70 75 70 70 65 74 2e 64 65 62 69 61 6e |<7>| 000b - 2e 6f 72 67 |<7>| RB: Have 5 bytes into buffer. Adding 180 bytes. |<7>| RB: Requested 185 bytes |<4>| REC[0x8126bf0]: Decrypted Packet[2] Handshake(22) with length: 180 |<6>| BUF[HSK]: Inserted 180 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126bf0]: CERTIFICATE REQUEST was received [180 bytes] |<6>| BUF[REC][HD]: Read 176 bytes of Data(22) |<6>| BUF[HSK]: Peeked 1346 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 176 bytes of Data |<2>| ASSERT: auth_cert.c:232 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 00 04 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[3] Handshake(22) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[3] Handshake(22) with length: 4 |<7>| READ: Got 4 bytes from 0x6 |<7>| READ: read 4 bytes from 0x6 |<7>| 0000 - 0e 00 00 00 |<7>| RB: Have 5 bytes into buffer. Adding 4 bytes. |<7>| RB: Requested 9 bytes |<4>| REC[0x8126bf0]: Decrypted Packet[3] Handshake(22) with length: 4 |<6>| BUF[HSK]: Inserted 4 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126bf0]: SERVER HELLO DONE was received [4 bytes] |<6>| BUF[HSK]: Peeked 180 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<3>| HSK[0x8126bf0]: CERTIFICATE was send [7 bytes] |<6>| BUF[HSK]: Peeked 4 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[0x8126bf0]: Sending Packet[1] Handshake(22) with length: 7 |<7>| WRITE: Will write 12 bytes to 0x6. |<7>| WRITE: wrote 12 bytes to 0x6. Left 0 bytes. Total 12 bytes. |<7>| 0000 - 16 03 01 00 07 0b 00 00 03 00 00 00 |<4>| REC[0x8126bf0]: Sent Packet[2] Handshake(22) with length: 12 |<3>| HSK[0x8126bf0]: CLIENT KEY EXCHANGE was send [262 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[0x8126bf0]: Sending Packet[2] Handshake(22) with length: 262 |<7>| WRITE: Will write 267 bytes to 0x6. |<7>| WRITE: wrote 267 bytes to 0x6. Left 0 bytes. Total 267 bytes. |<7>| 0000 - 16 03 01 01 06 10 00 01 02 01 00 20 03 a2 63 72 |<7>| 0001 - a0 23 d3 70 03 fa ae b0 e5 f7 0c ae 35 7c 8c 1d |<7>| 0002 - cc cf cb 97 aa 9d 23 ea de 8c 45 68 6e bf 2e 06 |<7>| 0003 - b2 63 14 dc b4 70 3a f8 22 3d 96 e1 d4 40 78 fc |<7>| 0004 - d3 12 dc a7 20 0c 24 1a a5 8d bd 6a d4 fd 37 53 |<7>| 0005 - 2c 7e bb 4d 65 10 a6 67 a8 5c 76 fd 08 10 b4 2d |<7>| 0006 - 2c 22 0d b4 57 0a e4 31 05 df 9e 82 2d 3d cf a3 |<7>| 0007 - 22 fe bc b2 6b 14 f5 4a ef 65 72 ce ec f2 c3 60 |<7>| 0008 - d6 b4 77 ad 21 37 b6 2f da 89 44 0d e1 1e ce 2c |<7>| 0009 - 1a f0 8a 34 de 35 5f e1 96 0b f9 60 a2 40 f6 01 |<7>| 000a - ed d8 f0 6e ff 5d b9 ba b8 d1 d0 1b dc 8f 25 c3 |<7>| 000b - 3b d3 80 c4 70 1d 71 27 cd 5f d9 24 a8 d3 ff dd |<7>| 000c - 00 10 40 58 4a b0 6b 5a ad 67 3e 79 f9 fd 10 2e |<7>| 000d - f2 ee 2c 6e 51 c5 d9 6e e6 59 a4 ba f9 94 49 bc |<7>| 000e - 32 50 dd 1e db 09 e7 03 12 6e b8 0b cc 4f 76 c4 |<7>| 000f - ad e4 7c 42 fb 62 5d 9a c6 68 da e5 20 7b 86 f9 |<7>| 0010 - f8 f9 92 a2 d4 fe 7b fa f5 12 c4 |<4>| REC[0x8126bf0]: Sent Packet[3] Handshake(22) with length: 267 |<3>| REC[0x8126bf0]: Sent ChangeCipherSpec |<4>| REC[0x8126bf0]: Sending Packet[3] Change Cipher Spec(20) with length: 1 |<7>| WRITE: Will write 6 bytes to 0x6. |<7>| WRITE: wrote 6 bytes to 0x6. Left 0 bytes. Total 6 bytes. |<7>| 0000 - 14 03 01 00 01 01 |<4>| REC[0x8126bf0]: Sent Packet[4] Change Cipher Spec(20) with length: 6 |<9>| INT: PREMASTER SECRET[48]: 03013bd89f4534935ecb4441d96cc3aa2e22fc117b8ab415733c31f64ca07e0e4b38014c0d0b6482f1e614d410717ca9 |<9>| INT: CLIENT RANDOM[32]: 4be50df1d7ad63909c0cabb12c8f215dfa57a08c912105dcec87d9a4d829818e |<9>| INT: SERVER RANDOM[32]: 4be50df38d5c6819dbb43e9478f8773db8fdfdaaeac5e1c2c2129effc73a4af5 |<9>| INT: MASTER SECRET: 5701d21d61c6f52a84ed2c137a777e480074e19903e39a439ff2549c84c8037fe202acb594d344c22cfaee84657d048b |<9>| INT: KEY BLOCK[136]: c5e1f2a91ce2c6a95b680d18dc17ed5e25167de982d8737499fd8f29b2063d8e |<9>| INT: CLIENT WRITE KEY [32]: ab0eabf72abc9db75ce75e86822c682cf9b3795348fa3b46a13388b7bfd913ba |<9>| INT: SERVER WRITE KEY [32]: c9c2edf890527d0ec6cb4e5bd576618770f0dbf9d333c58cbd101bc2d42ab15c |<3>| HSK[0x8126bf0]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126bf0]: Initializing internal [write] cipher sessions |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<3>| HSK[0x8126bf0]: FINISHED was send [16 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[0x8126bf0]: Sending Packet[0] Handshake(22) with length: 16 |<7>| WRITE: Will write 53 bytes to 0x6. |<7>| WRITE: wrote 53 bytes to 0x6. Left 0 bytes. Total 53 bytes. |<7>| 0000 - 16 03 01 00 30 4e 0e 4f ae fc ba 8b c3 63 7e ae |<7>| 0001 - f7 42 67 84 a9 db 84 4a b2 87 f5 31 41 c5 d7 30 |<7>| 0002 - a7 a7 05 91 9f c0 b9 e3 da 1e 47 51 d5 18 7c 42 |<7>| 0003 - 7a df a8 71 7a |<4>| REC[0x8126bf0]: Sent Packet[1] Handshake(22) with length: 53 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 14 03 01 00 01 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[4] Change Cipher Spec(20) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[4] Change Cipher Spec(20) with length: 1 |<7>| READ: Got 1 bytes from 0x6 |<7>| READ: read 1 bytes from 0x6 |<7>| 0000 - 01 |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. |<7>| RB: Requested 6 bytes |<4>| REC[0x8126bf0]: ChangeCipherSpec Packet was received |<3>| HSK[0x8126bf0]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x8126bf0]: Initializing internal [read] cipher sessions |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| 0000 - 16 03 01 00 40 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x8126bf0]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x8126bf0]: Received Packet[0] Handshake(22) with length: 64 |<7>| READ: Got 64 bytes from 0x6 |<7>| READ: read 64 bytes from 0x6 |<7>| 0000 - c1 11 b6 69 cf 72 a6 e6 6b 4e b0 9c 52 39 91 c4 |<7>| 0001 - b0 12 94 06 8e 94 d2 4d 5d 56 2e 30 e7 43 47 42 |<7>| 0002 - b7 e2 73 b9 9d 95 ef d3 ac 63 19 06 4f 36 cf 70 |<7>| 0003 - 1a b4 86 02 be d2 1b a7 40 40 f7 99 ae 5c 52 20 |<7>| 0004 - |<7>| RB: Have 5 bytes into buffer. Adding 64 bytes. |<7>| RB: Requested 69 bytes |<4>| REC[0x8126bf0]: Decrypted Packet[0] Handshake(22) with length: 16 |<6>| BUF[HSK]: Inserted 16 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x8126bf0]: FINISHED was received [16 bytes] |<6>| BUF[REC][HD]: Read 12 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 12 bytes of Data |<6>| BUF[HSK]: Cleared Data from buffer |<6>| BUF[HSK]: Cleared Data from buffer 09:08:33 31518 cipher: TLS1.0:RSA_AES_256_CBC_SHA1:32 09:08:33 31518 SMTP>> EHLO argenau From nmav at gnutls.org Sat May 8 09:58:04 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 08 May 2010 09:58:04 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <20100508072954.GB3269@downhill.g.la> References: <20100508072954.GB3269@downhill.g.la> Message-ID: <4BE5198C.8070303@gnutls.org> Andreas Metzler wrote: > Hello, > I have not managed to reproduce the error with gnutls-cli. When > looking at exim's tls code > http://git.exim.org/exim.git/blob_plain/HEAD:/exim-src/src/tls-gnu.c > one big difference to gnutls-cli is that exim only uses the specific > gnutls_*_set_priority() functions while gnutls-cli *always* invokes > gnutls_priority_set_direct() in the first place. Perhaps an > unintended dependency on gnutls_priority_*() was introduced? How easy would it be for exim to use gnutls_priority_* functions? The others have been deprecated for quite a time. Moreover it would be easier for exim to setup a configuration string for the priority_set_direct function. regards, Nikos From ametzler at downhill.at.eu.org Sat May 8 10:46:29 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 8 May 2010 10:46:29 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <4BE5198C.8070303@gnutls.org> References: <20100508072954.GB3269@downhill.g.la> <4BE5198C.8070303@gnutls.org> Message-ID: <20100508084629.GC3269@downhill.g.la> On 2010-05-08 Nikos Mavrogiannopoulos wrote: [...] > How easy would it be for exim to use gnutls_priority_* functions? The > others have been deprecated for quite a time. Moreover it would be > easier for exim to setup a configuration string for the > priority_set_direct function. [...] Hello, Doable, but not without pain. Exim exposes the gnutls_priority_* functions to the user (see options tls_require_ciphers et al in http://docs.exim.org/current/spec_html/ch39.html#SECTreqciphgnu) switching would cause an configuration file syntax change. - It could either ignore the old settings while still warning about them or throw an error (invalid setting). FWIW I think my guess was correct, after making the following change to exim the session succeeds. ----------------------------------- --- exim4-4.71.orig/src/tls-gnu.c +++ exim4-4.71/src/tls-gnu.c @@ -780,11 +780,15 @@ if ((expciphers != NULL && /* Define the various priorities */ -gnutls_cipher_set_priority(session, cipher_priority); +/* gnutls_cipher_set_priority(session, cipher_priority); gnutls_compression_set_priority(session, comp_priority); gnutls_kx_set_priority(session, kx_priority); gnutls_protocol_set_priority(session, proto_priority); -gnutls_mac_set_priority(session, mac_priority); +gnutls_mac_set_priority(session, mac_priority); */ + +fprintf (stderr, "amdebug 1 different priority stuff\n"); +gnutls_priority_set_direct (session, "NORMAL", NULL); +fprintf (stderr, "amdebug 1 done\n"); gnutls_cred_set(session, GNUTLS_CRD_CERTIFICATE, x509_cred); ----------------------------------- cu andreas From nmav at gnutls.org Sun May 16 12:12:51 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 16 May 2010 12:12:51 +0200 Subject: initial PKCS #11 support Message-ID: <4BEFC523.3050208@gnutls.org> Hello, I have implemented a limited (to public keys and private keys) PKCS #11 API in gnutls. This was inspired mainly by the neon PKCS #11 support and Alon's gnutls-pkcs11, although I think it has a larger scope. A sneak preview is at http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=shortlog;h=new * How it works: It can be enabled with a global config file (/etc/gnutls/pkcs11.conf) which contains the pkcs11 modules to load, or an application may ignore it and specify explicitly the modules it uses (see gnutls_pkcs11_init()). The file contains entries such as: "load=/xxx/pkcs11-lib.so" To reference PKCS #11 objects gnutls uses URLs as in http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 This has the advantage that all existing applications that use the gnutls functions to load keys/certificates will be able to use pkcs11 urls transparently. With certtool a list of the available keys is shown: ./certtool --pkcs11-list PIN required for token 'Nikos Mavrogiannopoulos (User P' in slot 'OmniKey CardMan 3121 00 00' Enter password: Certificate 0: URL: pkcs11:token=Nikos%20Mavrogiannopoulos%20%28User%20P;serial=307521161601031;model=PKCS%2315;manufacturer=EnterSafe;object=Certificate;id=db:5b:3e:b5:72:33:92:99:18:ed:bb:eb:74:68:31:bd:b2:23:67:26 Label: Certificate ID: db:5b:3e:b5:72:33:92:99:18:ed:bb:eb:74:68:31:bd:b2:23:67:26 With gnutls-cli or gnutls-serv and x509certfile/x509keyfile a pkcs11 url can be specified to use the corresponding keys and certificates. As a backend a modified pakchois library is used (modified to load an arbitrary library instead of looking into default paths). An example application can be seen at: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/examples/ex-cert-select-pkcs11.c;h=64875a97601d02d3288fe802831e71ec04c919e7;hb=9c21137aed2910de498832f598ae49238f40a27b Still there are several things to be done such as: 1. gnutls-cli/serv --x509cafile read from a pkcs11 url (certtool --pkcs11-list-trusted does something similar already) 2. Support for PKCS #11 secret keys in PSK ciphersuites 3. Thread lock issues with sharing of pkcs11 objects (probably implement locks around gnutls_pkcs11_privkey_t operations) 4. Allow signing of certificates with a pkcs 11 key (should be trivial using the gnutls_privkey_t api) 5. Allow reading and transforming pkcs11 public keys to certificates and certificate requests. 6. Allow generation of keys (still thinking whether its worthwhile) Any comments welcome. regards, Nikos From nmav at gnutls.org Tue May 18 21:16:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 May 2010 21:16:33 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <20100508084629.GC3269@downhill.g.la> References: <20100508072954.GB3269@downhill.g.la> <4BE5198C.8070303@gnutls.org> <20100508084629.GC3269@downhill.g.la> Message-ID: <4BF2E791.2040202@gnutls.org> Andreas Metzler wrote: > Hello, > Doable, but not without pain. Exim exposes the gnutls_priority_* > functions to the user (see options tls_require_ciphers et al in > http://docs.exim.org/current/spec_html/ch39.html#SECTreqciphgnu) > switching would cause an configuration file syntax change. - It could > either ignore the old settings while still warning about them or > throw an error (invalid setting). Correct patch attached (compiles). regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From nmav at gnutls.org Tue May 18 21:14:36 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 May 2010 21:14:36 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <20100508084629.GC3269@downhill.g.la> References: <20100508072954.GB3269@downhill.g.la> <4BE5198C.8070303@gnutls.org> <20100508084629.GC3269@downhill.g.la> Message-ID: <4BF2E71C.5000505@gnutls.org> Andreas Metzler wrote: > On 2010-05-08 Nikos Mavrogiannopoulos wrote: > [...] >> How easy would it be for exim to use gnutls_priority_* functions? The >> others have been deprecated for quite a time. Moreover it would be >> easier for exim to setup a configuration string for the >> priority_set_direct function. > [...] > > Hello, > Doable, but not without pain. Exim exposes the gnutls_priority_* > functions to the user (see options tls_require_ciphers et al in > http://docs.exim.org/current/spec_html/ch39.html#SECTreqciphgnu) > switching would cause an configuration file syntax change. - It could > either ignore the old settings while still warning about them or > throw an error (invalid setting). Does the attached patch to gnutls fixes the issue? regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From nmav at gnutls.org Tue May 18 21:34:41 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 May 2010 21:34:41 +0200 Subject: safe renegotiation In-Reply-To: <87vdbamtvb.fsf@mocca.josefsson.org> References: <87y6g6oerc.fsf@mocca.josefsson.org> <87vdbamtvb.fsf@mocca.josefsson.org> Message-ID: <4BF2EBD1.5000107@gnutls.org> Simon Josefsson wrote: > >> If people notice that no clients can connect on their servers will >> either install an older version of gnutls that "works" or just go to >> mod_ssl. Moreover it is problematic in the sense that an administrator >> might not detect at all that his site is inaccessible and only find >> out after losing customers or so. I think that fixing a security issue >> but as a side-effect causing serious issues in interoperability with >> old software is a recipe for people to move out of your software >> (intel never managed to get rid of x86, and I don't think we can >> afford it). >> >> Let's be conservative and wait. This issue proved not to be that >> important in the internet (not many people upgraded because of this). > > According to Tomas, OpenSSL protect against this. If that is the case, > I think the answer is simple: we should do the same. I've commited a patch that does that in git. regards, Nikos From andy at twvending.com Wed May 19 14:50:59 2010 From: andy at twvending.com (Andrew P. Hoffmeyer) Date: Wed, 19 May 2010 07:50:59 -0500 Subject: can't catch gnutls::exception Message-ID: <70FF8F59A0161A488984C62169FEF76E4B1D08@tw-exchange.twvending.com> When I try to compile a program, based on the C++ example on the web site, it calls terminate after throwing a gnutls::exception. When I try to catch the exception, the linker gives me the error: "undefined reference to "vtable for gnutls::exception" I have searched the web and found no suitable solutions to this problem, so as a last resort, I am contacting you to see if there is a solution. Thanks. Andrew Hoffmeyer Software Developer/Network Administrator Turnkey Corrections/Turnkey Software Solutions V: 715-386-5700 F: 715-386-9988 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed May 19 17:01:51 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 19 May 2010 17:01:51 +0200 Subject: can't catch gnutls::exception In-Reply-To: <70FF8F59A0161A488984C62169FEF76E4B1D08@tw-exchange.twvending.com> References: <70FF8F59A0161A488984C62169FEF76E4B1D08@tw-exchange.twvending.com> Message-ID: Which version of gnutls do you use? In any case can you try not using the libgnutlsxx.map on linking? (that would be to remove a line similar to: -Wl,--version-script=$(srcdir)/libgnutlsxx.map from your Makefile). regards, Nikos On Wed, May 19, 2010 at 2:50 PM, Andrew P. Hoffmeyer wrote: > When I try to compile a program, based on the C++ example on the web site, > it calls terminate after throwing a gnutls::exception.? When I try to catch > the exception, the linker gives me the error: > > > > ?undefined reference to ?vtable for gnutls::exception? > > > > I have searched the web and found no suitable solutions to this problem, so > as a last resort, I am contacting you to see if there is a solution. > > > > Thanks. > > > > Andrew Hoffmeyer > > Software Developer/Network Administrator > > Turnkey Corrections/Turnkey Software Solutions > > V: 715-386-5700 > > F: 715-386-9988 > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From ametzler at downhill.at.eu.org Wed May 19 19:04:01 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 19 May 2010 19:04:01 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <4BF2E791.2040202@gnutls.org> References: <20100508072954.GB3269@downhill.g.la> <4BE5198C.8070303@gnutls.org> <20100508084629.GC3269@downhill.g.la> <4BF2E791.2040202@gnutls.org> Message-ID: <20100519170401.GA3486@downhill.g.la> On 2010-05-18 Nikos Mavrogiannopoulos wrote: [...] > Correct patch attached (compiles). [...] Thank you. I will check, but probably will not find time to do so before mid of next week. cu andreas From simon at josefsson.org Fri May 21 14:00:50 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 21 May 2010 14:00:50 +0200 Subject: gnutls_safe_renegotiation_set? In-Reply-To: <8763352gx6.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 03 May 2010 16:33:57 +0200") References: <87ljc12ikg.fsf@mocca.josefsson.org> <8763352gx6.fsf@mocca.josefsson.org> Message-ID: <87ljbdqxal.fsf@mocca.josefsson.org> Simon Josefsson writes: > I'll remove these two APIs in a few days unless I hear objections. I've removed them now. I'm planning to prepare a new RC release over the weekend. /Simon From simon at josefsson.org Sat May 22 17:52:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 22 May 2010 17:52:05 +0200 Subject: safe renegotiation In-Reply-To: <4BF2EBD1.5000107@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 18 May 2010 21:34:41 +0200") References: <87y6g6oerc.fsf@mocca.josefsson.org> <87vdbamtvb.fsf@mocca.josefsson.org> <4BF2EBD1.5000107@gnutls.org> Message-ID: <87vdagc4t6.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >> >>> If people notice that no clients can connect on their servers will >>> either install an older version of gnutls that "works" or just go to >>> mod_ssl. Moreover it is problematic in the sense that an administrator >>> might not detect at all that his site is inaccessible and only find >>> out after losing customers or so. I think that fixing a security issue >>> but as a side-effect causing serious issues in interoperability with >>> old software is a recipe for people to move out of your software >>> (intel never managed to get rid of x86, and I don't think we can >>> afford it). >>> >>> Let's be conservative and wait. This issue proved not to be that >>> important in the internet (not many people upgraded because of this). >> >> According to Tomas, OpenSSL protect against this. If that is the case, >> I think the answer is simple: we should do the same. > > I've commited a patch that does that in git. Thanks! I think this solves the main remaining concern with the safe renegotiation stuff before a release... however documentation and self tests still needs to be written, I'll try to work on this now. /Simon From simon at josefsson.org Sat May 22 19:12:54 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 22 May 2010 19:12:54 +0200 Subject: safe renegotiation bug? Message-ID: <87hblzdfmx.fsf@mocca.josefsson.org> I have added tests/safe-renegotiation/srn5.c in which a client with support for safe reneg connect to a server without support for safe reneg. The handshake succeeds (as expected), however the call to gnutls_safe_renegotiation_status in the server, after the handshake, indicates that the session is using safe renegotiation -- this seems like a bug to me. Nikos/Steve, could you take a look? /Simon From nmav at gnutls.org Sat May 22 21:45:30 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 22 May 2010 21:45:30 +0200 Subject: safe renegotiation bug? In-Reply-To: <87hblzdfmx.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> Message-ID: <4BF8345A.2020009@gnutls.org> Simon Josefsson wrote: > I have added tests/safe-renegotiation/srn5.c in which a client with > support for safe reneg connect to a server without support for safe > reneg. The handshake succeeds (as expected), however the call to > gnutls_safe_renegotiation_status in the server, after the handshake, > indicates that the session is using safe renegotiation -- this seems > like a bug to me. Nikos/Steve, could you take a look? Should be ok now. I get aborts in the srn5 but they seem intended? From simon at josefsson.org Sat May 22 22:38:54 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 22 May 2010 22:38:54 +0200 Subject: safe renegotiation bug? In-Reply-To: <4BF8345A.2020009@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 22 May 2010 21:45:30 +0200") References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> Message-ID: <874ohzeko1.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> I have added tests/safe-renegotiation/srn5.c in which a client with >> support for safe reneg connect to a server without support for safe >> reneg. The handshake succeeds (as expected), however the call to >> gnutls_safe_renegotiation_status in the server, after the handshake, >> indicates that the session is using safe renegotiation -- this seems >> like a bug to me. Nikos/Steve, could you take a look? > > Should be ok now. I get aborts in the srn5 but they seem intended? I fixed that now -- however it seems there is another problem, now the rehandshake succeeds against a server that doesn't support safe renegotiation. The second handshake in srn5 should fail, shouldn't it? /Simon From nmav at gnutls.org Sun May 23 00:31:15 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 May 2010 00:31:15 +0200 Subject: safe renegotiation bug? In-Reply-To: <874ohzeko1.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> Message-ID: <4BF85B33.5040203@gnutls.org> Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> Simon Josefsson wrote: >>> I have added tests/safe-renegotiation/srn5.c in which a client with >>> support for safe reneg connect to a server without support for safe >>> reneg. The handshake succeeds (as expected), however the call to >>> gnutls_safe_renegotiation_status in the server, after the handshake, >>> indicates that the session is using safe renegotiation -- this seems >>> like a bug to me. Nikos/Steve, could you take a look? >> Should be ok now. I get aborts in the srn5 but they seem intended? > > I fixed that now -- however it seems there is another problem, now the > rehandshake succeeds against a server that doesn't support safe > renegotiation. The second handshake in srn5 should fail, shouldn't it? By default server is on unsafe renegotiation mode and doesn't require any of the extensions, either on the first or subsequent negotiations. Disallowing rengotiations after this point for the client shouldn't offer any advantage since you are already connected securely to a peer. The damage (for the client) is on the initial negotiation. But I might be wrong. It's too late for me :) regards, Nikos From simon at josefsson.org Mon May 24 21:50:24 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 May 2010 21:50:24 +0200 Subject: [Fwd: crash in GNUTLS-1.4.0] In-Reply-To: <87mzaax3hm.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sat, 12 Aug 2006 01:21:57 +0200") References: <44CB2B34.3030401@hyd.hellosoft.com> <87mzaax3hm.fsf@latte.josefsson.org> Message-ID: <87iq6d3wqn.fsf@mocca.josefsson.org> Tomas Hoger analyzed the problem further and provided this insight: The issue is a NULL pointer dereference crash that occurs during X509 certificate verification. Both clients and server could be affected. Attacker needs to have a certificate using hash algorithm not supported by the affected GnuTLS version, that was issued by a trusted CA. There wasn't any CVE for this vulnerability before, but we've assigned CVE-2006-7239 to it now. I've updated our web site about this: http://www.gnu.org/software/gnutls/security.html Note that this problem was fixed in GnuTLS version 1.4.2 which was released back in August 2006. /Simon Simon Josefsson writes: > With some guess-work, I was able to reproduce the problem, and the > patch is below. I'm not yet sure what it is that trigger the problem. > If I replace the server key/certificate with another pair, it doesn't > crash, and if I instead replace the CA certificate with another CA > certificate, it doesn't crash either. So it seems it is a combination > with the particular CA certificate and server key/certificate that you > sent. > > I'm going away over the weekend, so if anybody here wants to analyze > this further, that would be appreciated. Here is the recipe to > reproduce the crash: > > $ gnutls-serv --x509keyfile key.pem --x509certfile newcert.pem > ... > $ gnutls-cli --x509cafile cacert.pem --port 5556 localhost > > I'm labeling this problem as GNUTLS-SA-2006-02 because, under some > unclear situations, it is a remotely triggered crash of clients. > > /Simon > > Index: gnutls_algorithms.c > =================================================================== > RCS file: /cvs/gnutls/gnutls/lib/gnutls_algorithms.c,v > retrieving revision 2.156 > retrieving revision 2.157 > diff -u -p -r2.156 -r2.157 > --- gnutls_algorithms.c 15 Dec 2005 13:24:29 -0000 2.156 > +++ gnutls_algorithms.c 11 Aug 2006 22:40:36 -0000 2.157 > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2000, 2002, 2003, 2004, 2005 Free Software Foundation > + * Copyright (C) 2000, 2002, 2003, 2004, 2005, 2006 Free Software Foundation > * > * Author: Nikos Mavroyanopoulos > * > @@ -563,7 +563,7 @@ _gnutls_x509_oid2mac_algorithm (const ch > { > gnutls_mac_algorithm_t ret = 0; > > - GNUTLS_HASH_LOOP (if (strcmp (oid, p->oid) == 0) > + GNUTLS_HASH_LOOP (if (p->oid && strcmp (oid, p->oid) == 0) > { > ret = p->id; break;} > ); > > > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev From nmav at gnutls.org Mon May 24 23:49:01 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 24 May 2010 23:49:01 +0200 Subject: [Fwd: crash in GNUTLS-1.4.0] In-Reply-To: <87iq6d3wqn.fsf@mocca.josefsson.org> References: <44CB2B34.3030401@hyd.hellosoft.com> <87mzaax3hm.fsf@latte.josefsson.org> <87iq6d3wqn.fsf@mocca.josefsson.org> Message-ID: <4BFAF44D.8020909@gnutls.org> Simon Josefsson wrote: Nice to know. I've commited a similar check for other structures that used strcmp as well. regards, Nikos > Tomas Hoger analyzed the problem further and provided this insight: > > The issue is a NULL pointer dereference crash that occurs during X509 > certificate verification. Both clients and server could be affected. > Attacker needs to have a certificate using hash algorithm not > supported by the affected GnuTLS version, that was issued by a trusted > CA. > > There wasn't any CVE for this vulnerability before, but we've assigned > CVE-2006-7239 to it now. I've updated our web site about this: > http://www.gnu.org/software/gnutls/security.html > > Note that this problem was fixed in GnuTLS version 1.4.2 which was > released back in August 2006. > > /Simon > > Simon Josefsson writes: > >> With some guess-work, I was able to reproduce the problem, and the >> patch is below. I'm not yet sure what it is that trigger the problem. >> If I replace the server key/certificate with another pair, it doesn't >> crash, and if I instead replace the CA certificate with another CA >> certificate, it doesn't crash either. So it seems it is a combination >> with the particular CA certificate and server key/certificate that you >> sent. >> >> I'm going away over the weekend, so if anybody here wants to analyze >> this further, that would be appreciated. Here is the recipe to >> reproduce the crash: >> >> $ gnutls-serv --x509keyfile key.pem --x509certfile newcert.pem >> ... >> $ gnutls-cli --x509cafile cacert.pem --port 5556 localhost >> >> I'm labeling this problem as GNUTLS-SA-2006-02 because, under some >> unclear situations, it is a remotely triggered crash of clients. >> >> /Simon >> >> Index: gnutls_algorithms.c >> =================================================================== >> RCS file: /cvs/gnutls/gnutls/lib/gnutls_algorithms.c,v >> retrieving revision 2.156 >> retrieving revision 2.157 >> diff -u -p -r2.156 -r2.157 >> --- gnutls_algorithms.c 15 Dec 2005 13:24:29 -0000 2.156 >> +++ gnutls_algorithms.c 11 Aug 2006 22:40:36 -0000 2.157 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (C) 2000, 2002, 2003, 2004, 2005 Free Software Foundation >> + * Copyright (C) 2000, 2002, 2003, 2004, 2005, 2006 Free Software Foundation >> * >> * Author: Nikos Mavroyanopoulos >> * >> @@ -563,7 +563,7 @@ _gnutls_x509_oid2mac_algorithm (const ch >> { >> gnutls_mac_algorithm_t ret = 0; >> >> - GNUTLS_HASH_LOOP (if (strcmp (oid, p->oid) == 0) >> + GNUTLS_HASH_LOOP (if (p->oid && strcmp (oid, p->oid) == 0) >> { >> ret = p->id; break;} >> ); >> >> >> >> _______________________________________________ >> Gnutls-dev mailing list >> Gnutls-dev at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnutls-dev > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From thoger at redhat.com Tue May 25 14:54:00 2010 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 25 May 2010 14:54:00 +0200 Subject: [Fwd: crash in GNUTLS-1.4.0] In-Reply-To: <4BFAF44D.8020909@gnutls.org> References: <44CB2B34.3030401@hyd.hellosoft.com> <87mzaax3hm.fsf@latte.josefsson.org> <87iq6d3wqn.fsf@mocca.josefsson.org> <4BFAF44D.8020909@gnutls.org> Message-ID: <20100525145400.6803606a@redhat.com> On Mon, 24 May 2010 23:49:01 +0200 Nikos Mavrogiannopoulos wrote: > Nice to know. I've commited a similar check for other structures that > used strcmp as well. Good catch. The fix should not be required in current GnuTLS versions as, unlike hash_algorithms[], sign_algorithms[] and pk_algorithms[] don't contain entries with non-NULL name and NULL oid. th. From nmav at gnutls.org Tue May 25 15:53:10 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 25 May 2010 15:53:10 +0200 Subject: [Fwd: crash in GNUTLS-1.4.0] In-Reply-To: <20100525145400.6803606a@redhat.com> References: <44CB2B34.3030401@hyd.hellosoft.com> <87mzaax3hm.fsf@latte.josefsson.org> <87iq6d3wqn.fsf@mocca.josefsson.org> <4BFAF44D.8020909@gnutls.org> <20100525145400.6803606a@redhat.com> Message-ID: <4BFBD646.2010802@gnutls.org> Tomas Hoger wrote: > On Mon, 24 May 2010 23:49:01 +0200 Nikos Mavrogiannopoulos wrote: > >> Nice to know. I've commited a similar check for other structures that >> used strcmp as well. > > Good catch. The fix should not be required in current GnuTLS versions > as, unlike hash_algorithms[], sign_algorithms[] and pk_algorithms[] > don't contain entries with non-NULL name and NULL oid. Better safe than sorry :) From joelisaachart at gmail.com Thu May 27 00:22:57 2010 From: joelisaachart at gmail.com (Joel Hart) Date: Wed, 26 May 2010 16:22:57 -0600 Subject: Hello! Message-ID: <71240B81-E4E6-4541-863F-58484D0A05C5@gmail.com> Hi, I've got GNU_TLS installed on apache 2.2.11. I have 2 vhosts using gnutls to server the certs. Everything starts up fine in apache server, however when I goto the second vhosted site I get a server name mismatch error. Can anyone tell me why it seems like SNI is not happening? Joel From ametzler at downhill.at.eu.org Thu May 27 19:08:23 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 27 May 2010 19:08:23 +0200 Subject: gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.) In-Reply-To: <4BF2E791.2040202@gnutls.org> References: <20100508072954.GB3269@downhill.g.la> <4BE5198C.8070303@gnutls.org> <20100508084629.GC3269@downhill.g.la> <4BF2E791.2040202@gnutls.org> Message-ID: <20100527170823.GC3368@downhill.g.la> On 2010-05-18 Nikos Mavrogiannopoulos wrote: > Andreas Metzler wrote: > > Hello, > > Doable, but not without pain. Exim exposes the gnutls_priority_* > > functions to the user (see options tls_require_ciphers et al in > > http://docs.exim.org/current/spec_html/ch39.html#SECTreqciphgnu) > > switching would cause an configuration file syntax change. - It could > > either ignore the old settings while still warning about them or > > throw an error (invalid setting). > Correct patch attached (compiles). [...] Worked for me. Thanks. I am uploading it to Debian to get verification by the original bug submitter. cu andreas From simon at josefsson.org Fri May 28 09:07:50 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 28 May 2010 09:07:50 +0200 Subject: safe renegotiation bug? In-Reply-To: <4BF85B33.5040203@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 23 May 2010 00:31:15 +0200") References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> Message-ID: <87typs7bcp.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Nikos Mavrogiannopoulos writes: >> >>> Simon Josefsson wrote: >>>> I have added tests/safe-renegotiation/srn5.c in which a client with >>>> support for safe reneg connect to a server without support for safe >>>> reneg. The handshake succeeds (as expected), however the call to >>>> gnutls_safe_renegotiation_status in the server, after the handshake, >>>> indicates that the session is using safe renegotiation -- this seems >>>> like a bug to me. Nikos/Steve, could you take a look? >>> Should be ok now. I get aborts in the srn5 but they seem intended? >> >> I fixed that now -- however it seems there is another problem, now the >> rehandshake succeeds against a server that doesn't support safe >> renegotiation. The second handshake in srn5 should fail, shouldn't it? > > By default server is on unsafe renegotiation mode and doesn't require > any of the extensions, either on the first or subsequent negotiations. > Disallowing rengotiations after this point for the client shouldn't > offer any advantage since you are already connected securely to a peer. But this self tests is with a server that has safe renegotiation disabled, see tests/safe-renegotiation/srn5.c. The client by default permits connections, but I don't think clients should (by default) allow renegotiation against such servers. /Simon From simon at josefsson.org Fri May 28 09:26:21 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 28 May 2010 09:26:21 +0200 Subject: release In-Reply-To: <87k4qo7b62.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 28 May 2010 09:11:49 +0200") References: <4BFE9AE1.6080109@gnutls.org> <87k4qo7b62.fsf@mocca.josefsson.org> Message-ID: <87aark7ahu.fsf@mocca.josefsson.org> Simon Josefsson writes: > Items left is to write and check the safe renegotiation self tests > and to update the documentation section for it. I think there are bugs > in both those parts right now, that's why I haven't made any releases. Nikos, I have updated the manual now to describe what I believe the behaviour should be -- could you check that it matches your interpretation? Note that I'm not sure how %INITIAL_SAFE_RENEGOTIATION fits into this picture. I also suspect we want a priority string (e.g. %PARTIAL_RENEGOTIATION) to describe today's default behaviour of permitting initial handshakes but not rehandshakes -- so that clients/servers can use it and be forward-compatible even when/if we change the default to make clients/servers refuse initial handshakes without the extension. Once we agree on how the manual should look like, I'll write self tests for the various variants (there seems to be many different variants to consider!), so we make sure that the code actually does what we think it should. /Simon From nmav at gnutls.org Fri May 28 09:31:32 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 May 2010 09:31:32 +0200 Subject: safe renegotiation bug? In-Reply-To: <87typs7bcp.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> Message-ID: <4BFF7154.3060700@gnutls.org> Simon Josefsson wrote: >>>> Should be ok now. I get aborts in the srn5 but they seem intended? >>> I fixed that now -- however it seems there is another problem, now the >>> rehandshake succeeds against a server that doesn't support safe >>> renegotiation. The second handshake in srn5 should fail, shouldn't it? >> By default server is on unsafe renegotiation mode and doesn't require >> any of the extensions, either on the first or subsequent negotiations. >> Disallowing rengotiations after this point for the client shouldn't >> offer any advantage since you are already connected securely to a peer. > > But this self tests is with a server that has safe renegotiation > disabled, see tests/safe-renegotiation/srn5.c. > > The client by default permits connections, but I don't think clients > should (by default) allow renegotiation against such servers. Why? From nmav at gnutls.org Fri May 28 09:48:14 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 May 2010 09:48:14 +0200 Subject: release In-Reply-To: <87aark7ahu.fsf@mocca.josefsson.org> References: <4BFE9AE1.6080109@gnutls.org> <87k4qo7b62.fsf@mocca.josefsson.org> <87aark7ahu.fsf@mocca.josefsson.org> Message-ID: <4BFF753E.8090102@gnutls.org> Simon Josefsson wrote: > Simon Josefsson writes: > >> Items left is to write and check the safe renegotiation self tests >> and to update the documentation section for it. I think there are bugs >> in both those parts right now, that's why I haven't made any releases. > > Nikos, I have updated the manual now to describe what I believe the > behaviour should be -- could you check that it matches your > interpretation? > Note that I'm not sure how %INITIAL_SAFE_RENEGOTIATION fits into this > picture. I've update it to include it. Check it and let me know if you agree. > I also suspect we want a priority string (e.g. %PARTIAL_RENEGOTIATION) > to describe today's default behaviour of permitting initial handshakes > but not rehandshakes -- so that clients/servers can use it and be > forward-compatible even when/if we change the default to make > clients/servers refuse initial handshakes without the extension. I believe you are talking about the %SAFE_RENEGOTIATION string not enforcing the extension on every connection (negotiation or renegotiation). This is ok since the threat is not on the server. Server is not less secure without the extension. The SAFE_RENEGOTIATION flag on the server is there to protect the client and this protection should be during renegotiation according to the threat. The INITIAL_SAFE_RENEGOTIATION is there to enforce clients to upgrade, by denying access to them if they do not support the extension. It does not increase security on any of the client or server. regards, Nikos From simon at josefsson.org Fri May 28 09:48:31 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 28 May 2010 09:48:31 +0200 Subject: safe renegotiation bug? In-Reply-To: <4BFF7154.3060700@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 28 May 2010 09:31:32 +0200") References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> Message-ID: <87typs5uwg.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >>>>> Should be ok now. I get aborts in the srn5 but they seem intended? >>>> I fixed that now -- however it seems there is another problem, now the >>>> rehandshake succeeds against a server that doesn't support safe >>>> renegotiation. The second handshake in srn5 should fail, shouldn't it? >>> By default server is on unsafe renegotiation mode and doesn't require >>> any of the extensions, either on the first or subsequent negotiations. >>> Disallowing rengotiations after this point for the client shouldn't >>> offer any advantage since you are already connected securely to a peer. >> >> But this self tests is with a server that has safe renegotiation >> disabled, see tests/safe-renegotiation/srn5.c. >> >> The client by default permits connections, but I don't think clients >> should (by default) allow renegotiation against such servers. > > Why? To me it was more that I couldn't answer 'Why not?'. I'm not sure what the balance should be. We already decided that (by default) we can't disable everything we know is insecure due to interop, so decisions whether to enable/disable other things by default is subjective. NSS does not allow upgraded clients to renegotiate with unupgraded servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes /Simon From tmraz at redhat.com Fri May 28 09:58:04 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 28 May 2010 09:58:04 +0200 Subject: safe renegotiation bug? In-Reply-To: <87typs5uwg.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> Message-ID: <1275033484.10368.403.camel@vespa.frost.loc> On Fri, 2010-05-28 at 09:48 +0200, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > > Simon Josefsson wrote: > > > >>>>> Should be ok now. I get aborts in the srn5 but they seem intended? > >>>> I fixed that now -- however it seems there is another problem, now the > >>>> rehandshake succeeds against a server that doesn't support safe > >>>> renegotiation. The second handshake in srn5 should fail, shouldn't it? > >>> By default server is on unsafe renegotiation mode and doesn't require > >>> any of the extensions, either on the first or subsequent negotiations. > >>> Disallowing rengotiations after this point for the client shouldn't > >>> offer any advantage since you are already connected securely to a peer. > >> > >> But this self tests is with a server that has safe renegotiation > >> disabled, see tests/safe-renegotiation/srn5.c. > >> > >> The client by default permits connections, but I don't think clients > >> should (by default) allow renegotiation against such servers. > > > > Why? > > To me it was more that I couldn't answer 'Why not?'. I'm not sure what > the balance should be. We already decided that (by default) we can't > disable everything we know is insecure due to interop, so decisions > whether to enable/disable other things by default is subjective. > > NSS does not allow upgraded clients to renegotiate with unupgraded > servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes Note that the same decision was made also by OpenSSL developers. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From nmav at gnutls.org Fri May 28 10:05:40 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 May 2010 10:05:40 +0200 Subject: safe renegotiation bug? In-Reply-To: <87typs5uwg.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> Message-ID: <4BFF7954.3030101@gnutls.org> Simon Josefsson wrote: >>> The client by default permits connections, but I don't think clients >>> should (by default) allow renegotiation against such servers. >> Why? > > To me it was more that I couldn't answer 'Why not?'. I'm not sure what > the balance should be. We already decided that (by default) we can't > disable everything we know is insecure due to interop, so decisions > whether to enable/disable other things by default is subjective. > > NSS does not allow upgraded clients to renegotiate with unupgraded > servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes I do not believe this is a threat since you have already connected to the server and anyway he can do whatever he wants (he can do mitm with any other place he chooses even if you do support safe renegotiation). Anyway I would not object if you add this, I really see it very minor issue. For me if it proves to be a problem it could be fixed a minor release. The current stable version of gnutls does not support any kind of renegotiation protection and this is much worse. regards, Nikos From tmraz at redhat.com Fri May 28 10:05:26 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 28 May 2010 10:05:26 +0200 Subject: safe renegotiation bug? In-Reply-To: <87typs5uwg.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> Message-ID: <1275033926.10368.408.camel@vespa.frost.loc> On Fri, 2010-05-28 at 09:48 +0200, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > > Simon Josefsson wrote: > > > >>>>> Should be ok now. I get aborts in the srn5 but they seem intended? > >>>> I fixed that now -- however it seems there is another problem, now the > >>>> rehandshake succeeds against a server that doesn't support safe > >>>> renegotiation. The second handshake in srn5 should fail, shouldn't it? > >>> By default server is on unsafe renegotiation mode and doesn't require > >>> any of the extensions, either on the first or subsequent negotiations. > >>> Disallowing rengotiations after this point for the client shouldn't > >>> offer any advantage since you are already connected securely to a peer. > >> > >> But this self tests is with a server that has safe renegotiation > >> disabled, see tests/safe-renegotiation/srn5.c. > >> > >> The client by default permits connections, but I don't think clients > >> should (by default) allow renegotiation against such servers. > > > > Why? > > To me it was more that I couldn't answer 'Why not?'. I'm not sure what > the balance should be. We already decided that (by default) we can't > disable everything we know is insecure due to interop, so decisions > whether to enable/disable other things by default is subjective. > > NSS does not allow upgraded clients to renegotiate with unupgraded > servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes I've already argued about this before. Although in case of connecting to a server which does not have the renegotiation extension support the connection might be vulnerable. It as well might not be in case the server has renegotiation support turned off completely. On the other hand if the client successfully renegotiates with such server or the server requests renegotiation, the client now positively knows that the connection is vulnerable. So doing it like this seems to me as a reasonable compromise as there might be reasons why implementing the renegotiation extension on some legacy server was not feasible but it was possible to switch off the renegotiations on it completely making it non-vulnerable to the attack. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From nmav at gnutls.org Sat May 29 02:09:48 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 29 May 2010 02:09:48 +0200 Subject: safe renegotiation bug? In-Reply-To: <87typs5uwg.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> Message-ID: <4C005B4C.7030606@gnutls.org> Simon Josefsson wrote: >>> The client by default permits connections, but I don't think clients >>> should (by default) allow renegotiation against such servers. >> Why? > > To me it was more that I couldn't answer 'Why not?'. I'm not sure what > the balance should be. We already decided that (by default) we can't > disable everything we know is insecure due to interop, so decisions > whether to enable/disable other things by default is subjective. > > NSS does not allow upgraded clients to renegotiate with unupgraded > servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes Simon, Actually this is not what I understand from their release notes. Their transitional flag (SSL_RENEGOTIATE_TRANSITIONAL) does what we do now. Safe renegotiation by default on server and unsafe on client[0]. Their flag SSL_RENEGOTIATE_REQUIRES_XTN is our SAFE_RENEGOTIATION flag. Moreover by thinking it, I believe that the behavior of %UNSAFE_RENEGOTIATION to the client, that you check with srn5 is correct. It should have allowed the client to renegotiate. This is its purpose, compatibility with old servers, and I believe that this is what you documented in the manual[1] as well? [0]. Disallows unsafe renegotiation in server sockets only, but allows clients to continue to renegotiate with vulnerable servers. This value should only be used during the transition period when few servers have been upgraded. [1]. The @code{%UNSAFE_RENEGOTIATION} priority string permits (re-)handshakes even when the safe renegotiation extension was not negotiated. From simon at josefsson.org Mon May 31 19:23:35 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 May 2010 19:23:35 +0200 Subject: release In-Reply-To: <4BFF753E.8090102@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 28 May 2010 09:48:14 +0200") References: <4BFE9AE1.6080109@gnutls.org> <87k4qo7b62.fsf@mocca.josefsson.org> <87aark7ahu.fsf@mocca.josefsson.org> <4BFF753E.8090102@gnutls.org> Message-ID: <87r5ksj888.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Simon Josefsson writes: >> >>> Items left is to write and check the safe renegotiation self tests >>> and to update the documentation section for it. I think there are bugs >>> in both those parts right now, that's why I haven't made any releases. >> >> Nikos, I have updated the manual now to describe what I believe the >> behaviour should be -- could you check that it matches your >> interpretation? >> Note that I'm not sure how %INITIAL_SAFE_RENEGOTIATION fits into this >> picture. > I've update it to include it. Check it and let me know if you agree. Looks good, although I changed 'connections' to '(re-)handshakes' to be more consistent with the rest of the section. >> I also suspect we want a priority string (e.g. %PARTIAL_RENEGOTIATION) >> to describe today's default behaviour of permitting initial handshakes >> but not rehandshakes -- so that clients/servers can use it and be >> forward-compatible even when/if we change the default to make >> clients/servers refuse initial handshakes without the extension. > > I believe you are talking about the %SAFE_RENEGOTIATION string not > enforcing the extension on every connection (negotiation or > renegotiation). This is ok since the threat is not on the server. Server > is not less secure without the extension. The SAFE_RENEGOTIATION flag > on the server is there to protect the client and this protection should > be during renegotiation according to the threat. The > INITIAL_SAFE_RENEGOTIATION is there to enforce clients to upgrade, by > denying access to them if they do not support the extension. It does not > increase security on any of the client or server. I think this makes sense. I'll try to push out 2.9.11 tonight.. /Simon From simon at josefsson.org Mon May 31 19:54:40 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 May 2010 19:54:40 +0200 Subject: safe renegotiation bug? In-Reply-To: <4C005B4C.7030606@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 29 May 2010 02:09:48 +0200") References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org> Message-ID: <874ohoj6sf.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >>>> The client by default permits connections, but I don't think clients >>>> should (by default) allow renegotiation against such servers. >>> Why? >> >> To me it was more that I couldn't answer 'Why not?'. I'm not sure what >> the balance should be. We already decided that (by default) we can't >> disable everything we know is insecure due to interop, so decisions >> whether to enable/disable other things by default is subjective. >> >> NSS does not allow upgraded clients to renegotiate with unupgraded >> servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes > > Simon, > Actually this is not what I understand from their release notes. Their > transitional flag (SSL_RENEGOTIATE_TRANSITIONAL) does what we do now. But it is not NSS's default behaviour. > Safe renegotiation by default on server and unsafe on client[0]. > > Their flag SSL_RENEGOTIATE_REQUIRES_XTN is our SAFE_RENEGOTIATION flag. I think it is SAFE_RENEGOTIATION + INITIAL_SAFE_RENEGOTIATION. > Moreover by thinking it, I believe that the behavior of > %UNSAFE_RENEGOTIATION to the client, that you check with srn5 is > correct. It should have allowed the client to renegotiate. This is its > purpose, compatibility with old servers, The client in srn5 uses the default settings. Permitting clients to rehandshake without safe renegotiation seems like a bad idea to me -- then the client _knows_ it may be talking to an attacker. That is a default-unsafe behaviour, and there is no significant interop issue to consider for rehandshakes. > and I believe that this is what you documented in the manual[1] as > well? No -- the manual says: GnuTLS supports the safe renegotiation extension. The default behavior is as follows. Clients will attempt to negotiate the safe renegotiation extension when talking to servers. Servers will accept the extension when presented by clients. Clients and servers will permit an initial handshake to complete even when the other side does not support the safe renegotiation extension. Clients and servers will refuse renegotiation attempts when the extension has not been negotiated. I don't think that is (especially last sentence) what is implemented now. I would prefer to implement what is described in that text (because it seems to make sense to me), but we could change the text to match what is implemented (more relaxed approach). /Simon From nmav at gnutls.org Mon May 31 20:40:03 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 31 May 2010 20:40:03 +0200 Subject: safe renegotiation bug? In-Reply-To: <874ohoj6sf.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org> <874ohoj6sf.fsf@mocca.josefsson.org> Message-ID: <4C040283.8040603@gnutls.org> Simon Josefsson wrote: > GnuTLS supports the safe renegotiation extension. The default > behavior is as follows. Clients will attempt to negotiate the safe > renegotiation extension when talking to servers. Servers will accept > the extension when presented by clients. Clients and servers will > permit an initial handshake to complete even when the other side does > not support the safe renegotiation extension. Clients and servers > will refuse renegotiation attempts when the extension has not been > negotiated. > > I don't think that is (especially last sentence) what is implemented > now. I would prefer to implement what is described in that text > (because it seems to make sense to me), but we could change the text to > match what is implemented (more relaxed approach). I'd prefer to keep the current behavior because it allows clients to have a maximum compatibility when %UNSAFE_RENEGOTIATION is specified, which was my purpose of it. Maybe some other flag could be introduced such as %INITIAL_UNSAFE_RENEGOTIATION, but this can happen at any point later. regards, Nikos From simon at josefsson.org Mon May 31 21:30:22 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 May 2010 21:30:22 +0200 Subject: safe renegotiation bug? In-Reply-To: <4C040283.8040603@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 31 May 2010 20:40:03 +0200") References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org> <874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org> Message-ID: <87sk57g981.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >> GnuTLS supports the safe renegotiation extension. The default >> behavior is as follows. Clients will attempt to negotiate the safe >> renegotiation extension when talking to servers. Servers will accept >> the extension when presented by clients. Clients and servers will >> permit an initial handshake to complete even when the other side does >> not support the safe renegotiation extension. Clients and servers >> will refuse renegotiation attempts when the extension has not been >> negotiated. >> >> I don't think that is (especially last sentence) what is implemented >> now. I would prefer to implement what is described in that text >> (because it seems to make sense to me), but we could change the text to >> match what is implemented (more relaxed approach). > > I'd prefer to keep the current behavior because it allows clients to > have a maximum compatibility when %UNSAFE_RENEGOTIATION is specified, > which was my purpose of it. Maybe some other flag could be introduced > such as %INITIAL_UNSAFE_RENEGOTIATION, but this can happen at any point > later. Then there is no way to make clients allow initial handshakes but disallow renegotiations. That goes against a RECOMMENDED in RFC 5746: 4.2. Client Behavior: Legacy (Insecure) Renegotiation This text applies if the connection's "secure_renegotiation" flag is set to FALSE. It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients that do so MUST respond to such requests with a "no_renegotiation" alert (RFC 5246 requires this alert to be at the "warning" level). It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. If clients nevertheless choose to renegotiate, they MUST behave as described below. I would prefer a good reason to do something like that. I don't understand your "because it allows clients to have a maximum compatibility when %UNSAFE_RENEGOTIATION is specified". Changing the _default_ behaviour to follow the RFCs recommendation would not change what happens when %UNSAFE_RENEGOTIATION is specified. And indeed, with %UNSAFE_RENEGOTIATION clients do have maximum compatibility already. Could you clarify what you meant here? /Simon From nmav at gnutls.org Mon May 31 22:32:34 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 31 May 2010 22:32:34 +0200 Subject: safe renegotiation bug? In-Reply-To: <87sk57g981.fsf@mocca.josefsson.org> References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org> <874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org> <87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org> <87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org> <874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org> <87sk57g981.fsf@mocca.josefsson.org> Message-ID: <4C041CE2.3060006@gnutls.org> Simon Josefsson wrote: > Then there is no way to make clients allow initial handshakes but > disallow renegotiations. That goes against a RECOMMENDED in RFC 5746: > > 4.2. Client Behavior: Legacy (Insecure) Renegotiation > > This text applies if the connection's "secure_renegotiation" flag is > set to FALSE. > > It is possible that un-upgraded servers will request that the client > renegotiate. It is RECOMMENDED that clients refuse this > renegotiation request. Clients that do so MUST respond to such > requests with a "no_renegotiation" alert (RFC 5246 requires this > alert to be at the "warning" level). It is possible that the > apparently un-upgraded server is in fact an attacker who is then > allowing the client to renegotiate with a different, legitimate, > upgraded server. If clients nevertheless choose to renegotiate, they > MUST behave as described below. > > I would prefer a good reason to do something like that. > > I don't understand your "because it allows clients to have a maximum > compatibility when %UNSAFE_RENEGOTIATION is specified". Changing the > _default_ behaviour to follow the RFCs recommendation would not change > what happens when %UNSAFE_RENEGOTIATION is specified. And indeed, with > %UNSAFE_RENEGOTIATION clients do have maximum compatibility already. > Could you clarify what you meant here? I mean that the default now for the client is %UNSAFE_RENEGOTIATION. As far as I understand what you propose is to add an extra level for the client that allows initial negotiation but not subsequent ones. Am I right? To be honest I'd prefer to modify unsafe renegotiation to do what you propose rather than adding an extra level. The code getting more and more complicated as well as the behavior. It might be better to have few easily explained states, rather than a bunch. With this change clients using gnutls would need to specify %DISABLE_SAFE_RENEGOTIATION to have the compatibility behavior (which is not so good but one has to draw a line somewhere between keeping things simple and supporting everything). So which solution do you prefer? regards, Nikos