Nabble - Gnu - TLS

Re: Problems handling X.509 certificates

2009-11-27T00:59:35Z

Daniel Kahn Gillmor <dkg@...> writes:

> On 11/26/2009 09:18 AM, Simon Josefsson wrote:
>> The TLS protocol only allow clients to send one X.509 certificate to the
>> server. I suspect that if you need to send two client certificates,
>> something is wrong with your architecture.
>
> Laurence may be confused about this, and trying to send two end-entity
> certificates, in which case Simon's remarks here are correct.
>
> But a gnutls client may also offer intermediate certificate authority
> certificates (to bridge the gap from the server's announced root CAs to
> the client's end-entity certificate).
>
> In that case, the spec certainly allows the client to inject multiple
> certificates in the certificate_list structure, with the (maybe
> not-so-clear) intention of giving the server a chained trust path to the
> client's own certificate:
>
> http://tools.ietf.org/html/rfc5246#section-7.4.2
>
> Laurence, if this is what you're trying to do, i don't think you want to
> call gnutls_certificate_set_x509_key_file twice. What you want to do is
> to put the ordered certificates (end-entity cert, followed by successive
> CA certs) in file A, and then the private key in a file B (only the
> end-entity's private key -- there's no need to have the private key for
> any intermediate CA). then call gnutls_certificate_set_x509_key_file
> once, pointing to A and B.
>
> hope this helps clear up confusion.

Thank you, I hope that helps in case Laurence wanted to provide two
certs from the same chain to the server.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: Problems handling X.509 certificates

2009-11-26T07:14:06Z

On 11/26/2009 09:18 AM, Simon Josefsson wrote:
> The TLS protocol only allow clients to send one X.509 certificate to the
> server. I suspect that if you need to send two client certificates,
> something is wrong with your architecture.

Laurence may be confused about this, and trying to send two end-entity
certificates, in which case Simon's remarks here are correct.

But a gnutls client may also offer intermediate certificate authority
certificates (to bridge the gap from the server's announced root CAs to
the client's end-entity certificate).

In that case, the spec certainly allows the client to inject multiple
certificates in the certificate_list structure, with the (maybe
not-so-clear) intention of giving the server a chained trust path to the
client's own certificate:

http://tools.ietf.org/html/rfc5246#section-7.4.2

Laurence, if this is what you're trying to do, i don't think you want to
call gnutls_certificate_set_x509_key_file twice. What you want to do is
to put the ordered certificates (end-entity cert, followed by successive
CA certs) in file A, and then the private key in a file B (only the
end-entity's private key -- there's no need to have the private key for
any intermediate CA). then call gnutls_certificate_set_x509_key_file
once, pointing to A and B.

hope this helps clear up confusion.

--dkg

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

signature.asc (909 bytes) Download Attachment

Re: TLS 1.2 with standard signature? Why hash->size == 36??

2009-11-26T06:21:21Z

Hi Simon,

I didn't go that yet (I do not really have time to go on developing my
projekt at the moment :-( ), but for me, the hash excluding the OID
should be fine. I am not sure that is the case for every possible
application using the callback. Maybe it is better to pass the OID
too... It is easy to cut it of if it is not needed for further processing.

Carolin

Simon Josefsson wrote:

> That is great!
>
> Did you have to re-add the PKCS#1 ASN.1 OID before signing the data
> manually? Or was that not necessary? I'm wondering whether current API
> to only give the callback the hash value is OK, or whether it should
> also include the ASN.1 OID in the data passed to the callback. One
> problem with the current callback API is that there is no signalling of
> which hash function was used -- before in TLS this was not necessary
> since only MD5/SHA1 was used, and the default is still SHA-1, but it
> will be possible to sign using SHA-256 or similar too. The callback
> needs to be able to figure out that somehow.
>
> /Simon
>
> Carolin Latze <carolin.latze@...> writes:
>
>
>> Hi Simon,
>>
>> yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot
>> for fixing that!!!
>>
>> Cheers
>> Carolin
>>
>> Simon Josefsson wrote:
>>
>>> Carolin,
>>>
>>> I just re-ran the x509signself self-test with gnutls 2.9.x and the hash
>>> size passed to the function is now 20 bytes. I suppose GnuTLS adds the
>>> right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the
>>> callback should receive the entire PKCS#1 blob, to avoid having the
>>> callback reconstruct it, instead of just the hash value, but maybe this
>>> is sufficient to make things work for you? I'll release 2.9.9 in a few
>>> minutes with some minor fixes, please test it.
>>>
>>> /Simon
>>>
>>> Carolin Latze <carolin.latze@...> writes:
>>>
>>>
>>>
>>>> Hi Simon,
>>>>
>>>> I tried to use TLS 1.2 with and without sign callback, and I still see a
>>>> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't
>>>> it be max 35 then? Maybe we should check, whether I check the right
>>>> variables:
>>>>
>>>> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure
>>>> called dconcat. dconcat.size holds the hash size, right? and
>>>> dconcat.data should hold the hash itself? dconcat.size has a value of 36
>>>> for me...
>>>>
>>>> If I use the sign callback, I print the value of hash->size (=36) and
>>>> hash->data (cannot see the OID included in that value, so for me it
>>>> looks like it is really not SHA-1 only).
>>>>
>>>> Maybe I check the wrong values?
>>>>
>>>> BTW: I used the latest Snapshot, 2.9.8 to test it.
>>>>
>>>> Sorry... :-/
>>>> Carolin
>>>>
>>>> Simon Josefsson wrote:
>>>>
>>>>
>>>>> Carolin Latze <carolin.latze@...> writes:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if
>>>>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says
>>>>>> 36... that does not sound like a standard signature.. I would expect
>>>>>> something like 20 for SHA1. Am I wrong?
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take
>>>>> a look? It should have more solid TLS 1.2 support.
>>>>>
>>>>> Thanks,
>>>>> Simon
>>>>>
>>>>>
>>>>>

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: Problems handling X.509 certificates

2009-11-26T06:18:40Z

lfinsto@... writes:

> Hello,
>
> I need to use X.509 certificates for authentication/authorization in an
> application and I've been working through the examples in the GNUTLS
> manual.
>
> I'm new to GNUTLS (and network programming), so please excuse me if my
> questions are naive.
>
> I've been using and modifying the programs
> "7.3.2 Simple Client Example with X.509 Certificate Support"
> and
> "7.4.2 Echo Server with X.509 Authentication II".
>
> I've been trying to use the function `verify_certificate_chain' (defined
> in `ex-verify.c') instead of `verify_certificate' (defined in
> `ex-rfc2818.c'), but I can't seem to get it to work.
>
> I have two certificates that I want the client to send to the server. In
> the client, I call `gnutls_certificate_set_x509_key_file' twice, once for
> each certificate/key pair. However, in the server,
> `gnutls_certificate_get_peers' sets the `*LIST_SIZE' to 1, i.e., it only
> finds one certificate.
>
> I've tried various things to get it to work, but with no success. I must
> be overlooking something, but I don't know what it could be.

The TLS protocol only allow clients to send one X.509 certificate to the
server. I suspect that if you need to send two client certificates,
something is wrong with your architecture.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS 1.2 with standard signature? Why hash->size == 36??

2009-11-26T05:42:02Z

That is great!

Did you have to re-add the PKCS#1 ASN.1 OID before signing the data
manually? Or was that not necessary? I'm wondering whether current API
to only give the callback the hash value is OK, or whether it should
also include the ASN.1 OID in the data passed to the callback. One
problem with the current callback API is that there is no signalling of
which hash function was used -- before in TLS this was not necessary
since only MD5/SHA1 was used, and the default is still SHA-1, but it
will be possible to sign using SHA-256 or similar too. The callback
needs to be able to figure out that somehow.

/Simon

Carolin Latze <carolin.latze@...> writes:

> Hi Simon,
>
> yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot
> for fixing that!!!
>
> Cheers
> Carolin
>
> Simon Josefsson wrote:
>> Carolin,
>>
>> I just re-ran the x509signself self-test with gnutls 2.9.x and the hash
>> size passed to the function is now 20 bytes. I suppose GnuTLS adds the
>> right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the
>> callback should receive the entire PKCS#1 blob, to avoid having the
>> callback reconstruct it, instead of just the hash value, but maybe this
>> is sufficient to make things work for you? I'll release 2.9.9 in a few
>> minutes with some minor fixes, please test it.
>>
>> /Simon
>>
>> Carolin Latze <carolin.latze@...> writes:
>>
>>
>>> Hi Simon,
>>>
>>> I tried to use TLS 1.2 with and without sign callback, and I still see a
>>> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't
>>> it be max 35 then? Maybe we should check, whether I check the right
>>> variables:
>>>
>>> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure
>>> called dconcat. dconcat.size holds the hash size, right? and
>>> dconcat.data should hold the hash itself? dconcat.size has a value of 36
>>> for me...
>>>
>>> If I use the sign callback, I print the value of hash->size (=36) and
>>> hash->data (cannot see the OID included in that value, so for me it
>>> looks like it is really not SHA-1 only).
>>>
>>> Maybe I check the wrong values?
>>>
>>> BTW: I used the latest Snapshot, 2.9.8 to test it.
>>>
>>> Sorry... :-/
>>> Carolin
>>>
>>> Simon Josefsson wrote:
>>>
>>>> Carolin Latze <carolin.latze@...> writes:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if
>>>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says
>>>>> 36... that does not sound like a standard signature.. I would expect
>>>>> something like 20 for SHA1. Am I wrong?
>>>>>
>>>>>
>>>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take
>>>> a look? It should have more solid TLS 1.2 support.
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>>

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS 1.2 with standard signature? Why hash->size == 36??

2009-11-26T05:31:22Z

Hi Simon,

yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot
for fixing that!!!

Cheers
Carolin

Simon Josefsson wrote:

> Carolin,
>
> I just re-ran the x509signself self-test with gnutls 2.9.x and the hash
> size passed to the function is now 20 bytes. I suppose GnuTLS adds the
> right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the
> callback should receive the entire PKCS#1 blob, to avoid having the
> callback reconstruct it, instead of just the hash value, but maybe this
> is sufficient to make things work for you? I'll release 2.9.9 in a few
> minutes with some minor fixes, please test it.
>
> /Simon
>
> Carolin Latze <carolin.latze@...> writes:
>
>
>> Hi Simon,
>>
>> I tried to use TLS 1.2 with and without sign callback, and I still see a
>> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't
>> it be max 35 then? Maybe we should check, whether I check the right
>> variables:
>>
>> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure
>> called dconcat. dconcat.size holds the hash size, right? and
>> dconcat.data should hold the hash itself? dconcat.size has a value of 36
>> for me...
>>
>> If I use the sign callback, I print the value of hash->size (=36) and
>> hash->data (cannot see the OID included in that value, so for me it
>> looks like it is really not SHA-1 only).
>>
>> Maybe I check the wrong values?
>>
>> BTW: I used the latest Snapshot, 2.9.8 to test it.
>>
>> Sorry... :-/
>> Carolin
>>
>> Simon Josefsson wrote:
>>
>>> Carolin Latze <carolin.latze@...> writes:
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if
>>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says
>>>> 36... that does not sound like a standard signature.. I would expect
>>>> something like 20 for SHA1. Am I wrong?
>>>>
>>>>
>>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take
>>> a look? It should have more solid TLS 1.2 support.
>>>
>>> Thanks,
>>> Simon
>>>
>>>

--
Carolin Latze
PhD Student ICT Engineer

Department of Computer Science Swisscom Strategy and Innovation
Boulevard de Pérolles 90 Ostermundigenstrasse 93
CH-1700 Fribourg CH-3006 Bern

phone: +41 26 300 83 30 +41 79 72 965 27
homepage: http://diuf.unifr.ch/people/latzec

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: gnutls is unable to get x509 certificate

2009-11-26T01:39:53Z

Simon Josefsson <simon@...> wrote on 11/20/2009 08:57:06 AM: > Simon Josefsson <simon@...>
> 11/20/2009 08:57 AM
> > To
> > Tomasz Welman/Poland/IBM@IBMPL
> > cc
> > help-gnutls@...
> > Subject
> > Re: gnutls is unable to get x509 certificate
> > Tomasz Welman <tomasz.welman@...> writes: > > > Hi, > > > > The problem is that I am using LDAP, and ldaps://, but it doesn't work. > > With the help op openldap guys, I've tracked down the issue to be gnutls > > problem. > > > > The full description (with (hopefully all of the) debugging info) is here: > > > >http://www.openldap.org/lists/openldap-technical/200911/msg00039.html> > The IBM server is buggy, this has been debugged before, see complete > discussion and workarounds: > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477>
Ok, that helped a bit.

When I'm doing:
gnutls-cli -p 636 bluepages.ibm.com --priority NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-TLS1.2:-CTYPE-OPENPGP

it's working, but if I am giving it the CA certificate obtained this way:
openssl s_client -host bluepages.ibm.com -port 636 > bp.cert

and then:
twelman@darthvader:~$ gnutls-cli --x509cafile bp.cert -p 636 bluepages.ibm.com --priority NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-TLS1.2:-CTYPE-OPENPGP
it fails with message:
Processed 1 CA certificate(s).
Resolving 'bluepages.ibm.com'...
Connecting to '9.17.186.253:636'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `C=US,ST=Colorado,L=Boulder,O=International Business Machines,OU=Terms of use at www.verisign.com/rpa (c)05,OU=Terms of use at www.verisign.com/rpa (c)05,CN=bluepages.ibm.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA, activated `2008-03-19 00:00:00 UTC', expires `2011-05-23 23:59:59 UTC', SHA-1 fingerprint `b4ed74f52d5de2efac31cbac286ef20bccaba87a'
- Certificate[1] info:
- subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
- Certificate[2] info:
- subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
- The hostname in the certificate matches 'bluepages.ibm.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: SSL3.0
- Key Exchange: RSA
- Cipher: AES-256-CBC
- MAC: SHA1
- Compression: NULL
*** Verifying server certificate failed...

The bp.cert looks like this:
twelman@darthvader:~$ cat bp.cert
-----BEGIN CERTIFICATE-----
MIIFbzCCBFegAwIBAgIQQqowfydfbhGjnIrdG/yoqTANBgkqhkiG9w0BAQUFADCB
sDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMh
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBMB4XDTA4MDMxOTAwMDAw
MFoXDTExMDUyMzIzNTk1OVowgeIxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xv
cmFkbzEQMA4GA1UEBxQHQm91bGRlcjEoMCYGA1UEChQfSW50ZXJuYXRpb25hbCBC
dXNpbmVzcyBNYWNoaW5lczEzMDEGA1UECxQqVGVybXMgb2YgdXNlIGF0IHd3dy52
ZXJpc2lnbi5jb20vcnBhIChjKTA1MTMwMQYDVQQLFCpUZXJtcyBvZiB1c2UgYXQg
d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxGjAYBgNVBAMUEWJsdWVwYWdlcy5p
Ym0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDSUyh7l1px1jcmNeqf
48bV4DQUKhk1h0uBOn24+HdD5YS0TuYrOVtY7L/oX6jT+2Klaogyq8JdYaREnKJo
NVAHyPoAYUrnCHwguZdK0KRo9EjbP55qGoYw0gtd0zD9f/G03237x+Kz6sVAvnmN
zWeHZ8OT4EfLKDa1pGW/F7QHTQIDAQABo4IB0zCCAc8wCQYDVR0TBAIwADALBgNV
HQ8EBAMCBaAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL1NWUlNlY3VyZS1jcmwu
dmVyaXNpZ24uY29tL1NWUlNlY3VyZTIwMDUuY3JsMEQGA1UdIAQ9MDswOQYLYIZI
AYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYTAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU
b+yvoN2KpO/1KhBnLT9VgrzX7yUweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzAB
hhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9T
VlJTZWN1cmUtYWlhLnZlcmlzaWduLmNvbS9TVlJTZWN1cmUyMDA1LWFpYS5jZXIw
bgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMC
GgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u
Y29tL3ZzbG9nbzEuZ2lmMA0GCSqGSIb3DQEBBQUAA4IBAQBXSkgfiiwhOkhj1jZn
NYM+ic3E3niRM7xFuz4nz2vX5L7ThVFlYFlWoOynNyfuVXqMxqrf6f8Y2uVMY5Cj
PohjrjVocgDsN8epFaplIH/HSXj21q385wAajfYBsxzTQqHytUZ0Apva7rpGAG9l
TUYyqA7vxmr/xLTIPzWNk680hwXihFFw8f4vcIvS1riu1AwESUiRQN2BJkTAaRKt
n2qjBWirioah4j8kJWvsH/p1P7OAg63rM9hEWi3t9aQBZ2JKKKwmdTI98J2wG/nC
PkwhK2dIdkBjr+6ICd0Hp8MME0oTpXq8CuiAbEQRcvQ6aUttnDYOnE8dluRPccgf
5BFI
-----END CERTIFICATE-----

Can you help?

What I want to achieve is get the CA (as I did with openssl s_client) and then
be able to connect giving this CA for validation so I'm sure this bluepages.ibm.com
is actually the same server that gave me the CA.

--
Tomasz 'Trog' Welman
Software Developer
external: 48-12-628-9449
ITN: 34819449
T/L: 9449

IBM SWG Lab, Krakow, Poland
IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18 30 -150 Kraków
NIP: 526-030-07-24, KRS 0000012941
Kapitał zakładowy: 33.000.000 PLN

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Problems handling X.509 certificates

2009-11-25T00:38:44Z

Hello,

I need to use X.509 certificates for authentication/authorization in an
application and I've been working through the examples in the GNUTLS
manual.

I'm new to GNUTLS (and network programming), so please excuse me if my
questions are naive.

I've been using and modifying the programs
"7.3.2 Simple Client Example with X.509 Certificate Support"
and
"7.4.2 Echo Server with X.509 Authentication II".

I've been trying to use the function `verify_certificate_chain' (defined
in `ex-verify.c') instead of `verify_certificate' (defined in
`ex-rfc2818.c'), but I can't seem to get it to work.

I have two certificates that I want the client to send to the server. In
the client, I call `gnutls_certificate_set_x509_key_file' twice, once for
each certificate/key pair. However, in the server,
`gnutls_certificate_get_peers' sets the `*LIST_SIZE' to 1, i.e., it only
finds one certificate.

I've tried various things to get it to work, but with no success. I must
be overlooking something, but I don't know what it could be.

Any help would be much appreciated.

Laurence Finston

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: gnutls is unable to get x509 certificate

2009-11-19T23:57:06Z

Tomasz Welman <tomasz.welman@...> writes:

> Hi,
>
> The problem is that I am using LDAP, and ldaps://, but it doesn't work.
> With the help op openldap guys, I've tracked down the issue to be gnutls
> problem.
>
> The full description (with (hopefully all of the) debugging info) is here:
>
> http://www.openldap.org/lists/openldap-technical/200911/msg00039.html

The IBM server is buggy, this has been debugged before, see complete
discussion and workarounds:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: gnutls is unable to get x509 certificate

2009-11-19T14:25:47Z

Tomasz Welman wrote:
> Hi,
>
> The problem is that I am using LDAP, and ldaps://, but it doesn't work.
> With the help op openldap guys, I've tracked down the issue to be gnutls
> problem.
>
> The full description (with (hopefully all of the) debugging info) is here:
>
> http://www.openldap.org/lists/openldap-technical/200911/msg00039.html

Please tell us for a way to reproduce. If you cannot please run
gnutls-cli-debug against this server and send the output.

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

gnutls is unable to get x509 certificate

2009-11-19T00:02:59Z

Hi,

The problem is that I am using LDAP, and ldaps://, but it doesn't work.
With the help op openldap guys, I've tracked down the issue to be gnutls problem.

The full description (with (hopefully all of the) debugging info) is here:

http://www.openldap.org/lists/openldap-technical/200911/msg00039.html

--
Tomasz 'Trog' Welman
Software Developer
external: 48-12-628-9449
ITN: 34819449
T/L: 9449

IBM SWG Lab, Krakow, Poland
IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18 30 -150 Kraków
NIP: 526-030-07-24, KRS 0000012941
Kapitał zakładowy: 33.000.000 PLN

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-18T10:28:52Z

On Tue, 17 Nov 2009 11:32:46 +0100 Simon Josefsson
<simon@...> wrote:

> > In GnuTLS, rehandshaking needs to be done explicitly by servers when
> > they get the GNUTLS_E_REHANDSHAKE error back from
> > gnutls_record_recv. If servers don't call gnutls_handshake when
> > that happens, there is no problem. So people can check their
> > applications if they are vulnerable to this problem.
>
> For everyone's information, searching for "GNUTLS_E_REHANDSHAKE" in
> code is not be sufficient: that only takes care of the situation
> where the local client reacts on a renegotiation request from the
> remote server.
>
> You also have to search for "gnutls_rehandshake" to take care of the
> situation where the local server initiates the renegotiation request.

I did a search for that in Red Hat Enterprise Linux sources and I've
not found anything using it. Google codesearch finds it in mod_gnutls
though. From a 30sec look, it may be using it in similar cases as
mod_ssl / mod_nss.

th.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: FIPS Certification

2009-11-17T02:58:45Z

Simon Josefsson <simon@...> writes:

> "Hoyt, David" <hoyt6@...> writes:
>
>> Is or will there be an effort to become FIPS certified? If so, is
>> there a schedule laid out for the process? Is there a webpage I can
>> look at to keep myself up-to-date on the certification process?
>
> All the crypto in GnuTLS normally happens in libgcrypt, and I recall
> seeing libgcrypt mentioned on the list of projects underway of becoming
> FIPS-certified some time ago.

Looking again, I see that AES/3DES/SHA1/SHA2/RSA/DSA/RNG in libgcrypt
have been FIPS certified. Follow links from:

http://csrc.nist.gov/groups/STM/cavp/validation.html

Still, older TLS does not use standard RSA PKCS#1 so you have to make
sure GnuTLS is really using the right crypto bits from libgcrypt.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-17T02:32:46Z

Simon Josefsson <simon@...> writes:

> In GnuTLS, rehandshaking needs to be done explicitly by servers when
> they get the GNUTLS_E_REHANDSHAKE error back from gnutls_record_recv.
> If servers don't call gnutls_handshake when that happens, there is no
> problem. So people can check their applications if they are vulnerable
> to this problem.

For everyone's information, searching for "GNUTLS_E_REHANDSHAKE" in code
is not be sufficient: that only takes care of the situation where the
local client reacts on a renegotiation request from the remote server.

You also have to search for "gnutls_rehandshake" to take care of the
situation where the local server initiates the renegotiation request.

I believe one still has to look carefully at each example to understand
whether a particular instance is vulnerable or not: not all instances of
TLS reneg appears vulnerable. For example, a server could make sure
that before calling gnutls_rehandshake it reads all data coming from the
client and performs input sanitizing on it because there is no guarantee
that data comes from the same identity who performs the TLS rehandshake
and sends more data later on.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

RE: GNUTLS compression

2009-11-12T23:07:52Z

Hi Nikos,

Thanks for link. It helps! :)

Handi

-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos@...] On
Behalf Of Nikos Mavrogiannopoulos
Sent: Thursday, 12 November, 2009 4:01 AM
To: Handi Ajimasta
Cc: help-gnutls@...
Subject: Re: GNUTLS compression

Handi Ajimasta wrote:

> 4) Is there any performance gain from enabling the compression? I
> understand that we might save some bandwidth with the compression, but

