Subject: Re: [TLS] TLS 1.3 : small fragments attack

From: Jitendra Lulla <[email-masked]>
Date: Sat, 30 Dec 2017 05:33:13 +0000 (UTC)

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 10000 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 <[email-masked]> wrote:

 Subject: Re: [TLS] TLS 1.3 : small fragments attack
 To: "[email-masked]" <[email-masked]>, "Jitendra Lulla" <[email-masked]>
 Date: Saturday, December 30, 2017, 5:03 AM
 
 Jitendra Lulla <[email-masked]>
 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.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 30 Dec 2017 05:38:52 +0000

Jitendra Lulla <[email-masked]> writes:

>But what if such records, from the same session, come in a quantity of 10000
>or more per second which could be generated by uploading a 500 MB file by the
>client?

My comment was meant as a general observation on how hard anomaly-detection
is. At what point do you decide something is an attack?  What if they send 2-
byte messages?  Or 1-byte messages with only 64 bytes of padding?  Or 1 byte
every $server_timeout_value-1 seconds?

I think your idea in general is a good one, standards should include sanity
limits on what you should and shouldn't accept (I've managed to cause crashes
and reboots and whatnot on different servers by sending valid but unexpected
data during development, SSH makes this particularly easy), but in cases like
this it's hard to determine at which point you should and shouldn't accept the
traffic.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 30 Dec 2017 00:42:23 -0500

> On Dec 30, 2017, at 12:38 AM, Peter Gutmann <[email-masked]> wrote:
> 

Excessive padding aside, the traffic described could be largely normal,
for example an SSL-encrypted channel carrying user keystrokes...

-- 
	Viktor.