Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance

[Brian Smith]

Hubert Kario  wrote:
> 170 were detected as TLS 1.3 incompatible (3.9%)
> 183 were detected as TLS 1.4 incompatible (4.2%)
> 229 were detected as TLS 1.253 incompatible (5.22%)
>
> in the below excerpt (full list below, this is just entries that have at least
> 4 servers with same behaviour), "e/" means that it's the smallest size
> of "Very Compatible" client hello extended through the padding extension that
> causes its rejection by server, similarly "c/" indicates smallest size
> rejected by server when the client hello is made big through addition of
> cipher suite IDs

> Cumulative distribution function for size intolerancies looks like this:
>
> size  size  size  size  size  size >=c/81924064  92.5529

This seems like a good indication that clients should limit the number
of cipher suites in the client hello.

>
> size  size  size  TLS 1.3  170   3.8742
> TLS 1.4  183   4.1705

> size e/1356  100.2279
> size e/1356 c/1356   5 0.1139
> size e/1356 c/1357   5 0.1139
> size e/2046  1 0.0228
> size e/2046 c/1979   1 0.0228
> size e/2049  4 0.0912
> size e/2049 c/1153   1 0.0228
> size e/2049 c/2049   2 0.0456
> size e/2049 c/2050   1 0.0228
> size e/2053  1 0.0228
> size e/2053 c/5551 0.0228

When we consider the most reasonable (initial) ClientHello sizes, it
seems that the ClientHello version number intolerance is a much more
significant problem than size intolerance, if I'm understanding your
numbers correctly.

Cheers,
Brian
-- 
https://briansmith.org/

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

[TLS] [Editorial Errata Reported] RFC5246 (4750)

[RFC Errata System]

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246=4750

--
Type: Editorial
Reported by: Adrien de Croy 

Section: 4.3 Vectors

Original Text
-
The length of
   an encoded vector must be an even multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Corrected Text
--
The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes
-
Original text implies vectors can only contain even (0,2,4,6,8...) numbers of 
elements.  The example does not resolve this but indicates the intent is that 
parts of elements are not allowed. It is clear from other examples that odd 
numbers of elements are permitted.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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

Re: [TLS] Keeping TLS extension points working

[Sean Turner]

David,

Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to make 
via the IANA considerations section.  They enforce the registry policy 
established when we (the IETF/TLS WG) originally established the registry; the 
available policies are found in RFC 5226 (and there’s some more rules in RFC 
7120).  So, I’m hoping that you could tweak your draft somewhat to be 
instructional and then suggest some values (this purely procedural dance has 
worked in the past and it’s what we’re doing for draft-ietf-tls-ecdhe-psk-aead):

0) In s2, replace the two lists with something like:

The draft reservers the following X cipher suite values: Values TBD

The following X values are reserved as both GREASE extension values and GREASE 
named group values: Values TBD

1) In 5, add a {TBD} sub-column to the 1st column for each value in the tables 
(apologies for the formatting):

+-+-+-+-+
|Value   | Description | DTLS-OK |Reference|
+-+-+-+-+
| {TBD} {0x0A,0x0A} |   Reserved  |Y| (this document) |

And then add something like this to the end of the section:

  The cipher suite numbers listed in the second column in the
  values column are numbers used for cipher suite interoperability
  testing and it's suggested that IANA use these values for assignment.


I’m sure somebody will eventually comment on the following header fields:

0) “Status: Informational” because some of the registries right now require 
standards track RFCs to do the assignments.  But, everybody should momentarily 
suspend reality because we’re going to change the registry rules for the 
registries you are adding values you to be something that would allow an draft 
intended for “informational” to do the updates, i.e., just leave it alone for 
now.

1) “Updates: 5246 (if approved)” because typically extension documents don’t 
“update” the base specification.  If you are suggesting that all 
implementations must support these values then an updates header makes sense.  
Note I’m sure somewhere along the way an extension that isn’t expected to be 
supported by all implementation has an updates header but what I described is 
how we’re doing it now.