> with increased lag time, is there any noticeable difference?

Hello,
Check some tests I did when I implemented it:
http://lists.gnupg.org/pipermail/gnutls-dev/2002-September/000362.html

regards,
Nikos

Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: GNUTLS compression

2009-11-11T12:00:45Z

Handi Ajimasta wrote:

> 4) Is there any performance gain from enabling the compression? I
> understand that we might save some bandwidth with the compression, but
> with increased lag time, is there any noticeable difference?

Hello,
Check some tests I did when I implemented it:
http://lists.gnupg.org/pipermail/gnutls-dev/2002-September/000362.html

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: GNUTLS compression

2009-11-11T02:10:25Z

"Handi Ajimasta" <hajimasta@...> writes:

> Hi all,
>
> I installed gnutls 2.5.5 in Windows XP, and gnutls 2.8.4 in Windows 7
> Release Candidate from http://josefsson.org/gnutls4win/ .
>
> I thought that 'DEFLATE' compression algorithm is enabled by default in
> all gnutls releases. However, when I force my TLS client to use DEFLATE
> algorithm (and not the NULL) by:
>
> int pPriorities[3] = {GNUTLS_COMP_DEFLATE, 0};
> gnutls_compression_set_priority(session, pPriorities);
>
> My TLS client is not able to handshake with the server, because the
> compression algorithm is not available.
>
> When I did a 'gnutls-cli -l' in command prompt in both Windows XP and
> Windows 7, what I saw was: "COMPRESSION: NULL" only, without DEFLATE nor
> LZO algorithm.
>
>
> I successfully installed gnutls in an Ubuntu machine though, and when I
> did 'gnutls-cli -l' I could see that it has both DEFLATE algorithm and
> NULL there without me configuring anything at all.
>
> My questions are:
> 1) Is compression available for gnutls in Windows?
> 2) If it's yes.. how do I enable it?
> 3) If it's not available.. is there any way that I could enable it?
> 4) Is there any performance gain from enabling the compression? I
> understand that we might save some bandwidth with the compression, but
> with increased lag time, is there any noticeable difference?

