Re: [TLS] TLS 1.3 : small fragments attack

[Yoav Nir]

> On 30 Dec 2017, at 7:03, Peter Gutmann  wrote:
> 
> Jitendra Lulla  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.

Right. If you really want to hide typing patterns, you should send a big record 
every tenth of a second. Most of those would be zero-length fragments, but 
that’s OK.

In fact, the rogue client can do even better by just sending a bunch of 
zero-length records.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 : small fragments attack

[Viktor Dukhovni]

> On Dec 30, 2017, at 12:38 AM, Peter Gutmann  wrote:
> 
> 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.

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

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 : small fragments attack

[Peter Gutmann]

Jitendra Lulla  writes:

>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?

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 : small fragments attack

[Jitendra Lulla]

 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

Re: [TLS] TLS 1.3 : small fragments attack

[Peter Gutmann]

Jitendra Lulla  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