The common system security requirements

(1)

$FFHVVLQJ&25%$VHUYLFHVWKURXJKWKH:HE

IURPWKHVHFXUHFRUSRUDWHLQWUDQHWWRWKHVHFXUH HQFU\SWHGYLUWXDOFKDQQHOVRYHU,QWHUQHW

Telcordia Technologies Proprietary – Internal Use Only

This document contains proprietary information that shall be distributed, routed or made available only within Telcordia Technologies, except with written permission of Telcordia Technologies.

Telcordia Contact:

Francesco Caruso

[email protected] +1 (973) 829 4399

April 1999

An SAIC Company

Overview

ìThe need for security ìCORBA Security Service ìSecurity background ìSSL / Certificates ìSSL and the Web

ìCORBA Security Service Implementations ìSummary

(2)

Doc Name – 3 Telcordia Technologies Proprietary - Internal use only. See proprietary restrictions on title page.

The need for security

ìWithout security, these are the problems you might run into when sending sensitive information over a network:

–Eavesdropping, where your information remains intact, but its privacy is compromised. Some examples include someone spying on a private conversation, or intercepting classified information.

–Modification, where your original information is changed or replaced and then sent to the recipient, who is none the wiser. An example is someone altering an order for goods, or changing a person’s resume in route to the recipient.

–Impersonation, where your information passes to the recipient, but the recipient is an imposter.

–Unauthorized access, where an actor executes an operation not allowed.

The common system security requirements

ìAuthentication

–The action of determining the identity of the agent making or receiving a request for action or data.

ìAuthorization

–The action of determining whether the authenticated party requesting action or data is permitted to make the request.

ìPrivacy

–The action of ensuring that only the authorized recipient of data can view the received data.

(3)

The common system security requirements (cont.)

ìNon Repudiation

–prevent principals from falsely denying an action that it has in fact carried out.

ìAuditing

–The action of creating a historical record of requests for actions and/or data.

ìAdministration

–The action of creating authenticated agents

Security efforts

ìGSS-API (generic security services), defined by the CAT working group of the IETF (Internet Engineering Task Force).

–allows an application to integrate into network security systems like Kerberos 5 and SECUDE 5. It requires that the programs at both ends use the GSS-API (MIT calls this "kerberized") to secure their online

communications.

–http://www.ietf.org/ and ftp://ftp.internic.net/internet-drafts/draft-ietf-cat- gssv2-08.txt

ìDCE security

(4)

Object Management Group’s Security Service

ìOMG, CORBA Security Services Specification –v1.2 [formal/98-12-17]

–ftp://www.omg.org/pub/docs/formal/98-12-17.pdf

ìThe OMG CORBA standard specifies two levels of Security:

–Level one - addresses the basic requirements that enable the construction of secure systems.

–Level two - extends this capability with a variety of interfaces for specifying and managing security policies and domains.

CORBA Security Service Specification

ìAuthentication of users - authentication of principals, two-way where required.

ìAccess control of calls to a server e.g. using ACLs.

ìDelegation of a principal’s security credentials.

ìRecording of a security audit, so that administrators of a system have an audit of important calls.

ìProtection of messages on the network - encryption and other methods.

ìOptional feature: Non - repudiation - used to prevent a principal from falsely denying an action that it has in fact carried out.

(5)

CORBA Security levels

ìLevel 0 (this is not an approved OMG term):

–provision of the security basic mechanisms.

ìLevel 1:

–Supports clients and servers that are not aware of the Security Service.

ìLevel 2:

–Supports clients and servers that are aware of the Security Service.

CORBA Security level 1

–Specifies mechanisms for all the Generic Security Services (GSS)-API - like functions, and also for authorization of clients to servers for specific sets of operations.

–Non-repudiation, the prevention of disownment of transactions by mischievous clients. (optional )

–Authentication of principals (may be outside of the ORB)

–Secure invocation between client and server which includes: establishing trust, sealing messages (using encryption), and access control (e.g., using ACLs)

–Delegate incoming credentials (simple delegation)

(6)

CORBA Security level 2

ìSupports clients and servers that are aware of the Security Service.

–Provides application developers and administrators with additional interfaces to secure the application. Using the interfaces, the end-user credentials are made visible to the applications objects.

–The application is able to make access decisions regarding the end-user and the specified object.

–The use of these interfaces is not mandatory but offers the greatest security control

–Adds a number of interfaces for policy and policy domain management.

