[omniORB] Fallback from SSL to TCP on CA failure?

Peter Klotz peter.klotz at aon.at
Sun Oct 4 12:08:02 BST 2009


Hello

I have a client/server SSL setup with deliberately misconfigured 
certificates.

Options -ORBclientTransportRule and -ORBserverTransportRule are '* 
ssl,tcp' for client and server.

The server has a TCP and an SSL listen port who are both published in 
its IOR. omniNames just uses a TCP listen port.

The server implements two servants who each have a trivial ping() method.

Calling A::ping() results in a client side TRANSIENT_ConnectFailed 
exception. No fallback from SSL to TCP is performed.

Calling B::ping() works by performing a fallback to TCP (according to 
tcpdump).

Following is the trace level 40 output which we redirected to our 
logging framework.

Call of A::ping() which fails:

2009-10-03 23:38:03.506458 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections done (1254605883,504876000).
2009-10-03 23:38:05.445609 V omniORB          pid: 27194 tid: 1118259520
     omniORB: openSSL error detected in sslEndpoint::accept.
     Reason: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert 
unknown ca
2009-10-03 23:38:05.495830 V omniORB          pid: 27194 tid: 1118259520
     omniORB: SocketCollection idle. Sleeping.
2009-10-03 23:38:08.507753 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections (1254605888,506495000)

Call of B::ping() which succeeds:

2009-10-03 23:40:28.576844 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections (1254606028,575725000)
2009-10-03 23:40:28.576946 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections done (1254606028,575725000).
2009-10-03 23:40:30.484465 V omniORB          pid: 27194 tid: 1118259520
     omniORB: openSSL error detected in sslEndpoint::accept.
     Reason: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert 
unknown ca
2009-10-03 23:40:30.485112 V omniORB          pid: 27194 tid: 1116158272
     omniORB: Server accepted connection from giop:tcp:10.18.1.19:60232
2009-10-03 23:40:30.485268 V omniORB          pid: 27194 tid: 1102518592
     omniORB: AsyncInvoker: thread id = 57 has started. Total threads = 4
2009-10-03 23:40:30.485272 V omniORB          pid: 27194 tid: 1102518592
     omniORB: giopWorker task execute.
2009-10-03 23:40:30.485274 V omniORB          pid: 27194 tid: 1102518592
     omniORB: Accepted connection from giop:tcp:10.18.1.19:60232 because 
of this rule: "* ssl,tcp"
2009-10-03 23:40:30.485451 V omniORB          pid: 27194 tid: 1102518592
     omniORB: inputMessage: from giop:tcp:10.18.1.19:60232 38 bytes



How can the behavior be different depending on calling A::ping() or 
B::ping()?

Is it the desired behavior that omniORB (4.1.4) performs a fallback from 
SSL to TCP if the CA check fails?

I assumed that client and server agree on a transport that both support 
according to the published IOR and once started their communication are 
unable to fallback to anything else.

Any help is highly appreciated.

Regards, Peter.



More information about the omniORB-list mailing list