Cheers,

spt

PS: As chair, I try to deal with/deflect as many of these procedural issues as 
possible, but if you want to know more please let me know off-list.  This 
actually goes for anybody on the list.

> On Jul 25, 2016, at 18:32, David Benjamin  wrote:
> 
> Hi folks,
> 
> I'm not sure how this process usually works, but I would like to reserve a 
> bunch of values in the TLS registries to as part of an idea to keep our 
> extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft-davidben-tls-grease-00
> 
> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy 
> from https://www.imperialviolet.org/2016/05/16/agility.html )
> 
> One problem we repeatedly run into is servers failing to implement TLS's 
> various extension points correctly. The most obvious being version 
> intolerance. When we deployed X25519 in Chrome, we discovered an intolerant 
> implementation. (Thankfully it was rare enough to not warrant a fallback or 
> revert!) It appears that signature algorithms maybe also be gathering rust. 
> Ciphers and extensions seem to have held up, but I would like to ensure they 
> stay that way.
> 
> The root problem here is these broken servers interoperate fine with clients 
> at the time they are deployed. It is only after new values get defined do we 
> notice, by which time it is too late.
> 
> I would like to fix this by reserving a few values in our registries so that 
> clients may advertise random ones and regularly exercise these codepaths in 
> servers. If enough of the client base does this, we can turn a large class of 
> tomorrow's interop failures into today's interop failures. This is important 
> because an bug will not thrive in the ecosystem if it does not work against 
> the current deployment.
> 
> If you were in Berlin, you may recognize this idea from the version 
> negotiation debate. Alas that all happened in the wrong order as I hadn't 
> written this up yet. This idea can't be applied to versioning without giving 
> up on ClientHello.version, but we can start with the rest of the protocol.
> 
> David
> 
> PS: This is actually my first I-D, so apologies if I've messed it up 
> somewhere!
> ___
> 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] weird ECDSA interop problem with cloudflare/nginx

[Hubert Kario]

On Tuesday, 26 July 2016 12:08:33 CEST Viktor Dukhovni wrote:
> On Tue, Jul 26, 2016 at 01:09:04PM +0300, Ilari Liusvaara wrote:
> > > Failure:
> > > openssl s_client -connect regmedia.co.uk:443 -cipher
> > > ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305> 
> > If you swap the order of these two ciphersuites, does it suceed or fail?
> > 
> > I.e.
> > 
> > openssl s_client -connect regmedia.co.uk:443 -cipher
> > ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
> I can reproduce the reported failure in the original order, and at
> least for me the swapped variant succeeds.
> 
> > Well, your test results certainly blow basic "negotiation accidentially
> > blows off all valid candidates and then fails" hypothesis out of the
> > water. So it has to be soemthing more complicated.
> > 
> > Succeeding with the ciphersuites swapped would suggest (as somebody
> > else in this thread already said) that it only considers Chacha in
> > the first place, not noticing that it may be the only choice after
> > certificate selection.
> 
> Perhaps that's the issue.

if you send the AES-GCM then Chacha but do NOT include signature algorithms, 
it allows you to connect (other extensions are irrelevant).

If you send AES-GCM then Chacha in ciphers but in signatures algorithms don't 
include the SHA256/ecdsa pair, it works too.

in other words, this connects:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA512:RSA+SHA256

and this connects:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA512:RSA+SHA512

but this doesn't:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA256:RSA+SHA256

(using openssl-1.1.0-pre5)
-- 
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] weird ECDSA interop problem with cloudflare/nginx

[Viktor Dukhovni]

On Tue, Jul 26, 2016 at 01:09:04PM +0300, Ilari Liusvaara wrote:

> > Failure:
> > openssl s_client -connect regmedia.co.uk:443 -cipher 
> > ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
> 
> If you swap the order of these two ciphersuites, does it suceed or fail?
> 
> I.e.
> 
> openssl s_client -connect regmedia.co.uk:443 -cipher 
> ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

