Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Ilari Liusvaara  writes:
>On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
>> It also means you're going to be in for a rude shock when you encounter the
>> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
>
>That did not check for interop with any mainstream TLS library?

Mainstream TLS 1.3 libraries?  Since the spec is still subject to weekly
changes, I doubt there's anything to interop test with.  

(It's actually a bit of a rhetorical question, since I've seen little to no
evidence that embedded/SCADA/etc has any intention of throwing away their
existing investment and starting again with 1.3 or 2.0 or whatever it'll be
called, I doubt there'll be much to non-interop with.

>Also, code to "recover" tends to introduce security issues if used in
>security protocols. 

This isn't "code to recover", it's just normal code.  If anything, it's adding
additional code to check for problems that aren't really problems that'll lead
to security issues.

>Well, the problem you encounter first with HTTP/2 is that it really dislikes
>unencrypted operation. Which impiles you pretty much need encryption. Which
>impiles you pretty much need the WebPKI certificate model... Which tends to
>be poor match for anything except named servers on the internet, which tends
>not be suitable for IoT stuff...

Yup.  The HTTP/2 folks' response to this at the time was "let them eat 1.1",
pretty much guaranteeing a fork of the HTTP protocol, with two different
versions being maintained in perpetuity.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Yoav Nir  writes:

>But if at some point all websites use HTTP-whatever-the-current-version-is
>then maybe browsers can remove support for HTTP/1.1 and then your
>embedded/SCADA/IoT devices won’t give us that rude shock.

Since HTTP/2 pretty much guarantees that SCADA/IoT/etc will keep using HTTP
1.1 forever, browsers are going to have to keep supporting both versions
forever.  Either that or there'll be custom forks of browsers sold as "SCADA
administration clients" or something similar.

>I honestly don’t think that having two protocols for these two radically
>different use cases is a bad outcome.

Neither do I.  The problem is that we're supposed to pretend that HTTP 1.1
will go away and everything will only talk HTTP/2, rather than accepting that
both will be with us for a long time, if not forever.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote:
> Andreas Walz  writes:
> >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
> >addresses this in the Presentation Language section:
> >
> >  "Peers which receive a message which cannot be parsed according to the
> >  syntax (e.g., have a length extending beyond the message boundary or
> >  contain an out-of-range length) MUST terminate the connection with a
> >  "decoding_error" alert."
> 
> And how many implementations are going to do this?  Consider the
> error-message litmus test I proposed earlier, reasons for failing to
> connect to (say) amazon.com:
> 
>   Error: Couldn't connect to Amazon because its certificate isn't valid.
>  
>   Error: Couldn't connect to Amazon because no suitable encryption was
>  available.
> 
>   Error: Couldn't connect to Amazon because   decoding_error alert>

"received data was malformed."

> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.

We are talking about a cryptographic protocol. Being very strict about what 
you receive is the raison d'être of the whole thing.

POODLE happened because SSL 3 in general and some TLS implementations in 
particular weren't strict.

Researchers look at protocol itself and only a handful of popular 
implementations, they won't be analysing if the TLS-as-implemented-by-ACME-
widget-7000 is secure even if it isn't strict.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Suspicious behaviour of TLS server implementations

[Ilari Liusvaara]

On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote:
> Martin Thomson  writes:
> 
> >The advantage with deploying a new protocol is that you can be strict. If, 
> >for example, all of the browsers implement TLS 1.3 and are strict, then 
> >Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
> >pretty quickly.  You might suggest that that's aspiration to the point of 
> >delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
> >didn't squash ALL of the nasty bugs, but we got most of them.
> 
> It also means you're going to be in for a rude shock when you encounter the
> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.

That did not check for interop with any mainstream TLS library?

Also, code to "recover" tends to introduce security issues if used in
security protocols. Just because I don't have to deal with simple bugs
like buffer overflows leading to RCE or data races does not mean I can
do whatever I want and expect the code to have low number of security
issues. The existing stuff is way more than enough.

(Just fixed a bug where NotBefore/NotAfter of dedicated OCSP responder
certificate were not validated... Not related to recovery in any way,
but still some special code).

> The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
> Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
> else that uses HTTP as its universal substrate.  As a result there will be 
> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
> version-is.

Well, the problem you encounter first with HTTP/2 is that it really
dislikes unencrypted operation. Which impiles you pretty much need 
encryption. Which impiles you pretty much need the WebPKI certificate
model... Which tends to be poor match for anything except named servers
on the internet, which tends not be suitable for IoT stuff...

> (Should I mention TLS-LTS here? :-).

Ugh...



-Ilari

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Yoav Nir]

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann  wrote:
> 
> Martin Thomson  writes:
> 
>> The advantage with deploying a new protocol is that you can be strict. If, 
>> for example, all of the browsers implement TLS 1.3 and are strict, then 
>> Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
>> pretty quickly.  You might suggest that that's aspiration to the point of 
>> delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
>> didn't squash ALL of the nasty bugs, but we got most of them.
> 
> It also means you're going to be in for a rude shock when you encounter the
> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
> The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
> Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
> else that uses HTTP as its universal substrate.  As a result there will be 
> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
> version-is.

