On Tue, 2017-05-09 at 01:39 -0700, Gary Gregory wrote:
> On May 9, 2017 1:00 AM, "Oleg Kalnichevski" <[email protected]> wrote:
>
> On Tue, 2017-05-09 at 00:21 -0700, Gary Gregory wrote:
> > Hi All,
> >
> > We have a nice example in HttpCore for an HTTP reverse proxy here:
> >
> > https://hc.apache.org/httpcomponents-core-4.4.x/httpcore-nio/exampl
> > es
> > /org/apache/http/examples/nio/NHttpReverseProxy.java
> >
> > I've taken this example and morphed into a different beast. I am
> > wondering
> > how I can let each origin server client have its own SSLContext in
> > order
> > for me to given them different TrustStrategy implementations.
> >
> > In our example, we set things up like this:
> >
> > final IOEventDispatch *connectingEventDispatch *= new
> > DefaultHttpClientIODispatch(
> > clientHandler, ConnectionConfig.DEFAULT);
> >
> > final IOEventDispatch listeningEventDispatch = new
> > DefaultHttpServerIODispatch(
> > serviceHandler, ConnectionConfig.DEFAULT);
> >
> > Thread t = new Thread(new Runnable() {
> >
> > public void run() {
> > try {
> > connectingIOReactor.execute(*connectingEventDis
> > pa
> > tch*);
> > } catch (InterruptedIOException ex) {
> > System.err.println("Interrupted");
> > } catch (IOException ex) {
> > ex.printStackTrace();
> > } finally {
> > try {
> > listeningIOReactor.shutdown();
> > } catch (IOException ex2) {
> > ex2.printStackTrace();
> > }
> > }
> > }
> >
> > });
> > t.start();
> >
> >
> > In my case I build the connectingEventDispatch with our lower-level
> > APIs in
> > order to pass in the SSLContext like this:
> >
> > ConnectionConfig clientConnectionConfig = ConnectionConfig.DEFAULT;
> > IOEventDispatch *connectingEventDispatch *=
> > clientSslContext == null ?
> > new DefaultHttpClientIODispatch(clientHandler,
> > clientConnectionConfig)
> > :
> > new DefaultHttpClientIODispatch(clientHandler,
> > *clientSslContext*,
> > clientConnectionConfig);
> >
> > But this SSLContext is used for ALL origin servers (a.k.a. target
> > hosts)
> >
> > Do I need to build a connectingEventDispatch for each SSLContext I
> > need and
> > then execute each like the above:
> >
> > connectingIOReactor.execute(connectingEventDispatch);
> >
> > Each execute in its own thread?
> >
> > Or is there a cleaner, more HttpCore way to do this?
> >
>
> I suppose the IOEventDispatch#onConnect would be the right place to
> implement TLS upgrade. One can employ various strategies here, for
> instance, passing some sort of config object as an attachment to the
> session request and building SSL context for the session based on
> that
> config.
>
>
> Hi Oleg,
>
> I am not talking about upgrading connections, even though that would
> be
> nice but a separate topic. I
>
> I know at startup whether I need SSL or not for each origin server
> and
> which TrustStrategy for origin server. I am wondering how to install
> a TS
> for each given origin server.
I am not sure I understand the problem you are having. One would set up
trust material when upgrading to SSL/TLS, wound not one?
---
class MyIODispatch extends AbstractIODispatch<DefaultNHttpClientConnection> {
@Override
protected DefaultNHttpClientConnection createConnection(final IOSession
session) {
InetSocketAddress remoteAddress = (InetSocketAddress)
session.getRemoteAddress();
if ("secure-origin".equalsIgnoreCase(remoteAddress.getHostName())) {
SSLContext sslContext = SSLContextBuilder.create()
.loadTrustMaterial(new TrustStrategy() {
@Override
public boolean isTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
return true;
}
})
.build();
SSLIOSession sslioSession = new SSLIOSession(session,
SSLMode.CLIENT, sslContext, null);
session.setAttribute(SSLIOSession.SESSION_KEY, sslioSession);
}
return new DefaultNHttpClientConnection(session, 8 * 1024);
}
}
---
Oleg
>
> It is still a little too early for me to port my app to 5.0 as I am
> still
> flushing out features. I certainly plan on doing that and helping
> with 5.0
> as much as I can.
>
> Gary
>
>
> Oleg
>
> PS: I hope that TLS upgrade APIs in 5.0 are much nicer.
>
>
> > Thank you!
> > Gary
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