My Windows build of GnuTLS does not include libz, so it is not
available. You should be able to install libz and recompile GnuTLS for
Windows yourself, or provide me with a patch against the gnutls4win
makefile so that future builds will support libz.

I don't think compression is all that useful in normal use cases. It
can be relevant if you are on dial-up or slow wireless links though.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-11T02:03:54Z

On Tue, 10 Nov 2009 19:13:27 +0100 Florian Weimer <fw@...>
wrote:

> > So, in summary, given (my) current knowledge there is no need to
> > either patch GnuTLS or any server application using GnuTLS.
>
> But GNUTLS would have to implement the extension to secure connections
> to servers which support renegotiation.

Simon confirmed that the implementation of the extension is planned.
I apologize for not properly specifying that "no change needed" was
actually meant as "no change needed, not even reneg extension
implemented", which caused the confusion.

th.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS 1.2 with standard signature? Why hash->size == 36??

2009-11-10T23:08:03Z

Hi Simon,

that sounds good. I will check it in two weeks (I am out of office at
the moment, only reading my mails from time to time :-))

Thanks a lot!
Carolin

Simon Josefsson wrote:

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Unencrypted connection?

2009-11-10T14:16:54Z

I'm interested in using gnutls both for secure communication, but also as a cross-platform wrapper (Linux+Windows) for my unencrypted sockets use, so I don't have to write one myself. I'm wondering if it's possible to have an unencrypted connection, would it be say using GNUTLS_CIPHER_NULL, and also any detriments to doing that.