Perhaps. But if at some point all websites use 
HTTP-whatever-the-current-version-is then maybe browsers can remove support for 
HTTP/1.1 and then your embedded/SCADA/IoT devices won’t give us that rude shock.

I honestly don’t think that having two protocols for these two radically 
different use cases is a bad outcome.

Yoav

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Martin Thomson  writes:

>The advantage with deploying a new protocol is that you can be strict. If, 
>for example, all of the browsers implement TLS 1.3 and are strict, then 
>Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
>pretty quickly.  You might suggest that that's aspiration to the point of 
>delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
>didn't squash ALL of the nasty bugs, but we got most of them.

It also means you're going to be in for a rude shock when you encounter the
ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
else that uses HTTP as its universal substrate.  As a result there will be 
two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
version-is.

(Should I mention TLS-LTS here? :-).

Peter.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Martin Thomson]

You describe the observation that leads to Postel's maxim, namely that
if you found the internet in a mess when you got there, then you have
to be tolerant of rubbish.

The advantage with deploying a new protocol is that you can be strict.
If, for example, all of the browsers implement TLS 1.3 and are strict,
then Amazon won't be able to deploy a buggy 1.3 implementation without
noticing pretty quickly.  You might suggest that that's aspiration to
the point of delusion, but in fact it worked out pretty well with
HTTP/2 deployment.  We didn't squash ALL of the nasty bugs, but we got
most of them.


On 22 September 2016 at 01:53, Peter Gutmann  wrote:
> Andreas Walz  writes:
>
>>Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
>>addresses this in the Presentation Language section:
>>
>>  "Peers which receive a message which cannot be parsed according to the
>>  syntax (e.g., have a length extending beyond the message boundary or
>>  contain an out-of-range length) MUST terminate the connection with a
>>  "decoding_error" alert."
>
> And how many implementations are going to do this?  Consider the error-message
> litmus test I proposed earlier, reasons for failing to connect to (say)
> amazon.com:
>
>   Error: Couldn't connect to Amazon because its certificate isn't valid.
>
>   Error: Couldn't connect to Amazon because no suitable encryption was
>  available.
>
>   Error: Couldn't connect to Amazon because   decoding_error alert>.
>
> What would you put for the explanation for this case?  And if you say "decode
> error" the user's response will be to switch to some less buggy software that
> doesn't have problems connecting.
>
> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.
>
> Peter.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Ilari Liusvaara]

On Wed, Sep 21, 2016 at 03:53:33PM +, Peter Gutmann wrote:
> Andreas Walz  writes:
> 
>   Error: Couldn't connect to Amazon because   decoding_error alert>.
> 
> What would you put for the explanation for this case?  And if you say "decode
> error" the user's response will be to switch to some less buggy software that
> doesn't have problems connecting.

Well, valid response...
 
> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.

decode_error only happens if either end is buggy (the receiver parsing
can also be buggy), or if data is corrupted in transport.

It is meant for errors where length of something is wrong (and such
errors would likely be non-recoverable anyway)..



-Ilari

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Andreas Walz  writes:

>Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
>addresses this in the Presentation Language section:
>
>  "Peers which receive a message which cannot be parsed according to the
>  syntax (e.g., have a length extending beyond the message boundary or
>  contain an out-of-range length) MUST terminate the connection with a
>  "decoding_error" alert."

And how many implementations are going to do this?  Consider the error-message
litmus test I proposed earlier, reasons for failing to connect to (say)
amazon.com:

  Error: Couldn't connect to Amazon because its certificate isn't valid.
  
  Error: Couldn't connect to Amazon because no suitable encryption was
 available.

  Error: Couldn't connect to Amazon because .

What would you put for the explanation for this case?  And if you say "decode
error" the user's response will be to switch to some less buggy software that
doesn't have problems connecting.

