Copyright © Cloud Software Group, Inc. All Rights Reserved

Security Features

Rendezvous connection security is based on Transport Layer Security (TLS) protocols. This affects three areas of communication:

•	Client to daemon—see Secure Client Connections

•	Between routing daemon neighbors—both rvrd and rvsrd offer this feature.

•	Browser to daemon—based on HTTPS protocols.

 

Additional Security Tools

These three areas do not include access control nor program-level encryption. For flexible access control facilities and an encryption API, use the companion product, TIBCO Rendezvous DataSecurity.

Certificates

X.509 certificates are crucial to these security features. For details, see Certificates and Security.

Performance

In all three of the communication areas listed above, security features require encryption and decryption computations. In general, these cryptographic computations detract from performance (compared to ordinary, non-secure daemons) for the sake of security.

 

Cryptographic computations require a pool of random data. Some operating systems maintain a random pool, and others do not. On operating systems that do not, each process must initialize its own random pool, which can cause delays as the program starts. You might observe such a delay when starting a secure daemon, or any application program that connects to a secure daemon.

Secure Client Connections

The two secure daemons—rvsd and rvsrd—feature TLS for secure connections to client program transports:

•	rvsd, the Rendezvous secure communications daemon, corresponds to rvd

•	rvsrd, the Rendezvous secure routing daemon, corresponds to rvrd

 

Administrators can deploy these secure daemons in situations where clients must connect securely over a non-secure network.

For an API summary, see Secure Daemon.

For administrative details, see Chapter 5, Secure Daemons (rvsd and rvsrd) in TIBCO Rendezvous Administration.

Certificates and Security

A certificate is a structured string of bytes that uniquely represents a specific identity. The structure of those bytes is determined by the X.509 identity certificate specification. A trusted certificate authority (CA) issues a certificate only to entities that meet its identification criteria (which may vary).

Certificates also play an important role in TLS and HTTPS secure communication protocols.

Rendezvous software uses certificates in four ways:

•	Secure daemon components authenticate user programs.

•	User programs authenticate secure daemons.

•	Routing daemons authenticate other routing daemons (neighbors) when they communicate using TLS protocols.

•	Web browsers authenticate Rendezvous daemon components when they communicate using HTTPS protocols.

See Also

For more details, see Security Factors in TIBCO Rendezvous Administration.

Certificate Encodings and Formats

When a certificate contains a private key, programs and file standards safeguard the key using password encryption. To use a certificate with a private key, a user must also have the private key password.

PEM Encoding

Rendezvous software supports PEM encoding of X.509 certificates. PEM encoding is a text format, so you can distribute certificates easily.

PKCS #12 Format

Rendezvous software supports PKCS #12 format for X.509 certificates. PKCS #12 encoding is a binary format. PKCS #12 data files usually bear the .p12 or .pfx filename extensions.

Obtaining Certificates

Automatic Certificates

For ease of use, Rendezvous daemon components automatically generate their own self-signed certificates. You may use these certificates by copying them from the daemon’s browser administration interface, and distributing them to client programs, and to routing daemon neighbors as appropriate.

Self-signed certificates usually trigger a warning from web browsers. When connecting to the browser administration interface of a Rendezvous daemon component, you may safely proceed beyond these warnings when you have independently verified the identity of the daemon. To avoid these warnings, replace the automatic certificate with a certificate signed by a reliable commercial CA.

Using a Commercial CA Service

Each CA has its own policies and procedures for investigating identities and issuing certificates. Details are readily available through CA web sites, such as www.verisign.com.

When applying for a certificate, specify that you need these two files in either PKCS #12 binary format, or PEM text encoding:

•	Public certificate

•	Certificate with private key

CA Software

In some situations, application administrators prefer to act as an in-house CA, issuing identity certificates to users. CA software is available from companies such as Netscape and Microsoft. Shareware is also available, including the OpenSSL package.

Browsers

Many CA services and CA software programs can automatically install certificates in your browser. Many browsers can export certificates in PKCS #12 format (as .p12 files).

Distributing Certificates

An X.509 certificate actually comprises two separate but interrelated certificate texts—a public certificate and a certificate with private key. To effectively use certificates, you must securely distribute the two texts to the appropriate places.

•

A certificate with a private key proves the identity of the key holder. Each Rendezvous daemon process proves its identity this way. In some deployments, end users of client programs also identify themselves this way (while in other deployments, they prove their identities with user names and passwords).

•	Public certificates denote the identity of a trusted party. You must distribute the public certificate text to all other programs that interact with that party.

Copyright © Cloud Software Group, Inc. All Rights Reserved