You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Julius Davies <ju...@gmail.com> on 2007/03/10 00:57:42 UTC
Re: Outbound HTTPS with Client Certificate
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?
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 <mg...@fsenablers.com> 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:asankha@wso2.com]
> Sent: Friday, March 09, 2007 12:37 PM
> To: synapse-user@ws.apache.org
> 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: synapse-user-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-user-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Outbound HTTPS with Client Certificate
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <mg...@fsenablers.com> 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:asankha@wso2.com]
> > Sent: Friday, March 09, 2007 12:37 PM
> > To: synapse-user@ws.apache.org
> > 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: synapse-user-unsubscribe@ws.apache.org For additional
> > commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org