0
$\begingroup$

Note - I know SSLv3 is dangerous but that is why I am using it to do demo of POODLE attack using server and client written in python.

So the question is I am using "ECDHE-RSA-AES128-SHA" cipher for connection between client and server.I also implemented the MITM(Man-In-The-Middle) proxy for connection. And when I am seeing the size of data being transmitted for every message then it is not multiple of 16 bytes.

Data is of like something structure ---

header with 5 bytes -- "\x17\x03\x00\x00 " (yes there is space in the end) and the remaining encrypted data.Amusingly the new data length by subtracting these 5 bytes is still not multiple of 16.

For single letter messages the size of data transmitted after encryption is 74 bytes(including that 5 byte header which never changes). And as soon as the message becomes more than 11 characters one block of 16 bytes is added so now the size becomes 90 bytes.

Isn't the size supposed to be the multiple of block size? So what is actually the structure of data being transmitted .

Note - I am using ssl.wrap_socket method to create ssl socket

Improve this question
$\endgroup$
3
  • $\begingroup$ Did you consult the relevant RFC 6101? $\endgroup$
    – SEJPM
    Nov 21, 2016 at 19:00
  • $\begingroup$ Yes I did but I didn't seem to get if whether struct SSLCiphertext is of exactly the above matching structure.And according to that the first one content type is correct \x17 stands for application data and \x03 stands for v3 but what \x00 \x00 means as it is not even the length? $\endgroup$
    – Vishvajeet Patil
    Nov 21, 2016 at 19:02
  • $\begingroup$ x17=handshake x03,00=version x00,20=length (hex 20 is ASCII space). $\endgroup$
    – dave_thompson_085
    Nov 22, 2016 at 14:39

1 Answer 1

Reset to default
3
$\begingroup$

You won't find the answer in the RFC; instead, here's what your SSL implementation is doing: when you send a single byte of data, it actually generates two records.

The first record is empty; so it consists of the 5 byte record header, and the encryption of the 20 byte HMAC tag (which, after encryption padding, is 32 bytes long); this is a total of 37 bytes.

The second record consists of the actual data; so it consists of the 5 byte record header, and the encryption of the data (1 byte) and the 20 byte HMAC tag (which after encryption padding, is 32 bytes long); this is a total of 37 bytes.

This totals to 74 bytes, which is exactly what you're seeing.

Also note that if you send more than 11 characters (and less than 28) of data, then the data along with the 20 byte HMAC data would require 64 bytes; this would extend the total data sent to 90 bytes (again, exactly what you see)

Now, why might an implementation choose to do this? Well, it's a defense against the BEAST attack. By including a dummy record up front, it makes the IV used to encrypt the actual data unpredictable (and hence foiling that attack); because the dummy record isn't sent until we actually have the data, the attacker cannot use it's IV value to select the data to encrypt.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Sorry but I didn't get one point " it makes the IV used to encrypt the actual data unpredictable (and hence foiling that attack)" .Will you please explain.And thanks for perfect answer.I am very glad $\endgroup$
    – Vishvajeet Patil
    Nov 21, 2016 at 19:54
  • $\begingroup$ @VishvajeetPatil: in SSLv3, the IV used to encrypt a record is the final ciphertext block from the previous record. BEAST uses this (by knowing the IV used for the data record, it selects the data to act as an encryption oracle). With the dummy record that is sent immediately before the actual data record, the attacker cannot select the data to encrypt based on the IV they'll use, because that IV is the last ciphertext block of the encrypted dummy record, and that won't be sent until after we have the actual data in hand $\endgroup$
    – poncho
    Nov 21, 2016 at 20:13
  • $\begingroup$ If there are two actual data records A1 and A2 then when A1 is being sent it is preceded with dummy record D1 and if D1's last block is IV for A1 then why shouldn't I be able to decrypt A1 $\endgroup$
    – Vishvajeet Patil
    Nov 21, 2016 at 20:35
  • $\begingroup$ @VishvajeetPatil: BEAST doesn't allow you to decrypt; instead, what it does is act as an encryption oracle ("given X, what's Encrypt(X)"). The attacker has no control over the dummy record A1 (which consists of the HMAC, and the padding and nothing else); he has control over the actual data record A2, but as he has no idea what IV will be used to encrypt A2, he doesn't know what data would be useful to put in there. $\endgroup$
    – poncho
    Nov 21, 2016 at 20:38
  • $\begingroup$ Sorry for disturbing you with so many queries.Can you tell then what was that IV that has been used during encryption of A2 because the party at receiving end will need IV too and it must be sent at some point of time and why MITM attacker can't have it?. Can you refer me any reading sources about this defense? $\endgroup$
    – Vishvajeet Patil
    Nov 21, 2016 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.