Interest in splitting-off SSLSocketFactory customizers?

[Christopher Schultz <ch...@christopherschultz.net>]

All,

Lately, I've found myself re-writing the same code to customize an
SSLSocketFactory for a variety of clients I've been writing. Of course,
I have, at this point, written a re-usable library that I generally use,
but when I want to give-away the code to someone else, it's a little
nicer to have it all in one package, etc. and not have too much hidden
in a separate library.

This week, I'm looking at adding cipher-suite blacklisting (e.g. "never
use MD5") and I started thinking about Tomcat's OpenSSL-style cipher
suite parsing code.

I'm starting to think that, much like the Digester, this code would be
very useful to anyone writing a Java application that needs to customize
TLS connections.

Is anyone else (also) interested in possibly spinning-off Tomcat's
SSLSocketFactory management code into a separate library? Basically, I
was thinking that we could consolidate Tomcat's code (which is already
pretty segregated) that handles the following operations:

- trust managers
- key managers
- CRLs
- protocol selection (actually enabling/disabling SSLv3, TLSv1, TLSv1.1,
etc.)
- cipher suite selection
- anything else?

Since we are now supporting JSSE+OpenSSL, that could even be bundled in
there, so clients could request OpenSSL-backed crypto if they want.

In my case, I'm particularly interested in supporting clients
(SSLSocketFactory), but certainly supporting servers
(SSLServerSocketFactory) makes a lot of sense, too, since a lot of the
code is the same ... just slightly different plumbing.

Ultimately, I was going to suggest a fairly simple public API like this:

public class SocketFactoryBuilder {
  public SSLSocketFactory createClientFactory([supported protocols],
[cipher suite specs], [client cert store / client cert spec], [crl],
[hostname verifier]);

  public SSLServerSocketFactory createServerFactory([supported
protocols], [cipher suite specs], [server keystore], [client trust store]);
}

There are many ways one might want to specify the various stores (e.g.
filename, InputStream, etc.) so those might be overloaded to support
various combinations of things for convenience.

Any thoughts?

-chris

Re: Interest in splitting-off SSLSocketFactory customizers?

[Rémy Maucherat <re...@apache.org>]

2016-04-21 21:49 GMT+02:00 Christopher Schultz <chris@christopherschultz.net
>:

> All,
>
> Bump
>
> Not interested :)

Rémy

Re: Interest in splitting-off SSLSocketFactory customizers?

[Christopher Schultz <ch...@christopherschultz.net>]

All,

Bump

Thanks,
-chris

On 4/10/16 4:08 PM, Christopher Schultz wrote:
> All,
> 
> Lately, I've found myself re-writing the same code to customize an
> SSLSocketFactory for a variety of clients I've been writing. Of course,
> I have, at this point, written a re-usable library that I generally use,
> but when I want to give-away the code to someone else, it's a little
> nicer to have it all in one package, etc. and not have too much hidden
> in a separate library.
> 
> This week, I'm looking at adding cipher-suite blacklisting (e.g. "never
> use MD5") and I started thinking about Tomcat's OpenSSL-style cipher
> suite parsing code.
> 
> I'm starting to think that, much like the Digester, this code would be
> very useful to anyone writing a Java application that needs to customize
> TLS connections.
> 
> Is anyone else (also) interested in possibly spinning-off Tomcat's
> SSLSocketFactory management code into a separate library? Basically, I
> was thinking that we could consolidate Tomcat's code (which is already
> pretty segregated) that handles the following operations:
> 
> - trust managers
> - key managers
> - CRLs
> - protocol selection (actually enabling/disabling SSLv3, TLSv1, TLSv1.1,
> etc.)
> - cipher suite selection
> - anything else?
> 
> Since we are now supporting JSSE+OpenSSL, that could even be bundled in
> there, so clients could request OpenSSL-backed crypto if they want.
> 
> In my case, I'm particularly interested in supporting clients
> (SSLSocketFactory), but certainly supporting servers
> (SSLServerSocketFactory) makes a lot of sense, too, since a lot of the
> code is the same ... just slightly different plumbing.
> 
> Ultimately, I was going to suggest a fairly simple public API like this:
> 
> public class SocketFactoryBuilder {
>   public SSLSocketFactory createClientFactory([supported protocols],
> [cipher suite specs], [client cert store / client cert spec], [crl],
> [hostname verifier]);
> 
>   public SSLServerSocketFactory createServerFactory([supported
> protocols], [cipher suite specs], [server keystore], [client trust store]);
> }
> 
> There are many ways one might want to specify the various stores (e.g.
> filename, InputStream, etc.) so those might be overloaded to support
> various combinations of things for convenience.
> 
> Any thoughts?
> 
> -chris
>