Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

A simpler interpretation would be that application data should never be sent or received with sequence number = 0; only finished messages may have this sequence number. For connections with NPN enabled, we may need a slightly more complex rule. In TLS we can also assume that encrypted fragments

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

A simpler interpretation would be that application data should never be sent or received with sequence number = 0; only finished messages may have this sequence number. For connections with NPN enabled, we may need a slightly more complex rule. In TLS we can also assume that encrypted fragments

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

During renegotiation, app data should not appear between CCS and finished, but some implementations (e.g. NSS) do allow this. I would consider it a state machine bug, although finding a serious exploit is not so easy. > On 25 Sep 2015, at 12:40, Matt Caswell wrote: > > > >

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s-hit, SSL3_FLAGS_OK, s-s3-change_cipher_spec). Let’s carefully test any change here, so we do not re-enable

Re: OpenSSL client DH group limits

We noticed the same thing and would also recommend that the openssl client reject small DH groups. This would complement the strong validity checks that openssl already by e.g. checking primality and rejecting invalid public keys. On the precise number of minimum bits, please note that IIS