Re: [jetty-dev] SslSelectChannelConnector Refactor Suggestion

[Chad La Joie <chad.lajoie@xxxxxxxxx>]

Thanks Greg, issue created and patch submitted.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=283375

One I wanted to note.  In the existing code the trust store path and 
type are overwritten with the key store path and type if the trust store 
path is not set.  However, the store password and trust manager factory 
algo are not overwritten.  The patch I submitted does do this but it has 
a TODO on it as I wasn't 100% sure doing this was correct.  The reason I 
did it was because the key and trust stores may have different password 
and algo's.  In most cases they probably don't but this seemed to be the 
safest approach.

Greg Wilkins wrote:
> Chad,
>
> This sounds like a good idea.... and now is the time to do any more
> API changes before we go to a 7.0.0   (yes I know we did and RC0, but I
> think that was a tad early/optimistic).
>
> So a patch for this would be very welcome.  Can you also create a
> bugzilla at eclipse to attach the patch to, as that should ask you
> to ok the IP for inclusion.
>
>    https://bugs.eclipse.org/bugs/
>
> click   "Report a new bug" --> RT --> jetty
>
> thanks in advance
>
>
>
>
>
>
> Chad La Joie wrote:
> > Hey all, I'd like to suggest a small refactor of the
> > SslSelectChannelConnector class.
> >
> > Background:
> > I have an application that does not use standard PKIX validation during
> > client-cert auth.  Instead there is a separate client descriptor file
> > which contains, amongst other things, the certs which may be used by
> > clients.  Therefore we have custom connectors for Tomcat and Jetty 6
> > that use a "delegate to application" trust store (that it, the trust
> > store says anything is good and it's up to the application to do the
> > actual validation).
> >
> > Now, I am NOT even beginning to suggest such functionality be integrated
> > with any container.  It works for us because we have a controlled
> > environment but I recognize it could cause all sorts of issues if
> > deployed generally.  However, in trying to extend
> > SslSelectChannelConnector in Jetty 7 the task is made more difficult
> > because the reading in of the truststore (and keystore) are conflated
> > with the creation of the SSLContext.  So my suggestion would be to break
> > this apart.  Specifically I'd suggest the following:
> >
> > - Change the [get|set][Keystore|Truststore] methods to be
> > [get|set][Keystore|Truststore]Path and operate on Strings as they do now.
> >
> > - Add methods get[Keystore|Truststore] which are responsible for doing
> > something and returning a KeyStore object
> >
> > - Use the new methods in createSSLContext
> >
> > Doing this obviously helps me out but I think it also has some other
> > minor benefits:
> > -  The XML declaration of the connector may be a bit clearer since the
> > property names 'KeystorePath' or 'TruststorePath' are a bit more
> > self-documenting.
> > - The createSSLContext shrinks down quite a bit (~50 lines of code are
> > moved elsewhere)
> > - A common "read in keystore" method could be used by both getKeystore
> > and getTruststore and thus eliminate duplicate code.
> >
> > If this sounds okay and you'd be interested in it I'll prepare a patch
> > and submit it.  Just let me know, I'm certainly willing to do the bit of
> > work required to make the change.
> >
> > Thanks.
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie@xxxxxxxxx, http://www.switch.ch