Unfortuneatly the endpoint is not mine. It is a commercial endpoint of an actual service I need to call. My hope is that I can use synapse to deal with all of the HTTPS stuff that my main application platform does not have to deal with it. Seems like a perfect fit for synapse :-)
-----Original Message----- From: Asankha C. Perera [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 3:55 PM To: [email protected] Cc: [EMAIL PROTECTED] Subject: Re: Outbound HTTPS with Client Certificate Hi Griffin Hmmm.. this seems interesting and I am copying this to Julius for his expert views on what seems to be going wrong here. Is your endpoint a test endpoint accessible over the Internet? If so maybe I could give it a try? asankha Michael Griffin 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
