<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/21/16 6:41 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5BF53@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">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());
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
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).<br>
</body>
</html>