Re: Re: BC occasionally fails to establish a TLS connection

Hi Daniel,
Yes I think you may be onto something. If a client offers a session and
the server does not resume it, the client will invalidate it, which
destroys the master secret; it creates a race condition with other
clients that have offered the same session and may yet try to resume it.

We will fix this for the next release.

Regards,
Pete Dettman

On 8/11/19 1:09 am, Daniel Jeliński wrote:
> I dug a bit deeper in the wireshark logs and noticed something
> interesting, and probably related.
> We are establishing 2 connections at roughly the same time, and the
> problem sequence is as follows:
> TCP 1. > ClientHello, sessionID cab8..
> TCP 2. > ClientHello, sessionID cab8...
> TCP 1. < ServerHello, sessionID 8766... (NEW)
> TCP 2. < ServerHello, sessionID cab8.. (reused)
> TCP 1. > Client key exchange
> TCP 2. > TLS alert.
> 
> At this point I'm thinking that maybe BC destroys the old sessionID
> right after it gets a new sessionID from the server, and when it later
> gets the old sessionID from the server, it sends the alert. Does that
> sound right?
> Thanks,
> Daniel