SOAP Client: Client TLS credential selection

Brent Putman putmanb at georgetown.edu
Wed May 20 18:36:45 EDT 2015



On 5/13/15 7:56 PM, Brent Putman wrote:
>
> On 5/13/15 7:46 PM, Cantor, Scott wrote:
>> That kind of persuades me that it's a good idea, because recent years have 
>> demonstrated that per-connection control over TLS versions and ciphers is 
>> increasingly needed to deal with security issues much like it is with 
>> SHA-1 now.
> Looking at it just now, actually looks like it would be pretty easy to
> do with a custom HC socket factory.  It's just overriding 1 method. 
> The enabled cipher suites and TLS protocol version are not ultimately
> in the SSContext like I thought, it's the HC socket factory that does
> it.  And it has access to the HttpContext, so it would be easy to pass
> on a per-request basis that way. 

Turned out that actually subclassing their standard
SSLConnectionSocketFactory to do this was really hard/unclean, because
of the use of private fields with no getters, other private methods,
etc. One key method wasn't even being passed the HttpConetxt, just due
apparently due to lack of foresight.  So I just punted and did a new
factory of our own in java-support based off of it.  There's not a lot
to the factory, so I'm not concerned.  With that it was easy to
implement per-request protocols and cipher suites, as well as the bonus
of per-request hostname verifier, should we ever want one.

With this it will be relatively easy to get per-request data for these
options, as well as their existing support for per-request
RequestConfig (includes connection and socket timeouts) and basic auth
credentials.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150520/8136d3d6/attachment.html>


More information about the dev mailing list