SSL Bug in Fedora Core 8 (and 6)

[Duncan Berriman]

I have found a problem with openSSL on FC8. The site being connected to has
a 
TLSv1 and SSLV3 SSL Certificate, however as of Fedora Core 6 
onwards if SSLv2 is disabled an SSL connection can not be negotiated.
 
openssl s_client -no_ssl2 -connect xxxxxx.xxxx.com:443
CONNECTED(00000003)
2159:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
failure:s23_lib.c:188:

On Fedora Core 4 it works fine and wither a TLSv1 or SSLv3 
connection can be made.

New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 
00152056A7A28668B4EB1451B8A2F6809C29A16858585858474743BD00006718
    Session-ID-ctx:
    Master-Key: 
720DC5F3697624BF8C3BEA800AC9EB386B234BB759F9ACD338ADA9DDEBB090
9FD693C0F32DD0A6D577D6CA18A6345C72
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1195851233
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)

This encounted on a live server at a data 
centre running Fedora Core 6. I then did a fresh install on 
another machine at the office of FC6 and reproduced the
problem. I then did a fresh install of FC8 on the same 
machine and again managed to reproduce them straight away.

I have since downgraded the live server to FC4 and it has 
Fixed the issue. Problem is not apparent in FC4, Enterprise 3
Or enterprise 4.

Happy to provide the server name off list or do any debugging
If someone can tell me what they need.

Thanks in advance
Duncan

[Jonathan Underwood]

On 28/11/2007, Duncan Berriman <duncan(a)dcl.co.uk&gt; wrote:
>  I have found a problem with openSSL on FC8. The site being connected
> to has
>  a
>  TLSv1 and SSLV3 SSL Certificate, however as of Fedora Core 6
>  onwards if SSLv2 is disabled an SSL connection can not be negotiated.
>
>  openssl s_client -no_ssl2 -connect xxxxxx.xxxx.com:443
>  CONNECTED(00000003)
>  2159:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>  failure:s23_lib.c:188:
>
>  On Fedora Core 4 it works fine and wither a TLSv1 or SSLv3
>  connection can be made.
>
>  New, TLSv1/SSLv3, Cipher is RC4-MD5
>  Server public key is 1024 bit
>  SSL-Session:
>      Protocol  : TLSv1
>      Cipher    : RC4-MD5
>      Session-ID:
>  00152056A7A28668B4EB1451B8A2F6809C29A16858585858474743BD00006718
>      Session-ID-ctx:
>      Master-Key:
>  720DC5F3697624BF8C3BEA800AC9EB386B234BB759F9ACD338ADA9DDEBB090
>  9FD693C0F32DD0A6D577D6CA18A6345C72
>      Key-Arg   : None
>      Krb5 Principal: None
>      Start Time: 1195851233
>      Timeout   : 300 (sec)
>      Verify return code: 18 (self signed certificate)
>
>  This encounted on a live server at a data
>  centre running Fedora Core 6. I then did a fresh install on
>  another machine at the office of FC6 and reproduced the
>  problem. I then did a fresh install of FC8 on the same
>  machine and again managed to reproduce them straight away.
>
>  I have since downgraded the live server to FC4 and it has
>  Fixed the issue. Problem is not apparent in FC4, Enterprise 3
>  Or enterprise 4.
>
>  Happy to provide the server name off list or do any debugging
>  If someone can tell me what they need.
>
>  Thanks in advance
>  Duncan 
Sounds like you should file a bug report at http://bugzilla.redhat.com

[Gordon Messmer]

Duncan Berriman wrote:
>  I have found a problem with openSSL on FC8. The site being connected
> to has
>  a 
>  TLSv1 and SSLV3 SSL Certificate, however as of Fedora Core 6 
>  onwards if SSLv2 is disabled an SSL connection can not be negotiated.
>   
>  openssl s_client -no_ssl2 -connect xxxxxx.xxxx.com:443
>  CONNECTED(00000003)
>  2159:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
>  failure:s23_lib.c:188: 
I can't reproduce that.  I can connect to ssl sites with s_client reliably.

>  Happy to provide the server name off list or do any debugging
>  If someone can tell me what they need. 
Feel free to email me.  Give me the command line that you used, and I'll 
check the results.  If I can get the "self signed cert" warning, I'll 
try to determine why that is.