crypto/tls: fix pseudo-constant mitigation for lucky 13 #27071
dgryski opened this issue
Aug 18, 2018
· 11 comments
gopherbot pushed a commit that referenced this issue
Apr 16, 2019
The CBC mode ciphers in TLS are a disaster. By ordering authentication and encryption wrong, they are very subtly dependent on details and implementation of the padding check, admitting attacks such as POODLE and Lucky13. crypto/tls does not promise full countermeasures for Lucky13 and still contains some timing variations. This change fixes one of the easy ones: by checking the MAC, then the padding, rather than all at once, there is a very small timing variation between bad MAC and (good MAC, bad padding). The consequences depend on the effective padding value used in the MAC when the padding is bad. extractPadding simply uses the last byte's value, leaving the padding bytes effectively unchecked. This is the scenario in SSL 3.0 that led to POODLE. Specifically, the attacker can take an input record which uses 16 bytes of padding (a full block) and replace the final block with some interesting block. The MAC check will succeed with 1/256 probability due to the final byte being 16. This again means that after 256 queries, the attacker can decrypt one byte. To fix this, bitwise AND the two values so they may be checked with one branch. Additionally, zero the padding if the padding check failed, to make things more robust. Updates #27071 Change-Id: I332b14d215078928ffafe3cfeba1a68189f08db3 Reviewed-on: https://go-review.googlesource.com/c/go/+/170701 Reviewed-by: Filippo Valsorda <firstname.lastname@example.org> Run-TryBot: Filippo Valsorda <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.