[omniORB-dev] Hardcoded TAG_SSL_SEC_TRANS supports/requires components

[Ben Cullen]

The supports and requires components of all omniORB SSL IORs are
hardcoded to 96, due to the following code:

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,0x60,0x60);
    return 1;
  }
  return 0;
}


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


Obviously it would be good (as the code comment describes) if this is
configurable, however in the meantime may I suggest that the values be
changed to:

    omniIOR::add_TAG_SSL_SEC_TRANS(address,0x66,0x66);

In other words, integrity and confidentiality are supported and
required.


My requirement comes from trying to get openORB to interop over SSL with
omniORB. openORB expects to see integrity and confidentiality, otherwise
it doesn't attempt to connect to the SSL enabled port. See also my mails
in the omniORB mailing list:
http://www.omniorb-support.com/pipermail/omniorb-list/2006-February/0274
87.html

Note: I eventually got this configuration working with omniORB hacked to
publish 102/102 for supports/requires, and then correctly setting up the
certificates using openSSL and keystore.


Regards, Ben



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