<div dir="ltr">Hi Matt,<div><br></div><div>Error is reported from this:</div><div>FILE:../openssl-1.1.1b/ssl/statem/statem_srvr.c, FUNCTION:415, LINE:3055, reason=147, alert=51<br></div><div><br></div><div>We see that hardware is returning 48 bytes. Even if the decrypted premaster data is correct, openssl is expecting more than 48 bytes in return.</div><div>This check fails as decrypt_len is 48.</div><div><span style="font-size:11pt;font-family:Calibri,sans-serif;background:yellow">decrypt_len < 11 + SSL_MAX_MASTER_KEY_LENGTH</span><span style="font-size:11pt;font-family:Calibri,sans-serif"> </span><br></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div>We compared the data returned when software is used. Decrypt_len is 256 bytes and the last 48 bytes are actual premaster secret. Also, openssl checks for if the first byte is 0 and second byte is 2. </div><div><span style="font-size:11pt;font-family:Calibri,sans-serif">We are trying to rectify this issue in hardware and return the correct data.</span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif">Please suggest if you have any comments for the above info.</span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif">Thanks</span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif">Mahendra</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 30/10/2020 11:22, Mahendra SP wrote:<br>
> Hi Matt,<br>
> <br>
> Thank you for the inputs.<br>
> Yes, we had encountered the padding issue initially. But we added<br>
> support for RSA_NO_PADDING in our hardware. That's why we are able to<br>
> successfully decrypt the premaster secret in the hardware.<br>
> Hence the issue does not seem to be related to padding. We have<br>
> confirmed this by comparing the premaster secret on both client and<br>
> server and they are the same.<br>
<br>
Ok, good.<br>
<br>
> <br>
> We suspect in this case, verification of "encrypted handshake message"<br>
> failure is happening.<br>
<br>
It's possible. It would be helpful if you can get more information from<br>
the error stack on the server, e.g. by using ERR_print_errors_fp() or<br>
something similar. I'm particularly interested in identifying the source<br>
file and line number where the decrypt_error is coming from. Printing<br>
the error stack should give us that information. There are a number of<br>
places that a "decrypt error" can occur and it would be helpful to<br>
identify which one is the cause of the problem.<br>
<br>
<br>
> We understand constant_time_xx APIs get used for CBC padding validation.<br>
> Will this have  any dependency on the compiler optimization or asm<br>
> flags?<br>
<br>
CBC padding validation is fairly independent of anything to do with RSA,<br>
so I think its unlikely to be the culprit here. Of course sometimes<br>
compiler optimization/asm issues do occur so it can't be ruled out<br>
entirely - but it's not where I would start looking.<br>
<br>
> Will this issue be seen if hardware takes more time for the<br>
> operation?<br>
> <br>
<br>
No. Constant time here just means that we implement the code without any<br>
branching based on secret data (e.g. no "if" statements/while loops etc<br>
based on secret dependent data). It has very little to do with how long<br>
something actually takes to process.<br>
<br>
<br>
> Here is the snippet of the wireshark where our device acting as server<br>
> closes the connection with decryption failure.<br>
<br>
Thanks. To narrow it down further I need to figure out which line of<br>
code the decrypt_error is coming from as described above.<br>
<br>
Matt<br>
<br>
<br>
<br>
> If you need any further info, please let us know. <br>
> image.png<br>
> Thanks<br>
> Mahendra<br>
> <br>
> Please suggest.<br>
> <br>
> <br>
> <br>
> On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a><br>
> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>> wrote:<br>
> <br>
> <br>
> <br>
>     On 30/10/2020 09:18, Mahendra SP wrote:<br>
>     > Hi All.<br>
>     ><br>
>     > We have upgraded openssl version to 1.1.1b<br>
>     ><br>
>     > With this, we are seeing decryption error during SSL handshake for the<br>
>     > below explained scenario. Our device acts as an SSL server.<br>
>     ><br>
>     > We have external hardware to offload RSA private key operations using<br>
>     > the engine.<br>
>     > Decryption of pre-master secret is done using hardware and is<br>
>     > successful. We compared the pre-master secret on both server and<br>
>     client<br>
>     > and they match.<br>
>     > However, we see that SSL handshake fails with "decrypt error (51)"<br>
>     with<br>
>     > an alert number 21. Verifying the encrypted finish message on the<br>
>     server<br>
>     > side fails.<br>
>     ><br>
>     > This issue does not happen with software performing RSA private key<br>
>     > operations.<br>
>     ><br>
>     > Can someone help with the reason for decryption failure? Below is the<br>
>     > compiler and processor details. It is 64 bit.<br>
>     > arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon<br>
>     -mfloat-abi=hard<br>
> <br>
>     Potentially this is related to the use of PSS padding in libssl which is<br>
>     mandated in TLSv1.3. The TLSv1.3 spec also requires its use even in<br>
>     TLSv1.2.<br>
> <br>
>     The PSS padding is implemented within the EVP layer. Ultimately EVP<br>
>     calls the function RSA_private_encrypt() with padding set to<br>
>     RSA_NO_PADDING.<br>
> <br>
>     Assuming your engine is implemented via a custom RSA_METHOD does it<br>
>     support RSA_private_encrypt(() with RSA_NO_PADDING? If not this is<br>
>     likely to be the problem.<br>
> <br>
>     More discussion of this is here:<br>
> <br>
>     <a href="https://github.com/openssl/openssl/issues/7968" rel="noreferrer" target="_blank">https://github.com/openssl/openssl/issues/7968</a><br>
> <br>
>     Also related is the recent discussion on this list about the CAPI engine<br>
>     and this issue:<br>
> <br>
>     <a href="https://github.com/openssl/openssl/issues/8872" rel="noreferrer" target="_blank">https://github.com/openssl/openssl/issues/8872</a><br>
> <br>
>     Matt<br>
> <br>
</blockquote></div>