[omniORB] openORB-1.3.1 SSL client

[Ben Cullen]

An IOR from an openORB server looks like:
Profiles:
1. IIOP 1.2 xxx.xx.xx.xxx 1255 ".OO.H.......POA.DQ..."
            TAG_CODE_SETS char native code set: 0x100204e4
                          char conversion code set: 0x0001000f,
ISO-8859-1, 0x00010020
                          wchar native code set: UTF-16
                          wchar conversion code set: 0x00010100

            TAG_SSL_SEC_TRANS port = 7777 supports = 231 requires = 102

Note the supports and requires components compared to the hardcoded 96
in an omni IOR.

I tried with an omniORB non-zero port, however openORB tries to only
connect to the TCP port and fails.

I hacked the omniORB hardcoded supports/requires 96's to the openORB
preferred 231/102:
CORBA::Boolean
sslTransportImpl::addToIOR(const char* param) {

  IIOP::Address address;
  if (parseAddress(param,address)) {
    // XXX, hardwared security options to:
    //       EstablishTrustInTarget (0x20) | EstablishTrustInClient
(0x40)
    // In future, this will be expanded configurable options.
    omniIOR::add_TAG_SSL_SEC_TRANS(address,0xe7,0x66);
    return 1;
  }
  return 0;
}

Now I get an SSL handshake dialogue, however the connection ultimately
fails due to an unknown certificate:
omniORB: openSSL error detected in sslEndpoint::accept.
Reason: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown

From what I gather the supports/requires value of 96 means client and
server authentication, i.e. no SSL:
64 client authentication
32 server authentication
2 integrity
4 confidentiality

I'm interested in doing server authentication only over SSL, and
therefore require 38. I guess this requires an omniORB enhancement?

Cheers, Ben


-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: 21 February 2006 13:01
To: Ben Cullen
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] openORB-1.3.1 SSL client 

On Monday 20 February, "Ben Cullen" wrote:

> I'm currently trying to get an openORB-1.3.1 SSL client talking to 
> omniORB-4.0.5.

[...]
> 1. IIOP 1.2 xxx.xx.xx.xxx 0
> ".xxxxxxxxxxxxxxxxxxxxxxxxxxxxx....C...<....."
>             TAG_ORB_TYPE omniORB
>             TAG_CODE_SETS char native code set: ISO-8859-1
>                           char conversion code set: UTF-8
>                           wchar native code set: UTF-16
>                           wchar conversion code set: UTF-16
> 
>             TAG_SSL_SEC_TRANS port = 7777 supports = 96 requires = 96
> 
> 
> When I run my openORB client it appears to get upset at the zero port,

> and spits out the following exception:
> CORBA Exception : org.omg.CORBA.NO_PERMISSION: Port number published 
> in IOR is 0.  vmcid: 0x444f7000  minor code: 280  completed: No

The IOR is valid. The way the SSL profile is defined, it just contains a
port number, not a host address. It therefore only works in combination
with a non-ssl IIOP profile that gives a host address. Since the server
doesn't want to support TCP, it sets the port to zero to mean that it's
not available.

What does an IOR from an openORB server look like?

One thing you might try is to force omniORB to publish a port number
other than zero, and hope the client isn't upset that it's not
listening. To do that, you can use the endPointNoListen parameter:

endPoint = giop:ssl::7777
endPointNoListen = giop:tcp:xxx.xxx.xxx.xxx:7778

Note that you must include the IP address (or hostname) in the
endPointNoListen.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --




Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Trema does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Trema does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of Trema are neither given nor endorsed by the company or its directors. A list of Trema's directors is available on our web site: www.trema.com