Naming Service and SSL
Teng Meng Wah
Do anyone know whether if I use naming service, can I
cooperate SSL into the system? Is it necessary ?
I am using Vbroker 3.2.
Thanks in advance for your reply
Cheers
Meng Wah
Andre Srinivasan
TMW> Hi, Do anyone know whether if I use naming service, can I
TMW> cooperate SSL into the system?
TMW> I am using Vbroker 3.2.
The IOR determines whether an SSL connection is attempted.
You can enable SSL with any VisiBroker server by initializing the BOA
with SSLTPool (if you pass the command line args into BOA_init, -OAid
SSLTPool will do the trick) and initializing the SSL layer with a
digital identity (you can do this with initializers to avoid modifying
the code). The resulting IOR will contain an SSL component.
TMW> Is it necessary?
It depends what you're doing.
If you're concerned about authentication, your DNS lookup was not
secure and it would give you confidence you were talking to the right
name server. On the otherhand, the client could have a list of trust
points (certificates) to compare the identity presented by servers
against, and a rogue name service will not be able to direct you to a
rogue target.
If you're concerned about privacy when communicating with the name
service, someone could snoop the wire waiting for you to contact the
name service and then watch where you go next. I would therefore
argue that your privacy would be compromised anyway (with respect to
the TCP association).
-andre.
Nick Battle
> The IOR determines whether an SSL connection is attempted.
I have a question that is slightly off topic from the original question,
but the answer might be relevant to the originator:
Do SSL security implementations with CORBA solve or change the problem
of (securely) linking an object reference to the principal that it
represents? I'm talking about the issue of "Target Object Identities" in
CORBASEC appendix E.6.2 (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 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.
> If you're concerned about authentication, your DNS lookup was not
> secure and it would give you confidence you were talking to the right
> name server.
We went round the houses discussing the issue about security of name
services (but based on a CSI-ECMA protocol). In the end, we decided that
a CORBA name service (actually our Trader service) couldn't sensibly be
(CORBA) secured. It came down to bootstrap problems, such as not being
able to secure the connection to the Trader to get trustworthy object
references for the Authentication and Privilege (logon) services until
you'd already logged on etc.
I realise an SSL based scheme might well be different in this respect,
since an SSL client is more autonomous (not requiring the services of
external objects in order to obtain Credentials, true?). But I'm not
really sure about this... hence the question.
> On the otherhand, the client could have a list of trust
> points (certificates) to compare the identity presented by servers
> against, and a rogue name service will not be able to direct you to a
> rogue target.
This is my point: I think that's not just an option, but a *requirement*
on clients, unless they can otherwise obtain a secure source of object
references. Clients that don't do this can assume nothing about the true
identity of the target - eg. whether data returned is trustworthy, or
whether effects they believe they have produced have actually occurred.
And this is true *even* if they turn on EstablishTrustInTarget, which is
particularly frightening.
If this is true, I think the consequences should be made much more
visible to application writers. For example, one consequence is that
security *unaware* applications - those that can't call
get_security_names and check them - *must* operate on a trusted source
of object references, since they can't check security names for
themselves.
-nick
Andre Srinivasan
AS> The IOR determines whether an SSL connection is attempted.
NB> I have a question that is slightly off topic from the original
NB> question, but the answer might be relevant to the originator:
NB> Do SSL security implementations with CORBA solve or change the
NB> problem of (securely) linking an object reference to the principal
NB> that it represents?
It's moved to D.6.2. Out of the box, SSL does not solve or change the
problem.
NB> The problem is that IORs are not self securing. A security name
NB> (which I guess is the certificate name in SSL?) is included as a
NB> hint in the IOR (true?),
No, currently there are no SSL hints beyond the SSL component in the
IOR.
NB> but the system doesn't guarantee that the IOR hasn't been tampered
NB> with. So an attacker can tweak an object reference to use the
NB> security name of his own principal - something that he has the
NB> keys for and then clients using that object reference think they
NB> are operating securely (which in a sense they are!), but are
NB> actually talking to the wrong object. All the ORB guarantees is
NB> that you are talking securely to the security name in the IOR, not
NB> that the name in the IOR is the one you want to talk to.
NB> I understand how this works with the Kerberos and CSI-ECMA
NB> mechanisms, but I'm not sure how/if it's different with SSL. I see
NB> the problem as fundamental (there's no provable link between an
NB> object reference and the security name), so there must be an
NB> equivalent weakness in SSL based CORBA systems, true?
Correct.
NB> As E.6.2 says, the onus is on the client to check the security
NB> name(s) of any target it intends to use, unless it has a trusted
NB> source of object references.
The addition of this check 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.
AS> If you're concerned about authentication, your DNS lookup was not
AS> secure and it would give you confidence you were talking to the
AS> right name server.
NB> We went round the houses discussing the issue about security of
NB> name services (but based on a CSI-ECMA protocol). In the end, we
NB> decided that a CORBA name service (actually our Trader service)
NB> couldn't sensibly be (CORBA) secured. It came down to bootstrap
NB> problems, such as not being able to secure the connection to the
NB> Trader to get trustworthy object references for the Authentication
NB> and Privilege (logon) services until you'd already logged on etc.
NB> I realise an SSL based scheme might well be different in this
NB> respect, since an SSL client is more autonomous (not requiring the
NB> services of external objects in order to obtain Credentials,
NB> true?). But I'm not really sure about this... hence the question.
Since the act of 'logging on' with a public key based credential is
something along the lines of instantiating a local credential object
with your certificate and private key from local storage/hardware, the
bootstrap issue is easier.
AS> On the otherhand, the client could have a list of trust points
AS> (certificates) to compare the identity presented by servers
AS> against, and a rogue name service will not be able to direct you
AS> to a rogue target.
NB> This is my point: I think that's not just an option, but a
NB> *requirement* on clients, unless they can otherwise obtain a
NB> secure source of object references. Clients that don't do this can
NB> assume nothing about the true identity of the target - eg. whether
NB> data returned is trustworthy, or whether effects they believe they
NB> have produced have actually occurred. And this is true *even* if
NB> they turn on EstablishTrustInTarget, which is particularly
NB> frightening.
I guess we're in violent agreement on this.
NB> If this is true, I think the consequences should be made much more
NB> visible to application writers. For example, one consequence is
NB> that security *unaware* applications - those that can't call
NB> get_security_names and check them - *must* operate on a trusted
NB> source of object references, since they can't check security names
NB> for themselves.
I believe that a security unaware app *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.
-andre.
Nick Battle
> It's moved to D.6.2. [from E.6.2]
Ah good! That's one appendix nearer to someplace where people might
notice it.
> No, currently there are no SSL hints beyond the SSL component in the
> IOR.
You mean it just says "this is an SSL secured object" but says nothing
about what security name the target has? That sounds odd at first, but I
suppose it's no weaker than including untrustworthy hint information.
Are you saying the client just talks to whoever is at the other end,
regardless? What does get_security_names() return then?
(I promise I'll read the CORBA-SSL spec soon and stop wasting everyone's
time with my ignorance - but I just thought it was worth airing this
particular security issue publicly, since I don't think it's been
noticed by application developers, and as you confirmed it applies
equally to SSL secured systems).
> 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.
But this really just shifts the problem to the construction and
protection of the wallet of trust points, as you say yourself later. The
root problem is the same: the client needs a trusted source of trust
points, or has to verify each connection "personally" in some way.
You could store a wallet of trust with other "personal" trust items,
like the private key and CA certs and RLs I suppose. But in a relatively
dynamic system that becomes difficult to manage automatically. You could
tell all users that they were responsible for setting up their *own*
wallets, and that their security depended on it - but I can imagine the
complaints (and abuses) that would follow. Sounds like a PGP trust
model.
Perhaps it just needs an online service (with a well known security
name!) that would return signed certificates that link the interfaces
supported by a particular security name, or the security names that
implement a particular interface. That would at least be centrally
managable. It means extra overhead at invocation time, though
certificates could have a lifetime and be cached at the client. This
approach also says something subtle about trust being fixed and
domain-wide, whereas the personal wallet approach allows different users
to have different trust patterns (this isn't necessarily good or bad,
just different).
> Since the act of 'logging on' with a public key based credential is
> something along the lines of instantiating a local credential object
> with your certificate and private key from local storage/hardware, the
> bootstrap issue is easier.
Right, I thought that would/should be the case. It might therefore be
possible to construct workable systems with trusted and secured
name servers (ie. sources of trustworthy object references). I'm still a
bit confused though if you're saying IORs don't include SSL hint
information - if the hints are just obtained from the target (ie. it
identifies itself as part of the SSL connection anyway), then the source
of object references is irrelevant because they contain nothing that has
to be trusted(?)... so that leaves us with your wallet suggestion.
Perhaps that was your point?
> NB> And [they can't trust the target] *even* if
> NB> they turn on EstablishTrustInTarget, which is particularly
> NB> frightening.
>
> I guess we're in violent agreement on this.
So are we going to see commercial CORBA Security solutions that
implement trusted wallets or name-signing services? Or do you think it's
sufficient to leave the warning in D.6.2 and let the punters solve it
themselves?
(DAIS Security leaves it up to the application writers, though we do
check Trusted Identity Domain names (ie. security names) in our own
administration clients, since we can predict the TID names of our own
targets given the operation and the principal/policy domain name being
administered).
> I believe that a security unaware app *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.
OK, I agree that the wallet moves the problem so that security unaware
apps are still secure.
-nick
Steve Ganje
I'm using the corba that comes with java 1.2B3. We have just made an
application we would like to run off of netscape or Iexplorer, but found
out that this version of java isn't supported by the browsers yet. I
think the highest java currently supported is 1.1.6 . Does anybody know
of a possible way to get it to run on one of the browsers or do we just
have to wait until it becomes supported in later versions. We would use
the other java, but the program uses methods only supported in 1.2 .
Any help would be appreciated!
Thanks,
Steve
Bruno Coudoin
http://www.javasoft.com.
It works for IE and Netscape.
Charles S. Han
IE, but I was not able to get it to work for NC4.04 unless I removed the
iiop10.jar file included with NC4.04. As discussed at netscape.dev.corba, we
believe it is because NC4.04 downloads its own omg classes (Visigenic flavor)
and they are not overriden by anything, in this case the omg classes in the
plugin.
My impractical solution (as I have posted to this newsgroup already) is to ask
my users to replace the iiop10.jar file with my own version that is a
composite of the NC4.04 iiop10.jar and the omg and com class structure from
jdk1.2b2's classes.zip.
Please let me know if you had success in a different way and how you did it.
Thanks, Chuck
Charles S. Han
correctly access the plugin. However, I had to include the org.* classes in
my codebase--I had thought that these classes would be included in the plugin
since it is supposed to support jdk1.2. If anyone has similar or different
experiences, I'd like to know.
Steve Ganje
> Sorry, I did get it to work. I didn't correctly convert the HTML page to
> correctly access the plugin. However, I had to include the org.* classes in
> my codebase--I had thought that these classes would be included in the plugin
> since it is supposed to support jdk1.2. If anyone has similar or different
> experiences, I'd like to know.
>
> Chuck
You mentioned you didn't correctly convert the html page, how did you do
it? I have the plugin downloaded and I've also done an import on almost
all the things I can think of and the applet is always giving an error
when Netscape tries to load it--Can't start, Class not found, other times
it's class already loaded error. Every once in a while it also says
Security violation error. The HTML has the following code:
<applet width=450 height=550 code=FilerApplet.class>
</applet>
The imports in the actual code are:
import java.io.*;
import FileApp.*;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import java.awt.*;
import java.awt.event.*;
import java.awt.event.ActionListener;
import org.omg.CORBA.ORB;
In the java console in netscape it also says the following:
# Applet exception: class FilerApplet not found
java.lang.ClassNotFoundException: java/awt/event/ActionListener
at java.lang.ClassLoader.defineClass(ClassLoader.java)
at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java)
at netscape.applet.AppletClassLoader.findClass(AppletClassLoader.java)
at netscape.applet.AppletClassLoader.loadClass1(AppletClassLoader.java)
* at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java)
at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java)
at netscape.applet.DerivedAppletFrame.run(DerivedAppletFrame.java)
at java.lang.Thread.run(Thread.java)
If anyone has a clue, let me know. Thanks!
Steve