javax.net.ssl.SSLException Unrecognized SSL message - trying to make https request to a target - but send this through an upstream web proxy

[malcol...@cloudsherpas.com]

I am setting up membrane service proxy in a corporate environment where there is a web proxy on port 8080 that handles all traffic outbound to the internet.  I'm running version 4.0.18.  I should not that if I configure my local Chrome browser to have localhost:3128 as the proxy - I have no trouble accessing the https://www.google.de target.  The local squid proxy

I am trying to have this work so that when I make a request to http://localhost:8081 (non ssl) and have it reverse proxies to a https target through the corporate web proxy.

The config file is setup like this:

<router>

    <httpClientConfig>
        <proxy host="proxy.corporate.com" port="8080" password="sXXXXX" username="dsXXXX3"/>
    </httpClientConfig>

    <serviceProxy port="8081" >
        <log level="DEBUG" />
        <statisticsCSV file="./log.csv" />
        <target host="www.google.de" port="">
            <ssl />
        </target>
    </serviceProxy>

</router>

The error is:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
        at sun.security.ssl.InputRecord.handleUnknownRecord(Unknown Source)
        at sun.security.ssl.InputRecord.read(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
        at sun.security.ssl.AppOutputStream.write(Unknown Source)
        at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
        at java.io.BufferedOutputStream.flush(Unknown Source)
        at com.predic8.membrane.core.http.Message.write(Message.java:229)
        at com.predic8.membrane.core.transport.http.HttpClient.doCall(HttpClient.java:244)
        at com.predic8.membrane.core.transport.http.HttpClient.call(HttpClient.java:157)
        at com.predic8.membrane.core.interceptor.HTTPClientInterceptor.handleRequest(HTTPClientInterceptor.java:61)
        at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:106)
        at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeHandlers(InterceptorFlowController.java:71)
        at com.predic8.membrane.core.transport.http.AbstractHttpHandler.invokeHandlers(AbstractHttpHandler.java:68)
        at com.predic8.membrane.core.transport.http.HttpServerHandler.process(HttpServerHandler.java:210)
        at com.predic8.membrane.core.transport.http.HttpServerHandler.run(HttpServerHandler.java:102)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
20:28:31,946 DEBUG InterceptorFlowController:145 - Invoking abortion handler: Reverse Proxy on exchange: [time:Aug 12, 2016,requestURI:https://www.google.de:443

[malcol...@cloudsherpas.com]

I see this issue logged in Github - 

https://github.com/membrane/service-proxy/issues/145

Seems like that is the root cause here, however, looking at the code in 4.0.19 I don't see that this has been fixed.

[malcol...@cloudsherpas.com]

I see this issue logged in Github - 

https://github.com/membrane/service-proxy/issues/145

Seems like that is the root cause here, however, looking at the code in 4.0.19 I don't see that this has been fixed.

On Saturday, August 13, 2016 at 1:34:02 AM UTC-4, malcol...@cloudsherpas.com wrote:

[malcol...@cloudsherpas.com]

I was able to code a solution will post a diff/patch file to the original issue - this is working for me now (with the chances) in a locked down corporate environment.

See https://github.com/membrane/service-proxy/issues/145

On Saturday, August 13, 2016 at 1:34:02 AM UTC-4, malcol...@cloudsherpas.com wrote:

[malcol...@cloudsherpas.com]

Amazingly responsive team on the http://membrane-soa.org team - they have gone ahead and implemented this capability (with test coverage etc) - for a future core release.  See issue item below for details.

Thanks!