Wiring HTTP client security in Spring

[Brent Putman]

On 10/21/16 6:41 PM, Cantor, Scott wrote:
>> 3) Immediately after you invoke the client execute(), invoke the support
>> method that sanity checks that the TLS trust engine eval was actually done, if
>> applicable, like so:
>>
>> HttpResponse response = httpClient.execute(request, context);
>> HttpClientSecuritySupport.checkTLSCredentialEvaluated(context,
>> request.getURI().getScheme());
> Speaking of..
>
> Does it short-circuit the call to the server if the TLS validation fails? If not, that renders it kind of moot, you've already given it the data.

For the actual "you're doing things correctly" case: If you supply a
TrustEngine in the context and you actually have a
SecurityEnhancedTLSSocketFactory: Yes absolutely it fails early. The
trust engine eval is done at the socket factory layer and will fail the
socket creation with an SSLPeerUnverifiedException, just like it would
if you were using the standard Java PKIX JSSE stuff.

But that's not the #3 case above.  That's just a "the developer screwed
up by not wiring things properly" case, and it's gonna throw there
because we decided that was the safest thing to do, vs say logging a
WARN etc, which might not be caught.  But it can't not send the data,
because there's no way for us to short-circuit that outside of the
socket factory.  Well, maybe you could do it in an HC interceptor or
something, not sure, but that's wiring a custom class, which would be
the same thing as wiring the custom socket factory, and fail in the
same ways due to human error.  It's really a sanity check for dev/test
time, not production (unless the deployer is wiring things herself).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161021/f2de446b/attachment.html>