We have recently upgraded our product to 1.0.2k. We are getting this error on a packet sent to us from our browser-based user interface. I really need some suggestions as to how to debug this problem. I know it is in our code rather
than OpenSSL but I have no idea how to dig into what is happening.
Craig Weeks | Sr. Software Developer, Support Response Team (SRT), Trend Micro Inc.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
On 25/04/17 22:37, [hidden email] wrote:
> We have recently upgraded our product to 1.0.2k. We are getting this
> error on a packet sent to us from our browser-based user interface. I
> really need some suggestions as to how to debug this problem. I know it
> is in our code rather than OpenSSL but I have no idea how to dig into
> what is happening.
Is this a reproducible problem? Normally bad_record_mac would only occur
if there was some implementation issue in the SSL/TLS stack itself or if
something is corrupting the records after they have been generated by
I'd start by looking at the end-to-end pipe between the client SSL/TLS
stack and the server stack and validating that the records look sane and
unchanged at each step.
If that doesn't pin-point the problem then you may need to dig a little
deeper. bad_record_mac can cover a multitude of sins. You need to figure
out what specific sin you are committing. If it was me I would be
instrumenting the OpenSSL code in this area to see what it thinks it is
barfing on. You might want to start with the tls1_enc() function in
ssl/t1_enc.c. If its a non-AEAD ciphersuite then you may need to look at
tls1_mac() too (also in ssl/t1_enc.c). Possibly parts of
ssl3_get_record() in ssl/s3_pkt.c
> On Apr 26, 2017, at 3:39 AM, Matt Caswell <[hidden email]> wrote:
> I'd start by looking at the end-to-end pipe between the client SSL/TLS
> stack and the server stack and validating that the records look sane and
> unchanged at each step.
Well before that, I'd try to find out what's different about the 1.0.2k
handshake, by comparing the negotiated protocol, ciphersuite and extensions
with those negotiated with the previous version used.
It would be appropriate to post which version of OpenSSL was used previously.
It is also important to make sure that the headers and dev libraries are from
the same 1.0.2 release and that the run-time libraries are in fact also from
1.0.2 (same patch level or higher).
This post has NOT been accepted by the mailing list yet.
>>It would be appropriate to post which version of OpenSSL was used previously.
Even I am facing the same issue. Previously I was using openssl-1.0.2j, there, everything was working fine. When I upgraded to openssl-1.0.2k, started seeing this problem. The operating system which I was using is scientific linux. I encountered this issue, when sending http_requests to ISILON array through REST APIs provided by the array. Used httplib and paramiko to communicate with the storage array. Please help me debugging the issue.