Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Possible bug in openssl?
15 views
Skip to first unread message
Andreas Bießmann
May 10, 2012, 5:39:53 AM5/10/12
to
Dear list members,
I've encountered a problem connecting to some https resources (especially one)
from some of my boxes. It seems the root cause is somewhere in openssl. So
here is my test case:
(debian stable box)
---8<---
abiessmann@git:~$ date
Do 10. Mai 11:03:12 CEST 2012
abiessmann@git:~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010
abiessmann@git:~$ openssl s_client -connect banking.postbank.de:443
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
<snip chain>
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip certificate>
-----END CERTIFICATE-----
<some more snip>
---
SSL handshake has read 4623 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
1044F1F221E30E12B6E2217D9949149DED775F882C15F13AF63FE027495ADF4E
Session-ID-ctx:
Master-Key:
678A316973D51613D56DC87C0FE8BB34E6B96CF4D9523715084AB3F3511F0C22C12252C2716FED128B6A1F591C806097
Key-Arg : None
Start Time: 1336640595
Timeout : 300 (sec)
Verify return code: 20 (unable
to get local issuer
certificate)
---
^C
--->8---
(one of the errournous boxes)
---8<---
abiessmann@azuregos % date
Do 10. Mai 11:02:50 CEST 2012
abiessmann@azuregos % openssl version
OpenSSL 1.0.1b 26 Apr 2012
abiessmann@azuregos % openssl s_client -connect banking.postbank.de:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
--->8---
(the same for all boxes which use 1.0+ release)
My questions:
* can anyone confirm this behaviour (it seems other hosts are working with
openssl 1.0+, but not the banking.postbank.de)?
* can anyone give me a hint how to track this down?
Best regards
Andreas Bießmann
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
I've encountered a problem connecting to some https resources (especially one)
from some of my boxes. It seems the root cause is somewhere in openssl. So
here is my test case:
(debian stable box)
---8<---
abiessmann@git:~$ date
Do 10. Mai 11:03:12 CEST 2012
abiessmann@git:~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010
abiessmann@git:~$ openssl s_client -connect banking.postbank.de:443
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
<snip chain>
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip certificate>
-----END CERTIFICATE-----
<some more snip>
---
SSL handshake has read 4623 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
1044F1F221E30E12B6E2217D9949149DED775F882C15F13AF63FE027495ADF4E
Session-ID-ctx:
Master-Key:
678A316973D51613D56DC87C0FE8BB34E6B96CF4D9523715084AB3F3511F0C22C12252C2716FED128B6A1F591C806097
Key-Arg : None
Start Time: 1336640595
Timeout : 300 (sec)
Verify return code: 20 (unable
to get local issuer
certificate)
---
^C
--->8---
(one of the errournous boxes)
---8<---
abiessmann@azuregos % date
Do 10. Mai 11:02:50 CEST 2012
abiessmann@azuregos % openssl version
OpenSSL 1.0.1b 26 Apr 2012
abiessmann@azuregos % openssl s_client -connect banking.postbank.de:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
--->8---
(the same for all boxes which use 1.0+ release)
My questions:
* can anyone confirm this behaviour (it seems other hosts are working with
openssl 1.0+, but not the banking.postbank.de)?
* can anyone give me a hint how to track this down?
Best regards
Andreas Bießmann
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Erwann Abalea
May 10, 2012, 6:38:00 AM5/10/12
to
Le 10/05/2012 11:39, Andreas Bießmann a écrit :
> [...]
I happen to get the same behaviour behind our firewall when
ECDHE-whatever is negociated as the ciphersuite. The FW drops the
connection, resulting in this "errno=104" error. Try to limit the set of
ciphersuites in your client.
--
Erwann ABALEA
-----
Lu sur alt.france :
Peut-on installer Win 95 par dessus win 95 tout en gardant les
differents données des logiciels fonctionnant auparavant sur wwin 95 ?
-+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+-
> [...]
ECDHE-whatever is negociated as the ciphersuite. The FW drops the
connection, resulting in this "errno=104" error. Try to limit the set of
ciphersuites in your client.
--
Erwann ABALEA
-----
Lu sur alt.france :
Peut-on installer Win 95 par dessus win 95 tout en gardant les
differents données des logiciels fonctionnant auparavant sur wwin 95 ?
-+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+-
Andreas Bießmann
May 10, 2012, 7:41:56 AM5/10/12
to
On Thu, May 10, 2012 at 12:38:00PM +0200, Erwann Abalea wrote:
> Le 10/05/2012 11:39, Andreas Bießmann a écrit :
> >My questions:
> > * can anyone confirm this behaviour (it seems other hosts are working with
> > openssl 1.0+, but not the banking.postbank.de)?
> > * can anyone give me a hint how to track this down?
>
> I happen to get the same behaviour behind our firewall when
> ECDHE-whatever is negociated as the ciphersuite. The FW drops the
> connection, resulting in this "errno=104" error. Try to limit the
> set of ciphersuites in your client.
Ok so 'openssl s_client -connect banking.postbank.de:443 -cipher AES256-SHA'
> Le 10/05/2012 11:39, Andreas Bießmann a écrit :
> >My questions:
> > * can anyone confirm this behaviour (it seems other hosts are working with
> > openssl 1.0+, but not the banking.postbank.de)?
> > * can anyone give me a hint how to track this down?
>
> I happen to get the same behaviour behind our firewall when
> ECDHE-whatever is negociated as the ciphersuite. The FW drops the
> connection, resulting in this "errno=104" error. Try to limit the
> set of ciphersuites in your client.
works with 1.0.1b. Thanks so far.
But it is nasty to limit cipher by host. So I could exclude all these ECDHE-
stuff if these really causing the error.
But I wonder if there is another solution. I see this behaviour with all tools
using openssl 1.0.1. I found it first with python on my mac and asked myself
why it works from time to time (python packaged by fink uses openssl-1.0.1,
Apple's version uses openssl-0.9.8 ;). However that could be fixed by working
around in my scripts but wget fails also and curl does, ... So I ask myself
'could there be a solution inside the library?'.
Best regards
Andreas Bießmann
Erwann Abalea
May 10, 2012, 8:08:28 AM5/10/12
to
Le 10/05/2012 13:41, Andreas Bießmann a écrit :
> On Thu, May 10, 2012 at 12:38:00PM +0200, Erwann Abalea wrote:
>> Le 10/05/2012 11:39, Andreas Bießmann a écrit :
>>> My questions:
>>> * can anyone confirm this behaviour (it seems other hosts are working with
>>> openssl 1.0+, but not the banking.postbank.de)?
>>> * can anyone give me a hint how to track this down?
>> I happen to get the same behaviour behind our firewall when
>> ECDHE-whatever is negociated as the ciphersuite. The FW drops the
>> connection, resulting in this "errno=104" error. Try to limit the
>> set of ciphersuites in your client.
> Ok so 'openssl s_client -connect banking.postbank.de:443 -cipher AES256-SHA'
> works with 1.0.1b. Thanks so far.
After more tests on this host, it appears it suffers from the "0xff
> On Thu, May 10, 2012 at 12:38:00PM +0200, Erwann Abalea wrote:
>> Le 10/05/2012 11:39, Andreas Bießmann a écrit :
>>> My questions:
>>> * can anyone confirm this behaviour (it seems other hosts are working with
>>> openssl 1.0+, but not the banking.postbank.de)?
>>> * can anyone give me a hint how to track this down?
>> I happen to get the same behaviour behind our firewall when
>> ECDHE-whatever is negociated as the ciphersuite. The FW drops the
>> connection, resulting in this "errno=104" error. Try to limit the
>> set of ciphersuites in your client.
> Ok so 'openssl s_client -connect banking.postbank.de:443 -cipher AES256-SHA'
> works with 1.0.1b. Thanks so far.
limit ClientHello" bug.
Try adding a large SNI extension to make this message bigger, by adding
the "-servername xxxxxx" argument to your command line, with a
sufficiently large "xxxxxx" string. It will stop working. With this only
cipher accepted, the "xxxxxx" has to be at least 192 bytes long to cause
the server to fail.
Your firewall is probably OK, your client is OK, the server is faulty.
> But it is nasty to limit cipher by host. So I could exclude all these ECDHE-
> stuff if these really causing the error.
>
> But I wonder if there is another solution. I see this behaviour with all tools
> using openssl 1.0.1. I found it first with python on my mac and asked myself
> why it works from time to time (python packaged by fink uses openssl-1.0.1,
> Apple's version uses openssl-0.9.8 ;). However that could be fixed by working
> around in my scripts but wget fails also and curl does, ... So I ask myself
> 'could there be a solution inside the library?'.
>
behaviour to correctly adapt to buggy servers.
--
Erwann ABALEA
-----
Quelqu'un peut me dire comment on fait pour creer un nouveaux groupe
Usenet? A qui faut-il s'adresse? Cela coute il de quoi?
-+- Moe in GNU - De quoi qu'est ce que ca coute-t-il combien ? -+-
0 new messages