> From: owner-openssl-us...@openssl.org On Behalf Of Johnson, Chris E (OGA) > Sent: Wednesday, 10 August, 2011 11:45
> I typed in a term window in a linux machine the following command. > $ openssl s_client -connect rsa6.fema.gov:7004 > When the results are displayed there are two lines that show an error. > 47661220128736:error:140943FC: SSL routines: SSL3_READ_BYTES: > sslv3 alert bad record mac:s3_pkt.c:1193:SSL alert number 20 > 47661220128736:error:140790E5:SSL routines:SSL23_WRITE: > ssl handshake failure: s23_lib.c:177: 'bad-mac' shouldn't happen unless (at least) one end has a bug, or the data, here handshake data, was altered in transit (which *could* in principle be an attack, but is more often some piece of network infrastructure misconfigured or buggy). This is apparently 1.0.0b or later by the line numbers (unless whoever built it modified the source). Did you build it, or do you know who did, or are you using a public distro/package? What the software is that you're trying to connect to, if you know? Or at least the component doing SSL, we don't care about the rest? Or is it using hardware or offload for (SSL) crypto and if so what? Do you know or can you test if other clients (openssl on another machine, ideally another machine type, or other software) can connect to same server successfully? If so, what ciphersuite(s) do they select? > After those lines.the certificate part of the command is displayed > with the hashed cert. Do you mean like: Certificate chain 0 s:/CN=server2.CardSecure.example.invalid i:/CN=demoCA2.CardSecure.example.invalid 1 s:/CN=demoCA2.CardSecure.example.invalid i:/CN=demoCA2.CardSecure.example.invalid --- Server certificate -----BEGIN CERTIFICATE----- <several lines of alphanumeric and maybe plus slash equals> -----END CERTIFICATE----- subject=/CN=server2.CardSecure.example.invalid issuer=/CN=demoCA2.CardSecure.example.invalid --- ? That's not hashed, that's base64-encoded. You can recover the (full) cert if you need it, that's why it's displayed. If you see a cert the error is occurring at least well into the handshake. The only time bad-mac should occur in initial handshake is on the Finished, but "should" assumes no bugs. You can check by adding -state to your s_client commandline. (You could also or instead use -msg to get the PDU data, but I doubt that would be helpful here, just clutter.) Do you get the next block beginning "New ... Cipher is xxx" and if so what is xxx? If you manually select other available ciphersuites, do they fail the same way (bad-mac) or what? Possibly one end or the other has implemented one algorithm wrong, but that would be surprising -- unless it is an odd one like SEED or GOST, and then I'd be surprised to see it used on a USG server (although there might well be reason to do so). (Note that 'bad-mac' can actually mean bad-decrypt OR bad-mac; the alerts were combined to withhold sensitive information.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