I'm using the http://josefsson.org/gnutls4win/ port for Windows. However, I can't build the examples since tcp.c includes *nix headers not present on Windows... I'm a bit confused, does that mean the examples aren't ported?

Also, is it possible to use UDP instead of TCP?

Thanks

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T11:28:04Z

* Steve Dispensa:

> On 11/10/09 12:13 PM, "Florian Weimer" <fw@...> wrote:
>
>> * Simon Josefsson:
>>
>>> So, in summary, given (my) current knowledge there is no need to either
>>> patch GnuTLS or any server application using GnuTLS.
>>
>> But GNUTLS would have to implement the extension to secure connections
>> to servers which support renegotiation.
>
> (...which support safe renegotiation using the extension - no such thing as
> safe renegotiation absent both client and server supporting the extension.)

Eh, yes, this was sort-of implied. Thanks for the correction.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T10:13:27Z

* Simon Josefsson:

> So, in summary, given (my) current knowledge there is no need to either
> patch GnuTLS or any server application using GnuTLS.

But GNUTLS would have to implement the extension to secure connections
to servers which support renegotiation.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T08:49:28Z

Steve Dispensa <dispensa@...> writes:

> On 11/10/09 7:22 AM, "Tomas Hoger" <thoger@...> wrote:
>>> I think we now have some evidence to suggest GnuTLS needn't do anything
>>> about this. It seems any use of rehandshake with GnuTLS is
>>> application-specific and then the answer is probably to fix that
>>> application instead of GnuTLS.
>>
>> Is that meant as meant as "no change needed" or "no urgent temporary hotfix
>> needed"? Is the implementation of the proposed extension still the
>> long-term plan, so that apps needing rehandshakes can do them safely?
>
> [sorry if I'm late to the game; we had a baby a few days ago and I'm sadly
> behind on e-mail and most other things.]

