Secure CORBA and omniORB Implementation with TLS Configuration
Implementing secure communication in CORBA and omniORB using TLS ensures encrypted data transfer and authenticity through certificates and Certificate Authorities. Learn about configuring SSL transports, SSL endpoints, object references, and using OpenSSL for secure connections.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
CORBA and omniORB with TLS Duncan Grisby
omniORB transports omniORB supports multiple network transports giop:tcp classic standard GIOP over TCP giop:ssl standard TLS giop:unix omniORB specific Unix domain sockets giop:http omniORB specific HTTP(S) Choose the ssl transport with the endPoint parameter: -ORBendPoint giop:ssl:[hostname]:[port]
Object references and corbaloc URIs CORBA object references (IORs) automatically include SSL endpoints corbaloc URIs can use the ssliop scheme: corbaloc:ssliop:1.2@hostname/key (not part of the CORBA standard, but widely supported)
Certificates and Certificate Authorities TLS clients and servers can have Certificates Certificates are signed by a Certificate Authority (CA) On the web, normally only the server has a certificate Server certificate is signed by a public CA Browsers trust the public CAs In CORBA, by default, both ends need a signed certificate Usually use a private CA
Certificates and Certificate Authorities Simple configuration: Provide one CA certificate file ca.pem Provide one key file containing private key and certificate Choice: one key per process, or one shared key? Alternative: Explicitly configure connections Make a single-use CA for each configured connection See omniORB documentation for example CA commands
omni::sslContext A singleton object used to configure use of OpenSSL Default implementation covers most use cases Subclasses can override many things See include/omniORB4/sslContext.h Simple case: set static members: certificate_authority_file key_file key_file_password verify_mode (integer bitfield from OpenSSL headers)
Configuration parameters Alternative: configuration parameters sslCAFile sslKeyFile sslKeyPassword sslVerifyMode (string, e.g. peer,fail ) See sample.cfg
omniORB transport rules clientTransportRule how clients should connect serverTransportRule which connections servers should accept <IP range or *> unix,tcp,ssl,bidir e.g. to use unencrypted communication in local network but TLS elsewhere: 10.1.2.0/24 unix,tcp * ssl
Advanced configuration sslContext::verify_mode_incoming sslVerifyModeIncoming Provide a different verify mode for incoming (server) connections sslContext::certificate_authority_path sslCAPath Place multiple CA certificates in a hashed directory structure sslAcceptTimeout How long a server will wait for the TLS handshake to complete
Very advanced configuration omni::sslContext::PeerDetails Interceptors can access certificate, verification status, SSL object Verify callback Allows you to override certificate verification See SSL_CTX_set_verify Info callback Provides information about TLS handshakes See SSL_CTX_set_info_callback
