tintinweb / scapy-ssl_tls

SSL/TLS layers for scapy the interactive packet manipulation tool
GNU General Public License v2.0
419 stars 156 forks source link

Question: working around unsigned short assignment on TLSrecord length #89

Closed perrin-ay closed 7 years ago

perrin-ay commented 7 years ago

Hi again @alexmgr

I have a test case which requires me to send tlsrecord of > 2**19. I realize this is not rfc compliant which is sort of the objective of my test case. I'm still parsing through the code to see what can be done to accommodate this - already made changes to MAX_LEN in tlsrecord and also tried changing length to unsigned long or unsigned int. When i make this format character chnage , example say i change code to XLenField("length", None, fmt="!L")] in fields_desc of tlsrecord class, things get messed up in general with all tlsrecord's. example a working benchmark client hello when code remains unchanged( i.e fmt="!H") hex dump looks like

0000 16 03 03 00 2d 01 00 00 29 03 03 58 73 d4 f0 4a 0010 b4 f2 a2 45 25 5c f5 c7 38 fc 13 b5 d1 f6 02 f2 0020 83 d2 2d 42 64 bc f5 60 9d f7 df 00 00 02 00 35 0030 01 00 and is of 116 bytes

when i make the change to unsigned long the client hello hex dump looks like

0000 16 03 03 00 00 00 2d 01 00 00 29 03 03 58 73 d5 0010 78 cf 28 5c fb 62 35 ff 98 ea 0a c4 49 a0 50 56 0020 bd 64 5f f9 18 65 31 ad 3f c5 12 66 98 00 00 02 0030 00 35 01 00 and is of 118 bytes

the problem with the non working one is the extra two bytes of 00 00 ( in bold) inserted. If not for that , the hexdump would be congruous to the working hexdump and should work fine.

I'm still perusing the code to understand it better and make correct adjustments , but in the mean time if you have any quick tips or suggestions , i would very much appreciate it

Thanks!

alexmgr commented 7 years ago

Hi @perrin-ay,

There is tls_fragment_payload which allows to fragment records on whatever boundary you wish. I understand that that's not really what you're after, but worth mentioning ;)

I don't think what you're trying to do will work, because the record length field is dictated by the spec. So even if you increase it's size, the receiving end will still read it as a 3 byte field. Generally with TLS fragmentation, the interesting use cases I have seen are around fragmenting the handshake across multiple records. The max record size (214) and max handshake size (216) are different, which leads to some interesting edge cases.

Cheers, Alex

perrin-ay commented 7 years ago

Hi @alexmgr

Apologies for opening this issue. I realized the mistake in my query moments after hitting submit and subsequently closed the case.

But thank you for your attention and input.

If you are interested , to give some background on what i was looking at , at the time, was to draw out a plan to trigger this ASSERT in openssl https://github.com/openssl/openssl/blob/master/ssl/s3_cbc.c#L170

I had to step away from this and onto other things , but time permitting will get back to it soon.

Thanks again!