I can reproduce the reported failure in the original order, and at
least for me the swapped variant succeeds.

> Well, your test results certainly blow basic "negotiation accidentially
> blows off all valid candidates and then fails" hypothesis out of the
> water. So it has to be soemthing more complicated.
> 
> Succeeding with the ciphersuites swapped would suggest (as somebody
> else in this thread already said) that it only considers Chacha in
> the first place, not noticing that it may be the only choice after
> certificate selection.

Perhaps that's the issue.

-- 
Viktor.

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

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

[Hubert Kario]

On Monday, 25 July 2016 21:08:49 CEST Martin Rex wrote:
> I've just run into a weird interoperability problem with an (alleged)
> cloudflare/nginx TLS server and my personal Firefox settings.
> 
> https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg
> 
> 
> Traditionally I have all TLS ciphersuites with ECDSA disabled through
> about:config, but it seems that recently two new TLS ciphersuites were
> added to FF, which caused complete loss of interop with regmedia.co.uk
> for me with my existing configuration. (Loss of pictures on the
> www.theregister.co.uk news site).
> 
> specifically, after the FF update, this new TLS ciphersuite:
> 
>security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)
> 
> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
> 
> It looks like a bug in the cloudflare/nginx cipher suites selection
> algorithm, which appears to blindly go for ECDSA, even though there is
> no actual ECDSA cipher suite available which the server supports.

could you post packet capture (pcap format, if possible) that shows that 
problem?

-- 
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] weird ECDSA interop problem with cloudflare/nginx

[Peter Gutmann]

Since I've referred to TLS-LTS a couple of times now I should mention that
I've just posted an update, with the following changes:

- Clarified what happens during a session resumption.

- Fixed the ServerKeyExchange text to indicate what happens when the hash
  isn't the default SHA-256.  Is the resulting text comprehensible?  That is,
  does it make clear what's signed, and with what hash?

- Added an alternative, quicker way to verify domain parameters that doesn't
  require the full FIPS 186 checks.

- Reworked the text about the handling of extensions yet again.  I'm still not
  happy with this, or certain that it's sufficiently unambiguous, can people
  see if they can pick holes in it?

- Reworked the rationale.

Peter.

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

Re: [TLS] Keeping TLS extension points working

[Hubert Kario]

On Monday, 25 July 2016 23:32:41 CEST David Benjamin wrote:
> On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni 
> 
> wrote:
> > On Mon, Jul 25, 2016 at 10:32:29PM +, David Benjamin wrote:
> > > I'm not sure how this process usually works, but I would like to reserve
> > 
> > a
> > 
> > > bunch of values in the TLS registries to as part of an idea to keep our
> > > extension points working. Here's an I-D:
> > > 
> > > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> > 
> > To really make this work, it would be necessary to expand the
> > reserved pool gradually, rather than all at once, so that servers
> > can't hard-code just the initially reserved pool, and still fail
> > with new "real" extensions later.
> 
> My hope is that, especially with the values allocated sparsely, after
> getting interop failure once or twice from unknown values, the servers will
> quickly figure it out. I'm assuming the implementations simply made
> mistakes or weren't paying enough attention to the specification rather
> than being actively malicious.
> 
> But, you are right, one failure mode here is implementations may
> "accidentally" hard-code the reserved pool... somehow.

Then we have "pet-projects" of which the primary/only developer walks away/
changes jobs well after it was tightly integrated with already deployed 
systems, code that is passed over to interns as nobody either has time, 
inclination or knows much about  anyway[1]...

Thus I don't think it solves the problem even for non malicious programmers

While the idea of code points that MUST NOT be negotiated by servers is not 
bad one from testing perspective, we already have few values like this 
(0x00,0x14 for cipher, 15 for supported groups, just of the top of my head). 
And for a test suite any value not defined by IANA already has this function 
(and you do need to test all those values to search for undocumented features, 
backdoors, etc. anyway).

 1 - talking purely hypothetically here, even if I wanted, I wouldn't know 
