BTW those flags for negotiation state are locked ? since we can write
from another thread, it should no ?
On Mon, May 6, 2013 at 10:26 PM, Jeff MAURY jeffma...@jeffmaury.com wrote:
Agree with that. So we probably need a flag to tell do not encrypt that
will also be used for handshake messages.
Emmanuel,
that's a good resume of what we discussed yesterday but I'd like to add the
following:
1) Events
The sessionOpened event is generated when the socket is created, should we
defer it until the handshake is completed ? And as we now support
rehandshaking, what do we do when the
Le 5/6/13 10:05 AM, Jeff MAURY a écrit :
Emmanuel,
that's a good resume of what we discussed yesterday but I'd like to add the
following:
1) Events
The sessionOpened event is generated when the socket is created, should we
defer it until the handshake is completed ?
I don't think so.
Jean-François,
in the SslHelper class, processRead method, line 241, you check the
numbe rof produced bytes, and you call the processMessageReceived()
method if it's not zero.
I think we should call the processMessageReceived() even if ther eis
zero bytes produced, accordingly to the
Jean-François,
one interesting piece of information from the RFC :
7.1 :
...
Note: If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the old
CipherSpec. However, once the ChangeCipherSpec has been sent, the new
CipherSpec
Agree with that. So we probably need a flag to tell do not encrypt that
will also be used for handshake messages.
Regards
Jeff
On Mon, May 6, 2013 at 5:31 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Jean-François,
one interesting piece of information from the RFC :
7.1 :
...
Note:
Hi guys,
we have had a pleasant and useful working session this afternoon with
Jean-François (as we both live in Paris, it was easy for us to meet and
discuss)
Here are a few things we tried to figure out and some of the elements
that need to be further analysed
1) General state machine
The