[go: up one dir, main page]

Menu

#10 SSL handshake does not require mutual authentication

open
nobody
CORBA (3)
5
2004-01-06
2003-05-02
No

Currently, Security Server and Security Manager use SSL
to communicate with each other, but in DSI we need
mutual authentication of "client" and "server"... which
is not the default behaviour in SSL.
Unfortunately, OmniORB does not offer an easy interface
to request this.
We should investigate with omniORB guys to see how to
achieve this.
Hints:
- Use SSL_set_verify and SSL_CTX_set_verify with
SSL_VERIFY_FAIL_IF_NO_PEER_CERT +
SSL_VERIFY_CLIENT_ONCE + SSL_VERIFY_PEER.
- set SSL_CTX_set_verify_depth to 3 ?
- use omniORB's ../orbcore/ssl/sslContext.cc interface
(sslContext.h)

Axelle.

Discussion

  • Axelle Apvrille

    Axelle Apvrille - 2003-09-05

    Logged In: YES
    user_id=204539

    Hi all,

    Just to let you know about the problem with DSI's SSL
    channels. In DSI,
    we want Security Server and Security Managers to
    communicate on secure
    authenticated channels, using SSL. Unfortunately, we had
    noticed that
    all our events were communicated in cleartext... because
    omniEvents
    2.1.2 does not support SSL yet.

    I include at the end of this mail a very quick fix to make
    omniEvents
    support SSL. This is only a quick fix as the SSL CA and key
    files are
    hardcoded, but if you need to get it work quickly, there it
    is. I've
    been talking with the guy responsible for omniEvents. He's
    been very
    helpful actually, and I suppose he'll be integrating this
    fix as soon as
    he can (he's got to make it cleaner for a release).

    With this fix, and the latest sources of DSI, it's now
    possible to get
    SS and SMs communicate through SSL only.
    There's still another problem to solve: by default SSL only
    authenticates the server side. This is how the SSL
    connections have been
    implemented in OmniORB. But, for DSI, we want the
    authentication to be
    set on both sides (otherwise, we're not totally sure of the
    consumer's
    identity). I'm working on this with the omniORB's mailing-list.

    Regards,
    Axelle.

    [lmcaxpr@glacier lmcaxpr]$ diff omniEvents.cc
    /usr/local/omni/src/contrib/omniEvents/src/omniEvents.cc
    34a35,44
    > Revision 1.1.1.1.2.1 2002/09/28 22:20:51 shamus13
    > Added ifdefs to enable omniEvents to compile
    > with both omniORB3 and omniORB4. If __OMNIORB4__
    > is defined during compilation, omniORB4 headers
    > and command line option syntax is used, otherwise
    > fall back to omniORB3 style.
    >
    > Revision 1.1.1.1 2002/09/25 19:00:34 shamus13
    > Import of OmniEvents source tree from release 2.1.1
    >
    83a94,95
    > #include <omniORB4/sslContext.h>
    > #include <sys/stat.h>
    146,148d157
    < argv[1] = strdup("-endpoint");
    < argv[2] = new char[32 + 1];
    < sprintf(argv[2], "%d", port);
    151a161,182
    > sslContext::certificate_authority_file =
    "/etc/dsi/dsi_root.pem";
    > sslContext::key_file = "/etc/dsi/dsi_server.pem";
    > sslContext::key_file_password = "password";
    >
    > struct stat sb;
    > if (stat(sslContext::certificate_authority_file,&sb) <
    0) {
    > cerr << "Cannot open certificate file: "
    > << sslContext::certificate_authority_file << endl;
    > return 1;
    > }
    > if (stat(sslContext::key_file,&sb) < 0) {
    > cerr << "Cannot open key file"
    > << sslContext::key_file << endl;
    > return 1;
    > }
    >
    > #ifdef __OMNIORB4__
    > argv[1] = strdup("-ORBendPoint");
    > argv[2] = new char[32 + 1];
    > // sprintf(argv[2], "giop:::%d", port);
    > sprintf(argv[2],"giop:ssl::%d",port);
    >
    153a185,194
    > #else
    > argv[1] = strdup("-BOAiiop_port");
    > argv[2] = new char[32 + 1];
    > sprintf(argv[2], "%d", port);
    >
    > CORBA::ORB_ptr orb =
    CORBA::ORB_init(argc,argv,"omniORB3");
    > CORBA::BOA_ptr boa =
    orb->BOA_init(argc,argv,"omniORB3_BOA");
    > #endif
    > argv[2] = new char[32 + 1];
    > sprintf(argv[2], "%d", port);

     
  • Axelle Apvrille

    Axelle Apvrille - 2004-01-06
    • assigned_to: axellec --> nobody
     
  • Axelle Apvrille

    Axelle Apvrille - 2004-01-06

    Logged In: YES
    user_id=204539

    This is not solved yet (I haven't had time to work on it). Note
    it is rather important on a security point of view for DSI.

     

Log in to post a comment.