If you're writing a strict validating protocol parser than disconnecting in
this case is a valid response, but if it's software that will be used by
actual humans then failing a connect based on something like this makes no
sense.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote:
> Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
> fact that the TLS 1.3 draft now  explicitly addresses this in the
> Presentation Language section:
> 
>  "Peers which receive a message which cannot be parsed according to the
> syntax (e.g., have a length extending beyond the message boundary or
> contain an out-of-range
> length) MUST terminate the connection with a "decoding_error" alert."

technically TLSv1.2 also is like this, it's just not explicit. All the 
messages and structures must match their definitions exactly, that means any 
kind of trailing data is an encoding error and as such should cause connection 
abort.

at least in theory if implementation does not reject such malformed fields or 
messages, it may be possible to trick it into talking with a different 
protocol that just happens to be parseable as TLS. Multiple checks on self-
consistency of messages make that unlikely.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Suspicious behaviour of TLS server implementations

[Andreas Walz]

Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the 
fact that
 the TLS 1.3 draft now  explicitly addresses this in the Presentation Language 
section:

 "Peers which receive a message which cannot be parsed according to the 
syntax
 (e.g., have a length extending beyond the message boundary or contain an
 out-of-range
length) MUST terminate the connection with a "decoding_error" alert."

Cheers,
Andi


>>> Martin Thomson  09/21/16 9:25 AM >>>
On 21 September 2016 at 17:21, Andreas Walz
 wrote:
> Do you see any argument why ignoring such trailing data would be acceptable
> (or even desirable)?

No.

Well, we exploited that to add extensions to the protocol once, so I
won't categorically rule it out, but in the case of
supported_groups/supported_curves, no good can come of ignoring
rubbish.  Of course, it's hard to point to this being harmful as well
:)


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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Martin Thomson]

On 21 September 2016 at 17:21, Andreas Walz
 wrote:
> Do you see any argument why ignoring such trailing data would be acceptable
> (or even desirable)?

No.

Well, we exploited that to add extensions to the protocol once, so I
won't categorically rule it out, but in the case of
supported_groups/supported_curves, no good can come of ignoring
rubbish.  Of course, it's hard to point to this being harmful as well
:)

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Andreas Walz]

Dear all,

sorry for bringing up this thread again. We were doing some further studies 
with TLS implementations (all TLS 1.2) for embedded systems and found more 
cases where, within substructures of handshake messages, trailing data without 
any associated field in the specification is *not* rejected. One example is the 
"Supported Elliptic Curves Extension" [RFC4492]:

struct {
NamedCurve elliptic_curve_list<1..2^16-1>;
} EllipticCurveList;

which is parsed as if there was an additional field "trailing" absorbing all 
remaining data:

struct {
NamedCurve elliptic_curve_list<1..2^16-1>;
opaque trailing[];
} EllipticCurveList;

(There are various other places where this happens.)

I must say I'm having hard times finding any rationale behind ignoring such 
data rather than rejecting it (and aborting the handshake). In fact, most 
implementations do reject such messages and send a "decode_error" alert.

Do you see any argument why ignoring such trailing data would be acceptable (or 
even desirable)?

Thanks again and Cheers,
Andi Walz


___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany



>>> "Andreas Walz"  09/14/16 4:20 PM >>>
Hi,

>>> Hubert Kario  09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer

@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the 
repository before and I skimmed through the code. However, I didn't run the 
code and I don't know details about the way it is generating input. Is there 
some paper or presentation about it? 

>>> Peter Gutmann  09/14/16 1:39 PM >>>
> My code checks for extensions all the way down, but I could quite easily be
> persuaded that ignoring trailing garbage is OK too, based on what earlier
> versions of TLS did.  Like RFC 3546 originally did for extensions, some future
> RFC might add a new field at the end, so not failing on finding more data may
> be a good thing.  Or at least I can't see why it would be a bad thing.

@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be 
missing something here, I do see some issues with adding new fields to the 
ClientHello in the future (i.e. following the "client_hello_extension_list"). 
As far as I can see, there is no way within a ClientHello to convey some kind 
of a version of the ClientHello format itself (as the ClientHello's version 
field is just indicating the highest version the client supports). That is, the 
only mechanism I see here is the same as the one that allowed to add extensions 
to a ClientHello message with RFC3546. However, that door has explicitly been 
closed therein in section 2.1 (as Hubert Kario pointed out)

A server that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello
format, and (as for all other messages) MUST check that the amount of
data in the message precisely matches one of these formats; if not
then it MUST send a fatal "decode_error" alert.  This overrides the
"Forward compatibility note" in [TLS].

