Hi! I *think* the problem you are describing is actually on the server side.
IIRC this is because your s_client by default will attempt to use TLS 1.0 (SSL 3.1), which the server incorrectly parses as SSL 3.0 (ignoring the minor version number). TLS 1, which s_client assumes both parties have agreed to use, uses a different message authentication strategy than SSL 3.0, which is what the server thinks has been agreed. Thus, the server ends up generating a MAC which s_client is not able to verify, thus the error. If you explicitly tell s_client to only use SSL 2 or 3 this problem gets worked around. I'd better apologize in advance in case I've got this wrong. :-) //oscar Amnon Cohen wrote: > > Hi, > > I am having trouble performing a SSLv23 handshake to a large number of > servers > e.g. > > OpenSSL> s_client -connect commerce.www.ibm.com:443 > Loading 'screen' into random state - done > CONNECTED(00000028) > 497:error:1408F071:SSL routines:SSL3_GET_RECORD:bad mac > decode:.\ssl\s3_pkt.c:383: > > with -ssl3 or ssl2, the connect succeeds. > > I have searched the archives and found this problem mentioned a number of > times, > but no explanation or solution. > > Is this a bug in the openssl client or in IBM's server. > If it is a bug in openssl, is a fix planned? > > If it is a bug in IBM's server, is there an argument to SSL_set_options() > which will work around this bug? > > Many Thanks! > Amnon Cohen > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
