synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <asan...@wso2.com>
Subject Re: Outbound HTTPS with Client Certificate
Date Sun, 11 Mar 2007 19:20:38 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I do not think this is an issue in the HttpCore/NIO-SSL code.. or in
blocking / non-blocking implementation difference.. <br>
<br>
Griffin, I need you to send me the *full* debug level log from Synapse
for your entire use case, and it should include the *full* SSL debug
output too - from the initialization of the key stores to completion.
You can remove the actual hostname of the target server from the post
if its sensitive<br>
<br>
asankha<br>
<br>
Oleg Kalnichevski wrote:
<blockquote cite="mid1173635525.4801.47.camel@okhost" type="cite">
  <pre wrap="">On Fri, 2007-03-09 at 15:57 -0800, Julius Davies wrote: 
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,

I'm cross-posting with "synapse-dev" because I know Oleg watches that list.

Oleg - I got Griffin to try using that "Ping" utility in
not-yet-commons-ssl.  Thanks to the results of that I'm pretty
confident that the client trusts the server, and the client cert is
being loaded successfully.  Also no issues with certificate expiry or
hostname validation.

Looks like Griffin found a really interesting difference between using
SOAP-UI (blocking) and Synapse (non-blocking) with javax.net.debug=all
turned on.  Griffin says the java version (and JAVA_HOME, for that
matter) was identical for both the SOAP-UI and Synapse runs.

Anything look suspicious to you?

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hi Julius,

Unfortunately I do not have an explanation for it. All I can do is to
add more test cases in order to try to stress HttpCore NIOSSL in some
different ways. I can well imagine this may be a bug in HttpCore NIOSSL,
as non-blocking SSL is an extremely complex thing to get right.

Oleg 


  </pre>
  <blockquote type="cite">
    <pre wrap="">ps. Griffin - does this issue happen on both latest Java 5 and Java
6?
 Might be interesting to  experiment with IBM and Bea JVM's as well -
they've both got "preview" releases of Java 6 out last I checked.


yours,

Julius

(Oleg ... check out the javax.net.debug=all output below!)

On 3/9/07, Michael Griffin <a class="moz-txt-link-rfc2396E" href="mailto:mgriffin@fsenablers.com">&lt;mgriffin@fsenablers.com&gt;</a>
wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">asankha,

I did some more analysis with the javax.net.debug=all turned on.  Basically
I have found that betwen the two clients SOAPUI and Synapse there is a
difference during the ClientKeyExchange step.  The difference is as follows:

For the SOAPUI test client (this one works)
        *** ClientKeyExchange, RSA PreMasterSecret, TLSv1
        Random Secret:  { .... }
        [write] MD5 and SHA1 hashes:  len = 134
        pool-1-thread-1, WRITE: TLSv1 Handshake, length = 134
A1      [Raw write]: length = 139
        SESSION KEYGEN:
        PreMaster Secret:
        CONNECTION KEYGEN:
        Client Nonce:
        Server Nonce:
        Master Secret:
        Client MAC write Secret:
        Server MAC write Secret:
        Client write key:
        Server write key:
        ... no IV for cipher
        pool-1-thread-1, WRITE: TLSv1 Change Cipher Spec, length = 1
B1      [Raw write]: length = 6
        *** Finished
        verify_data:  { 107, 203, 92, 131, 85, 121, 87, 171, 96, 206, 238, 30 }
        ***
        [write] MD5 and SHA1 hashes:  len = 16
        Padded plaintext before ENCRYPTION:  len = 32
        pool-1-thread-1, WRITE: TLSv1 Handshake, length = 32
A2
B2
        [Raw write]: length = 37
        [Raw read]: length = 5
        [Raw read]: length = 1
        pool-1-thread-1, READ: TLSv1 Change Cipher Spec, length = 1
        [Raw read]: length = 5
        [Raw read]: length = 32
        pool-1-thread-1, READ: TLSv1 Handshake, length = 32
        Padded plaintext after DECRYPTION:  len = 32
        *** Finished
        verify_data:  { 40, 93, 34, 17, 33, 112, 112, 78, 161, 7, 217, 136 }
        ***
        %% Didn't cache non-resumable client session: [Session-1,
SSL_RSA_WITH_RC4_128_MD5]

For Synapse the A1 and B1 are in a different place

        *** ClientKeyExchange, RSA PreMasterSecret, TLSv1
        Random Secret:  { .... }
        [write] MD5 and SHA1 hashes:  len = 134
        I/O reactor worker thread, WRITE: TLSv1 Handshake, length = 134
A1
        SESSION KEYGEN:
        PreMaster Secret:
        CONNECTION KEYGEN:
        Client Nonce:
        Server Nonce:
        Master Secret:
        Client MAC write Secret:
        Server MAC write Secret:
        Client write key:
        Server write key:
        ... no IV for cipher
        I/O reactor worker thread, WRITE: TLSv1 Change Cipher Spec, length = 1