A similar statement is given in RFC5246, section 7.4.1.2.:

A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all
other messages) it MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert.

Thus, to my understanding, any new field in the ClientHello would automatically 
break backward compatibility (at least with older compliant servers or unless 
everyone explicitly skips a MUST check in the interest of forward 
compatibility).

___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany





>>> Peter Gutmann  09/14/16 1:39 PM >>>
Martin Rex  writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally 

Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
> 
> >>> Hubert Kario  09/12/16 6:56 PM >>>
> > 
> > are you aware of the tlsfuzzer framework?
> > https://github.com/tomato42/tlsfuzzer
> 
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository before and I skimmed through the code. However, I didn't run the
> code and I don't know details about the way it is generating input. Is
> there some paper or presentation about it?

there are presentation slides in the docs/ directory

Decision which messages are to be generated is done using scenarios that 
describe conversations between client and server. See in scripts/ for them; a 
simple example is scripts/test-conversation.py while an example of negative 
test would be scripts/test-early-application-data.py

in tlsfuzzer/messages.py is the code that generates the messages, client hello 
is here:
https://github.com/tomato42/tlsfuzzer/blob/master/tlsfuzzer/messages.py#L306

Example of a test case you were asking about (the one with data extending past 
extensions) would be scripts/test-truncating-of-client-hello.py

The messages themselves are generated through a combination of sensible 
defaults and "guessing" expected values by inspecting already exchanged 
messages (think TLS state machine that explicitly has support for any state 
transitions).

In general, it allows you to both negotiate connections and send arbitrary 
messages (through changing their order, modifying them pre or post encryption, 
or sending raw values). In particular, it does support renegotiation despite 
the the fact that the underlying tls library doesn't.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Suspicious behaviour of TLS server implementations

[Andreas Walz]

Hi,

>>> Hubert Kario  09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer

@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the 
repository before and I skimmed through the code. However, I didn't run the 
code and I don't know details about the way it is generating input. Is there 
some paper or presentation about it? 

>>> Peter Gutmann  09/14/16 1:39 PM >>>
> My code checks for extensions all the way down, but I could quite easily be
> persuaded that ignoring trailing garbage is OK too, based on what earlier
> versions of TLS did.  Like RFC 3546 originally did for extensions, some future
> RFC might add a new field at the end, so not failing on finding more data may
> be a good thing.  Or at least I can't see why it would be a bad thing.

@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be 
missing something here, I do see some issues with adding new fields to the 
ClientHello in the future (i.e. following the "client_hello_extension_list"). 
As far as I can see, there is no way within a ClientHello to convey some kind 
of a version of the ClientHello format itself (as the ClientHello's version 
field is just indicating the highest version the client supports). That is, the 
only mechanism I see here is the same as the one that allowed to add extensions 
to a ClientHello message with RFC3546. However, that door has explicitly been 
closed therein in section 2.1 (as Hubert Kario pointed out)

A server that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello
format, and (as for all other messages) MUST check that the amount of
data in the message precisely matches one of these formats; if not
then it MUST send a fatal "decode_error" alert.  This overrides the
"Forward compatibility note" in [TLS].

A similar statement is given in RFC5246, section 7.4.1.2.:

A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all
other messages) it MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert.

Thus, to my understanding, any new field in the ClientHello would automatically 
break backward compatibility (at least with older compliant servers or unless 
everyone explicitly skips a MUST check in the interest of forward 
compatibility).

___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany





>>> Peter Gutmann  09/14/16 1:39 PM >>>
Martin Rex  writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined.  I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to 

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Martin Rex  writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined.  I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to track a potentially arbitrary number of extensions that you don't
know what to do with anyway doesn't seem worthwhile.  And then there's the
same problem as with ignoring extra data at the end of the hello, at some
point a future RFC may define an extension where having duplicate copies makes
sense or is even required for things to work.  So you don't really gain
anything by ignoring duplicate unknown extensions, and will potentially break
things in the future if you do reject them.

Having said that, some extensions are purely signalling extensions, like EMS
and EtM.  I'm not sure if there's any problem with accepting doubles of those,
it could just be the other side being emphatic.  Consider how you'd need to
report this to the user, "shut down the TLS connection because I saw two
copies of some extension you've never heard of before", you can imagine what a
user who sees that would think of the anal-retentive &^@#* who added special
code to the handshake in order to reject it if this condition is encountered.

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Martin Thomson]

I think that Martin (R) provided you with the answers I would have.