where to point fingers in realm of TLS implementations
-- 
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] weird ECDSA interop problem with cloudflare/nginx

[Peter Gutmann]

Ilari Liusvaara  writes:

>The basic problem (let's ignore non-cert modes for a bit):
>
>When choosing the certificate, you need to consider if you have a ciphersuite
>that can use some supported group and protection/prf-hash available.
>
>Similarly, when choosing a group, you need to consider that you have a
>ciphersuite that is consistent in other (possible) choices.
>
>And protection/prf-hash also has to be consistent with other choices.
>
>The reason these choices couple is because the client can send pretty much
>arbitrary combination of oters that depends on each considered factor.

OK, so that's pretty much the same stuff I ran into.  What makes it really
ugly is that you can no longer decide, based on a cipher suite offered,
whether you can actually continue with that, but then have to tunnel down into
the extensions that follow the suites to see what's there.  If there's nothing
appropriate you go back to the cipher suites and find the next-best match, try
that against the extensions, and so on.  Mostly things appear to work now
because virtually everything supports the de facto standard of P256 + SHA-256
with ECDSA and ECDH (which is why TLS-LTS specifies it as one of its two suite
choices), but once you start veering away from that de facto universal
standard you run into problems.  Rather than spend forever trying various
poke-and-hope strategies, my code looks for the default form (P/SHA-256) and
if that's not found falls back to DHE + RSA.  That seems to work well enough,
and I don't have to debug weird failures with oddball combinations.

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

Re: [TLS] Keeping TLS extension points working

[David Benjamin]

On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario  wrote:

> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> > I would like to fix this by reserving a few values in our registries so
> > that clients may advertise random ones and regularly exercise these
> > codepaths in servers. If enough of the client base does this, we can
> turn a
> > large class of tomorrow's interop failures into today's interop failures.
> > This is important because an bug will not thrive in the ecosystem if it
> > does not work against the current deployment.
>
> What prevents an implementation from ignoring values from just those
> reserved
> ranges and continuing to be intolerant to other values? After all, if they
> are
> reserved for this, they just need to ignore those values (as no "real"
> extension/value will ever use them) to "resolve the problem".
>

Nothing. Just as nothing prevents an implementation from taking every
ClientHello current browsers send (variable parts like client_random
normalized), hard-coding their SHA-256 hashes, and rejecting anything that
doesn't match.

The point is to catch honest mistakes, not to avoid servers that are
maliciously trying to mess up the ecosystem.

We can certainly increase the pool over time as Viktor suggested if
special-casing these becomes a problem. I don't expect it to be, but we'll
see. Whereas not ignoring unknown values has empirically been a problem.

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

Re: [TLS] Keeping TLS extension points working

[Hubert Kario]

On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn a
> large class of tomorrow's interop failures into today's interop failures.
> This is important because an bug will not thrive in the ecosystem if it
> does not work against the current deployment.

What prevents an implementation from ignoring values from just those reserved 
ranges and continuing to be intolerant to other values? After all, if they are 
reserved for this, they just need to ignore those values (as no "real" 
extension/value will ever use them) to "resolve the problem".

-- 
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] weird ECDSA interop problem with cloudflare/nginx

[Ilari Liusvaara]

