These flags are relative to the messages and not the session so I don't
think there is concurrent issue.
Jeff
On Tue, May 7, 2013 at 9:02 AM, Julien Vermillard wrote:
> BTW those flags for negotiation state are locked ? since we can write
> from another thread, it should no ?
>
> On Mon, May 6
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 wrote:
> Agree with that. So we probably need a flag to tell do not encrypt that
> will also be used for handshake messages.
>
> Regards
> Jeff
>
>
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 wrote:
> Jean-François,
>
> one interesting piece of information from the RFC :
>
> 7.1 :
> ...
>
> "Note: If a rehand
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 MU
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 specificat
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
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 rehandshake
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 ide
On extending java.nio.ByteBuffer : it's not doable because the constructor
is private :(
On Fri, May 3, 2013 at 3:40 PM, Jeff MAURY wrote:
> +1
>
> I think we shall rewrite the code and let be driven by the underlying
> SSLengine status.
> Now, if after processing there are still remaining data
Le 5/3/13 4:45 PM, Jeff MAURY a écrit :
> On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny wrote:
>
>> Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
>>> +1
>>>
>>> I think we shall rewrite the code and let be driven by the underlying
>>> SSLengine status.
>> Absolutely. I have created a branch to play a
On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny wrote:
> Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
> > +1
> >
> > I think we shall rewrite the code and let be driven by the underlying
> > SSLengine status.
> Absolutely. I have created a branch to play a bit with SSL.
> > Now, if after processing t
Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
> +1
>
> I think we shall rewrite the code and let be driven by the underlying
> SSLengine status.
Absolutely. I have created a branch to play a bit with SSL.
> Now, if after processing there are still remaining data in the input
> buffer, we must keep it unt
+1
I think we shall rewrite the code and let be driven by the underlying
SSLengine status.
Now, if after processing there are still remaining data in the input
buffer, we must keep it until the next buffer is received.
In order to preserve performances, as we need to assemble the input buffer
with
Hi guys,
the way we handle incomming SSL data on the server will not work if the
data are fragmented.
Let's say we are receiving some Handshake data. This is typically a few
hundreds of bytes, that usually comes in one block. In this case, we are
all good. But if those data aren't read in one blo
Hi,
when we process some incoming data over a secured connection, at some
point, we must decrypt the data.
We receive an encrypted buffer, then we call the unwrap method, and we
obtain a decrypted buffer :
[$*#@X] --unwrap--> [ABCDE]
The key here is that we will have to deal with data fragm
Hi guys,
so after some readings, and some thoughts, I'm coming with a proposal
for the SSL/TLS handling in MINA 3.
First of all, as we decided to get rid of the SSL filter, everything
must be handled directly on the SelectorProcessor. That means we must
have a way to tell the processor worke
On 11/24/11 4:35 PM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharny wrote:
On 11/24/11 4:16 PM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny
wrote:
On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Em
On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharny wrote:
> On 11/24/11 4:16 PM, Julien Vermillard wrote:
>>
>> On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny
>> wrote:
>>>
>>> On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny
wr
On 11/24/11 4:16 PM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny wrote:
On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny
wrote:
Hi guys,
yesterday, I fought with the way MINA 2 is dealing with SSL. Down the
li
On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny wrote:
> On 11/24/11 10:40 AM, Julien Vermillard wrote:
>>
>> On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny
>> wrote:
>>>
>>> Hi guys,
>>>
>>> yesterday, I fought with the way MINA 2 is dealing with SSL. Down the
>>> line,
>>> we use a filte
On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny wrote:
Hi guys,
yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line,
we use a filter for that, which handles the handhsake using the SslEngine
class.
The problem is that at
On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny wrote:
Hi guys,
yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line,
we use a filter for that, which handles the handhsake using the SslEngine
class.
The problem is that at
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny wrote:
> Hi guys,
>
> yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line,
> we use a filter for that, which handles the handhsake using the SslEngine
> class.
>
> The problem is that at the same time, the session is conside
Hi guys,
yesterday, I fought with the way MINA 2 is dealing with SSL. Down the
line, we use a filter for that, which handles the handhsake using the
SslEngine class.
The problem is that at the same time, the session is considered as
opened, even if we haven't done any handshake, as we can't
24 matches
Mail list logo
