Re: [TLS] TLS 1.3 : small fragments attack
The pattern is perfectly normal and might be assumed to be coming from an interactive terminal. But what if such records, from the same session, come in a quantity of 1 or more per second which could be generated by uploading a 500 MB file by the client? And how about 100s of such clients targeting a server which is allowing file uploads? The server can be very easily kept busy decrypting and HMAC verifying such records just to obtain 1 real application data byte per record while the remaining 308 bytes are just overhead of securing the said byte! On Sat, 12/30/17, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: Subject: Re: [TLS] TLS 1.3 : small fragments attack To: "tls@ietf.org" <tls@ietf.org>, "Jitendra Lulla" <lull...@yahoo.com> Date: Saturday, December 30, 2017, 5:03 AM Jitendra Lulla <lull...@yahoo.com> writes: >The client can have a rogue TLS implementation with the following intentional >changes: > >0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing >power requirements) and non paralleliz'able cipher suite. > >1. After the handshake, always send all the TLS records (Application Data) >plain text fragment size which is no greater than 1 Byte. > >2. Always send a padding of max possible or big size (eg 256 Bytes) Apart from (2), that looks like interactive terminal traffic over TLS. The large padding may also be natually sent by an implementation that's trying a bit too hard to hide typing/traffic patterns. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 : small fragments attack
Hi, Is it possible for the standards/RFCs to dictate de-prioritization of certain troublesome TLS processing patterns? The RFCs -- may suggest identification of such patterns, -- may suggest implementation of certain low priority processing queues/threads/executions. Following is an example troublesome pattern which may or may not be coming from attackers: Please consider a scenario wherein a server is allowing the clients to upload big files. The client is mostly doing the transmission in this case. The client can have a rogue TLS implementation with the following intentional changes: 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing power requirements) and non paralleliz'able cipher suite. 1. After the handshake, always send all the TLS records (Application Data) plain text fragment size which is no greater than 1 Byte. 2. Always send a padding of max possible or big size (eg 256 Bytes) So the TLS record will look like: (1.2 version) 5 B Hdr + 16 B IV + 1B Cipher Text + 32 B HMAC + 255 B Padding.= 309 Bytes including the tls header. Additionally the client's network stack can have some changes which may possibly cause the following too: A. TCP segmentation B. IP Fragmentation Now the server will have to i. do ip reassmebly/ TCP reassembly to recover every single TLS record ii. The TLS record thus recovered will undergo decryption/HMAC verification only to obtain 1 Byte of plaintext application payload. If many such rogue clients sending huge files to the server, the server will end up denying services to the genuine clients. Now A and B above are not related to TLS, but the other points do have something to do with the implementations. If the server's TLS implantation can recognize this pattern [possibly from an attacker], it can give low priority to such requests so that other genuine requests may get served without being affected. If such preventive measures are a part of the RFCs, the implementations will be less vulnerable. Thanks Jitendra ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] rfc 6520 TLS heartbeat feature
Hi, As tls 1.3 is being worked upon, older work like rfc 6520 and any enhancements to it may not be as important. Also, particularly the TLS heartbeat feature, which has become famous for wrong reasons, is disabled by the SSL implementations eg OpenSSL. I tried to uncover an issue below pertaining to the heartbeat messages here: https://www.mail-archive.com/openssl-dev@openssl.org/msg47273.html Experts struggle to find any significant use of this feature for both the TLS and DTLS. I am planning to propose enhancements which will include restricted issuance of the heartbeat requests (wrt size and frequency) to avoid the exploit mentioned in the link above. A stronger standard will trigger bug/vulnerability free implementations. I would like to know if enhancements to this rfc are welcomed or it is there to be abandoned completely? In other words, is it worth spending time? Thanks Jitendra ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
