If I remember/understand correctly, the cloudflare patch for chacha/poly would (when server preference is in use) only attempt to use it when it appeared first in the client's preference list, and would ignore it elsewhere. This could potentially lead to negotiation failures if, e.g., the server only supported chacha/poly but the client did not put it first in the list. That doesn't seem to match up with what is being described here, but could provide some insight into where to look.
-Ben On 07/25/2016 04:00 PM, Ilari Liusvaara wrote: > On Mon, Jul 25, 2016 at 04:36:27PM -0400, Viktor Dukhovni wrote: >>> On Jul 25, 2016, at 3:08 PM, Martin Rex <m...@sap.com> 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 > I wonder what is happening is that having ECDSA ciphersuite enabled > causes Firefox to include the ECDSA signatures in signature_algorithms > and the server end sees ECDSA supported, tries to choose that, but > then blows up when it does not find any enabled ciphersuites it knows > that support ECDSA... > > > > -Ilari > > _______________________________________________ > 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