Congratulations! Perfect timing.. ;)

> I agree with Tomas. When I wrote up the patch, I noticed that there were a
> few impediments to doing renegotiation at all in the way things are
> currently implemented (unless I misunderstood, which I always quite
> possible). Still, at some point, someone is going to really need the feature
> (or decide that the implementation is incomplete without perfect support for
> it), and once that happens, the bug will magically appear unless the TLS
> extension I supported.
>
> There's also a good reason to support the extension from an interop
> standpoint - servers will want to detect patched clients in the (near?)
> future, so sending the extension along will be helpful.

Definitely. Given a patch (and copyright assignment) for this, we could
add it to the experimental branch today, and once the IANA has allocated
a code point it could even be backported into the stable branch.

But that would be completely unrelated to fixing any short-term security
problem.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T08:43:55Z

Tomas Hoger <thoger@...> writes:

>> I think we now have some evidence to suggest GnuTLS needn't do anything
>> about this. It seems any use of rehandshake with GnuTLS is
>> application-specific and then the answer is probably to fix that
>> application instead of GnuTLS.
>
> Is that meant as meant as "no change needed" or "no urgent temporary hotfix
> needed"?

Both. ;-)

The situation appears to be that 1) there is no patch against GnuTLS
that we can use as a temporary hotfix, and 2) there appears (so far) to
be no servers that use GnuTLS in a way that is vulnerable to this
problem.

