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  wrote:

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

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

[TLS] TLS 1.3 : small fragments attack

[Jitendra Lulla]

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

Re: [TLS] Interaction between cookies and middlebox compat mode

[Matt Caswell]

On 28/12/17 18:06, Eric Rescorla wrote:
> I must be missing your point. According to the spec as it stands even
> with a stateful server I MUST ignore a CCS that comes first. Since this
> is a stateful server it may end up negotiating TLSv1.2 - which requires
> us to abort the handshake if the CCS comes first. No sensible
> implementation will ever send a CCS first in this scenario, so why am I
> required by the spec to ignore it and implement the extra complexity in
> TLSv1.2 handling?
> 
> In reality I wouldn't bother to implement this which would make me
> technically non-compliant. I would prefer it if the wording were fixed
> to not require this.
> 
> 
> OK, I understand your point now, I think it's fine to reject this case
> as long as
> you properly handle things in the stateless case. If you want to submit
> a PR,
> I will take a look.

https://github.com/tlswg/tls13-spec/pull/1129

Matt

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