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 handlers.
Maintaining clear understanding of which code and which flow has the
responsibility of setting up the SSL is important for maintainability and
testing.
On Mon, Jan 17, 2022 at 10:30 AM Emmanuel Lécharny <elecha...@gmail.com>
wrote:
> 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( LdapSession session,
> ExtendedRequest req ) throws Exception
> {
> IoFilterChain chain = session.getIoSession().getFilterChain();
> SslFilter sslFilter = ( SslFilter ) chain.get( "sslFilter" );
>
> if ( sslFilter == null )
> {
> // Establish the ssl filter
> }
> else
> {
> // Be sure we disable SSLV3
> sslFilter.setEnabledProtocols( new String[]
> { "TLSv1", "TLSv1.1", "TLSv1.2" } );
> sslFilter.startSsl( session.getIoSession() ); // What for ???
> }
>
> Actually, there is no reason to redo a handshake if the SSLFilter has
> already been established, and I think we mis-understood the RFC, which
> says:
>
> "3.1.1. StartTLS Request Sequencing
>
> A client may send the StartTLS extended request at any time after
> establishing an LDAP session, except:
>
> - when TLS is currently established on the session,"
>
> So I guess this missing method is a no problem.
>
>
> 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.
> >
> > 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 <elecha...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> 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 event then read the AttributeKey to obtain the
> >> SslSession.
> >>>
> >>>
> >>
> https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56
> >>
> >> My second mail clarified my requirement. I need to have access to the
> >> SslSession instance, to grab the client certificate from it.
> >>
> >> --
> >> Emmanuel Lécharny
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> For additional commands, e-mail: dev-h...@mina.apache.org
> >>
> >>
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