There _could_ be servers that use GnuTLS which were vulnerable. For
these applications, the simplest short-term solution appears to be to
remove/disable the TLS renegotiation code. That would be an urgent
problem that needs to be addressed quickly, if there actually are
deployed instances of that situation.

If a majority of servers that used GnuTLS were vulnerable to this
problem, I think we'd have to consider patching GnuTLS instead of
recommending patching application. Compare when we changed X.509 path
validation in GnuTLS to check expiry/activation times: it was not a
GnuTLS problem but it affected so many applications and it made more
sense to fix it in GnuTLS than change all the applications. Our survey
of servers using GnuTLS indicates that we are not close to being in this
situation for this problem.

Daniel suggested to add a priority string to allow admin's to disable
TLS renegotiation unconditionally without having to recompile
application/libraries. That seems like a good idea, but there are no
instances where we known that it would improve anything. Priority
strings is a quite new features, so the application would have to make
use of priority strings AND do renegotiation AND implement a protocol
that is vulnerable to this attack (e.g., HTTP) in order for things to
work. That situation seems unlikely, but could happen, and then we'll
certainly implement Daniel's suggestion.

We could also release a GnuTLS that does not support TLS renegotiation
at all. Right now, that is not known to fix anything, so I don't see
what you would gain in doing so. But we could end up needing to do that
too.

So, in summary, given (my) current knowledge there is no need to either
patch GnuTLS or any server application using GnuTLS.

> Is the implementation of the proposed extension still the long-term
> plan, so that apps needing rehandshakes can do them safely?

Yes.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T05:22:16Z

On Tue, Nov 10, 2009 at 12:29:04PM +0100, Simon Josefsson wrote:
> If the servers are linked with OpenSSL I don't know if they are
> vulnerable or not, it would depend on whether OpenSSL perform
> renegotiation without application interaction.

OpenSSL and NSS both do renegotiation transparently for application.

> I think we now have some evidence to suggest GnuTLS needn't do anything
> about this. It seems any use of rehandshake with GnuTLS is
> application-specific and then the answer is probably to fix that
> application instead of GnuTLS.

Is that meant as meant as "no change needed" or "no urgent temporary hotfix
needed"? Is the implementation of the proposed extension still the
long-term plan, so that apps needing rehandshakes can do them safely?

Thanks!

th.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T03:29:04Z

Tomas Hoger <thoger@...> writes:

> On Tue, Nov 10, 2009 at 09:55:52AM +0100, Simon Josefsson wrote:
>> What other popular servers use GnuTLS?
>
> CUPS and libvirt(d). No GNUTLS_E_REHANDSHAKE in their sources, client
> requested renegotiations seem to fail.

Thanks for checking. So to summarize, so far the following servers
appears to not be affected by this problem when used with GnuTLS:

gnutls-serv
mod_gnutls
exim4
mailutils
CUPS
libvirtd

If the servers are linked with OpenSSL I don't know if they are
vulnerable or not, it would depend on whether OpenSSL perform
renegotiation without application interaction. So make sure they are
linked to GnuTLS before declaring victory.

I think we now have some evidence to suggest GnuTLS needn't do anything
about this. It seems any use of rehandshake with GnuTLS is
application-specific and then the answer is probably to fix that
application instead of GnuTLS. Any more insight or thoughts on this is
welcome.

What GnuTLS needs to do, though, is to have a discussion of the issue in
the manual where renegotiation is discussed, so application writers are
aware of the problem.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

GNUTLS compression

2009-11-10T02:37:24Z

Hi all,

I installed gnutls 2.5.5 in Windows XP, and gnutls 2.8.4 in Windows 7
Release Candidate from http://josefsson.org/gnutls4win/ .

I thought that 'DEFLATE' compression algorithm is enabled by default in
all gnutls releases. However, when I force my TLS client to use DEFLATE
algorithm (and not the NULL) by:

int pPriorities[3] = {GNUTLS_COMP_DEFLATE, 0};
gnutls_compression_set_priority(session, pPriorities);

My TLS client is not able to handshake with the server, because the
compression algorithm is not available.

When I did a 'gnutls-cli -l' in command prompt in both Windows XP and
Windows 7, what I saw was: "COMPRESSION: NULL" only, without DEFLATE nor
LZO algorithm.

I successfully installed gnutls in an Ubuntu machine though, and when I
did 'gnutls-cli -l' I could see that it has both DEFLATE algorithm and
NULL there without me configuring anything at all.

My questions are:
1) Is compression available for gnutls in Windows?
2) If it's yes.. how do I enable it?
3) If it's not available.. is there any way that I could enable it?
4) Is there any performance gain from enabling the compression? I
understand that we might save some bandwidth with the compression, but
with increased lag time, is there any noticeable difference?

Thanks in advance for any help given.

Regards,
Handi

Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-10T00:55:52Z

Simon Josefsson <simon@...> writes:

> For example, the mod_gnutls Apache plugin does not support renegotiation
> so there is no problem with it (this was the main case that I were
> concerned with):

Other servers that use GnuTLS is Exim4 and GNU Mailutils. I checked the
sources and cannot find any place where they performs TLS renegotiation.
So as far as I can tell, they are safe too.

(Of course, this assume that it is even possible to exploit this problem
with SMTP/IMAP/POP3 which I haven't seen explained yet.)

What other popular servers use GnuTLS?

Is there _any_ GnuTLS server that is vulnerable? Not even our
gnutls-serv appears to support renegotiation as far as I can tell.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-09T23:08:49Z

Daniel Kahn Gillmor <dkg@...> writes:

> On 11/09/2009 10:19 AM, Simon Josefsson wrote:
>> It is important to understand that you are not vulnerable unless you use
>> renegotiation, which is not typical. If you use renegotiation, perhaps
>> to request client certificates in a web server, the simplest "fix" is to
>> disable any use of renegotiation.
>
> My understanding is that the published attacks are undetectable from the
> client-side without the use of the newly-proposed extension.

Yes.

> So barring that extension, it seems that that the protective
> workaround you describe (disabling renegotiation) needs to be done on
> the server side.
>
> Is there a way that this can be done generically with GnuTLS (e.g. a
> priority string, which could conceivably be passed into gnutls by an
> administrator without needing a rebuild), or should the server simply
> avoid calling gnutls_handshake() more than once per session?

In GnuTLS, rehandshaking needs to be done explicitly by servers when
they get the GNUTLS_E_REHANDSHAKE error back from gnutls_record_recv.
If servers don't call gnutls_handshake when that happens, there is no
problem. So people can check their applications if they are vulnerable
to this problem.

For example, the mod_gnutls Apache plugin does not support renegotiation
so there is no problem with it (this was the main case that I were
concerned with):

if (rc == GNUTLS_E_REHANDSHAKE) {
/* A client has asked for a new Hankshake. Currently, we don't do it */
ap_log_error(APLOG_MARK, APLOG_INFO, ctxt->input_rc,
ctxt->c->base_server,
"GnuTLS: Error reading data. Client Requested a New Handshake."
" (%d) '%s'", rc, gnutls_strerror(rc));
}

Possibly we could indeed have a new mode where GnuTLS refuses to do
renegotiation based on a priority string.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS 1.2 with standard signature? Why hash->size == 36??

2009-11-09T10:09:51Z

Carolin,

I just re-ran the x509signself self-test with gnutls 2.9.x and the hash
size passed to the function is now 20 bytes. I suppose GnuTLS adds the
right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the
callback should receive the entire PKCS#1 blob, to avoid having the
callback reconstruct it, instead of just the hash value, but maybe this
is sufficient to make things work for you? I'll release 2.9.9 in a few
minutes with some minor fixes, please test it.

/Simon

Carolin Latze <carolin.latze@...> writes:

> Hi Simon,
>
> I tried to use TLS 1.2 with and without sign callback, and I still see a
> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't
> it be max 35 then? Maybe we should check, whether I check the right
> variables:
>
> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure
> called dconcat. dconcat.size holds the hash size, right? and
> dconcat.data should hold the hash itself? dconcat.size has a value of 36
> for me...
>
> If I use the sign callback, I print the value of hash->size (=36) and
> hash->data (cannot see the OID included in that value, so for me it
> looks like it is really not SHA-1 only).
>
> Maybe I check the wrong values?
>
> BTW: I used the latest Snapshot, 2.9.8 to test it.
>
> Sorry... :-/
> Carolin
>
> Simon Josefsson wrote:
>> Carolin Latze <carolin.latze@...> writes:
>>
>>
>>> Hi all,
>>>
>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if
>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says
>>> 36... that does not sound like a standard signature.. I would expect
>>> something like 20 for SHA1. Am I wrong?
>>>
>>
>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take
>> a look? It should have more solid TLS 1.2 support.
>>
>> Thanks,
>> Simon
>>

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: TLS Renegotiation problem

2009-11-09T10:01:23Z

On 11/09/2009 10:19 AM, Simon Josefsson wrote:
> It is important to understand that you are not vulnerable unless you use
> renegotiation, which is not typical. If you use renegotiation, perhaps
> to request client certificates in a web server, the simplest "fix" is to
> disable any use of renegotiation.

My understanding is that the published attacks are undetectable from the
client-side without the use of the newly-proposed extension. So barring
that extension, it seems that that the protective workaround you
describe (disabling renegotiation) needs to be done on the server side.

Is there a way that this can be done generically with GnuTLS (e.g. a
priority string, which could conceivably be passed into gnutls by an
administrator without needing a rebuild), or should the server simply
avoid calling gnutls_handshake() more than once per session?

Regards,

--dkg

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

signature.asc (909 bytes) Download Attachment

TLS Renegotiation problem

2009-11-09T07:19:50Z

As you may have heard, people how found out how to attack TLS as used in
many application protocols. For more info see:

http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
http://extendedsubset.com/
http://www.imperialviolet.org/2009/11/05/tls-reneg.html

It is important to understand that you are not vulnerable unless you use
renegotiation, which is not typical. If you use renegotiation, perhaps
to request client certificates in a web server, the simplest "fix" is to
disable any use of renegotiation. You don't need to do this if your
application protocol is robust -- for example XMPP/Jabber appears to be
robust against the problem. HTTPS is not robust.

There is work ongoing to specify a new extension to make TLS
renegotiation safe against this attack, and hopefully GnuTLS will
support it soon. Patches have been published in
http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3944 but
not yet tested or verified, and the IETF/IANA has not allocated a TLS
extension number for it yet either.

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: GnuTLS 2.8.5

2009-11-02T06:20:28Z

Marco Maggi <mrc.mgg@...> writes:

>> Internationalization
>> ====================
>>
>> The GnuTLS library messages have been translated into
>> Czech, Dutch, French, German, Malay, Polish, Swedish, and
>> Vietnamese. We welcome the addition of more translations.
>
> Let's say that, in a purely hypothetical parallel universe,
> I can attempt Italian translation; what should I do?

Check out http://translationproject.org/html/translators.html and
contact the Italian translation team. Thanks in advance!

/Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

GnuTLS 2.8.5

2009-11-02T03:55:43Z

We are proud to announce a new stable GnuTLS release: Version 2.8.5.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications. GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later). The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later). The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

The project page of the library is available at:
http://www.gnu.org/software/gnutls/

What's New
==========

** libgnutls: In server side when resuming a session do not overwrite the
** initial session data with the resumed session data.

** libgnutls: Fix PKCS#12 encoding.
The error you would get was "The OID is not supported.". Problem
introduced for the v2.8.x branch in 2.7.6.

** guile: Compatibility with guile 2.x.
By Ludovic Courtes <ludovic.courtes@...>.

** tests: Fix expired cert in chainverify self-test.

** tests: Fix time bomb in chainverify self-test.
Reported by Andreas Metzler <ametzler@...> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3925>.

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>. The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2
http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2.sig
http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature. You can use the command

gpg --verify gnutls-2.8.5.tar.bz2.sig

This checks whether the signature file matches the source file. You
should see a message indicating that the signature is good and made by
that signing key. Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key. The signing
key can be identified with 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 <simon@...>
uid Simon Josefsson <jas@...>
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

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values. The values are for SHA-1 and SHA-224 respectively:

