next up previous contents
Next: 7.5.13 What SSL implementations Up: 7.5 SSL Previous: 7.5.11 Does SSL raise

7.5.12 Do SSL security implementations with CORBA solve or change the problem of securely linking an object reference to the principal that it represents?

 

Extended Question
Nick Battle (July, 1998)51: I'm talking about the issue of "Target Object Identities" in CORBASEC appendix E.6.2 [ed: D.6.2 in the current version of the spec] (at least it used to be in the July 97 spec I have to hand!).

The problem is that IORs are not self securing. A security name (which I guess is the certificate name in SSL?) is included as a hint in the IOR (true?), but the system doesn't guarantee that the IOR hasn't been tampered with. So an attacker can tweak an object reference to use the security name of his own principal - something that he has the keys for - and then clients using that object reference think they are operating securely (which in a sense they are!), but are actually talking to the wrong object. All the ORB guarantees is that you are talking securely to the security name in the IOR, not that the name in the IOR is the one you want to talk to.

I understand how this works with the Kerberos and CSI-ECMA mechanisms, but I'm not sure how/if it's different with SSL. I see the problem as fundamental (there's no provable link between an object reference and the security name), so there must be an equivalent weakness in SSL based CORBA systems, true?

As E.6.2 [ed: D.6.2 in the current version of the spec] says, the onus is on the client to check the security name(s) of any target it intends to use, unless it has a trusted source of object references.

Andre Srinivasan
(July, 1998)52: Currently there are no SSL hints beyond the SSL component in the IOR.

The addition of this check [ed: by client of the security name(s) of any target it intends to use] is pretty straight forward though and the ORB could do it for you. If a communicating party presents something like a wallet that not only contains credentials, but contains trustpoints (i.e. trusted certificates that aren't necessarily roots), the ORB can reject the connection if the target identity does not contain a trustpoint.

I believe that a security unaware application CAN operate in an environment where the source of object references is not necessarily trusted IF a wallet can be administered that contains trustpoints. Basically the wallet notion moves the source of trust to the wallet rather than relying on the source of object references.


next up previous contents
Next: 7.5.13 What SSL implementations Up: 7.5 SSL Previous: 7.5.11 Does SSL raise