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

[Bodo Moeller <bmoeller at acm.org>]

On Mon, Nov 27, 2006 at 09:27:16PM +0100, Martin Rex wrote:
> Pasi.Eronen at nokia.com wrote:

>>       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.  [...]

"Care must be taken to avoid leaking information" is exactly right.
It is true that supressing the detailed error information can be a
problem for debugging, but this just means that the standard
production setup isn't always adequate for debugging purposes.
(E.g. software could have a switch that enables more detailed
log file entries that reveal when a padding error was detected.)

The problem is that the adversary might have access, however limited,
to the server system.  Even if the adversary can't actually read the
TLS server logfile, we may have an "ls -l" attack if the error
messages are of different length for different error cases: merely
observing the length of the logfile may allow the adversary to
distinguish between different error cases, and thus to perform the
attack.

You still can record the information if you desire, you just have to
thoroughly make sure you don't leak it to the adversary.

Bodo


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