5121c52efd4718ad3d8b641d28343b0c6abaa571 gnutls-2.8.5.tar.bz2
9d6f1906e380cc7366e2427493c33b72a137e438cdc9080fba3d84f6 gnutls-2.8.5.tar.bz2

Documentation
=============

The manual is available online at:

http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.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/

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available. The installer contains DLLs for application
development, manuals, examples, and source code. The installer includes
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.5.

For more information about GnuTLS for Windows:
http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
http://josefsson.org/gnutls4win/gnutls-2.8.5.exe (15MB)
http://josefsson.org/gnutls4win/gnutls-2.8.5.exe.sig

The checksum values for SHA-1 and SHA-224 are:

5dadd78a630f30d3b4b3a34261068e74cba28d80 gnutls-2.8.5.exe
53af38a54ff2f971d9eecfb44f4ab39cc6dbad371ad6425d312eaccd gnutls-2.8.5.exe

A ZIP archive containing the Windows binaries:
http://josefsson.org/gnutls4win/gnutls-2.8.5.zip (5.3MB)
http://josefsson.org/gnutls4win/gnutls-2.8.5.zip.sig

The checksum values for SHA-1 and SHA-224 are:

b41c0ac3088620bf78996d719b335317cb90405a gnutls-2.8.5.zip
73ca7da90ebac569948114735d6899a08431ebbe15be3d619bec05a3 gnutls-2.8.5.zip

A Debian mingw32 package is also available:
http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.5-1_all.deb (4.8MB)

The checksum values for SHA-1 and SHA-224 are:

4ecb2e7617d8722d090ec96138ce595647c06a82 mingw32-gnutls_2.8.5-1_all.deb
cbdd418aea622dfaf9876f563ebc1e192ec0ab90bca8748277501e76 mingw32-gnutls_2.8.5-1_all.deb

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the
addition of more translations.

Support
=======

Improving GnuTLS is costly, but you can help! We are looking for
organizations that find GnuTLS useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

attachment0 (429 bytes) Download Attachment

Re: High loads and failure due to mod_gnutls

2009-10-29T03:26:51Z

Thank you for your answer, but unfortunately it didn't solve the problem.

2009/10/29 Simon Josefsson <simon@...>:

> john doe <couickie@...> writes:
>
>> Hello,
>>
>> I am using Apache 2.2.9 and mod_gnutls.so (GNUTLS version 1_4) and I
>> have experienced high load values on my server (HTTP/HTTPS Reverse
>> proxy running on Lenny).
>>
>> Regularly a new apache2 process spawns on the `top` command and takes
>> X% of the CPU, if there is a single bugged process X=100, if there are
>> 2 X=50 etc...
>> `w' command reported a load value of 27 this morning, after a restart
>> of apache it went down to 0 again. After 2 hours the load is now at 2.
>
> I've seen this too, especially in high-load scenarios, but for me it
> always appeared to be related to the 'GnuTLSCache dbm' setting. Maybe
> you could try changing /etc/apache2/mods-enabled/gnutls.conf to use
> 'GnuTLSCache none none' to see if the problem goes away?
>
> Maybe someone on the mod_gnutls list knows more.
>
> /Simon
>
>> I am not used to troubleshooting but I managed to get a backtrace with
>> gdb, here is the output:
>>
>> #0 0xb7f78a0e in apr_bucket_free () from /usr/lib/libaprutil-1.so.0
>> #1 0x08078dac in ap_core_output_filter ()
>> #2 0xb75133d3 in mgs_transport_write () from
>> /usr/lib/apache2/modules/mod_gnutls.so
>> #3 0xb78b93f2 in _gnutls_io_write_buffered () from /usr/lib/libgnutls.so.26
>> #4 0xb78b9950 in _gnutls_io_write_flush () from /usr/lib/libgnutls.so.26
>> #5 0xb78b5dc0 in _gnutls_send_int () from /usr/lib/libgnutls.so.26
>> #6 0xb78b627b in gnutls_record_send () from /usr/lib/libgnutls.so.26
>> #7 0xb7513b09 in mgs_filter_output () from
>> /usr/lib/apache2/modules/mod_gnutls.so
>> #8 0x0806f10e in ap_content_length_filter ()
>> #9 0xb74e07fc in ?? () from /usr/lib/apache2/modules/mod_proxy_http.so
>> #10 0x08407b98 in ?? ()
>> #11 0x084223a0 in ?? ()
>> #12 0x084223a0 in ?? ()
>> #13 0x00000001 in ?? ()
>> #14 0x00002000 in ?? ()
>> #15 0x00000000 in ?? ()
>>
>> I sent a interrupt signal to the process and then ended up in a sort
>> of fatal error function from gnu_tls (I cannot recall the name).
>> Maybe some function in gnu_tls is looping forever, waiting for a right
>> return value (that never come unfortunately).
>>
>> Here are some other debugging clues:
>>
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 5269 www-data 20 0 15136 5516 2424 R 49.8 0.4 15:53.62 apache2
>> 5314 www-data 20 0 15012 5296 2308 R 47.8 0.4 10:55.86 apache2
>>
>> load average: 1.50, 1.80, 1.68
>>
>> This output is redundant in apache error log:
>>
>> [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1819): proxy: worker
>> proxy:reverse already initialized
>> [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1913): proxy:
>> initialized single connection worker 17 in child 5461 for (*)
>> =====================================================================================
>> [Wed Oct 28 15:48:33 2009] [info] [client 62.36.240.2] (104)Connection
>> reset by peer: core_output_filter: writing data to the network
>> [Wed Oct 28 15:49:40 2009] [info] [client 193.203.96.2] (32)Broken
>> pipe: core_output_filter: writing data to the network
>> [Wed Oct 28 15:53:59 2009] [info] [client 193.203.96.2] (32)Broken
>> pipe: core_output_filter: writing data to the network
>>
>>
>> I may not be able to give you more information about this server, the
>> load was high but there were no latency.
>> Do you have an idea about this issue ?
>>
>> Thank you for your attention.
>> Regards.
>

--
Regards,

shiro.

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls