[openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

[Gola, Shailender K]

I ran some more tests, the issue seems to be optimization not platform types... when I removed -xO[n] from CFLAG, something (either cc or openssl compile set up) turned back on optimization at -xO3 level and I got this warning " cc: Warning: Optimizer level changed from 0 to 3 to support dependence based transformations." 

Since while using cc I was unable to force stop optimization, I used gcc and edited Makefile to remove optimization flag. It compiled with no alteration to optimization and the problem went away.

Thanks for your help.

Shailender Gola
Verizon Telecom




-----Original Message-----
From: Andy Polyakov via RT [mailto:rt at openssl.org] 
Sent: Wednesday, May 20, 2015 5:15 AM
To: Gola, Shailender K
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" 

Attachment 1 indicates that you execute on SPARC. At the same time you keep mentioning configuration for solaris-x86-cc. In normal situation it's interpreted as two platforms.

> 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see 
> attachment 2 showing " platform: solaris-x86-cc " (which I had done 
> before as well)... and executed the program, resulting in same ssl 
> errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept 
> problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption 
> failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: 
> SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert 
> bad record mac)

If you force x86 configuration on SPARC, no guarantees can be provided.
Even if it happens to work in some particular case. It just makes no sense to spend time thinking about it.