Re: connection problem with the version 1.0.1e
I understand the main problem is the server not responding clients supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull data by python not curl so we don't have the fancy to pass openssl parameters for connections and such. It uses the protocols whatever version of openssl it was compiled with. I am definitely going to complain about this issue to the service provider but I don't have much hope for them to take this seriously. So I wonder if next versions of openssl should care about workarounds for these painful servers? cheers. Roy On Wed, Jul 24, 2013 at 11:02 PM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Rajesh Malepati Sent: Wednesday, 24 July, 2013 13:03 On Wed, Jul 24, 2013 at 9:30 PM, kirpit kir...@gmail.com wrote: ... requests to one of our API provider ... works fine with 0.9.8o but 1.0.1e. The server doesn't seem to care to respond to clients supporting TLS 1.2 ok: openssl s_client -tls1 -connect emea.webservices.travelport.com:443 no reply: openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443 More exactly, it appears to be one of the several servers that fail for the longer ClientHello used in TLS1.2 by default: -ssl3 or -tls1 uses a shorter hello and works. -no_tls1_2 ditto and works negotiating 1.0. -tls1_1 ditto gets 1.0 response which s_client rejects. -tls1_2 -cipher (shortlist) ditto ditto. (default) -cipher (shortlist) ditto gets 1.0 response and works. such servers should be beaten to pulp. Agreed, but in the meantime, according to curl.haxx.se, curl has options to specify TLS1(.0?), SSL3, and/or cipherlist, which should allow a workaround. -1 or -3 looks easier than figuring out a good cipherlist for the (each?) host. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Password callback functions per SSL_use_PrivateKey_file
On Thu, Jul 25, 2013, Karthik Krishnamurthy wrote: Steve, Thanks much for the reply. I did not realize that EVP_PKEY structures can have their own callbacks. It's a few extra hoops, but worth it! Actually EVP_PKEY structures don't have callbacks at all, but you can load them using arbitrary callbacks using the appropriate API (for example PEM) and avoid the limitations of SSL/SSL_CTX. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: connection problem with the version 1.0.1e
On Thu, Jul 25, 2013, kirpit wrote: I understand the main problem is the server not responding clients supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull data by python not curl so we don't have the fancy to pass openssl parameters for connections and such. It uses the protocols whatever version of openssl it was compiled with. I am definitely going to complain about this issue to the service provider but I don't have much hope for them to take this seriously. So I wonder if next versions of openssl should care about workarounds for these painful servers? There are two workarounds but they have to be enables at compile time. You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or restrict the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for example 50. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: libssl 1.0.1 breaking program
On 26 June 2013 18:44, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote:
By enabling debug information in the program, I was able to obtain
these error messages:
pppd[2236]: EAP-TLS SSL error stack:
pppd[2236]: error:0D0C5006:asn1 encoding
routines:ASN1_item_verify:EVP lib
and
err: 7 (certificate signature failure)
The error certificate signature failure happens only when the
public key of an issuer certificate in the chain does not generate
a matching signature for its child certificate. Either the trust
store (CAfile, CApath, ...) certificates are not identical in the
two test cases, or one of the two parties sends a different chain,
or the handshake is somehow corrupted.
crypto/x509/x509_vfy.c:
internal_verify():
...
else if (X509_verify(xs,pkey) = 0)
{
ctx-error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
Look closely with wireshark at the chains captured on the machine
where the error is detected. Are the peer certificate chains the
same in every detail between the two library versions?
Are both cases using compression? Any other differences?
I meant to reply to this earlier but I got busy with other stuff. Anyhow, I
took some time and redid some tests:
- ppp with EAP-TLS patch compiled with libssl 0.9.8o-4squeeze14 works ok
(I had some surprises with CRL handling, but that's besides the point
right now)
- ppp with EAP-TLS patch compiled with libssl 1.0.1e-2 exhibits the same
behaviour I originally described, i.e.: server fails to validate
signature and sends an alert message to the client.
I tried two scenarios:
a) one root CA, generates two intermediate CAs. The first intermediate CA
is used to generate a certificate for the server, and the second CA
generates certificates for clients.
b) one root CA, used to generate two certificates (1 for the server and 1
for the client).
In both cases, only the server validates the client cert. Additionally, I made
sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for
message digests as MD5 is broken.
I noticed that the error occurs if one of the two peers is using the binary
linked with libssl 1.0.1.
As Viktor suggested, I examined the handshake with Wireshark.
What I noticed:
ClientHello
* libssl 1.0.1 exposes more cipher suites
* libssl 1.0.1 adds more extensions (ec_point_formats,
elliptic_curves, heartbeat)
ServerHello
* libssl 1.0.1 adds the heartbeat extension
Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, 'x'
* 'x' is a TLSv1 Record Layer: Handshake Protocol: Finished for
libssl1.0.1
* 'x' is a TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake
Message for libssl0.9.8
I googled around to find more information regarding the encrypted handshake
message and I couldn't find anything relevant. In fact, RFC2246 says the
handshake should end with 'Finished' on both ends. I have no idea where that
'Encrypted Handshake Message' appeared from. Could it be some outdated
function that is called to setup the connection that is changing this
from the default ?
Below the URLs for the (text) captures. Let me know if you need the pcaps ..
though I found having the text version is easier to run diff :-)
Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
I can share the certs ca files also if needed.
Marios
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: connection problem with the version 1.0.1e
There are two workarounds but they have to be enables at compile time. You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or restrict the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for example 50. I believe we will be solving our problem like this temporarily. Meantime, I'm just wondering that it sounds a bit strange to use TLS 1.2 as a default version while only 16% of the websites are supporting it according to wiki: https://en.wikipedia.org/wiki/Transport_Layer_Security#Applications_and_adoption Maybe I might be bias if there is any changing protocol negotiation or something. Thanks for all the help by the way. Roy. On Thu, Jul 25, 2013 at 4:00 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Thu, Jul 25, 2013, kirpit wrote: I understand the main problem is the server not responding clients supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull data by python not curl so we don't have the fancy to pass openssl parameters for connections and such. It uses the protocols whatever version of openssl it was compiled with. I am definitely going to complain about this issue to the service provider but I don't have much hope for them to take this seriously. So I wonder if next versions of openssl should care about workarounds for these painful servers? There are two workarounds but they have to be enables at compile time. You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or restrict the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for example 50. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: libssl 1.0.1 breaking program
On Thu, Jul 25, 2013, Marios Makassikis wrote:
On 26 June 2013 18:44, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote:
By enabling debug information in the program, I was able to obtain
these error messages:
pppd[2236]: EAP-TLS SSL error stack:
pppd[2236]: error:0D0C5006:asn1 encoding
routines:ASN1_item_verify:EVP lib
and
err: 7 (certificate signature failure)
The error certificate signature failure happens only when the
public key of an issuer certificate in the chain does not generate
a matching signature for its child certificate. Either the trust
store (CAfile, CApath, ...) certificates are not identical in the
two test cases, or one of the two parties sends a different chain,
or the handshake is somehow corrupted.
crypto/x509/x509_vfy.c:
internal_verify():
...
else if (X509_verify(xs,pkey) = 0)
{
ctx-error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
Look closely with wireshark at the chains captured on the machine
where the error is detected. Are the peer certificate chains the
same in every detail between the two library versions?
Are both cases using compression? Any other differences?
I meant to reply to this earlier but I got busy with other stuff. Anyhow, I
took some time and redid some tests:
- ppp with EAP-TLS patch compiled with libssl 0.9.8o-4squeeze14 works ok
(I had some surprises with CRL handling, but that's besides the point
right now)
- ppp with EAP-TLS patch compiled with libssl 1.0.1e-2 exhibits the same
behaviour I originally described, i.e.: server fails to validate
signature and sends an alert message to the client.
I tried two scenarios:
a) one root CA, generates two intermediate CAs. The first intermediate CA
is used to generate a certificate for the server, and the second CA
generates certificates for clients.
b) one root CA, used to generate two certificates (1 for the server and 1
for the client).
In both cases, only the server validates the client cert. Additionally, I made
sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for
message digests as MD5 is broken.
I noticed that the error occurs if one of the two peers is using the binary
linked with libssl 1.0.1.
Well that error is caused by a certificate chain verification failure. In
particular the signature verification of a certificate using the key in it's
issuer.
Possibly cause of that is a failure of the cryptographic algorithm (OpenSSL
bug or compiler bug) or for some reason OpenSSL isn't using the correct
certificate to verify the signature.
Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
I can share the certs ca files also if needed.
OpenSSL (among other things) does this when verifying the certificate chain:
openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem
where allcerts.pem is the complete peer chain and ee.pem is the peer
certificate. I'd be interested to see what that commands produces for
different version. If you use a directory and use -CApath instead.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Using MD5 certificates in OpenSSL FIPS
I am using OpenSSL FIPS module 2.0.5 with OpenSSL 1.0.1e on Windows. After calling FIPS_mode_set(1), I cannot call SSL_CTX_use_RSAPrivateKey_file. When I debug into it, it is failing when trying to initialize MD5. Apparently the private key is encrypted with MD5. I was under the impression that MD5 was not allowed in FIPS mode **unless** it's being used with TLS, which is what I'm doing. Am I wrong, or is there something else I have to do to allow MD5 in this case? Thank you Graeme Perrow __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: libssl 1.0.1 breaking program
On Thu, Jul 25, 2013 at 07:08:30PM +0200, Dr. Stephen Henson wrote: openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem where allcerts.pem is the complete peer chain and ee.pem is the peer certificate. I'd be interested to see what that commands produces for different version. If you use a directory and use -CApath instead. It should be noted that OpenSSL 1.0 changed the hashing algorithm used to index CApath/ directories. If the OP is using CApath with c_rehash generated from 0.9.8, that could failure to validate the client certificate, though the error would typically reflect lack of trust, not cryptographic integrity problems. Perhaps the client sends a stale copy of one the CA certificates, which has the right issuer name, but the wrong public key. Or the client's private key and certificate are not as intended... As for the packe captures on pastebin, it is too difficult to read pre-decoded packet dumps. The OP should post links to the binary pcap files. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: libssl 1.0.1 breaking program
On Thu, Jul 25, 2013, Viktor Dukhovni wrote: On Thu, Jul 25, 2013 at 07:08:30PM +0200, Dr. Stephen Henson wrote: openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem where allcerts.pem is the complete peer chain and ee.pem is the peer certificate. I'd be interested to see what that commands produces for different version. If you use a directory and use -CApath instead. It should be noted that OpenSSL 1.0 changed the hashing algorithm used to index CApath/ directories. If the OP is using CApath with c_rehash generated from 0.9.8, that could failure to validate the client certificate, though the error would typically reflect lack of trust, not cryptographic integrity problems. Yes I'd considered that as a possibility but as you say you'd get a different error. Perhaps the client sends a stale copy of one the CA certificates, which has the right issuer name, but the wrong public key. Or the client's private key and certificate are not as intended... The hints I get imply the verify algorithm is using the wrong certificate to verify the chain. To the OP: do those two CA certificates you mentioned have the exact same subject name? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: libssl 1.0.1 breaking program
From: owner-openssl-us...@openssl.org On Behalf Of Marios Makassikis Sent: Thursday, 25 July, 2013 11:56 To: openssl-users@openssl.org Subject: Re: libssl 1.0.1 breaking program On 26 June 2013 18:44, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote: pppd[2236]: EAP-TLS SSL error stack: pppd[2236]: error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib err: 7 (certificate signature failure) The error certificate signature failure happens only when the public key of an issuer certificate in the chain does not generate a matching signature for its child certificate. Either the trust store (CAfile, CApath, ...) certificates are not identical in the two test cases, or one of the two parties sends a different chain, or the handshake is somehow corrupted. Look closely with wireshark at the chains captured on the machine where the error is detected. Are the peer certificate chains the same in every detail between the two library versions? I meant to reply to this earlier but I got busy with other stuff. Anyhow, I took some time and redid some tests: snip In both cases, only the server validates the client cert. Additionally, I made sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for message digests as MD5 is broken. Are you sure? According to your successful (0.9.8) traces, the server requests client-auth and the client sends it. Unless ppp (can be and) is configured to tell libssl to do client-auth, but then supplies a callback that ignores the validation (a la s_client) it is validating. I noticed that the error occurs if one of the two peers is using the binary linked with libssl 1.0.1. As Viktor suggested, I examined the handshake with Wireshark. What I noticed: ClientHello * libssl 1.0.1 exposes more cipher suites * libssl 1.0.1 adds more extensions (ec_point_formats, elliptic_curves, heartbeat) ServerHello * libssl 1.0.1 adds the heartbeat extension 1.0.0 enabled ECC suites by default (in 0.9.8 had to enable explicitly) plus a few others. 1.0.1 enabled TLSv1.1 and v1.2 and additional suites for the latter, but ppp is apparently directing only TLSv1.0 even when using openssl 1.0.1. Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, 'x' Actually that's server Certificate, CertReq, HelloDone, then client KeyExchange, CertVerify, ChangeCipher, (Finished) then if successful server (something), ChangeCipher, (Finished) * 'x' is a TLSv1 Record Layer: Handshake Protocol: Finished for libssl1.0.1 * 'x' is a TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message for libssl0.9.8 I googled around to find more information regarding the encrypted handshake message and I couldn't find anything relevant. In fact, RFC2246 says the handshake should end with 'Finished' on both ends. I have no idea where that 'Encrypted Handshake Message' appeared from. Could it be some outdated function that is called to setup the connection that is changing this from the default ? The Finished message is a handshake message and is encrypted, since it occurs (just) after ChangeCipher. If Wireshark knows the data keys, it decrypts the message and displays it as Finished. If Wireshark doesn't know the data keys, it just displays Encrypted Handshake Message since it doesn't know which message it is without decrypting. For akRSA key-exchange, as this case, Wireshark can compute the data keys if it can determine the server RSA privatekey. Obviously it did this right in the case that displays (1.0.1). For normal IP connections, Wireshark chooses the server RSA key based on the server IP address and port; I don't know how that works/changes for PPP, but that's where I'd start looking. Below the URLs for the (text) captures. Let me know if you need the pcaps .. though I found having the text version is easier to run diff :-) Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv The 2nd and 4th are the same URL, but even 1st and 3rd appear to be two ends of the same exchange, which is redundant (unless there is frame loss or damage, which there isn't). I don't see anything in the 2nd that would explain sig-fail. Can you try openssl commandline on the same pair(s?) of systems, i.e. run s_server with the same CAcert and server keycert that pppd is using, and s_client to that server with the same CAcert and client keycert ppd client is using, for each version of openssl? If that fails we have an easier case to work on. If it works, there must be something about the embedding in EAP by ppp that messes up only sometimes, which would be really nasty.
CORR: libssl 1.0.1 breaking program
From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson Sent: Thursday, 25 July, 2013 21:32 From: owner-openssl-us...@openssl.org On Behalf Of Marios Makassikis Sent: Thursday, 25 July, 2013 11:56 Aargh. Sorry, I read this wrong: In both cases, only the server validates the client cert. Additionally, I made sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for message digests as MD5 is broken. Are you sure? According to your successful (0.9.8) traces, the server requests client-auth and the client sends it. Unless ppp (can be and) is configured to tell libssl to do client-auth, but then supplies a callback that ignores the validation (a la s_client) it is validating. People so often say only validate server that my eyes saw that even though you clearly wrote validate client. Ignore this and continue with the rest. Phooey. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
