Using OpenSSL 0.9.8 issue between version k and r with Application
Evans, Darren E (IS)
My customer(Government) wants to block use of SSLv2 with the INN server due to security vulnerabilities. I recompiled the INNews source and specify the SSL option of no SSLv2. I had tried just compiling OpenSSL without SSLv2, but that caused problems as well. The issue I am having is that it works with OpenSSL 0.9.8k, but not with 0.9.8r. It gets the following error with a SSL alert number 20, alert bad record mac.
Using the openssl on the server I was able to get the following info as well:
# /usr/local/ssl/bin/openssl s_client -connect vbnews:563
CONNECTED(00000004)
depth=0 /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=DISA/CN=vbnews.vb.c2fse.northgrum.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=DISA/CN=vbnews.vb.c2fse.northgrum.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=DISA/CN=vbnews.vb.c2fse.northgrum.com
verify error:num=21:unable to verify the first certificate
verify return:1
22555:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1102:SSL alert number 20
22555:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
I have checked all of the obvious issues with certificates (It is issued from a real CA and the trusts and CAcerts are all in place). The server is in DNS correctly. My development network does not have outside connectivity, but is a VLAN (You can get in, but not out). Everything worked fine with INN 2.5.1 and openssl-0.9.8k, but I decided to use the newer version for updates and bug fixes.
Has anyone seen any problems with INN 2.5.1 or another application and the newer openssl versions? Is 0.9.8r doing more strict verification? I am using the INNews opensource so it is possible to make changes to how it creates it’s SSL context, like specifying the no SSLv2, but I am not familiar with the source, we just repackage it.
Thank you for the help.
Darren Evans
Software Engineer
NORTHROP GRUMMAN Corporation
Mission Systems
Darren Evans
Software Engineer
NORTHROP GRUMMAN Corporation
Mission Systems
2829 Guardian Lane
Virginia Beach, VA 23452
Office: 757.226.1161
Fax: 757.226.1175
Cell: 757.641.1578
darren...@ngc.com
evansda
View this message in context: http://old.nabble.com/Using-OpenSSL-0.9.8-issue-between-version-k-and-r-with-Application-tp32759494p32759494.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
> Sent: Tuesday, 01 November, 2011 11:43
> My customer(Government) wants to block use of SSLv2 with the
> INN server due
> to security vulnerabilities. I recompiled the INNews source
> and specify the
> SSL option of no SSLv2. I had tried just compiling OpenSSL
> without SSLv2,
> but that caused problems as well. The issue I am having is
> that it works
> with OpenSSL 0.9.8k, but not with 0.9.8r. It gets the
> following error with
> a SSL alert number 20, alert bad record mac.
>
> Using the openssl on the server I was able to get the
> following info as
> well:
>
> # /usr/local/ssl/bin/openssl s_client -connect vbnews:563
>
> CONNECTED(00000004)
> verify return:1
> verify return:1
> verify return:1
> 22555:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert
> bad record mac:s3_pkt.c:1102:SSL alert number 20
> 22555:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
>
> I have checked all of the obvious issues with certificates
> (It is issued
> from a real CA and the trusts and CAcerts are all in place).
OpenSSL ... but that caused problems"; does that mean
you are NOT using a version you built (did not install it,
or removed it)? Are both the 0.9.8k and the 0.9.8r you are
trying built/packaged by the same supplier, in the same way?
To see where they look, /each/ver/openssl version -d (or -a) .
Or specify -CAfile and/or -CApath explicitly to s_client .
But an untrusted server cert doesn't cause bad_record_mac.
In s_client it is overridden; in an app like INN it likely
causes the connection attempt (handshake) to fail;
but it should never cause bad_record_mac. (OpenSSL
verify_error=20 and SSL alertnum=20 are entirely different
and unrelated, they just happen to be the same number.)
Also note that a different alertnum=21 was assigned for
decryption_failure but this distinction turned out to aid
some attacks so most implementations including OpenSSL now
use 20 for both causes -- but NEITHER should be happening.
Do you have other (server) apps that are using, or could use,
the same 0.9.8r? With what result(s)? How about a different
build of 0.9.8r (on different machine type, or from source)?
What ciphersuite is selected when it fails (for s_client,
or for other clients which I assume you have some of)?
(Use s_client -msg and decode the ServerHello, or usually
easier get a network trace. I find wireshark most convenient
but it's only Windows and Mac so you need one of those on
the same LAN segment, or capture with tcpdump or similar
and download the file to wireshark.) When it succeeds?
Try forcing other ciphersuite(s) especially the data cipher
and perhaps MAC (easy with s_client if there are any allowed
and supported by the server, other clients I can't say)?
> The server is
> in DNS correctly. My development network does not have outside
> connectivity, but is a VLAN (You can get in, but not out). Everything
(I'd normally expect a netnews server to use and have outgoing
access, but that's not an SSL issue and not relevant here.)
> worked fine with INN 2.5.1 and openssl-0.9.8k, but I decided
> to use the
> newer version for updates and bug fixes.
>
> Has anyone seen any problems with INN 2.5.1 or another
> application and the
> newer openssl versions? Is 0.9.8r doing more strict
I don't know about (any version of) INN. The only major
protocol change I recall is that since about 0.9.8m
(and 1.0.0a IIRC) the secure-renegotiation feature
is implemented. You could go through the CHANGES file,
but any new check or restriction should fail the handshake
with a specific error, not bad_record_mac.