From ametzler at downhill.at.eu.org Sun Jan 3 15:04:46 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 3 Jan 2010 15:04:46 +0100 Subject: Typo fixes Message-ID: <20100103140446.GA3289@downhill.g.la> Hello, find attached some typo fixes (documentaton and comments). cu andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Typo-fix-s-prefered-preferred.patch Type: text/x-diff Size: 2720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Typo-fixes-succesful-precendence.patch Type: text/x-diff Size: 2354 bytes Desc: not available URL: From ametzler at downhill.at.eu.org Sun Jan 3 16:16:52 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 3 Jan 2010 16:16:52 +0100 Subject: libtasn1: Typos Message-ID: <20100103151652.GB3289@downhill.g.la> Hello, comments in tasn1 talk about a "create_stucture" function, I think the respective function is called asn1_create_element. Patch attached. Please doublecheck. cu andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Typos-sructure-stucture.-There-is-no-function-named-.patch Type: text/x-diff Size: 3416 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jan 5 05:59:24 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 Jan 2010 23:59:24 -0500 Subject: Typo fixes In-Reply-To: <20100103140446.GA3289@downhill.g.la> References: <20100103140446.GA3289@downhill.g.la> Message-ID: <4B42C72C.4070404@fifthhorseman.net> On 01/03/2010 09:04 AM, Andreas Metzler wrote: > find attached some typo fixes (documentaton and comments). applied, thanks! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Jan 5 06:11:00 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Jan 2010 00:11:00 -0500 Subject: libtasn1: Typos In-Reply-To: <20100103151652.GB3289@downhill.g.la> References: <20100103151652.GB3289@downhill.g.la> Message-ID: <4B42C9E4.9080508@fifthhorseman.net> On 01/03/2010 10:16 AM, Andreas Metzler wrote: > comments in tasn1 talk about a "create_stucture" function, I think the > respective function is called asn1_create_element. Patch attached. > Please doublecheck. It looks reasaonable to me, but I haven't worked with libtasn1 enough to feel confident in my own assessment of this patch, particularly with Andreas' "please doublecheck" request. Could someone else assess it and apply it if it's good? sorry to not be able to clear this out with the typos. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From ametzler at downhill.at.eu.org Sat Jan 9 16:34:08 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 9 Jan 2010 16:34:08 +0100 Subject: Certificate expiration not checked by gnutls-cli [GNUTLS-SA-2009-3] [CVE-2009-1417] In-Reply-To: <87bpqe77g7.fsf@mocca.josefsson.org> References: <87bpqe77g7.fsf@mocca.josefsson.org> Message-ID: <20100109153408.GA3320@downhill.g.la> On 2009-04-30 Simon Josefsson wrote: [...] > We have set up three demo URLs with expired certificates for testing > purposes: > https://expired.demo.gnutls.org/ - Expired server certificate [...] > You can test them like this: > jas at mocca:~$ gnutls-cli expired.demo.gnutls.org > Resolving 'expired.demo.gnutls.org'... > Connecting to '207.192.75.61:443'... > - Ephemeral Diffie-Hellman parameters > - Using prime: 2056 bits > - Secret key: 2047 bits > - Peer's public key: 2048 bits > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > # The hostname in the certificate matches 'expired.demo.gnutls.org'. > # valid since: Wed Apr 22 00:00:58 CEST 2009 > # expires at: Thu Apr 23 00:00:58 CEST 2009 > # fingerprint: 97:B9:94:8C:4F:29:31:56:CD:85:9F:8D:D5:4E:D2:4E > # Subject's DN: CN=expired.demo.gnutls.org > # Issuer's DN: O=CA for expired.demo.gnutls.org > # error: certificate has expired > jas at mocca:~$ > The expected behaviour is that gnutls-cli should complain that the > certificate has expired for all URLs. [...] > if (status & GNUTLS_CERT_SIGNER_NOT_FOUND) > printf ("- Peer's certificate issuer is unknown\n"); > + if (status & GNUTLS_CERT_NOT_ACTIVATED) > + printf ("- Peer's certificate chain uses not yet valid certificate\n"); > + if (status & GNUTLS_CERT_EXPIRED) > + printf ("- Peer's certificate chain uses expired certificate\n"); > if (status & GNUTLS_CERT_INVALID) > printf ("- Peer's certificate is NOT trusted\n"); > else Hello, this test does not work for me with any version of gnutls. There is no "error: certificate has expired" or even "Peer's certificate chain uses expired certificate". 2.4.2+patch: ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org Resolving 'expired.demo.gnutls.org'... Connecting to '207.192.75.61:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 2056 bits - Secret key: 2039 bits - Peer's public key: 2048 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'expired.demo.gnutls.org'. # valid since: Wed Apr 22 00:00:58 CEST 2009 # expires at: Thu Apr 23 00:00:58 CEST 2009 # fingerprint: 97:B9:94:8C:4F:29:31:56:CD:85:9F:8D:D5:4E:D2:4E # Subject's DN: CN=expired.demo.gnutls.org # Issuer's DN: O=CA for expired.demo.gnutls.org - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed 2.8.5 (SID)ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org Resolving 'expired.demo.gnutls.org'... Connecting to '207.192.75.61:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 2048 bits - Secret key: 2047 bits - Peer's public key: 2048 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=expired.demo.gnutls.org', issuer `O=CA for expired.demo.gnutls.org', RSA key 2048 bits, signed using RSA-SHA, activated `2009-04-21 22:00:58 UTC', expires `2009-04-22 22:00:58 UTC', SHA-1 fingerprint `55f198f9ff1777e9f202e1ac268fe8946f0c84b9' - The hostname in the certificate matches 'expired.demo.gnutls.org'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed 2.9.9: (SID)ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org Resolving 'expired.demo.gnutls.org'... Connecting to '207.192.75.61:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 2048 bits - Secret key: 2045 bits - Peer's public key: 2045 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=expired.demo.gnutls.org', issuer `O=CA for expired.demo.gnutls.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-04-21 22:00:58 UTC', expires `2009-04-22 22:00:58 UTC', SHA-1 fingerprint `55f198f9ff1777e9f202e1ac268fe8946f0c84b9' - The hostname in the certificate matches 'expired.demo.gnutls.org'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed 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' From nmav at gnutls.org Sun Jan 10 12:21:28 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jan 2010 12:21:28 +0100 Subject: libtasn1: Typos In-Reply-To: <20100103151652.GB3289@downhill.g.la> References: <20100103151652.GB3289@downhill.g.la> Message-ID: <4B49B838.4000102@gnutls.org> Andreas Metzler wrote: > Hello, > > comments in tasn1 talk about a "create_stucture" function, I think the > respective function is called asn1_create_element. Patch attached. > Please doublecheck. You are correct. Applied! regards, Nikos From nmav at gnutls.org Sun Jan 10 12:32:42 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jan 2010 12:32:42 +0100 Subject: bug: lib/gnutlsxx.cpp missing various ENABLE_XXX ifdefs In-Reply-To: <1261976066.7474.7.camel@neosoft.neocat.org> References: <1261976066.7474.7.camel@neosoft.neocat.org> Message-ID: <4B49BADA.4010308@gnutls.org> Bill Randle wrote: > I fixed my previous problem with the missing ifdef in mpi.c (see patch > below). Hello, Applied, thank you! A similar problem also exists in gnutlsxx.cpp where the only > ENABLE_XXX ifdefs are ENABLE_OPENPGP and ENABLE_SRP. There should also > be ifdefs for ENABLE_PKI and ENABLE_PSK (and perhaps others?). I don't think this is a serious issue. The functionality flags are to be used by embedded applications and I wouldn't consider the C++ api to be used there. best regards, Nikos From simon at josefsson.org Mon Jan 11 10:59:02 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 11 Jan 2010 10:59:02 +0100 Subject: getting a godaddy cert using certtool Message-ID: <874omt6jyx.fsf@mocca.josefsson.org> There has been some questions about getting certificates from commercial CAs using GnuTLS tools. I just bought a cert from godaddy and it worked fine. I was using certtool and thought I'd share the steps I used. I used GnuTLS 2.8.5 as packaged in Debian. $ certtool -p --outfile api2.yubico.com-key.pem Generating a 2048 bit RSA private key... $ $ certtool --generate-request --load-privkey api2.yubico.com-key.pem Generating a PKCS #10 certificate request... Country name (2 chars): SE Organization name: Yubico AB Organizational unit name: Locality name: State or province name: Common name: api2.yubico.com UID: Enter a dnsName of the subject of the certificate: api2.yubico.com Enter a dnsName of the subject of the certificate: Enter the IP address of the subject of the certificate: 74.207.251.59 Enter the e-mail of the subject of the certificate: Enter a challenge password: Does the certificate belong to an authority? (y/N): n Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): y Will the certificate be used for encryption (RSA ciphersuites)? (y/N): y Is this a TLS web client certificate? (y/N): n Is this also a TLS web server certificate? (y/N): y PKCS #10 Certificate Request Information: ... I cut'n'pasted the CSR printed in '...' above to Godaddy, and verified the domain ownership through their e-mail ping, and I was then able to download a ZIP file containing the certificate. There are some things I note in the certificate I got though: Key Purpose (not critical): TLS WWW Server. TLS WWW Client. This is even though I didn't ask for a WWW client cert! Key Usage (critical): Digital signature. Key encipherment. This seems right. Subject Alternative Name (not critical): DNSname: api2.yubico.com DNSname: www.api2.yubico.com They added a 'www.api2.yubico.com' name although I didn't ask for it. Note that they dropped the IP address SAN that I supplied. /Simon From dispensa at phonefactor.com Mon Jan 11 15:46:11 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Mon, 11 Jan 2010 08:46:11 -0600 Subject: Safe renegotiation patch Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1944@pos-exch1.corp.positivenetworks.net> All, I've updated the patch I initially submitted to conform to the new renegotiation draft. It's building and working, and I'm starting interoperability testing today. I hope to have something to post to the list for review in the next day or two. I wanted to run a couple of decisions by the group as to how this should work. I've modified GNUTLS to always send (only) the RI extension for TLS1+, and to send SCSV for SSLv3 initial client hellos. All other SSLv3 hellos use the extension, as required by the draft. Does that make sense? I'd be glad to explain my reasoning if you'd like. Also, I'm providing three API's: - gnutls_allow_unsafe_renegotiation - allows for "lenient" mode, where we'll agree to talk to a peer that doesn't indicate support for safe renegotiation - gnutls_allow_unsafe_initial_negotiation - allows servers to talk to a client that doesn't indicate support for safe renegotiation only as long as the client doesn't attempt to renegotiate (but drops the connection on any renegotiation attempt) Both default to off. Thoughts? Thanks. -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Jan 11 16:43:40 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 11 Jan 2010 16:43:40 +0100 Subject: Safe renegotiation patch In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1944@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1944@pos-exch1.corp.positivenetworks.net> Message-ID: On Mon, Jan 11, 2010 at 3:46 PM, Steve Dispensa wrote: > All, > > I've updated the patch I initially submitted to conform to the new > renegotiation draft. It's building and working, and I'm starting > interoperability testing today. I hope to have something to post to the list > for review in the next day or two. > I wanted to run a couple of decisions by the group as to how this should > work. I've modified GNUTLS to always send (only) the RI extension for TLS1+, > and to send SCSV for SSLv3 initial client hellos. All other SSLv3 hellos use > the extension, as required by the draft. Does that make sense? I'd be glad > to explain my reasoning if you'd like. Hello Steve, That sounds reasonable, however I am mostly concerned with the changes required to send the SCSV. I had also ported yesterday your previous patch to git (with modifications - mostly error checking, priority string support and the new draft changes except for SCSV), so it would be nice to sync them. If you post your code I could merge both codes. > Also, I'm providing three API's: > ?- gnutls_allow_unsafe_renegotiation - allows for "lenient" mode, where > we'll agree to talk to a peer that doesn't indicate support for safe > renegotiation Seems ok. > ?- gnutls_allow_unsafe_initial_negotiation - allows servers to talk to a > client that doesn't indicate support for safe renegotiation only as long as > the client doesn't attempt to renegotiate (but drops the connection on any > renegotiation attempt) Why this one is needed? Shouldn't all initial negotiations be accepted and fail only if renegotiation is requested? I believe this was the behavior of your previous patch. best regards, Nikos From dispensa at phonefactor.com Mon Jan 11 17:10:25 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Mon, 11 Jan 2010 10:10:25 -0600 Subject: Safe renegotiation patch In-Reply-To: References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1944@pos-exch1.corp.positivenetworks.net> Message-ID: <30822137-DDBE-4597-BBEA-8D439B2079BF@phonefactor.com> On Jan 11, 2010, at 9:43 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Jan 11, 2010 at 3:46 PM, Steve Dispensa > wrote: > >> All, >> >> I've updated the patch I initially submitted to conform to the new >> renegotiation draft. It's building and working, and I'm starting >> interoperability testing today. I hope to have something to post to >> the list >> for review in the next day or two. >> I wanted to run a couple of decisions by the group as to how this >> should >> work. I've modified GNUTLS to always send (only) the RI extension >> for TLS1+, >> and to send SCSV for SSLv3 initial client hellos. All other SSLv3 >> hellos use >> the extension, as required by the draft. Does that make sense? I'd >> be glad >> to explain my reasoning if you'd like. > > Hello Steve, > That sounds reasonable, however I am mostly concerned with the > changes required to send the SCSV. That part was fairly straightforward; the ugly part was getting it to send the RI extension for SSLv3 renegotiations. > I had also ported yesterday your previous patch to git (with > modifications - mostly error checking, priority string support and the > new draft changes except for SCSV), so it would be nice to sync them. > If you post your code I could merge both codes. That would be great. My code has changed pretty significantly; I ported it to the head of 2.9, so it was reorganized a bit. The extension processing is also updated, since the draft changed a bit. I'll try to get it cleaned up and sent over this evening. I believe it's about 800 lines. > >> Also, I'm providing three API's: I meant two, of course. :-) >> - gnutls_allow_unsafe_renegotiation - allows for "lenient" mode, >> where >> we'll agree to talk to a peer that doesn't indicate support for safe >> renegotiation > > Seems ok. > >> - gnutls_allow_unsafe_initial_negotiation - allows servers to talk >> to a >> client that doesn't indicate support for safe renegotiation only as >> long as >> the client doesn't attempt to renegotiate (but drops the connection >> on any >> renegotiation attempt) > > Why this one is needed? Shouldn't all initial negotiations be accepted > and fail only if renegotiation > is requested? I believe this was the behavior of your previous patch. A totally strict server may not want to allow unpatched clients, since those clients are unable to tell if they're being attacked. I defaulted it to off to be conservative from a security perspective. > > best regards, > Nikos -Steve From simon at josefsson.org Mon Jan 11 23:07:49 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 11 Jan 2010 23:07:49 +0100 Subject: libtasn1 2.4 release candidate Message-ID: <87wrzoe1my.fsf@mocca.josefsson.org> It is release time, and I'm starting with libtasn1 this time... Please check that this one works for you: http://daily.josefsson.org/libtasn1/libtasn1-20100111.tar.gz I'll release it as v2.4 next week or so unless there are any negative reports. /Simon From nmav at gnutls.org Mon Jan 11 23:11:44 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 11 Jan 2010 23:11:44 +0100 Subject: Safe renegotiation patch In-Reply-To: <30822137-DDBE-4597-BBEA-8D439B2079BF@phonefactor.com> References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1944@pos-exch1.corp.positivenetworks.net> <30822137-DDBE-4597-BBEA-8D439B2079BF@phonefactor.com> Message-ID: <4B4BA220.1070306@gnutls.org> Steve Dispensa wrote: >> Why this one is needed? Shouldn't all initial negotiations be accepted >> and fail only if renegotiation >> is requested? I believe this was the behavior of your previous patch. > > A totally strict server may not want to allow unpatched clients, since > those clients are unable to tell if they're being attacked. I defaulted > it to off to be conservative from a security perspective. I understand. However this will make the new release non-interoperable with anything else existing. Thus for now I believe this should be allowed and at a later point that secure renegotiation is common practice that should be by default off. regards, Nikos From dispensa at phonefactor.com Tue Jan 12 05:33:29 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Mon, 11 Jan 2010 22:33:29 -0600 Subject: Renegotiation patch Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E061204CD195D@pos-exch1.corp.positivenetworks.net> All, Here is an updated patch that conforms to the latest secure renegotiation draft (draft-ietf-tls-renegotiation-03). Included are a 570-line patch plus two new source files implementing the extension. This patch is still not quite perfect, but I wanted to get it into people's hands sooner rather than later, so here it is. Some of the remaining shortcomings: - Correct error return values (rather than -1) - Send appropriate alerts, as required by the draft - Documentation of the two new API's, as well as of the design - Automated test cases - Additional interoperability testing I've tested the basic functionality, but additional testing and code review would be much appreciated. The API's are still defaulted to secure (as opposed to interoperable) mode, which should probably change for the short run. -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-renegotiation-patch Type: application/octet-stream Size: 17242 bytes Desc: gnutls-renegotiation-patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ext_safe_renegotiation.c Type: application/octet-stream Size: 3341 bytes Desc: ext_safe_renegotiation.c URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ext_safe_renegotiation.h Type: application/octet-stream Size: 1109 bytes Desc: ext_safe_renegotiation.h URL: From dispensa at phonefactor.com Tue Jan 12 07:12:32 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Tue, 12 Jan 2010 00:12:32 -0600 Subject: DECR macro signedness Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1962@pos-exch1.corp.positivenetworks.net> Sorry if this is well known (I suspect it is, based on some of the code), but DECR_LEN and friends have an integer underflow problem if they're passed unsigned quantities. Spot-checking the code shows that it's generally called with signed quantities, but I didn't see any documentation pointing out the problem. Here's a patch if you want it; it uses the C99 intmax_t type to make a signed copy of the potentially unsigned argument for the negativity test. Apologies if this is old news. -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: decr_patch Type: application/octet-stream Size: 1050 bytes Desc: decr_patch URL: From nmav at gnutls.org Tue Jan 12 09:32:57 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 12 Jan 2010 09:32:57 +0100 Subject: DECR macro signedness In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1962@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD1962@pos-exch1.corp.positivenetworks.net> Message-ID: I like that change. In my version I had changed the input value to be signed instead, but it is better to have a generic macro to avoid issues like that. regards, Nikos On Tue, Jan 12, 2010 at 7:12 AM, Steve Dispensa wrote: > > Sorry if this is well known (I suspect it is, based on some of the code), > but DECR_LEN and friends have an integer underflow problem if they're passed > unsigned quantities. Spot-checking the code shows that it's generally called > with signed quantities, but I didn't see any documentation pointing out the > problem. > > Here's a patch if you want it; it uses the C99 intmax_t type to make a > signed copy of the potentially unsigned argument for the negativity test. > > Apologies if this is old news. > > ?-Steve > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From nmav at gnutls.org Tue Jan 12 20:27:52 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 12 Jan 2010 20:27:52 +0100 Subject: Renegotiation patch In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061204CD195D@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD195D@pos-exch1.corp.positivenetworks.net> Message-ID: <4B4CCD38.2090206@gnutls.org> Steve Dispensa wrote: > All, > > Here is an updated patch that conforms to the latest secure renegotiation draft (draft-ietf-tls-renegotiation-03). Included are a 570-line patch plus two new source files implementing the extension. > > This patch is still not quite perfect, but I wanted to get it into people's hands sooner rather than later, so here it is. Some of the remaining shortcomings: I have just merged this to git. I have also added some new extension class (resumed) to add the safe renegotiation extension since this one has to be parsed even when resuming (which we don't do for other extensions). I also changed the default to allow an initial negotiation even if safe renegotiation extension exists. > - Correct error return values (rather than -1) > - Send appropriate alerts, as required by the draft > - Documentation of the two new API's, Those should have been done. > [...] as well as of the design > - Automated test cases > - Additional interoperability testing Those still remain. Thank you, Nikos From dispensa at phonefactor.com Tue Jan 12 21:09:05 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Tue, 12 Jan 2010 14:09:05 -0600 Subject: Renegotiation patch In-Reply-To: <4B4CCD38.2090206@gnutls.org> References: <0F7F9A82BB0DBB4396A9F8386D0E061204CD195D@pos-exch1.corp.positivenetworks.net> <4B4CCD38.2090206@gnutls.org> Message-ID: On Jan 12, 2010, at 1:27 PM, Nikos Mavrogiannopoulos wrote: > Steve Dispensa wrote: > I have just merged this to git. I have also added some new extension > ... >> [...] as well as of the design >> - Automated test cases >> - Additional interoperability testing > > Those still remain. Furthermore, I missed session resumption support. I've started work on that this afternoon. -Steve From dispensa at phonefactor.com Wed Jan 13 07:33:27 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Wed, 13 Jan 2010 00:33:27 -0600 Subject: Two patches Message-ID: Here are two more patches. The first adds support for renegotiation of resumption. I'd appreciate some review here; I tested this against the resume.c test case, and had odd results: it worked well when --verbose was specified, but it failed immediately when that switch was omitted. I don't think the problem lies in the gnutls lib code, but I thought it was suspicious. Any ideas? Also, I found a bug in my initial implementation - I was incorrectly sending the SCSV on all connections, not only those using SSLv3, as should have been the case. Let me know what you think. -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: resumption-and-scsv.patch Type: application/octet-stream Size: 2546 bytes Desc: not available URL: From nmav at gnutls.org Wed Jan 13 20:56:18 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 13 Jan 2010 20:56:18 +0100 Subject: Two patches In-Reply-To: References: Message-ID: <4B4E2562.1010909@gnutls.org> Steve Dispensa wrote: > Here are two more patches. The first adds support for renegotiation of > resumption. I'd appreciate some review here; I tested this against the > resume.c test case, and had odd results: it worked well when --verbose was > specified, but it failed immediately when that switch was omitted. I don't > think the problem lies in the gnutls lib code, but I thought it was > suspicious. Any ideas? It was problematic but uncovered some issues with resuming and saving/restoring parameters. I have fixed it now and should work with both resuming and normal cases. > > Also, I found a bug in my initial implementation - I was incorrectly sending > the SCSV on all connections, not only those using SSLv3, as should have been > the case. Applied. From ametzler at downhill.at.eu.org Sun Jan 17 09:37:12 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 17 Jan 2010 09:37:12 +0100 Subject: Certificate expiration not checked by gnutls-cli [GNUTLS-SA-2009-3] [CVE-2009-1417] In-Reply-To: <20100109153408.GA3320@downhill.g.la> References: <87bpqe77g7.fsf@mocca.josefsson.org> <20100109153408.GA3320@downhill.g.la> Message-ID: <20100117083712.GA3249@downhill.g.la> Ping? On 2010-01-09 Andreas Metzler wrote: > On 2009-04-30 Simon Josefsson wrote: > [...] > > We have set up three demo URLs with expired certificates for testing > > purposes: > > https://expired.demo.gnutls.org/ - Expired server certificate > [...] > > You can test them like this: > > jas at mocca:~$ gnutls-cli expired.demo.gnutls.org > > Resolving 'expired.demo.gnutls.org'... > > Connecting to '207.192.75.61:443'... > > - Ephemeral Diffie-Hellman parameters > > - Using prime: 2056 bits > > - Secret key: 2047 bits > > - Peer's public key: 2048 bits > > - Certificate type: X.509 > > - Got a certificate list of 1 certificates. > > - Certificate[0] info: > > # The hostname in the certificate matches 'expired.demo.gnutls.org'. > > # valid since: Wed Apr 22 00:00:58 CEST 2009 > > # expires at: Thu Apr 23 00:00:58 CEST 2009 > > # fingerprint: 97:B9:94:8C:4F:29:31:56:CD:85:9F:8D:D5:4E:D2:4E > > # Subject's DN: CN=expired.demo.gnutls.org > > # Issuer's DN: O=CA for expired.demo.gnutls.org > > # error: certificate has expired > > jas at mocca:~$ > > The expected behaviour is that gnutls-cli should complain that the > > certificate has expired for all URLs. > [...] > > if (status & GNUTLS_CERT_SIGNER_NOT_FOUND) > > printf ("- Peer's certificate issuer is unknown\n"); > > + if (status & GNUTLS_CERT_NOT_ACTIVATED) > > + printf ("- Peer's certificate chain uses not yet valid certificate\n"); > > + if (status & GNUTLS_CERT_EXPIRED) > > + printf ("- Peer's certificate chain uses expired certificate\n"); > > if (status & GNUTLS_CERT_INVALID) > > printf ("- Peer's certificate is NOT trusted\n"); > > else > Hello, > this test does not work for me with any version of gnutls. There is no > "error: certificate has expired" or even "Peer's certificate chain > uses expired certificate". > 2.4.2+patch: > ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org > Resolving 'expired.demo.gnutls.org'... > Connecting to '207.192.75.61:443'... > - Ephemeral Diffie-Hellman parameters > - Using prime: 2056 bits > - Secret key: 2039 bits > - Peer's public key: 2048 bits > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > # The hostname in the certificate matches 'expired.demo.gnutls.org'. > # valid since: Wed Apr 22 00:00:58 CEST 2009 > # expires at: Thu Apr 23 00:00:58 CEST 2009 > # fingerprint: 97:B9:94:8C:4F:29:31:56:CD:85:9F:8D:D5:4E:D2:4E > # Subject's DN: CN=expired.demo.gnutls.org > # Issuer's DN: O=CA for expired.demo.gnutls.org > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted > - Version: TLS1.1 > - Key Exchange: DHE-RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > 2.8.5 > (SID)ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org > Resolving 'expired.demo.gnutls.org'... > Connecting to '207.192.75.61:443'... > - Ephemeral Diffie-Hellman parameters > - Using prime: 2048 bits > - Secret key: 2047 bits > - Peer's public key: 2048 bits > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > - subject `CN=expired.demo.gnutls.org', issuer `O=CA for expired.demo.gnutls.org', RSA key 2048 bits, signed using RSA-SHA, activated `2009-04-21 22:00:58 UTC', expires `2009-04-22 22:00:58 UTC', SHA-1 fingerprint `55f198f9ff1777e9f202e1ac268fe8946f0c84b9' > - The hostname in the certificate matches 'expired.demo.gnutls.org'. > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted > - Version: TLS1.1 > - Key Exchange: DHE-RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > 2.9.9: > (SID)ametzler at argenau:~$ gnutls-cli expired.demo.gnutls.org > Resolving 'expired.demo.gnutls.org'... > Connecting to '207.192.75.61:443'... > - Ephemeral Diffie-Hellman parameters > - Using prime: 2048 bits > - Secret key: 2045 bits > - Peer's public key: 2045 bits > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > - subject `CN=expired.demo.gnutls.org', issuer `O=CA for expired.demo.gnutls.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-04-21 22:00:58 UTC', expires `2009-04-22 22:00:58 UTC', SHA-1 fingerprint `55f198f9ff1777e9f202e1ac268fe8946f0c84b9' > - The hostname in the certificate matches 'expired.demo.gnutls.org'. > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted > - Version: TLS1.1 > - Key Exchange: DHE-RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > 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' From nmav at gnutls.org Sun Jan 17 10:37:31 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 17 Jan 2010 10:37:31 +0100 Subject: Certificate expiration not checked by gnutls-cli [GNUTLS-SA-2009-3] [CVE-2009-1417] In-Reply-To: <20100117083712.GA3249@downhill.g.la> References: <87bpqe77g7.fsf@mocca.josefsson.org> <20100109153408.GA3320@downhill.g.la> <20100117083712.GA3249@downhill.g.la> Message-ID: <4B52DA5B.5050302@gnutls.org> Andreas Metzler wrote: > Ping? [...] >> this test does not work for me with any version of gnutls. There is no >> "error: certificate has expired" or even "Peer's certificate chain >> uses expired certificate". I checked it and it seems that the verification code will stop once a certificate in the chain is found invalid (that was added to counter some denial of service attacks). Here gnutls-cli cannot verify the CA certificate thus stops there and does not move forward to check time for the actual certificate. regards, Nikos From ametzler at downhill.at.eu.org Sun Jan 17 11:40:45 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 17 Jan 2010 11:40:45 +0100 Subject: Certificate expiration not checked by gnutls-cli [GNUTLS-SA-2009-3] [CVE-2009-1417] In-Reply-To: <4B52DA5B.5050302@gnutls.org> References: <87bpqe77g7.fsf@mocca.josefsson.org> <20100109153408.GA3320@downhill.g.la> <20100117083712.GA3249@downhill.g.la> <4B52DA5B.5050302@gnutls.org> Message-ID: <20100117104045.GB3249@downhill.g.la> On 2010-01-17 Nikos Mavrogiannopoulos wrote: > Andreas Metzler wrote: > > Ping? > [...] > >> this test does not work for me with any version of gnutls. There is no > >> "error: certificate has expired" or even "Peer's certificate chain > >> uses expired certificate". > I checked it and it seems that the verification code will stop once a > certificate in the chain is found invalid (that was added to counter > some denial of service attacks). Here gnutls-cli cannot verify the CA > certificate thus stops there and does not move forward to check time for > the actual certificate. I see and have managed to verify this. Thank you for the explanation. 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' From simon at josefsson.org Mon Jan 18 09:10:52 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 18 Jan 2010 09:10:52 +0100 Subject: GNU Libtasn1 2.4 Message-ID: <87hbqjsuib.fsf@mocca.josefsson.org> GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.4 (2010-01-18) [stable] - Doc fixes. - Updated gnulib files. - Clean up copyright notices. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.4.zip http://josefsson.org/gnutls4win/libtasn1-2.4.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.4-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: . All manuals are available from: http://www.gnu.org/software/gsasl/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf API Reference manual: http://www.gnu.org/software/gsasl/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 8cecbb6335e0294ddbcb3a798f0c61c7a2735f23 libtasn1-2.4.tar.gz 04229d6777d176e09aad870b08b69b29eb8826249046f52521f6c975 libtasn1-2.4.tar.gz bcbef65089c6ea44ff5065e4f933c58e650153a0 libtasn1-2.4.zip b81f7643664975a7de12058b20489d8a489121880101c4b1fb24a115 libtasn1-2.4.zip b99a35e23c9e8d3afc2e7ca808f951d0d00c282d mingw32-libtasn1_2.4-1_all.deb 177f47b46154b56623f5b4e51b747e82b6ee4d646c01ce8f38fb3afb mingw32-libtasn1_2.4-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From dispensa at phonefactor.com Tue Jan 19 06:03:23 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Mon, 18 Jan 2010 23:03:23 -0600 Subject: Another renegotiation patch Message-ID: Here is another patch that fixes an interoperability problem with safe renegotiation and resumption. In copying forward the safe renegotiation state across resumptions, I got a little carried away and copied too much data (new connections should start with empty RI data). -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: resume-patch Type: application/octet-stream Size: 1283 bytes Desc: not available URL: From nmav at gnutls.org Tue Jan 19 20:06:53 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 19 Jan 2010 20:06:53 +0100 Subject: Another renegotiation patch In-Reply-To: References: Message-ID: <4B5602CD.1020408@gnutls.org> Steve Dispensa wrote: > Here is another patch that fixes an interoperability problem with safe > renegotiation and resumption. In copying forward the safe renegotiation > state across resumptions, I got a little carried away and copied too much > data (new connections should start with empty RI data). Applied. I will also try to add some test cases. best regards, Nikos From simon at josefsson.org Wed Jan 20 11:12:44 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 20 Jan 2010 11:12:44 +0100 Subject: gnutls 2.8.6 release candidate Message-ID: <87ska113vn.fsf@mocca.josefsson.org> Folks, I think we have enough fixes on the 2.8.x trunk, and the last 2.8.x release was over two months ago, so it is time for 2.8.6. Please test this snapshot as if it were the new release: http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20100120.tar.bz2 I'll release sometime next week. Build tests on Solaris/HP are very welcome, I'll see if I can find time to do them myself. /Simon From dam at opencsw.org Wed Jan 20 16:08:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jan 2010 16:08:38 +0100 Subject: gnutls 2.8.6 release candidate In-Reply-To: <87ska113vn.fsf@mocca.josefsson.org> References: <87ska113vn.fsf@mocca.josefsson.org> Message-ID: Hi Simon, Am 20.01.2010 um 11:12 schrieb Simon Josefsson: > I think we have enough fixes on the 2.8.x trunk, and the last 2.8.x > release was over two months ago, so it is time for 2.8.6. Please test > this snapshot as if it were the new release: > > http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20100120.tar.bz2 > > I'll release sometime next week. Build tests on Solaris/HP are very > welcome, I'll see if I can find time to do them myself. This issue about gpg-error and lnsl we talked about has not been resolved in this release, but in 2.9.9: Am 05.11.2009 um 16:35 schrieb Simon Josefsson: > Dagobert Michelsen writes: > >> Hi Simon, >> >> Am 05.11.2009 um 16:17 schrieb Simon Josefsson: >>> Dagobert Michelsen writes: >>> >>>>> - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], >>>>> + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include >>>>> ], >>>>> [enum gcry_cipher_algos i = GCRY_CIPHER_CAMELLIA128]) >>>>> if test "$ac_cv_libgcrypt" != yes; then >>>>> AC_MSG_ERROR([[ >>>>> -- >>>>> 1.6.5.2 >>>> >>>> Yes, this solves the problem with the missing libgpg-error. Now >>>> only >>>> the -lsocket -lnsl issue needs to be resolved :-) >>> >>> Great. The -lnsl issue could be fixed by using more recent gnulib >>> here. >> >> It would be great if you had an updated tarball of the release-to- >> come >> will all known errors fixed so I can verify it. > > Of 2.8.x or 2.9.x? I'll see if I can push out a 2.9.x release today. > > /Simon Best regards -- Dago From simon at josefsson.org Wed Jan 20 16:35:09 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 20 Jan 2010 16:35:09 +0100 Subject: gnutls 2.8.6 release candidate In-Reply-To: (Dagobert Michelsen's message of "Wed, 20 Jan 2010 16:08:38 +0100") References: <87ska113vn.fsf@mocca.josefsson.org> Message-ID: <877hrcrdqq.fsf@mocca.josefsson.org> Dagobert Michelsen writes: > This issue about gpg-error and lnsl we talked about has not been > resolved > in this release, but in 2.9.9: Oops! >>>>>> - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], >>>>>> + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include I've back-ported this to 2.8.x now. The daily autobuilder should catch it, so you can verify that it has been fixed in a few hours. >>>>> Yes, this solves the problem with the missing libgpg-error. Now >>>>> only >>>>> the -lsocket -lnsl issue needs to be resolved :-) >>>> >>>> Great. The -lnsl issue could be fixed by using more recent gnulib >>>> here. I'll see if we can just backport that particular gnulib module involved here rather than updating all of gnulib. /Simon From nmav at gnutls.org Thu Jan 21 21:42:00 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Jan 2010 21:42:00 +0100 Subject: Another renegotiation patch In-Reply-To: References: Message-ID: <4B58BC18.7030100@gnutls.org> Steve Dispensa wrote: > Here is another patch that fixes an interoperability problem with safe > renegotiation and resumption. In copying forward the safe renegotiation > state across resumptions, I got a little carried away and copied too much > data (new connections should start with empty RI data). I was thinking about the safe renegotiation case. Currently with the defaults the client behavior is to drop the connection to servers that do not advertise safe renegotiation... This is quite an inconvenience. How do you think of instead of failing disabling renegotiation for this session? I think this will prevent a lot of people from completely disabling safe renegotiation and only disables the part of the protocol that isn't secure.. regards, Nikos From ludo at gnu.org Thu Jan 21 23:38:19 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 21 Jan 2010 23:38:19 +0100 Subject: Continuous builds on Hydra Message-ID: <874omfccdg.fsf@gnu.org> Hello, The Hydra build farm at TU Deflt[*] now continuously builds GnuTLS from Git using Libtasn1 from Git and Libgcrypt from SVN: http://hydra.nixos.org/jobset/gnu/gnutls-master http://hydra.nixos.org/jobset/gnu/gnutls-master/all Currently it gets built on GNU/Linux (i686 and x86_64), Darwin (i686), and Cygwin (i686). When everything goes well, the following web page is updated, with a tarball, NixOS binaries (we could add Debian, etc.), the HTML and PDF manual, and a code coverage report: http://hydra.nixos.org/view/gnu/gnutls-master If you?re interested in it, I can set up email notification so that some of you or a mailing list receives a notification each time the build status changes (e.g., from SUCCEEDED to FAILED). Thanks, Ludo?. [*] See http://nixos.org/hydra/ . Thanks to Eelco Dolstra and Rob Vermaas for their help setting it up. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From simon at josefsson.org Fri Jan 22 11:14:22 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 22 Jan 2010 11:14:22 +0100 Subject: Continuous builds on Hydra In-Reply-To: <874omfccdg.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Thu, 21 Jan 2010 23:38:19 +0100") References: <874omfccdg.fsf@gnu.org> Message-ID: <87y6jqbg5d.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hello, > > The Hydra build farm at TU Deflt[*] now continuously builds GnuTLS from > Git using Libtasn1 from Git and Libgcrypt from SVN: > > http://hydra.nixos.org/jobset/gnu/gnutls-master > http://hydra.nixos.org/jobset/gnu/gnutls-master/all > > Currently it gets built on GNU/Linux (i686 and x86_64), Darwin (i686), > and Cygwin (i686). Great! > When everything goes well, the following web page is updated, with a > tarball, NixOS binaries (we could add Debian, etc.), the HTML and PDF > manual, and a code coverage report: > > http://hydra.nixos.org/view/gnu/gnutls-master > > If you?re interested in it, I can set up email notification so that some > of you or a mailing list receives a notification each time the build > status changes (e.g., from SUCCEEDED to FAILED). Yes, please e-mail gnutls-commit at gnu.org. I think we can use the same list for this purpose. If people find it annoying, we can set up a separate list for automatic build notifications, but I'm not sure it is useful... /Simon From ludo at gnu.org Fri Jan 22 15:48:46 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 22 Jan 2010 15:48:46 +0100 Subject: Continuous builds on Hydra References: <874omfccdg.fsf@gnu.org> <87y6jqbg5d.fsf@mocca.josefsson.org> Message-ID: <87d4128ab5.fsf@gnu.org> Hi, Simon Josefsson writes: > ludo at gnu.org (Ludovic Court?s) writes: [...] >> If you?re interested in it, I can set up email notification so that some >> of you or a mailing list receives a notification each time the build >> status changes (e.g., from SUCCEEDED to FAILED). > > Yes, please e-mail gnutls-commit at gnu.org. Done. > I think we can use the same list for this purpose. If people find it > annoying, we can set up a separate list for automatic build > notifications, but I'm not sure it is useful... Agreed. We?ll see... Thanks, Ludo?. From ludo at gnu.org Fri Jan 22 16:53:09 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 22 Jan 2010 16:53:09 +0100 Subject: Continuous builds on Hydra References: <874omfccdg.fsf@gnu.org> <87y6jqbg5d.fsf@mocca.josefsson.org> Message-ID: <87bpgm5e6y.fsf@gnu.org> BTW, you might have seen that the Hydra build script does this: patchPhase = # Remove occurrences of /usr/bin/perl and /bin/bash. '' for i in \ tests/nist-pkits/build-chain \ doc/scripts/sort2.pl \ doc/scripts/gdoc \ doc/doxygen/Doxyfile.orig \ doc/doxygen/Doxyfile.in do echo "patching \`/usr/bin/perl' in \`$i'..." sed -i "$i" -e's|/usr/bin/perl|${pkgs.perl}/bin/perl|g' done for i in "tests/"*"/"* do if grep -q /bin/bash "$i" then echo "patching \`/bin/bash' in \`$i'..." sed -i "$i" -e's|/bin/bash|/bin/sh|g' fi done ''; The Right Fix would be: - For /usr/bin/perl, use AC_PATH_PROG and substitute @PERL@ in those scripts. - For /bin/bash, it?s probably enough to use /bin/sh. Thanks, Ludo?. From dkg at fifthhorseman.net Fri Jan 22 21:40:13 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Jan 2010 15:40:13 -0500 Subject: Another renegotiation patch In-Reply-To: <4B58BC18.7030100@gnutls.org> References: <4B58BC18.7030100@gnutls.org> Message-ID: <4B5A0D2D.8060608@fifthhorseman.net> On 01/21/2010 03:42 PM, Nikos Mavrogiannopoulos wrote: > I was thinking about the safe renegotiation case. Currently with the > defaults the client behavior is to drop the connection to servers that > do not advertise safe renegotiation... This is quite an inconvenience. > How do you think of instead of failing disabling renegotiation for this > session? I think this will prevent a lot of people from completely > disabling safe renegotiation and only disables the part of the protocol > that isn't secure.. The problem, as i understand it, is that the client is incapable of telling whether the plaintext prefix injection attack has already happened. I don't think disabling renegotiation for the session resolves the problem. For a server which does not announce and enforce safe renegotiation, what the client sees as an initial connection may unknowingly actually be renegotiating an existing session that was started by an attacker. The concern isn't that the (legitimate) client will have their session re-negotiated by an attacker; it's that the MITM attacker can trick the server into viewing the client's initial authentication as a re-negotiation of a TLS session already underway. for servers which do odd things like apply the credentials of the post-renegotiation client to the traffic that happened before the renegotiation (e.g. HTTPS, with client-side certificates required only for certain subdirectories), a safe-renegotiation-aware client *should* refuse to connect to servers which do not announce safe renegotiation if they want to resist this attack. (i think! i'm still struggling to get my head around this too, and i'd be happy for any corrections) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dispensa at phonefactor.com Fri Jan 22 21:57:49 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Fri, 22 Jan 2010 14:57:49 -0600 Subject: Another renegotiation patch In-Reply-To: <4B58BC18.7030100@gnutls.org> Message-ID: On 1/21/10 2:42 PM, "Nikos Mavrogiannopoulos" wrote: > Steve Dispensa wrote: >> Here is another patch that fixes an interoperability problem with safe >> renegotiation and resumption. In copying forward the safe renegotiation >> state across resumptions, I got a little carried away and copied too much >> data (new connections should start with empty RI data). > > I was thinking about the safe renegotiation case. Currently with the > defaults the client behavior is to drop the connection to servers that > do not advertise safe renegotiation... This is quite an inconvenience. > How do you think of instead of failing disabling renegotiation for this > session? The client can't tell when the attacker is renegotiating. If the client doesn't want to, e.g., tweet his password in clear text, he has to drop the connection. The whole problem is that to the attacker and to one peer, it looks like a renego, but to the other peer, it looks entirely normal. -Steve From dispensa at phonefactor.com Fri Jan 22 22:02:05 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Fri, 22 Jan 2010 15:02:05 -0600 Subject: Another renegotiation patch In-Reply-To: <4B5A0D2D.8060608@fifthhorseman.net> Message-ID: On 1/22/10 2:40 PM, "Daniel Kahn Gillmor" wrote: > On 01/21/2010 03:42 PM, Nikos Mavrogiannopoulos wrote: >> I was thinking about the safe renegotiation case. Currently with the >> defaults the client behavior is to drop the connection to servers that >> do not advertise safe renegotiation... This is quite an inconvenience. >> How do you think of instead of failing disabling renegotiation for this >> session? I think this will prevent a lot of people from completely >> disabling safe renegotiation and only disables the part of the protocol >> that isn't secure.. > > The problem, as i understand it, is that the client is incapable of > telling whether the plaintext prefix injection attack has already > happened. I don't think disabling renegotiation for the session > resolves the problem. Right, exactly. (And by the way, it's probably more precise to think of it in terms of peers; the same attack is theoretically possible in the direction of the client, but all of the described exploits are in the direction of the server.) > > For a server which does not announce and enforce safe renegotiation, > what the client sees as an initial connection may unknowingly actually > be renegotiating an existing session that was started by an attacker. Yep. > > The concern isn't that the (legitimate) client will have their session > re-negotiated by an attacker; it's that the MITM attacker can trick the > server into viewing the client's initial authentication as a > re-negotiation of a TLS session already underway. Right, while it looks like the initial negotiation to the client. Again, this attack is theoretically possible in the opposite direction, i.e., where the server sees an initial negotiation but the client thinks he's renegotiating. Nobody has publicly described a way to attack that angle, but it's still broken in theory. > > for servers which do odd things like apply the credentials of the > post-renegotiation client to the traffic that happened before the > renegotiation (e.g. HTTPS, with client-side certificates required only > for certain subdirectories), a safe-renegotiation-aware client *should* > refuse to connect to servers which do not announce safe renegotiation if > they want to resist this attack. It's worse than that - you don't want to tweet your password. Think about the Twitter attack; it's pretty general. > > (i think! i'm still struggling to get my head around this too, and i'd > be happy for any corrections) > > --dkg This is incredibly subtle, and yeah, you've got it. -Steve From dkg at fifthhorseman.net Fri Jan 22 22:37:00 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Jan 2010 16:37:00 -0500 Subject: Another renegotiation patch In-Reply-To: References: Message-ID: <4B5A1A7C.8020402@fifthhorseman.net> On 01/22/2010 04:02 PM, Steve Dispensa wrote: > Again, this attack is theoretically possible in the opposite direction, > i.e., where the server sees an initial negotiation but the client thinks > he's renegotiating. Nobody has publicly described a way to attack that > angle, but it's still broken in theory. Wouldn't that require the client to have initially negotiated to the attacker, who was posing as the server? That's basically ruled out by the convention that TLS server operators are expected to offer an initial certificate (anonymous/certificate-less servers aren't accepted by any TLS client i've tried, but i might be trying wrong somehow). The exploit works as widely as it does because the default mode in most TLS connections today is that the client *is* initially anonymous from the server's point of view, right? Once one side has been authenticated by their private key (and associated cert), that side of the session cannot be controlled by an MITM attacker. A server that demands a client certificate from the first handshake can't be compromised this way (but of course there's no way for a client to know that the server they're interacting with holds this policy). Or is there some other way that this could work in the server-to-client direction? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Fri Jan 22 22:41:34 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Jan 2010 22:41:34 +0100 Subject: Another renegotiation patch In-Reply-To: <4B5A0D2D.8060608@fifthhorseman.net> References: <4B58BC18.7030100@gnutls.org> <4B5A0D2D.8060608@fifthhorseman.net> Message-ID: <4B5A1B8E.6010507@gnutls.org> Daniel Kahn Gillmor wrote: > On 01/21/2010 03:42 PM, Nikos Mavrogiannopoulos wrote: >> I was thinking about the safe renegotiation case. Currently with the >> defaults the client behavior is to drop the connection to servers that >> do not advertise safe renegotiation... This is quite an inconvenience. >> How do you think of instead of failing disabling renegotiation for this >> session? I think this will prevent a lot of people from completely >> disabling safe renegotiation and only disables the part of the protocol >> that isn't secure.. > > The problem, as i understand it, is that the client is incapable of > telling whether the plaintext prefix injection attack has already > happened. I don't think disabling renegotiation for the session > resolves the problem. Ooops. I just reverted my previous change and added NEWS entries. regards, Nikos From dam at opencsw.org Sat Jan 23 10:59:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 23 Jan 2010 10:59:44 +0100 Subject: gnutls 2.8.6 release candidate In-Reply-To: <877hrcrdqq.fsf@mocca.josefsson.org> References: <87ska113vn.fsf@mocca.josefsson.org> <877hrcrdqq.fsf@mocca.josefsson.org> Message-ID: <92E596C1-19F1-4915-988A-742DD042180D@opencsw.org> Hi Simon, Am 20.01.2010 um 16:35 schrieb Simon Josefsson: > Dagobert Michelsen writes: > >> This issue about gpg-error and lnsl we talked about has not been >> resolved >> in this release, but in 2.9.9: > > Oops! > >>>>>>> - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], >>>>>>> + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include > > I've back-ported this to 2.8.x now. The daily autobuilder should > catch > it, so you can verify that it has been fixed in a few hours. > >>>>>> Yes, this solves the problem with the missing libgpg-error. Now >>>>>> only >>>>>> the -lsocket -lnsl issue needs to be resolved :-) >>>>> >>>>> Great. The -lnsl issue could be fixed by using more recent gnulib >>>>> here. > > I'll see if we can just backport that particular gnulib module > involved > here rather than updating all of gnulib. I just compiled the latest snapshot from today, the gpgerror issue is fixed, however, the -lsocket -lnsl is still missing there: > Undefined first referenced > symbol in file > inet_ntop ex-serv1.o (symbol belongs to > implicit dependency /lib/libnsl.so.1) > ld: fatal: Symbol referencing errors. No output written to ex-serv1 Best regards -- Dago From csaavedra at igalia.com Sat Jan 23 23:15:13 2010 From: csaavedra at igalia.com (Claudio Saavedra) Date: Sun, 24 Jan 2010 00:15:13 +0200 Subject: [PATCH] Correct manual regarding pkg-config usage Message-ID: <1264284913.20081.4.camel@knuth.CityApart> The manual mentions that 'pkg-config libgnutls' should be used, but this is wrong, since there is lib/gnutls.pc.in instead. Claudio -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Correct-manual-regarding-pkg-config-usage.patch Type: text/x-patch Size: 3784 bytes Desc: not available URL: From v.mayatskih at gmail.com Mon Jan 25 16:00:23 2010 From: v.mayatskih at gmail.com (Vitaly Mayatskikh) Date: Mon, 25 Jan 2010 16:00:23 +0100 Subject: gnutls-cli: handle binary data from stdin Message-ID: <87tyuatek8.wl%vmayatsk@redhat.com> Hello! gnutls-cli is used as TLS wrapper in several MUAs (like Gnus and Wanderlust) to access secured IMAP mail servers. IMAP proto has extension RFC4978 for traffic compression with deflate method. However, gnutls-cli is pure text-oriented client, so it can't handle binary data from stdin correctly. This trivial patch fixes the problem. P.s.: Please, keep me in Cc, I'm not subscribed to the list. --- src/cli.c.orig 2009-06-02 20:59:32.000000000 +0200 +++ src/cli.c 2010-01-25 15:52:59.504321067 +0100 @@ -558,6 +558,7 @@ main (int argc, char **argv) struct timeval tv; int user_term = 0, retval = 0; socket_st hd; + int bytes; set_program_name (argv[0]); @@ -749,7 +750,7 @@ after_handshake: if (FD_ISSET (fileno (stdin), &rset)) { - if (fgets (buffer, MAX_BUF, stdin) == NULL) + if ((bytes = read (fileno(stdin), buffer, MAX_BUF)) < 0) { if (hd.secure == 0) { @@ -778,11 +779,13 @@ after_handshake: if (crlf != 0) { char *b = strchr (buffer, '\n'); - if (b != NULL) + if (b != NULL) { strcpy (b, "\r\n"); + bytes++; + } } - ret = socket_send (&hd, buffer, strlen (buffer)); + ret = socket_send (&hd, buffer, bytes); if (ret > 0) { -- wbr, Vitaly From simon at josefsson.org Wed Jan 27 10:31:04 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 10:31:04 +0100 Subject: gnutls-cli: handle binary data from stdin In-Reply-To: <87tyuatek8.wl%vmayatsk@redhat.com> (Vitaly Mayatskikh's message of "Mon, 25 Jan 2010 16:00:23 +0100") References: <87tyuatek8.wl%vmayatsk@redhat.com> Message-ID: <87r5pbj3mv.fsf@mocca.josefsson.org> Vitaly Mayatskikh writes: > Hello! > > gnutls-cli is used as TLS wrapper in several MUAs (like Gnus and > Wanderlust) to access secured IMAP mail servers. IMAP proto has > extension RFC4978 for traffic compression with deflate > method. However, gnutls-cli is pure text-oriented client, so it can't > handle binary data from stdin correctly. > > This trivial patch fixes the problem. Thanks. How well have you tested it? I'm surprised there aren't more text-oriented assumptions in the code. However I believe we should use getline instead of fgets/read to avoid the fixed size buffer. It should handle binary data transparent. /Simon > P.s.: Please, keep me in Cc, I'm not subscribed to the list. > > --- src/cli.c.orig 2009-06-02 20:59:32.000000000 +0200 > +++ src/cli.c 2010-01-25 15:52:59.504321067 +0100 > @@ -558,6 +558,7 @@ main (int argc, char **argv) > struct timeval tv; > int user_term = 0, retval = 0; > socket_st hd; > + int bytes; > > set_program_name (argv[0]); > > @@ -749,7 +750,7 @@ after_handshake: > > if (FD_ISSET (fileno (stdin), &rset)) > { > - if (fgets (buffer, MAX_BUF, stdin) == NULL) > + if ((bytes = read (fileno(stdin), buffer, MAX_BUF)) < 0) > { > if (hd.secure == 0) > { > @@ -778,11 +779,13 @@ after_handshake: > if (crlf != 0) > { > char *b = strchr (buffer, '\n'); > - if (b != NULL) > + if (b != NULL) { > strcpy (b, "\r\n"); > + bytes++; > + } > } > > - ret = socket_send (&hd, buffer, strlen (buffer)); > + ret = socket_send (&hd, buffer, bytes); > > if (ret > 0) > { From wk at gnupg.org Wed Jan 27 11:20:05 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jan 2010 11:20:05 +0100 Subject: gnutls-cli: handle binary data from stdin In-Reply-To: <87r5pbj3mv.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 27 Jan 2010 10:31:04 +0100") References: <87tyuatek8.wl%vmayatsk@redhat.com> <87r5pbj3mv.fsf@mocca.josefsson.org> Message-ID: <87d40vu9wq.fsf@vigenere.g10code.de> On Wed, 27 Jan 2010 10:31, simon at josefsson.org said: > text-oriented assumptions in the code. However I believe we should use > getline instead of fgets/read to avoid the fixed size buffer. It should > handle binary data transparent. But it will resize the buffer as needed and thus it can easily eat up all RAM available to the process and other code will cease to work. In particular on small devices this is a problem. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Wed Jan 27 15:49:18 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 15:49:18 +0100 Subject: gnutls-cli: handle binary data from stdin In-Reply-To: <87d40vu9wq.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 27 Jan 2010 11:20:05 +0100") References: <87tyuatek8.wl%vmayatsk@redhat.com> <87r5pbj3mv.fsf@mocca.josefsson.org> <87d40vu9wq.fsf@vigenere.g10code.de> Message-ID: <873a1rhac1.fsf@mocca.josefsson.org> Werner Koch writes: > On Wed, 27 Jan 2010 10:31, simon at josefsson.org said: > >> text-oriented assumptions in the code. However I believe we should use >> getline instead of fgets/read to avoid the fixed size buffer. It should >> handle binary data transparent. > > But it will resize the buffer as needed and thus it can easily eat up > all RAM available to the process and other code will cease to work. In > particular on small devices this is a problem. Good point. I'll use the original patch. /Simon From simon at josefsson.org Wed Jan 27 15:57:34 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 15:57:34 +0100 Subject: gnutls-cli: handle binary data from stdin In-Reply-To: <87tyuatek8.wl%vmayatsk@redhat.com> (Vitaly Mayatskikh's message of "Mon, 25 Jan 2010 16:00:23 +0100") References: <87tyuatek8.wl%vmayatsk@redhat.com> Message-ID: <87y6jjfvdt.fsf@mocca.josefsson.org> Vitaly Mayatskikh writes: > Hello! > > gnutls-cli is used as TLS wrapper in several MUAs (like Gnus and > Wanderlust) to access secured IMAP mail servers. IMAP proto has > extension RFC4978 for traffic compression with deflate > method. However, gnutls-cli is pure text-oriented client, so it can't > handle binary data from stdin correctly. > > This trivial patch fixes the problem. > > P.s.: Please, keep me in Cc, I'm not subscribed to the list. I modified it slightly and applied it on git master now, thanks! /Simon From simon at josefsson.org Wed Jan 27 16:02:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 16:02:05 +0100 Subject: [PATCH] Correct manual regarding pkg-config usage In-Reply-To: <1264284913.20081.4.camel@knuth.CityApart> (Claudio Saavedra's message of "Sun, 24 Jan 2010 00:15:13 +0200") References: <1264284913.20081.4.camel@knuth.CityApart> Message-ID: <87tyu7fv6a.fsf@mocca.josefsson.org> Claudio Saavedra writes: > The manual mentions that 'pkg-config libgnutls' should be used, but > this is wrong, since there is lib/gnutls.pc.in instead. Thank you! It didn't apply cleanly, but I applied it manually. /Simon From v.mayatskih at gmail.com Wed Jan 27 10:59:00 2010 From: v.mayatskih at gmail.com (Vitaly Mayatskikh) Date: Wed, 27 Jan 2010 10:59:00 +0100 Subject: gnutls-cli: handle binary data from stdin In-Reply-To: <87r5pbj3mv.fsf@mocca.josefsson.org> References: <87tyuatek8.wl%vmayatsk@redhat.com> <87r5pbj3mv.fsf@mocca.josefsson.org> Message-ID: <87y6jjyil7.wl%vmayatsk@redhat.com> At Wed, 27 Jan 2010 10:31:04 +0100, Simon Josefsson wrote: > > This trivial patch fixes the problem. > > Thanks. How well have you tested it? I use it for 5 days now to handle all my email traffic. Besides Google mail, which supports compression, there's corporate server, which doesn't support it, so gnutls-cli processes only text there. > I'm surprised there aren't more text-oriented assumptions in the > code. However I believe we should use getline instead of fgets/read > to avoid the fixed size buffer. It should handle binary data > transparent. It shouldn't stop reading at any delimiter, like null, CR or LF characters. Unless I miss something, I don't see the problem with fixed size buffer, because data sent over network can be split by network devices anyway. -- wbr, Vitaly From Brandt.Springman at ubiquisys.com Thu Jan 28 12:39:43 2010 From: Brandt.Springman at ubiquisys.com (Brandt Springman) Date: Thu, 28 Jan 2010 11:39:43 -0000 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 Message-ID: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> Hi Gnu, I was wondering if you could please tell me how you determined that OpenSSL does not support TLS v1.1 or TLS v1.2. I had come to the same conclusion but only because I saw they claimed to support TLS v1 which seems vague and ambiguous. But perhaps they mean they support the latest of the v1? Thanks for any help, Brandt -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Jan 29 13:36:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Jan 2010 13:36:05 +0100 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> (Brandt Springman's message of "Thu, 28 Jan 2010 11:39:43 -0000") References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> Message-ID: <87tyu53x6y.fsf@mocca.josefsson.org> "Brandt Springman" writes: > Hi Gnu, > > > > I was wondering if you could please tell me how you determined that > OpenSSL does not support TLS v1.1 or TLS v1.2. > > > > I had come to the same conclusion but only because I saw they claimed to > support TLS v1 which seems vague and ambiguous. > > > > But perhaps they mean they support the latest of the v1? I don't see anything beyond TLSv1.0 in /usr/include/openssl/tls1.h on my system. If you have any more reliable information, please let us know. /Simon From vivek at collabora.co.uk Fri Jan 29 14:14:31 2010 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Fri, 29 Jan 2010 13:14:31 +0000 (GMT) Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <87tyu53x6y.fsf@mocca.josefsson.org> References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> Message-ID: > I don't see anything beyond TLSv1.0 in /usr/include/openssl/tls1.h on my > system. If you have any more reliable information, please let us know. I ran up against a buggy proprietary server which a user reported didn't work with our GnuTLS backend but did with OpenSSL - turned out to be because the server exploded in a messy fireball if it saw a minor version of the protocol in the client hello that it didn't know about, instead of responding with the highest protocol level it supported (analysed with ssltap from libnss3 - is there an equivalent from GnuTLS, btw?): The OpenSSL verssion worked because it only ever advertised TLS1.0, and I couldn't find any reference to making it advertise a higher version of the protocol. Not conclusive, but it does point to OpenSSL not implementing TLS 1.1 or 1.2 (at least in any documented, on-by-default way). From simon at josefsson.org Fri Jan 29 14:54:39 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Jan 2010 14:54:39 +0100 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: (Vivek Dasmohapatra's message of "Fri, 29 Jan 2010 13:14:31 +0000 (GMT)") References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> Message-ID: <87ljfh2ezk.fsf@mocca.josefsson.org> Vivek Dasmohapatra writes: >> I don't see anything beyond TLSv1.0 in /usr/include/openssl/tls1.h on my >> system. If you have any more reliable information, please let us know. > > I ran up against a buggy proprietary server which a user reported > didn't work with our GnuTLS backend but did with OpenSSL - turned out > to be because the server exploded in a messy fireball if it saw a > minor version > of the protocol in the client hello that it didn't know about, instead of > responding with the highest protocol level it supported That's not unusual. Check the GnuTLS manual on how to make GnuTLS just talk TLS 1.0 if you can't fix that server. > (analysed with ssltap from libnss3 - is there an equivalent from > GnuTLS, btw?): There is gnutls-cli, but I don't know how it compares. > The OpenSSL verssion worked because it only ever advertised TLS1.0, > and I couldn't find any reference to making it advertise a higher > version of the protocol. Not conclusive, but it does point to OpenSSL > not implementing TLS 1.1 or 1.2 (at least in any documented, > on-by-default way). Right. /Simon From vivek at collabora.co.uk Fri Jan 29 15:15:50 2010 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Fri, 29 Jan 2010 14:15:50 +0000 (GMT) Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <87ljfh2ezk.fsf@mocca.josefsson.org> References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> Message-ID: > That's not unusual. Check the GnuTLS manual on how to make GnuTLS just > talk TLS 1.0 if you can't fix that server. I did, I mention it only as background here. >> (analysed with ssltap from libnss3 - is there an equivalent from >> GnuTLS, btw?): > > There is gnutls-cli, but I don't know how it compares. ssltap lets you be an (obvious) man-in-the-middle and dumps out information about the ssl protocol - it listens on a port and interface you specify and proxies to the real server you want your client to talk to. Can be quite handy. From nmav at gnutls.org Fri Jan 29 18:31:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 29 Jan 2010 18:31:33 +0100 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> Message-ID: <4B631B75.8060508@gnutls.org> Vivek Dasmohapatra wrote: >>> (analysed with ssltap from libnss3 - is there an equivalent from >>> GnuTLS, btw?): >> >> There is gnutls-cli, but I don't know how it compares. > > ssltap lets you be an (obvious) man-in-the-middle and dumps out > information about the ssl protocol - it listens on a port and interface > you specify and proxies to the real server you want your client to > talk to. Can be quite handy. Check also wireshark. It is quite detailed as well. best regards, Nikos From dispensa at phonefactor.com Fri Jan 29 21:27:50 2010 From: dispensa at phonefactor.com (Steve Dispensa) Date: Fri, 29 Jan 2010 14:27:50 -0600 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <4B631B75.8060508@gnutls.org> References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> <4B631B75.8060508@gnutls.org> Message-ID: <8F1D715E-5CF5-4229-9313-8DCE82A99CE2@phonefactor.com> On Jan 29, 2010, at 11:31 AM, Nikos Mavrogiannopoulos wrote: > Vivek Dasmohapatra wrote: > >> ssltap lets you be an (obvious) man-in-the-middle and dumps out >> information about the ssl protocol - it listens on a port and >> interface >> you specify and proxies to the real server you want your client to >> talk to. Can be quite handy. > > Check also wireshark. It is quite detailed as well. +1. We used wireshark extensively in testing and documenting the TLS MitM that we recently published. Works great. (A little hard to set up, but that's another story.) -Steve