Have you tried printing the entirety of the contents from the Socket
inbound and compare against what is passed into the SSLEngine to make sure
our buffer combination/management isn’t corrupting the stream?
On Jan 28, 2022 at 7:45:29 PM, Emmanuel Lécharny
wrote:
> Ok, moving forward:
>
> The te
Ok, moving forward:
The test does:
- create the server and set the SSLFilter with TLS 1.2
- create the secured connection (TLSv1.2)
- write a first message ('test-1')
- that initiate the HS, then the message is written to the server
- once the HS is completed, the response is sent (response 1)
-
🤯
On Fri, Jan 28, 2022 at 6:30 PM Emmanuel Lécharny
wrote:
> It should.
>
> What is really puzzling is when we set the server to use TLS 1.2 *and*
> the client to TLS 1.2, and that fails whatever Java version we use...
>
> On 29/01/2022 00:14, Jonathan Valliere wrote:
> > Shouldn’t it be downgra
It should.
What is really puzzling is when we set the server to use TLS 1.2 *and*
the client to TLS 1.2, and that fails whatever Java version we use...
On 29/01/2022 00:14, Jonathan Valliere wrote:
Shouldn’t it be downgrading during the handshake?
On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Léc
Shouldn’t it be downgrading during the handshake?
On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny
wrote:
> Hi Jonathan,
>
> after a big fight, I finally found that the SslFilterTest was failing in
> Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3
> (it was set to use "T
Hi Jonathan,
after a big fight, I finally found that the SslFilterTest was failing in
Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3
(it was set to use "TLS"). Note that the client is a plain SSL Socket,
created by a SSLSocketFactory.
So the combinations that work :
On 21/01/2022 13:23, Jonathan Valliere wrote:
You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.
Yes, but all in all, I think this WriteRequest class should go. The
original Attribute was specifically created to bypass the SslFilt
You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.
On Fri, Jan 21, 2022 at 3:58 AM Emmanuel Lécharny
wrote:
> I have it working. The filter approach is actually the silmpler way to
> deal with the requirement, I don't even have to leve
I have it working. The filter approach is actually the silmpler way to
deal with the requirement, I don't even have to leverage the crypt
bypass flag. I just check if the message to be written is the
StartTlsResponse one, and if so, I 'jump' over the SslFilter:
public void filterWrite(Next
On 20/01/2022 13:25, Jonathan Valliere wrote:
The old method was unsafe from a concurrency standpoint. This switching
logic should be in a filter.
Agreed. StartTLS is by itself very intrusive and I think it deserves to
be made a MINA filter, instead of expecting MINA to be twisted in a way
The old method was unsafe from a concurrency standpoint. This switching
logic should be in a filter.
On Thu, Jan 20, 2022 at 1:40 AM Emmanuel Lécharny
wrote:
>
>
> On 18/01/2022 14:06, Jonathan Valliere wrote:
> > Yes, I added that specifically for anyone who needed that attribute I
> > removed
On 18/01/2022 14:06, Jonathan Valliere wrote:
Yes, I added that specifically for anyone who needed that attribute I
removed. Unlike that attribute of disable once, this is completely safe
to use.
But sadly, it can't be used from the outside.
The typical use from an application PoV is :
Yes, I added that specifically for anyone who needed that attribute I
removed. Unlike that attribute of disable once, this is completely safe to
use.
On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny
wrote:
>
>
> On 18/01/2022 05:04, Jonathan Valliere wrote:
> > Doesn't the DisableEncryptionWrit
On 18/01/2022 05:04, Jonathan Valliere wrote:
Doesn't the DisableEncryptionWriteRequest get you where you need to go?
Just wrap the startTLS message and pass upstream into the SSLFilter.
You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
trick !
Will test it and tell
Doesn't the DisableEncryptionWriteRequest get you where you need to go?
Just wrap the startTLS message and pass upstream into the SSLFilter.
On Mon, Jan 17, 2022 at 10:11 PM Emmanuel Lécharny
wrote:
>
>
> On 17/01/2022 17:13, Jonathan Valliere wrote:
> > Shouldn’t Directory be able to configure
On 17/01/2022 17:13, Jonathan Valliere wrote:
Shouldn’t Directory be able to configure and add the SSLFiler on demand?
Yes, this is done when it receives a startTLS request.
There is a trick though: When the server receives the request, it should
establish the SSL layer, then send back the
Shouldn’t Directory be able to configure and add the SSLFiler on demand?
It will setup and attempt to start the moment it’s added on the server
filterchain.
On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny
wrote:
>
>
> On 17/01/2022 16:48, Jonathan Valliere wrote:
> > I think that piece of co
On 17/01/2022 16:48, Jonathan Valliere wrote:
I think that piece of code is trying to move the concern of configuring
the SSL into a place which doesn’t have enough information about the
state. The Ciphers can be set when the Filter is created. If a special
workflow is needed, you can alwa
I think that piece of code is trying to move the concern of configuring the
SSL into a place which doesn’t have enough information about the state.
The Ciphers can be set when the Filter is created. If a special workflow
is needed, you can always extend SSLFilter now which has convenient
override
Some more difference:
In order to be able to programatically start a SSL session, we need the
startSsl/stopTls methods in the SslFilter.
I'm trying to figure out if this is not a superfluous addition in MINA.
The directory server code looks like that:
public void handleExtendedOperation( Ld
On 17/01/2022 15:50, Jonathan Valliere wrote:
AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.
Ah, crap, totally missed this one. I was focusing of the fact the
SSL_SESSION attributeKey was missing ;-)
yeah:
session.setAttribute(SslFilte
AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.
You have access to the peer certificate after the handshake is done or are
you needing access earlier?
On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny
wrote:
>
>
> On 17/01/2022 15:09, Jonathan
On 17/01/2022 15:09, Jonathan Valliere wrote:
Emmanuel,
The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired. This was done to help improve best
practices for when this object is accessible. Your application can listen
for the SECURED ev
Emmanuel,
The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired. This was done to help improve best
practices for when this object is accessible. Your application can listen
for the SECURED event then read the AttributeKey to obtain the SslSes
On 17/01/2022 14:17, Emmanuel Lécharny wrote:
Hi Jonathan,
I'm testing MINA 2.2 in Apache Directory, and there are two API
differences :
- The SslSession is not anymore present in the IoSession attributes. Is
there any reason for the removal ?
To clarify, we need this information in the
Hi Jonathan,
I'm testing MINA 2.2 in Apache Directory, and there are two API
differences :
- The SslSession is not anymore present in the IoSession attributes. Is
there any reason for the removal ?
- The SslFilter.setUseClientMode(boolean) has also been removed. I
understand that we can im
26 matches
Mail list logo