Have you filed bugs against the servers in question for the issues
that you have seen?

On 10 September 2016 at 00:23, Andreas Walz
 wrote:
> Dear all,
>
> we are working on an approach/framework for testing TLS implementations
> (currently only servers, but clients are planned for the future as well).
> While running our tests against a bunch of different TLS (server)
> implementations, we found several types of suspicious behaviour (see below).
> As the TLS specification left me with doubts on what the correct behaviour
> should be, I'd like to raise this questions here (please let me know if this
> is not the appropriate place or this has been answered before).
>
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression even
> if that has not been in the ClientHello's list. The specification is rather
> clear that null compression MUST be part of the list. However, I'm not aware
> of any clear statement about what a compliant server should do in case it
> receives a ClientHello without null compression. My best guess would have
> been that in such cases the server should abort the handshake (at least if
> it does not support whatever the client proposed).
>
> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything following
> the list of compression methods as extensions. Aside from this certainly
> being a deviation from the specification, I was wondering whether a server
> should silently ignore data following the extension list (e.g. for the sake
> of upward compatibility) or (as one could infer from RFC5246, p. 42) send
> e.g. a "decode_error" alert.
>
> (3) If a ClientHello contains multiple extensions of the same type, several
> server implementations proceed with the handshake (even if they parse these
> specific extensions). The specification again is clear that "there MUST NOT
> be more than one extension of the same type". However, what should a server
> do in case there are? Again, my guess would be that it should abort the
> handshake. Should this also be the case for extensions that a server simply
> ignores (as it e.g. doesn't know them)?
>
> Thank you very much.
>
> Cheers,
> Andi
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Martin Rex]

My personal take on your questions:


Andreas Walz wrote:
> 
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.

Sounds like reasonable behaviour (improving interop) which does not cause
any security issues.

>
> The specification is rather clear that null compression MUST be part of
> the list.  However, I'm not aware of any clear statement about what a
> compliant server should do in case it receives a ClientHello without
> null compression. My best guess would have been that in such cases the
> server should abort the handshake (at least if it does not support
> whatever the client proposed).

The requirement is about the Client.  The Server behaviour is un(der)specifed.
The server choosing null compression anyway and continuing looks pretty
reasonable to me (least amount of code, so the safest to implement).

Aborting by the server would be OK with the specification, but not
necessarily reasonable.  Consider that there was a time when compression
within TLS was available and widely used.  A server that wanted and would
use TLS compression when offered would behave sort-of unrational when
complaining about an absence of a compression method it does not intend
to use (in presence of the compression method it wants to use).

The actual problem is the design flaw in TLS that availability of 
null compression is not implied, but rather given a seperate codepoint,
and the server choosing null compression and continuing even when it
is not explicitly asserted by the client, is a server silently making up
for that design flaw in the TLS spec.


> 
> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything
> following the list of compression methods as extensions.  Aside from this
> certainly being a deviation from the specification, I was wondering
> whether a server should silently ignore data following the extension
> list (e.g. for the sake of upward compatibility) or (as one could infer
> from RFC5246, p. 42) send e.g. a "decode_error" alert.

Up to TLSv1.2, TLS extensions were purely optional, so an implementation
that unconditionally ignores everything following compression methods is
at least fully conforming to SSLv3, TLSv1.0 and TLSv1.1.

For an TLS implementation that parses TLS extensions, the behaviour of
what to do about trailing garbage is a different matter.  Personally
I prefer aborting in case of garbage trailing TLS extensions.

When I looked at OpenSSL's implemenation of the extensions parser a few
years ago, I noticed that it was ignoring (I believe up to 3) trailing bytes.
(the shortest possible TLS extension is 4 bytes).


>
> (3) If a ClientHello contains multiple extensions of the same type,
> several server implementations proceed with the handshake (even if they
> parse these specific extensions). The specification again is clear that
> "there MUST NOT be more than one extension of the same type".
> However, what should a server do in case there are? Again, my guess
> would be that it should abort the handshake. Should this also be the
> case for extensions that a server simply ignores (as it e.g. doesn't
> know them)?

What the server does in presence of multiple TLS extensions of the same type
is implementation defined.  I think it would be extremely reasonable for a
server to perform a simple plausibility check on decode whether it is decoding
the same TLS extension more than once, and then abort with a decode_error
alert, in order to have ambiguities caught early.
Recognizing duplicate TLS extensions that the server does not
support/implement does not (yet) create ambiguities (for that server)
and requires more complex code, so I would not implement that check.


-Martin

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