Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#17 closed clarification (fixed)

RSA padding bugs

Reported by: pasi.eronen@… Owned by:
Priority: minor Milestone:
Component: draft-ietf-tls-rfc4346-bis Version: 03
Severity: Keywords:
Cc:

Description

http://www1.ietf.org/mail-archive/web/tls/current/msg00881.html

Page 62: Section 7.4.9.1 under Note: This section suggests a
procedure to prevent the Bleichenbacher attack on PKCS#1 v1.5
encrypted messages (specifically the pre-master secret.) This
procedure is not listed as mandatory. We recommend that either 
this procedure be made mandatory, or that all RSA encrypted 
messages be required to use the OAEP padding scheme specified 
in PKCS#1 v2. In the latter scenario, the overwhelming majority 
of PKCS#1 v1.5 formatted messages would need to be rejected by 
any compliant implementation.  

There is ANOTHER note later in this section (at the very end, 
after the implementation notes) that discusses a variant of 
the Bleichenbacher attack (by Klima, Pokorny, and Rosa - see 
[KPR03]) that depends on the server reporting on errors found 
in the version number included in the RSA-decrypted premaster-
secretmessage. Therefore, the draft's weak statement to the 
effect that servers shouldn't generate an alert if there is 
such a problem should also be strengthened to a MUST NOT. In 
fact, it should be a general rule that decryption problems 
with PKCS #1.5-formatted messages MUST NOT trigger actions 
that are observably different than the actions that would be 
taken if there were no problems.

Change History (7)

comment:1 Changed 15 years ago by pasi.eronen@…

http://www1.ietf.org/mail-archive/web/tls/current/msg01003.html

Hmm... IMHO this section, as its currently written, doesn't offer
enough guidance for an implementer to get it right. Furthermore, the
text in Appendix E.2 (about what TLS-capable servers should do in SSL
2.0 compatibility mode) confuses things even further (and seems to
ignore the existence of Bleichenbacher/Klima attacks).

Then there's the issue on what the spec should say about checking the
version number in PreMasterSecret. Currently, it simply says "Client
implementations MUST and Server implementations MAY check the version
number", which is IMHO a bit vague.

Here's a suggested rephrasing for the first and fourth note
in Section 7.4.9.1:

   Note: The version number in the PreMasterSecret is the version
      offered by the client in the ClientHello.client_version, not the
      version negotiated for the connection.  This feature is designed
      to prevent rollback attacks.  Unfortunately, some old
      implementations use the negotiated version instead and therefore
      checking the version number may lead to failure to interoperate
      with such incorrect client implementations.

      Client implementations MUST always send the correct version
      number in PreMasterSecret. If ClientHello.client_version is TLS
      1.1 or higher, server implementations MUST check the version
      number as described in the note below. If the version number is
      earlier than 1.0, server implementations SHOULD check the
      version number, but MAY have a configuration option to disable
      the check.

   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.
    
      The RSAES-OAEP encryption scheme defined in [PKCS1] is more
      secure against the Bleichenbacher attack. However, for maximal
      compatibility with earlier versions of TLS, this specification
      uses the RSAES-PKCS1-v1_5 scheme. No variants of the
      Bleichenbacher attack are known to exist provided that the above
      recommendations are followed.

And rewrite appendix E.2 as follows (changing SHOULD to MUST 
for sending the 0x03 padding):

E.2. Avoiding man-in-the-middle version rollback

   When TLS clients fall back to Version 2.0 compatibility mode, they
   MUST use special PKCS#1 block formatting. This is done so that TLS
   servers will reject Version 2.0 sessions with TLS-capable clients.

   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
   the right-hand (least-significant) 8 random bytes of the PKCS
   padding (not including the terminal null of the padding) for the
   RSA encryption of the ENCRYPTED-KEY-DATA field of the
   CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random).

   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
   padding bytes are 0x03. If they are not, the server SHOULD generate
   a random value for SECRET-KEY-DATA, and continue the handshake
   (which will eventually fail since the keys will not match).  Note
   that reporting the error situation to the client could make the
   server vulnerable to attacks described in [BLEI].

comment:2 Changed 15 years ago by pasi.eronen@…

http://www1.ietf.org/mail-archive/web/tls/current/msg01048.html

> I do agree that such debugging features are useful in many 
> circumstances -- but there are other channels than timing
> that may leak information. How about rephrasing this:
> 
>    "Care must also be taken to avoid leaking information about
>    the error situation via log files, or other channels."
> 
> as follows:
> 
>    "It may be useful to log the real cause of failure for
>    troubleshooting purposes; however, care must be taken to 
>    avoid leaking the information the attacker (though, e.g.,
>    timing, log files, or other channels)."

Fine with me.

               ... the information to an attacker ...

maybe.

comment:3 Changed 15 years ago by pasi.eronen@…

  • Milestone set to milestone1

comment:4 Changed 15 years ago by ekr@…

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 follow-up: Changed 15 years ago by pasi.eronen@…

  • Milestone milestone1 deleted
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 02 to 03

This isn't fixed or otherwise handled yet in -03?

comment:6 in reply to: ↑ 5 Changed 14 years ago by ekr@…

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to pasi.eronen@nokia.com:

This isn't fixed or otherwise handled yet in -03?

comment:7 Changed 14 years ago by ekr@…

OK. Fixed it this time.

Note: See TracTickets for help on using tickets.