Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks)

Pasi.Eronen@nokia.com wrote:
> 
>    Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. 
>       [KPR03] can be used to attack a TLS server that reveals whether
>       a particular message, when decrypted, is properly PKCS#1
>       formatted, contains a valid PreMasterSecret structure, or has
>       the correct version number.
> 
>       The best way to avoid these vulnerabilities is to treat
>       incorrectly formatted messages in a manner indistinguishable
>       from correctly formatted RSA blocks. In other
> 
>       1. Generate a string R of 46 random bytes
> 
>       2. Decrypt the message M
> 
>       3. If the PKCS#1 padding is not correct, or the length of 
>          message M is not exactly 48 bytes:
>             premaster secret = ClientHello.client_version || R
>          else If ClientHello.client_version <= TLS 1.0, and
>          version number check is explicitly disabled:
>             premaster secret = M
>          else:
>             premaster secret = ClientHello.client_version || M[2..47]
> 
>       In any case, a TLS server MUST NOT generate an alert if
>       processing an RSA-encrypted premaster secret message fails, or
>       the version number is not as expected. Instead, it MUST continue
>       the handshake with a randomly generated premaster secret. Care
>       must also be taken to avoid leaking information about the error
>       situation via log files, or other channels.

I once had to analyze a handshake problem with a particular's vendor
SSL accellerator (server-side middle-box), where that box contained
an error in the RSA encryption and every once in a while sent garbage,
i.e. there was no recognizable PKCS#1 padding when RSA-decrypting
on the backend server.  I was lucky that our SSL implementation did
not use the OpenSSL approach, where this kind of error is not only
hidden from the peer, but also from the local caller.

Completely hiding the decryption failure from the local caller
creates a serious supportablility issue, so please be more careful
with the recommendation.  One should be careful, though, that the
local error reporting, which may be as simple as setting an integer
value to a particular value, does not result in a measurable timing
difference.  It is important that the local caller is able to
retrieve the real reason why the session establishment failed,
not "MAC failure" (as the SSL alert on the wire suggests") but
RSA-decryption failure.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls