On Tue, Jul 26, 2016 at 12:08:33PM +, 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
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 t
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
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
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 r
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
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 resu
On Tue, Jul 26, 2016 at 11:52:25AM +0200, Martin Rex wrote:
>
> 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
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
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
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
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 o
On Mon, Jul 25, 2016 at 04:36:27PM -0400, 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 suit
> 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_fail
> On Jul 25, 2016, at 3:08 PM, Martin Rex wrote:
>
> https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg
FWIW, OpenSSL interoperates with this server:
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4169 bytes and written 310
On Mon, Jul 25, 2016 at 09:08:49PM +0200, 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
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
17 matches
Mail list logo
