Hello,
I have spent some times reviewing the SSL code in order to add support
client handshake start.
I have seen several problems that I'd like to share:
- messages sent are encrypted when they are submitted: I see two
problems with that: if a message is submitted before the handshake is
Le 03/07/2014 00:42, Jeff MAURY a écrit :
> Hello,
>
> I have spent some times reviewing the SSL code in order to add support
> client handshake start.
> I have seen several problems that I'd like to share:
>
>- messages sent are encrypted when they are submitted: I see two
>problems with t
On Thu, Jul 3, 2014 at 1:19 AM, Emmanuel Lécharny
wrote:
> Le 03/07/2014 00:42, Jeff MAURY a écrit :
> > Hello,
> >
> > I have spent some times reviewing the SSL code in order to add support
> > client handshake start.
> > I have seen several problems that I'd like to share:
> >
> >- messages
Le 03/07/2014 07:56, Jeff MAURY a écrit :
> On Thu, Jul 3, 2014 at 1:19 AM, Emmanuel Lécharny
> wrote:
>
>> Le 03/07/2014 00:42, Jeff MAURY a écrit :
>>> Hello,
>>>
>>> I have spent some times reviewing the SSL code in order to add support
>>> client handshake start.
>>> I have seen several proble
Hello,
back to work, I have the following thoughts:
- encrypting just before we write to the socket may lead to other
problems: if the resulting message is greater than the send buffer, then we
would need to wait for the rest of the buffer. If between, we receive an
handshake, we may
Le 17/07/2014 17:15, Jeff MAURY a écrit :
> Hello,
>
> back to work, I have the following thoughts:
>
>- encrypting just before we write to the socket may lead to other
>problems: if the resulting message is greater than the send buffer, then we
>would need to wait for the rest of the b
On Thu, Jul 17, 2014 at 5:53 PM, Emmanuel Lécharny
wrote:
> Le 17/07/2014 17:15, Jeff MAURY a écrit :
> > Hello,
> >
> > back to work, I have the following thoughts:
> >
> >- encrypting just before we write to the socket may lead to other
> >problems: if the resulting message is greater t
Le 17/07/2014 18:01, Jeff MAURY a écrit :
> On Thu, Jul 17, 2014 at 5:53 PM, Emmanuel Lécharny
> wrote:
>
>> Le 17/07/2014 17:15, Jeff MAURY a écrit :
>>> Hello,
>>>
>>> back to work, I have the following thoughts:
>>>
>>>- encrypting just before we write to the socket may lead to other
>>>
Hi,
just wanted to add my 2 eurocent, don't know if it really makes sense
in the discussed context.
In Vysper, a state machine is maintained which tracks the connection
status between connected, started, authenticated, encrypted, etc.
Depending on the connection state, Vysper will reject messages
Le 17/07/2014 23:34, Bernd Fondermann a écrit :
> Hi,
>
> just wanted to add my 2 eurocent, don't know if it really makes sense
> in the discussed context.
>
> In Vysper, a state machine is maintained which tracks the connection
> status between connected, started, authenticated, encrypted, etc.
>
On 18.07.14 00:35, Emmanuel Lécharny wrote:
Le 17/07/2014 23:34, Bernd Fondermann a écrit :
Hi,
just wanted to add my 2 eurocent, don't know if it really makes sense
in the discussed context.
In Vysper, a state machine is maintained which tracks the connection
status between connected, started
Le 18/07/2014 11:23, Bernd Fondermann a écrit :
> On 18.07.14 00:35, Emmanuel Lécharny wrote:
>> Le 17/07/2014 23:34, Bernd Fondermann a écrit :
>>> Hi,
>>>
>>> just wanted to add my 2 eurocent, don't know if it really makes sense
>>> in the discussed context.
>>>
>>> In Vysper, a state machine is
Some mor ethoughts, after I spent a couple of hours in Rescorla SSL's
book...
One of the critical point is what to do when we have pending messages to
write to a remote peer, which has initiated a (re-)handshake.
My initial take was that we should finish to send the current message to
teh remote
No, I don't agree with that because the spec says that the new key materials
should be set current only when the change cipher spec message is received from
the server. So I think we can continue sending messages encrypted with the old
key if the handshake messages are after in the queue. The pr
Le 19/07/2014 17:34, Jeff MAURY a écrit :
> No, I don't agree with that because the spec says that the new key materials
> should be set current only when the change cipher spec message is received
> from the server. So I think we can continue sending messages encrypted with
> the old key if the
On Sat, Jul 19, 2014 at 6:25 PM, Emmanuel Lécharny
wrote:
> Le 19/07/2014 17:34, Jeff MAURY a écrit :
> > No, I don't agree with that because the spec says that the new key
> materials should be set current only when the change cipher spec message is
> received from the server. So I think we can
Le 20/07/2014 23:11, Jeff MAURY a écrit :
> On Sat, Jul 19, 2014 at 6:25 PM, Emmanuel Lécharny
> wrote:
>
>> Le 19/07/2014 17:34, Jeff MAURY a écrit :
>>> No, I don't agree with that because the spec says that the new key
>> materials should be set current only when the change cipher spec message
On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny
wrote:
> Le 20/07/2014 23:11, Jeff MAURY a écrit :
> > On Sat, Jul 19, 2014 at 6:25 PM, Emmanuel Lécharny
> > wrote:
> >
> >> Le 19/07/2014 17:34, Jeff MAURY a écrit :
> >>> No, I don't agree with that because the spec says that the new key
> >>
Le 21/07/2014 11:53, Jeff MAURY a écrit :
> On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny
> wrote:
>
>> Le 20/07/2014 23:11, Jeff MAURY a écrit :
>>
>>record layer to make the write pending state the write active state.
>> The SSL sepc says basically the same thing.
>>
>> However, that on
On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny
wrote:
> Le 21/07/2014 11:53, Jeff MAURY a écrit :
> > On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny
> > wrote:
> >
> >> Le 20/07/2014 23:11, Jeff MAURY a écrit :
> >>
> >>record layer to make the write pending state the write active st
Le 21/07/2014 16:16, Jeff MAURY a écrit :
> On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny
> wrote:
>
>> Le 21/07/2014 11:53, Jeff MAURY a écrit :
>>> On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny
>>> wrote:
>>>
Le 20/07/2014 23:11, Jeff MAURY a écrit :
record layer to
On Mon, Jul 21, 2014 at 5:25 PM, Emmanuel Lécharny
wrote:
> Le 21/07/2014 16:16, Jeff MAURY a écrit :
> > On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny
> > wrote:
> >
> >> Le 21/07/2014 11:53, Jeff MAURY a écrit :
> >>> On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny <
> elecha...@gmail.
Le 23/07/2014 10:56, Jeff MAURY a écrit :
> On Mon, Jul 21, 2014 at 5:25 PM, Emmanuel Lécharny
> wrote:
>
>> Le 21/07/2014 16:16, Jeff MAURY a écrit :
>>> On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny
>>> wrote:
>>>
Le 21/07/2014 11:53, Jeff MAURY a écrit :
> On Mon, Jul 21, 2014 at
Hello,
after thinking about the messages ordering and rehandshaking, I agree that
we should encrypt just before sending. The only problematic case that I can
see is if the send queue is empty and the application submit a message when
the last client handshake message is received : if both runs co
Le 30/07/2014 23:26, Jeff MAURY a écrit :
> Hello,
>
> after thinking about the messages ordering and rehandshaking, I agree that
> we should encrypt just before sending.
A
> The only problematic case that I can
> see is if the send queue is empty and the application submit a message whe
Hello,
as I'm working on the SSL part this time and more specifically on the
handshake/rehandshake processing, I have a couple of questions and some
infos to share:
- I've added 3 more methods in IoHandler to reflect handshake related
event: handshakeStarted, handshakeCompleted and secureCl
Le 07/10/14 23:37, Jeff MAURY a écrit :
> Hello,
>
> as I'm working on the SSL part this time and more specifically on the
> handshake/rehandshake processing, I have a couple of questions and some
> infos to share:
>
>- I've added 3 more methods in IoHandler to reflect handshake related
>ev
On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny
wrote:
> Le 07/10/14 23:37, Jeff MAURY a écrit :
> > Hello,
> >
> > as I'm working on the SSL part this time and more specifically on the
> > handshake/rehandshake processing, I have a couple of questions and some
> > infos to share:
> >
> >-
Le 08/10/14 11:45, Jeff MAURY a écrit :
> On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny
> wrote:
>
>> Le 07/10/14 23:37, Jeff MAURY a écrit :
>>> Hello,
>>>
>>> as I'm working on the SSL part this time and more specifically on the
>>> handshake/rehandshake processing, I have a couple of quest
On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny
wrote:
> Le 08/10/14 11:45, Jeff MAURY a écrit :
> > On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny
> > wrote:
> >
> >> Le 07/10/14 23:37, Jeff MAURY a écrit :
> >>> Hello,
> >>>
> >>> as I'm working on the SSL part this time and more specif
Le 11/10/14 08:38, Jeff MAURY a écrit :
> On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny
> wrote:
>
>
> I was mentioning the SSLContext that is the argument of the initSecure
> method. Please note that in 3.0, there is no more SSLFilter as SSL
>> handling
>>> has been moved to core.
>>> So my
Replying again, but this time with MINA 3 in mind (please add a tage in
front of teh subject, i order to avoid confusion : I was in MINA 2 mode
those last 3 weeks...)
Le 07/10/14 23:37, Jeff MAURY a écrit :
> Hello,
>
> as I'm working on the SSL part this time and more specifically on the
> hands
32 matches
Mail list logo
