Weird size of data transmitted in SSLv3 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
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.