On Tue, Jul 26, 2016 at 07:48:05AM +, Peter Gutmann wrote:
> Ilari Liusvaara  writes:
> 
> >I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way
> >that always negotiates something if at least one valid configuration exists,
> >and respects TLS 1.2 rules.
> >
> >The resulting code was totally insane, and I am very much not surprised to
> >see buggy implementations. Nor can I say my implementation is not buggy, as
> >testing that mess is just about impossible (and it it will very much do GIGO
> >in order to maximize interop).
> 
> Do you have any more details on some of the issues you ran into?  It'd be good
> to know for anyone else in this situation.
> 
> (I've had to do the same thing, with awkward logic that backs off and retries
> different options if an earlier attempt fails.  This was one of the motivators
> for the Grigg's Law cipher-suite handling in TLS-LTS).

The basic problem (let's ignore non-cert modes for a bit):

When choosing the certificate, you need to consider if you have a
ciphersuite that can use some supported group and protection/prf-hash
available.

Similarly, when choosing a group, you need to consider that you have
a ciphersuite that is consistent in other (possible) choices.

And protection/prf-hash also has to be consistent with other
choices.


The reason these choices couple is because the client can send
pretty much arbitrary combination of oters that depends on each
considered factor.

And the selections have to be consistent: The current leading
hypothesis about this interop issue is that certificate selection
consisers ciphersuite valid candidate when protection selection does
not.


TLS 1.3 negotiation revamp would solve this by ensuring that
whichever you choose first, you don't restrict choice on others
(PSK modes are special here, so need to be chosen first[1]), so
whatever you have chosen so far, there either is next valid
choice, or the whole problem has no solution.


[1] There are some couplings here too, but one only needs to check
group overlap for ke and signature/cert overlap for auth (and these
overlap decisions can be used for normal dhe/cert anyway). And one
does not need to consider interaction of those two.



-Ilari

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

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

[Martin Rex]

Viktor Dukhovni wrote:
> 
>> On Jul 25, 2016, at 3:08 PM, Martin Rex  wrote:
>> 
>> specifically, after the FF update, this new TLS ciphersuite:
>> 
>>   security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)
>> 
>> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
>> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
> 
> OpenSSL lists "CC, A9" as:
> 
> 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA 
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> 
> Which is not AES_128_GCM.  The IANA registry seems to agree:
> 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> 
>   0xCC,0xA9   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256   Y   
> [RFC7905]


Sorry for the confusion about the cipher suite.

The issue seems a little weirder than what I thought, because the
failure seems to happen only for a particular cipher suite combo
(which happens to be the combo produced by my own Firefox config):

I can repro the handshake failure with openssl-1.1.0-pre5 with this
command line:

Failure:
openssl s_client -connect regmedia.co.uk:443 -cipher 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305

Success:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256

Success:
openssl s_client -connect regmedia.co.uk:443 -cipher 
ECDHE-ECDSA-CHACHA20-POLY1305



-Martin

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

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

[Peter Gutmann]

Ilari Liusvaara  writes:

>I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way
>that always negotiates something if at least one valid configuration exists,
>and respects TLS 1.2 rules.
>
>The resulting code was totally insane, and I am very much not surprised to
>see buggy implementations. Nor can I say my implementation is not buggy, as
>testing that mess is just about impossible (and it it will very much do GIGO
>in order to maximize interop).

Do you have any more details on some of the issues you ran into?  It'd be good
to know for anyone else in this situation.

(I've had to do the same thing, with awkward logic that backs off and retries
different options if an earlier attempt fails.  This was one of the motivators
for the Grigg's Law cipher-suite handling in TLS-LTS).

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

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

[Martin Rex]

Correction--

I'm sorry, I mistyped the firefox config, this should have said
the chacha20_poly1305 (0xcc 0xa9) cipher suite was the only one enabled.


 
Martin Rex wrote:
> I've just run into a weird interoperability problem with an (alleged)
> cloudflare/nginx TLS server and my personal Firefox settings.
> 
> https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg
> 
> 
> Traditionally I have all TLS ciphersuites with ECDSA disabled through
> about:config, but it seems that recently two new TLS ciphersuites were
> added to FF, which caused complete loss of interop with regmedia.co.uk
> for me with my existing configuration. (Loss of pictures on the
> www.theregister.co.uk news site).
> 
> specifically, after the FF update, this new TLS ciphersuite:
> 
>security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)

security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256  (0xcc, 0xa9)
 
> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
> 
> It looks like a bug in the cloudflare/nginx cipher suites selection
> algorithm, which appears to blindly go for ECDSA, even though there is
> no actual ECDSA cipher suite available which the server supports.
> 
> 
> -Martin

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