Policies are not necessarily limited to software, they include details of how individuals (principals) are authorized, where secure equipment is physically stored etc.

–The implementation of the Security Service hides the use of any particular security technology

CORBA Security level 0

ìWith the growing use of Secure Sockets Layer (SSL) technology for web authentication and privacy, organizations wanted to make use of this widely available technology.

ìWhile not officially defined by the OMG this is known as CORBA Security Level 0.

ìSSL is currently being considered by the OMG.

ìSSL features employed with CORBA Security Level 0 include:

–Mutual authentication via public key.

–Data Privacy & integrity using SSL channel encryption.

(7)

What is available today

ìMost of the ORB vendors (Inprise, Iona, etc.) provide at least Level 0.

ìThird party companies provide frameworks to support Level 1 & 2 –AccessMaster from BULL (http://openmaster.us.bull.com/)

ìsecure authentication and network encryption to client / server applications and mail applications based on open systems standards: the GSS-API interfaces and the DCE Kerberos and SESAME public key technologies. (Level 1?)

–DASCOM Intraverse (http://www.dascom.com/)

ìIntraverse gives the ability to secure and manage the Inprise VisiBroker™ family of object request brokers. (Level 2)

–Gradient (http://www.gradient.com/Products/products.htm#NetC) ìOrbixSecurity, based on PC-DCE (2Q 1997) based on DCE and Kerberos (level 1

only Orbix).

ìNetCrusader™/CORBA (Level 2 Orbix/VisiBroker)

Security background

ìSymmetric Encryption and Decryption ìAsymmetric Encryption and Decryption ìCryptographic Hash

ìDigital Signature

ìCommon cryptography Algorithms

(8)

Symmetric Encryption and Decryption

this is a msg, ...

Encrypt

Klkdw;refef

Decrypt Key this is a msg,

...

Klkdw;refef

Asymmetric Encryption and Decryption Private Key this is a msg,

...

Encrypt

Klkdw;refef

Decrypt this is a msg,

...

Klkdw;refef

Public Key

(9)

Cryptographic Hash

ìFixed length output (16 or 20 bytes) –One way

–Extremely hard to modify original document and keep hash constant

this is a msg, ...

Hash Klkdw;refef

Digital Signature

ìSign - Hash original and encrypt with signer’s private key ìVerify - Hash original document, decrypt signature with signer’s

public key, and compare

this is a msg, ...

Hash Klkdw;refef Encrypt sdf;,se;lflf

(10)

Common cryptography Algorithms

ìSymmetric Algorithms –DES, RC4, RC5 ìAsymmetric Algorithms

–RSA

ìCryptographic Hash Algorithms –MD5, SHA

ìDigital Signature Algorithms –DSA (DSS), RSA

Level 0 - Netscape SSL

ìCORBA SSL stack

ìAuthentication in SSL (RSA) ìThe SSL Handshake protocol ìSSL features

(11)

CORBA SSL stack

Client Application Code

ORB Core

IIOP

SSL

TCP/IP IDL Stub DII

Code

Serv er Application Code

ORB Core

IIOP

SSL

TCP/IP IDL Skeleton DSI

Code

The SSL Handshake protocol

(12)

SSL features:

ìConfidentiality is ensured through encryption, the process of disguising information so that it can’t be deciphered (or decrypted) by anyone other than the intended recipient. The information can still be intercepted, but it will be unreadable to third parties.

ìData integrity verifies that the data sent between client and server wasn’t altered during transfer. If the message does not decrypt correctly, the recipient can tell that someone has tampered with the message.

ìAuthentication is provided through authenticity certificates, which are very difficult to falsify. You purchase or otherwise receive a certificate from a third party whom both parties already trust. In this way, the certificate acts as a sort of digital passport.

Privacy of SSL Communications

ìImmediately after authentication, an SSL client application sends an encoded data value to the server. This unique session encoded value is a key to a symmetric cryptographic algorithm.

ìThe client picks a cipher (the stronger) from the server Cipher suite and notify the server.

ìUS law requires max 40-bit encryption for exported connections.

ìThe cipher choice is a trade-off between security and performance.

(13)

Common SSL 3.0 ciphers (non exportable)

–Triple DES with 168-bit encryption and SHA message authentication.

ìThis cipher is the same as the SSL 2.0 version of Triple DES with 168-bit encryption, but uses SHA (Secure Hash Algorithm) message authentication instead of MD5 message authentication. SHA is a government standardized algorithm that is used to construct a message authentication code that detects attempts to modify data while it is in transit. SHA is slower than MD5, but it is stronger.

–DES with 56-bit encryption and SHA message authentication.

ìThis cipher is the same as the SSL 2.0 version of DES with 56-bit encryption but uses SHA message authentication instead of MD5 message authentication.

–RC4 with 128-bit encryption and MD5 message authentication.

ìThis cipher is the same as the SSL 2.0 version of RC4 with 128-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.

Common SSL 3.0 ciphers (exportable < 40 bits)

–DES with 40-bit encryption and SHA message authentication.

ìThis cipher is the same as the SSL 2.0 version of DES with 40-bit encryption but uses SHA message authentication instead of MD5 message authentication.

ìThis cipher is the same as the SSL 2.0 version of RC4 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect attempts to modify data in transit.

ìThis cipher is the same as the SSL 2.0 version of RC2 with 40-bit encryption but uses a more secure implementation of MD5 message authentication to detect

(14)

Integrity of SSL Communications

ìTo detect if an application has received data modified by an

intermediary, SSL adds a message authentication code (MAC) to each message. This code is computed by applying a function to the message content and the secret key used in the symmetric cryptographic algorithm.

ìAn intermediary cannot fake the MAC for a message without knowing the secret key used to encrypt it. If the message is corrupted during transmission, the message content will not match the MAC. SSL automatically detects this error and rejects corrupted messages.

Principal Identity Authentication

ìSSL handshake will exchange Public keys and challenge the server.

ìIf the client is able to decode with the public key, data coded by the server, the server must be the owner of the related private key.

ìWe still may need to verify the identity of the server in order to proceed with further access control.

ìCertificate relate a public key to an identity

–Sig. Mario Rossi, PK=12312312312312331243124124124124412 –Telcordia Web Server, PK=2345 234 234 234 234 234554 234 54 –etc …

(15)

X.509 Certificate.

private

Owner’s public key

public

C=US, O=Rossi, CN=Paolo

Expires: 7/10/2010

Public Key:

Signed: Issuer’s Signature

Serial #: 2794893756

Other Data:

10236288300257273 Other data

Expiration date and validation.

Owner

Issuer

MD5

Private Key Encryption (Digital Signature)

X.509 Certificate chain

ìInternational Telecommunications Union (ITU) recommendation X.509 defines a standard format for certificates.

ìThe name of the entity identified by the certificate.

ìThe public key of the entity.

ìThe name of the certification authority that issued the certificate.

ìOther data transmitted in an X.509 certificate is not significant in the context of this overview of SSL authentication.

ìSignature

Certificate Authority

(16)

Certification Authorities

ìThe role of a certificate is to match an entity name to a public key. A certification authority is a trusted authority that verifies the validity of the combination of entity name and public key in a certificate.

ìSite policies that use SSL authentication must specify the certification authorities from which they accept certificates.

ìYou must choose a CA to sign certificates for your applications.

–A commercial CA is a company that signs certificates for many systems.

–A private CA is a trusted node that you set up and use to sign certificates for your system only.

Commercial Certification Authorities

–Signing certificates with a commercial CA often involves less initial expenditure on resources than using a private CA. Consequently, some organizations use commercial CAs to sign applications that are only available on internal networks.

– Before choosing a commercial CA, compare the certificate signing policies of several and, if your applications are designed to be available on an internal network only, review the potential costs of setting up a private CA.

–An advantage of commercial CAs is that they are often trusted by a large number of people.

–If your applications are designed to be available to systems external to your organization then use a commercial CA to sign your certificates.

–The mechanism for signing a certificate using a commercial CA depends

(17)

Most common commercial CAs

(https://certs.netscape.com/client.html)

–VeriSign - is the leading provider of digital authentication products and services. The first commercial CA,

–Thawte Consulting - Thawte has representatives in 20 countries, providing first-class local support and service.

–Società per i Servizi Bancari - SSB S.p.A. The Trusted Certification Authority. SSB provides highly secured X.509 v1 v3 certificates on behalf of banks for Internet clients and servers, financial services, and electronic commerce.

–Internet Publishing Services - IPS provides server, client, and object- signing certificates based on SSL standards.

–Certisign Certification Digital Ltda.

–BelSign International, with local registration offices across Europe.

Private Certification Authorities

ìIf you wish to take responsibility for signing certificates for your system, set up a private CA.

ìThis is feasible in a large intranet (single domain application).

ìIt may be less expensive solution in a large company.

(18)

How to setup a private CA

ìSeveral packages that provide utilities for creating and signing certificates are available:

–SSLeay - a free implementation of SSL developed by Eric Young of CryptSoft Pty. Ltd (available at http://www.cryptsoft.com/) ìRequired steps for SSLeay:

–Choose a suitable host to act as CA. (secure hosts!) –Install SSLeay on the CA host.

–Use the SSLeay utilities to create a certificate and private key for the CA.

–Copy the CA certificate and private key to the required directories on the CA host.

–When you complete these steps, you can use the SSL utilities to sign application certificates for your system.

Using SSL in a CORBA client/Server architecture

Java/C++ Client

Java/C++ Server

Java/C++ Server IIOP

IIOP SSL

(19)

SSL products: IONA OrbixSSL

ìOrbixSSL provides a complete development and deployment package for developing C++ and Java based applications.

ìStrong encryption (128 bit) which can be provided worldwide.

ìOrbixSSL allows Orbix and OrbixWeb based applications to be easily retro-fitted or newly developed using SSL security.

ìOrbixSSL replaces the default IIOP protocol with the standardized SSL-IIOP protocol (IIOP over secure SSL connections).

OrbixSSL features

ìWorldwide 128 bit encryption ìC++ development support ìJava development support ìCertificate Authority utilities ìX.509 certificate generation utilities ìPrivate key generation

ìCertificate signing

(20)

SSL products: Inprise Visibroker SSL

ìVisibroker SSL feature uses the industry-standard Secure Socket Layer Version 3 (SSL3.0) protocol to establish secure connections between clients and servers (peers in SSL terminology).

ìThe Visibroker SSL feature is mostly invisible to developers.

–An existing client or server can be instrumented to use SSL by adding a few lines of initialization code (interceptors). Client code that invokes methods and server code that implements methods are not affected by the presence or absence of SSL.

ìSSL is also complementary to threads and other Visibroker facilities.

–choosing security does not mean giving up something else.

SSL performance implications

ìSecure connections are slightly slower than ordinary ones.

–When using Visibroker SSL, there is a one-time per-connection cost of a few extra messages for establishing a secure connection.

–All invocations by a client to a particular server, possibly to multiple objects implemented by that server, are conducted over a single connection.

– Invocations over a secure connection take a little longer because requests and replies are encrypted and decrypted.

(21)

SSL Performance results Solaris

Relative Performance (Solaris)

0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50

test_bind() - 0 bytes test_no_param() - 0 bytes test_prim_args() - 2500 bytes test_struct() - 2500 bytes test_prim_seq() - 250000 bytes test_struct_seq() - 250000 bytes test_prim_args() - 10000 bytes test_struct_args() - 10000 bytes test_prim_seq() - 1000000 bytes test_struct_seq() - 1000000 bytes test_struct_array() - 1000000 bytes

One-way authentication Two-way authentication

Secure Web Applications

Corporate Firewall

Enterprise App.

Server Internet Client

HTML client

Web Server CGI Script

HTTP Not Permitted

CorporateIntranet

Sockets, RPC, etc.

(22)

SSL and the Web

Corporate Firewall

CORBA App.

Server

Database and other servers Internet Client

CORBA/Java- enabled client

Web Server HTTP

Visigenic Gatekeeper

Not Permitted Corporate Enterprise

IIOP with SSL

CORBA Security Service Implementations (Levels 1 & 2)

ìThis section describes some of the commercially available implementations of the CORBA Security Service.

ìFeatures added from Level 0:

–Access control –Delegation –Auditing

(23)

OrbixSecurity Iona Technologies (Level 1)

ìSupport for ’single sign-on’ of users.

ìAllows applications to be made security aware without any API changes.

ìSupports the five prime security features:

–Encryption –Authentication –Authorization –Delegation –Auditing & logging

ìSupport for multiple security environments and platform coverage.

ìReplaceable security components for maximum flexibility

OrbixSecurity introduction

ìOrbixSecurity leverages both Kerberos and DCE security services.

ìEach principal uses its credentials set to log into the domain and gain secure (encrypted) access to services.

ìAuthentication of principals ensures that its claimed identities are correct.

ìPrincipals must have permission to perform operations. This is handled by the access control mechanism, which contains the

permission for each principal and ensures that these are followed. This allows applications to be protected and accessed only by the intended

(24)

OrbixSecurity introduction (cont.)

Access control

Principal (user or system) Server-s ide

Delegation

Credentials Authentication

Auditing &

Logging

Intraverse Availability & Performance

ìDASCOM (www.dascom.com) is a company that provides network security management products like IntraVerse and NetSEAT ìIntraVerse provides a complete authorization solution for corporate

Web, client/server, and legacy applications for both Visibroker and Orbix.

ìCapable of using both public key authentication such as SSL and symmetric key authentication to provide authorization for Web-based services.

ìMakes authorization available to all applications via its Auth-API.

ìCentralized management of Web resources and applications,

(25)

IntraVerse network security manag. sys features:

–Can authenticate public or private key (can mix & match), e.g., DCE RPC, GSS API, SSL v3

–Allows single sign-on either through the system (e.g. at login) or through the Web –High availability — can replicate servers

–High performance — through local caching of ACLs.

–Supports simple delegation (multi-tier authorization) –Flexible authorization framework

–Coarse or fine-grained –Role based

–Controllable through a simple GUI –Extensible — can define new permission

IntraVerse Support for Availability and Performance

Hierarchical Namespace

Application Master Policy

Service Managem ent

Console

Replication Cache

(26)

Intraverse transparent AC architecture

Intraverse explicit AC architecture

CORBA Client

Interceptor authentication

integrity

Infrastructure Services Authentication Service Authorization Service

Interceptor authentication

integrity

Security Context Security Context

DCE/Kerberos PKI - X.509

CORBA Server

DCE/Kerberos PKI - X.509 Privilege Service

ACL DB ACL Manager

X.509 = PAC Mapping

permitted (yes/no)

display GUI choice list item ? transfer > 3 MM$ ?

(27)

Summary

ìThe performance of the benchmark application with SSL varies between the platforms used in this study.

–The performance is approximately 2.0 to 3.0 times slower on the Window NT platform (Pentium 233 MHz), and 2.0 to 4.0 times slower on Solaris (Sparc 10).

ìThe results seem to suggest a higher performance hardware platform would produce relative performance values closer to 2.0, as well as values that are relatively unaffected by the amount of data passed between the client and server.

References

–http://www.consensus.com/security

–http://www.netscape.com/info/security-doc.html –http://www.rsa.com

–For more information on certificates and how to obtain them, see Appendix I and/or the web pages of certificate authorities such as VeriSign <http://www.verisign.com>.

–Iona Technologies, Orbix Security White Paper, 1997,

http://www.iona.com/support/whitepapers/orbixsecurity/index.html.

–OMG, CORBA Security Services Specification, November 1996, http://www.omg.org/corba/sectrans.htm#sec.

–Iona Technologies, OrbixSSL Programmer’s and Administrator’s Guide, December 1997, http://www.iona.com/

–Visigenic, Visigenic SSL Pack Programmer’s Guide, Version 3.0, September 1997, http://www.inprise.com/

(28)

Extra slides

Prerequisites for Using Visibroker SSL

ìYou need very little knowledge of SSL to use Visibroker SSL:

–Most of the work is done “under the covers” by the Visibroker code.

–If you are writing a server, or a client that authenticates itself, you must understand and obtain your certificate chain and private key.

–If you are writing a client or server that inspects the certificates sent by a peer, you must understand the syntax and semantics of certificate chains and you must hold (in your program or a file) the certificate chain and private key.

(29)

How to Use Visibroker SSL

ìClients and servers use the Visibroker SSL APIs almost identically.

–a certificate chain is required for a servers and optional for clients.

ìFor both clients and servers, the SSL interfaces are generally used only for initialization.

ìThe core client or server code is the same whether SSL is in force or not.

How to Use Visibroker SSL (cont.)

ìThe procedure for using Visibroker SSL is summarized as follows:

–Set an ORB property specifying that your code uses Visibroker SSL and initialize the ORB as usual.

–If a server, get an instance of SSL::CertificateManager, initialize it with a certificate chain and arguments describing properties of the SSL

connections that are to be made. Clients that authenticate themselves to servers do the same.

–If a client, bind to a server as usual; this creates an SSL connection instead of an ordinary one. Servers do not take any explicit action to create SSL connections.

(30)

SSL details: Sever

// Create a property list specifying ssl

java.util.Properties props = new java.util.Properties();

props.put("ORBservices", "com.visigenic.vbroker.ssl");

props.put("OAid", "SSLTPool");

// Initialize the ORB.

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props);

// Get the certificate manager from the initial references.

try {

manager = CertificateManagerHelper.narrow(

orb.resolve_initial_references("SSLCertificateManager"));

}

catch(InvalidName e) {

System.err.println("/nSSLCertificateManager could not be found.");

}

// Set my certificate chain, ordered from user to CA.

byte[] testCert = testCert_base64.getBytes( );

byte[] caCert = caCert_base64.getBytes( );

byte[][] certificates = { testCert, caCert };

manager.setCertificateChain(certificates);

// Set the private key.

byte[] encryptedPrivateKey = encryptedPrivateKey_base64.getBytes( );

manager.setEncryptedPrivateKey(encryptedPrivateKe y, "@borland");

// Request client certificate manager.requestClientCertificate( );

SSL details: Client

// Create a property list specifying ssl

java.util.Properties props = new java.util.Properties();

props.put("ORBservices", "com.visigenic.vbroker.ssl");

// Initialize the ORB.

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props);

// Get the certificate manager from the initial references.

try {

manager = CertificateManagerHelper.narrow(

orb.resolve_initial_references("SSLCertificateManager"));

}

System.err.println("SSLCertificateManager could not be found: " + e);

System.exit(-1);

// Set the certificate chain. Order: user, ..., CA byte[][] certificates = {

testCert_base64.getBytes(), caCert_base64.getBytes() };

manager.setCertificateChain(certificates);

// Set the private key.

byte[] encryptedPrivateKey = encryptedPrivateKey_base64.getBytes();

manager.setEncryptedPrivateKey(encryptedPrivate Key, "@borland");

(31)

SSL details: The Current interface

try {

com.visigenic.vbroker.ssl.Current current = com.visigenic.vbroker.ssl.CurrentHelper.narrow (_orb().resolve_initial_references("SSLCurrent"));

System.out.println("Negotiated Cipher: " + CipherSuite.toString(current.getNegotiatedCipher(this)));

System.out.println("Protocol Version: " + current.getProtocolVersion(this));

System.out.println("Peer’s certificate: " + current.getPeerCertificateChain(this));

}

System.err.println("Could not check peer’s certificate: " + e);

}

