Hi again,
Some more light about this topic.
The main issue is related with the connectionPool that the
servicemix-http component uses wich is an
org.mortbay.jetty.client.HttpClient.
In case of an SSL connection, this client uses the
org.mortbay.jetty.security.SslHttpChannelEndPoint as connector with
the default configuration, i.e. SSL-renegotiation is not allowed.
I cannot find the way to configure/customize this behaviour, because
the jettyConnectorClassName property in the configuration section of
the component [1] seems only works when the component acts as server
("consumer" role).
Any ideas or workarounds are welcome,
keep you posted,
[1] http://servicemix.apache.org/servicemix-http.html
El día 2 de noviembre de 2010 10:24, Agustín Gañán <[email protected]> escribió:
> Hi all,
>
> I'm developing a web service client wich has to interact with a
> RPC/encoded web service through an https connection. Following this
> post [1] I'm using an http endpoint but I'm facing a problem related
> with the SSL connection.
>
> The WS wich I'm trying to connect tries to "renegotiate" the
> connection during the invocation and this closes the connection
> because the SSL renegotiation is disabled by default in the
> servicemix-http component, here is the warning:
>
> 2010-10-27 18:06:54,565 WARN org.mortbay.jetty - SSL renegotiate
> denied: java.nio.channels.SocketChannel
>
> The cause is that the http endpoint uses the
> org.mortbay.jetty.security.SslHttpChannelEndPoint class in order to
> stablish the SSL connection and since version 6.1.22 of
> jetty-sslengine the renegotiation is disabled by default.
>
> I know that this behaviour is the best practice because there is a
> known vulnerability [2] related with the SSL renegotiation but I need
> to interact with this WS and I cannot do changes in the "server side"
> (if I could, I would say goodbye to RPC/encoded firstly, :-$)
>
> I've done some tests and with the 6.1.21 version of the
> jetty-sslengine I'm able to stablish the connection succesfully so I
> think that maybe could be a good idea allows the configuration of the
> SSL renegotiation in the http endpoint.
>
> What do you think?
> Does anyone have another approach or hint?
>
> Thanks in advance,
>
> Agus
>
> [1] http://www.mail-archive.com/[email protected]/msg00434.html
> [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
>
