<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/13/15 7:56 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:5553E4AA.8050204@georgetown.edu" type="cite">
<pre wrap="">
On 5/13/15 7:46 PM, Cantor, Scott wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>