> From: [email protected] On Behalf Of Evans, Darren E (IS)
> Sent: Thursday, 03 November, 2011 17:04

> I build both the 0.9.8k and 0.9.8r from the source.  They are 
> configured the same way, ./Configure solaris-sparcv9-cc 
> no-shared no-ecdh
> 
> It is installed in /usr/local/ssl.  I am linking in the 
> static libraries into the InterNetNews executable.  The 
> server it is installed on has 0.9.8o installed in /usr/local/ssl.
> 
To be exact, you're building INN on machine A linked statically 
against /usr/local/ssl while that contains either your k or r build,
and then running that link on machine B? Are you just re-linking, 
or are you recompiling INN? I don't recall any API changes that 
require recompiling, and I know the project tries to avoid them, 
but there might have been some and I wouldn't have noticed because 
the programs I work on are recompiled anyway. Also for completeness, 
which build is the commandline s_client you are using?

> On a successful connection it uses TLSv1/SSLv3, Cipher is 
> DHE-RSA-AES256-SHA. I'm not sure what it uses on the failed 
> connections.  I used s_client -msg, but it didn't say(output 
> below).  I'll try and get a network trace, but I'm not very 
> familiar with doing that, but will look into it.
> 
One must decode -msg (as I mentioned) but it is the same.

> **Result with 0.9.8k**
> # /usr/local/ssl/bin/openssl s_client -connect vbnews:563 -msg -state
<snip most>
> <<< TLS 1.0 Handshake [length 004a], ServerHello
>     02 00 00 46 03 01 4e b2 ff 92 c8 ee 39 0a 00 e1
>     ...
>     9a 5e 07 8b e9 da 24 00 39 00

Compare to below.

> **Result with 0.9.8r**
> # /usr/local/ssl/bin/openssl s_client -connect vbnews:563 -msg -state
> CONNECTED(00000004)
> SSL_connect:before/connect initialization
> >>> SSL 2.0 [length 007d], CLIENT-HELLO
>     01 03 01 00 54 00 00 00 20 00 00 39 00 00 38 00
>     ...
>     e9 c9 4a 08 fa 26 c4 c0 f5 c0 67 d1 06
> SSL_connect:SSLv2/v3 write client hello A
> <<< TLS 1.0 Handshake [length 0051], ServerHello
>     02 00 00 4d 03 01 4e b2 fe 5d a2 da 84 cd cb f6
>     ...
>     f6 40 85 d5 82 68 2f 00 39 00 00 05 ff 01 00 01
>     00

The 2 bytes at 71=x47 are the selected ciphersuite, 
and 00 39 is indeed DHE-RSA-AES256-SHA. As normally 
expected, this was the first entry in the client's 
list of offered ciphersuites. The 00 is the selected 
compression = none, and the 00 05 ff 01 00 01 00 
(which weren't in the 0.9.k response) is the new 
'secure-renegotiation' extension. 

<snip most>
> >>> TLS 1.0 ChangeCipherSpec [length 0001]
>     01
> SSL_connect:SSLv3 write change cipher spec A
> >>> TLS 1.0 Handshake [length 0010], Finished
>     14 00 00 0c 0c ef ac 10 ff c9 37 79 42 d1 f6 1e
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> <<< TLS 1.0 Alert [length 0002], fatal bad_record_mac
>     02 14
> SSL3 alert read:fatal:bad record mac
> SSL_connect:failed in SSLv3 read finished A
> 29173:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert 
> bad record mac:s3_pkt.c:1102:SSL alert number 20
> 29173:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
> failure:s23_lib.c:188:

So the server is definitely indicating the error on the 
Finished, which is the first encrypted&MACed record. (As 
expected since the handshake failed, but this confirms it.)

Does INN log the error(s) it gets from openssl? Maybe optionally? 
I would hope that gives some more detail, although for 
a crypto or MAC error it is unlikely to really pin it down.

Try using s_server instead of your server (unless you already 
did, but I don't remember you saying so). That will definitely 
give all available error details. Since you are building 
no-shared, commandline openssl is also statically linked, 
and you can copy that executable by itself.

Run each of the k and r openssl s_server, and try your same 
s_client to each of them. If that fails, you have a definite 
bug in openssl with what should be an easy reproducer. 
If not, i.e. the problem only occurs (or at least is visible) 
with INN application code, it's going to be harder. Either 
way, to try to narrow it, force different -cipher on s_client 
e.g. EDH-RSA-DES-CBC3-SHA DES-CBC3-SHA DES-CBC3-MD5 RC4-MD5.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [email protected]

Reply via email to