On Fri, 2007-03-09 at 15:57 -0800, Julius Davies wrote:
> 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?
>
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
> 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 <[EMAIL PROTECTED]> wrote:
> > 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 [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 09, 2007 12:37 PM
> > To: [email protected]
> > 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: [EMAIL PROTECTED] For additional
> > commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