The common system security requirements

$FFHVVLQJ&25%$VHUYLFHVWKURXJKWKH:HE

Overview

The need for security

The common system security requirements

The common system security requirements (cont.)

Security efforts

Object Management Group’s Security Service

CORBA Security Service Specification

CORBA Security levels

CORBA Security level 1

CORBA Security level 2

CORBA Security level 0

What is available today

Security background

Symmetric Encryption and Decryption

this is a msg, ...

Encrypt

Klkdw;refef

Decrypt Key this is a msg,

...

Klkdw;refef

Asymmetric Encryption and Decryption Private Key this is a msg,

...

Encrypt

Klkdw;refef

Decrypt this is a msg,

...

Klkdw;refef

Public Key

Cryptographic Hash

this is a msg, ...

Hash Klkdw;refef

Digital Signature

this is a msg, ...

Hash Klkdw;refef Encrypt sdf;,se;lflf

Common cryptography Algorithms

Level 0 - Netscape SSL

CORBA SSL stack

The SSL Handshake protocol

SSL features:

Privacy of SSL Communications

Common SSL 3.0 ciphers (non exportable)

Common SSL 3.0 ciphers (exportable < 40 bits)

Integrity of SSL Communications

Principal Identity Authentication

X.509 Certificate.

X.509 Certificate chain

Certification Authorities

Commercial Certification Authorities

Most common commercial CAs

(https://certs.netscape.com/client.html)

Private Certification Authorities

How to setup a private CA

Using SSL in a CORBA client/Server architecture

SSL products: IONA OrbixSSL

OrbixSSL features

SSL products: Inprise Visibroker SSL

SSL performance implications

SSL Performance results Solaris

Secure Web Applications

SSL and the Web

CORBA Security Service Implementations (Levels 1 & 2)

OrbixSecurity Iona Technologies (Level 1)

OrbixSecurity introduction

OrbixSecurity introduction (cont.)

Intraverse Availability & Performance

IntraVerse network security manag. sys features:

IntraVerse Support for Availability and Performance

Intraverse transparent AC architecture

Intraverse explicit AC architecture

Summary

References

Extra slides

Prerequisites for Using Visibroker SSL

How to Use Visibroker SSL

How to Use Visibroker SSL (cont.)

SSL details: Sever

SSL details: Client

SSL details: The Current interface

$FFHVVLQJ&25%$VHUYLFHVWKURXJKWKH:HE