B1
        *** Finished
        verify_data:  { 61, 90, 82, 31, 54, 31, 45, 19, 5, 78, 129, 203 }
        ***
        [write] MD5 and SHA1 hashes:  len = 16
        Padded plaintext before ENCRYPTION:  len = 32
        I/O reactor worker thread, WRITE: TLSv1 Handshake, length = 32
A2      [Raw write]: length = 139
B2      [Raw write]: length = 6
        [Raw write]: length = 37
        [Raw read]: length = 5
        [Raw read]: length = 1
        I/O reactor worker thread, READ: TLSv1 Change Cipher Spec, length = 1
        [Raw read]: length = 5
        [Raw read]: length = 32
        I/O reactor worker thread, READ: TLSv1 Handshake, length = 32
        Padded plaintext after DECRYPTION:  len = 32
        *** Finished
        verify_data:  { 128, 51, 223, 64, 166, 195, 190, 199, 81, 87, 82, 197 }
        ***
        %% Didn't cache non-resumable client session: [Session-1,
SSL_RSA_WITH_RC4_128_MD5]

The two 6 byte writes contain the same data, the 139 byte writes are
different.

In both cases, I am using the same to keystore and trustore and the same
javax.net.debug setting.  Both run on the same server and use the same VM
instance.  I don't know enough about SSL to provide any additional insight
into what I think the problem is.

regards,
griffin


-----Original Message-----
From: Asankha C. Perera [<a class="moz-txt-link-freetext" href="mailto:asankha@wso2.com">mailto:asankha@wso2.com</a>]
Sent: Friday, March 09, 2007 12:37 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:synapse-user@ws.apache.org">synapse-user@ws.apache.org</a>
Subject: Re: Outbound HTTPS with Client Certificate


Hi Griffin

I am able to reproduce your scenario where Synapse seems to stop responding,
when a SSL handshake failure happens - and I am quite sure that its the same
thing thats happening at your end too. If you run Synapse
with -Djavax.net.debug=all this would be evident. Also if you are using the
SVN trunk - get the latest code - I did a minute fix to the
ClientHandler.java to print the stack trace that will help you debug the
issue easily. Also check if you are getting the ClientHandler - I/O error:
General SSLEngine problem in your logs?

[I/O reactor worker thread 1] DEBUG Axis2HttpRequest - get source channel of
the pipe on which the outgoing response is written
....
I/O reactor worker thread 1, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
I/O reactor worker thread 1, SEND TLSv1 ALERT:  fatal, description =
certificate_unknown
I/O reactor worker thread 1, WRITE: TLSv1 Alert, length = 2
I/O reactor worker thread 1, fatal: engine already closed.  Rethrowing
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
[I/O reactor worker thread 1] ERROR ClientHandler - I/O error : General
SSLEngine problem

That seems like a good idea.  The interesting thing is that I didn't provide
addressing headers to begin with, they seem to have been added by Synapse.

Yes, this seems like a bug .. Could you please raise a JIRA for it, and we
will fix it

Also with regard to this endpoint, is there a way to control the protocol
behaviours - i.e. disable Transfer-Encoding: chunked.

No, this is left to the transport implementation to decide, and as we do not
read the complete message from the wire into memory before we parse it, we
do not know the size of the message - hence most of the time the chunked
encoding is used. Same applies during a write as its possible that we do not
know the size when we start to write the message to the wire. But this
should have *no* impact on your application as its purely a transport
decision.

In my attempt to get the outbound HTTPS proxy to work, I've found that if I
use SOAP-UI and configure the key and truststores as I have them with the
Synapse/Axis2 httpniosslsender I am able to complete the request.  The
differences that I see in the debug streams are related to the HTTP header
and the user of the Transfer-Encoding - the NIOSSL sender uses
Transfer-Encoding: chunked and the Jakarta commons HTTP client used by
SOAP-UI uses Content-Length: xxx instead.

No I am positive that its not the chunked encoding, but the keystores.. I
think its Synapse that doesn't trust your server. Could you tell me what
your service host is? Is it Axis2/.net? and can does it use a self signed
cert or CA cert? have you imported its cert or the CA cert into the trust
store of Synapse?..

asankha
--------------------------------------------------------------------- To
unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-user-unsubscribe@ws.apache.org">synapse-user-unsubscribe@ws.apache.org</a>
For additional
commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-user-help@ws.apache.org">synapse-user-help@ws.apache.org</a>



---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-user-unsubscribe@ws.apache.org">synapse-user-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-user-help@ws.apache.org">synapse-user-help@ws.apache.org</a>


      </pre>
    </blockquote>
    <pre wrap="">
    </pre>
  </blockquote>
  <pre wrap=""><!---->

---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-dev-unsubscribe@ws.apache.org">synapse-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:synapse-dev-help@ws.apache.org">synapse-dev-help@ws.apache.org</a>


  </pre>
</blockquote>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message