1.19 KB, patch
Wan-Teh Chang: review+
|Details | Diff | Splinter Review|
4.30 KB, patch
Wan-Teh Chang: review+
Terry Hayes: superreview+
|Details | Diff | Splinter Review|
In http://www.openssl.org/~bodo/tls-cbc.txt the author describes an attack, attributed to Serge Vaudenay, against SSL/TLS ciphersuites that use block ciphers and CBC mode. To safeguard against this attack, he recommends that TLS and SSL3 implementations always return the alert bad_record_mac whenever the value of a padding byte does not contain the expected result. He recommends that the TLS alert decryption_failed be sent only when the input is not a multiple of the block size. This attack is against the symmetric cipher keys in a session, not against the server's private key(s). This attack has been public for some time.
Created attachment 93348 [details] [diff] [review] patch makes recommended changes (checked into NSS 3.6) Review invited.
Comment on attachment 93348 [details] [diff] [review] patch makes recommended changes (checked into NSS 3.6) r=wtc. Nelson told me that the first change in this patch is really an unrelated bug fix (the bug is that we are not sending any alert if the protocol is SSL3).
patch checked in
I'm reopening this bug. The patch checked in last August, which implemented changes recommended in the paper cited above, does NOT eliminate the vulnerability it was intended to prevent. Consequently, servers based on NSS 3.6 are still vulnerable to this attack, despite those changes. The attack depends on the ability to differentiate among various errors that may occur when processing a received encrypted TLS record. The cited paper recommended using the same error code in the alert records (TLS error messages) for all these errors, making it impossible to differentiate among the errors by the error code values. That is what the patch from last August did. But the error codes may never have been very useful to an attacker, because they are encrypted. The attacker used other means than error codes to differentiate among the errors, So, eliminating differences in error codes alone is insufficient to eliminate the vulnerability. http://lasecwww.epfl.ch/memo_ssl.shtml reveals the use of timing of the error messages, rather than their content (which is encrypted) to differentiate among the types of errors. Servers may choose to skip the CPU-intensive MAC calculation when the results of a previous test make it obvious that the MAC result will be incorrect prior to computing it. But consequently, the server's error message is sent more quickly than if the MAC was computed in all cases. The attacker uses the server's time savings to his advantage. Below I will attach a new patch that, when applied to the present NSS trunk sources, will render that timing attack ineffective by computing a MAC on received records whenever feasible, even when the TLS padding value is obviously incorrect.
Changing target milestone to NSS 3.8. Perhaps this should go into 3.7.2?
Created attachment 115133 [details] [diff] [review] new patch, v1 This patch is to be applied on top of the code with the previous patch. It is not a replacement for the previous patch, but suplements that patch.
Adding Terry to cc list. Terry, please review comments and patch recently added to this bug.
Comment on attachment 115133 [details] [diff] [review] new patch, v1 This looks correct to me. r=mcgreer
Here's a slightly better explanation than the one I gave in comment 4 above. The attacker observes an existing TLS connection that has completed a TLS handshake and has sent a message from client to server that contains the client's password. The attacker then constructs a specially designed TLS record and sends it to the server, making it appear to have come from the client. The constructed record is likely to cause the server to encounter an error when the server decrypts it and attempts to validate it. The attack depends on the attacker's ability to determine which of the various errors is detected by the server when processing that special TLS record. There are potentially several different ways that the attacker might make this determination. If the server sends out different error messages for the different errors, the attacker MIGHT be able to use those different error messages to determine which error occurred. The cited paper recommended having the server send out a single error code regardless of which of the different errors occured while validating the decrypted record. That would make it impossible for the attacker to use the error code number from the server to determine which error occurred. But in practice, the error codes are probably not very useful to the attacker because they are encrypted and the attacker typically cannot decrypt them. The attacker has to use other means to determine which error occured. So making the server send a single error code doesn't actually thwart the attack. I must correct one statement in my original description of the attack, preceeding comment 1 above. This is not an attack on keys. It is an attack that reveals the plain text of the messages without determining any keys. I have another, better, patch forthcoming.
What should users of existing NSS-based client and server products do in response to this bug? In my opinion, client users do not need to take any action. If they wish, they can disable TLS (but not SSL3) in the security preferences in mozilla or Netscape browsers, as an additional protection for unfixed servers. In my opinion, administrators of servers that implement TLS should disable TLS (not SSL3) until they can get a fixed version of the server. Administrators of servers that do NOT implement TLS do not need to take any action, in my opinion.
Created attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes This patch computes a MAC in ALL cases, unless the decryption fails completely or the MAC computation fails. Also, better comments.
Note, the paper that explains the actual attack is found at http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps Patch v2 checked in on trunk, after receiving oral review approval from wtc and thayes. Thanks also to Ian for reviewing patch v1.
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes r=wtc.
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes Requesting mozilla 1.3 approval.
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes sr=thayes
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes Approving for mozilla 1.3 (which should now be on the MOZILLA_1_3_BRANCH).
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes Patch checked into NSS_CLIENT_TAG for the Mozilla trunk (1.4alpha).
Patch checked into the NSS_3_7_BRANCH for the NSS 3.7.2 release.
Comment on attachment 115181 [details] [diff] [review] patch v2, incorporating review feedback from wtc and thayes I checked in this patch on the MOZILLA_1_3_BRANCH for mozilla 1.3 final.
patch checked into NSS_3_3_BRANCH. Checking in ssl3con.c; /cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v <-- ssl3con.c new revision: 22.214.171.124; previous revision: 126.96.36.199 done
Patch checked into NSS_3_4_BRANCH (ssl3con.c, rev. 188.8.131.52).