From d7e2e9316a5540e93595b5386f67594135de736d Mon Sep 17 00:00:00 2001 From: lloyd Date: Fri, 9 Apr 2010 03:43:48 +0000 Subject: If the CBC padding is incorrect, then assume the pad size is zero and carry on with the procedure. This prevents a timing attack where an attacker could distinguish bad padding vs MAC failure. This timing channel used in the paper "Password Interception in a SSL/TLS Channel" by Vaudenay et. al. to attack SSL in certain fairly realistic use scenarios. --- src/ssl/rec_read.cpp | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'src') diff --git a/src/ssl/rec_read.cpp b/src/ssl/rec_read.cpp index 4f030cf1e..8f8e5dc1e 100644 --- a/src/ssl/rec_read.cpp +++ b/src/ssl/rec_read.cpp @@ -163,18 +163,24 @@ u32bit Record_Reader::get_record(byte& msg_type, byte pad_value = plaintext[plaintext.size()-1]; pad_size = pad_value + 1; + /* + * Check the padding; if it is wrong, then say we have 0 bytes of + * padding, which should ensure that the MAC check below does not + * suceed. This hides a timing channel. + * + * This particular countermeasure is recommended in the TLS 1.2 + * spec (RFC 5246) in section 6.2.3.2 + */ if(version == SSL_V3) { if(pad_value > block_size) - throw TLS_Exception(BAD_RECORD_MAC, - "Record_Reader: Bad padding"); + pad_size = 0; } else { for(u32bit j = 0; j != pad_size; j++) if(plaintext[plaintext.size()-j-1] != pad_value) - throw TLS_Exception(BAD_RECORD_MAC, - "Record_Reader: Bad padding"); + pad_size = 0; } } -- cgit v1.2.3