SSL Encryption

Question 1: What is SS- based 40-128 bit security? How does it use Digital Certificates? Do I need SSL?

FioranoMQ supports 40 to128-bit encryption of data. FioranoMQ is configured to provide more than 40-bit encryption in the United States only.

Question 2: Does Fiorano provide support for content-based encryption?

FioranoMQ does not provide toolkits for encryption, neither does it interpret the contents of the message. As a result, the developer can use any encryption technology to encrypt the message.

Ciphersuites

Question 3: What is a ciphersuite?

A ciphersuite is a collection of cryptographic algorithms and is used in conjunction with an SSL connection. Algorithms in a ciphersuite consist of:

• A key exchange algorithm: Diffie-Helmman or RSA
• A certificate format: Digital Signature Standard (DSS) or RSA
• A symmetric encryption algorithm: DES, RC4, RC2, IDEA, and NULL
• The mode that the encryption algorithm is used in: Cipher Block Chaining (CBC), Encrypt-Decrypt-Encrypt (EDE)
• A message digest or hash algorithm: MD5 or SHA

Question 4: How are ciphersuites selected for use in an SSL connection?

The FioranoMQ server has a set of acceptable ciphersuites. They can be controlled using the set ServerCipherSuites() method in the SSLParams context object.
Each SSL client has a set of acceptable ciphersuites. They are controlled by using the setClientCipherSuites() method in the SSLParams context object. Please refer to the MySecurityManager.java in any samples directory for more information.
The SSL protocol selects a common ciphersuite acceptable to both client and server. The actual ciphersuite for the connection has to be selected as the first of those, requested by the client that is supported by the server. If there is no common ciphersuite, you would be receiving a Fatal Handshake exception.

Question 5: If I don't set a client or server ciphersuite at runtime by instantiating an SSLParams object (e.g. using the setClientCipherSuites() and setServerCipher-Suites() methods before creating the SSLSocket connection) what ciphersuites are used?

The SSLParams object contains a list of default ciphersuites. These ciphersuites are coded in the SSLParams.java class in the arrays SSLParams.serverCipher-Suites and SSLParams.clientCipherSuites. These are the ciphersuites used if they are not set at runtime.

Digital Certificates

Question 6: What is a digital certificate?

A certificate is used to authenticate an entity. It consists of a public key which is bound to the information about the entity, such as the e-mail address of the entity. Certificates in SSL are in a format called X.509. The corresponding SSLava class that encapsulates X.509 certificates is crysec.X509. The certificate consists of the public key, entity information, and a signature by the entity that issued the certificate.
Certificates used in SSL are two types:

• RSA
• DSS

They correspond to the algorithm used to create the signature.

Question 7: Who issues or generates certificates?

Certificates are generally issued by Certification Authorities (CAs). CAs verifies the identity of an entity and signs the certificate.
Certificates can be issued by Phaos products such as the J/CA Certification Toolkit (pure Java CA library), as well as the Centuris Public Key Infrastructure Platform (products for building enterprise CAs).
Certificates can also be issued by services such as Verisign or Thawte. SSLava is compatible with the certificate formats issued by such services.

Question 8: What is "server certification" and "client certification"?

Certificates are used to authenticate the computer that is connecting to an SSL connection. For example, an SSL client checks the server's certificate, to verify it. This is called server authentication or server certification.
Similarly, an SSL server can check a client's certificate to verify it. This is called client authentication or client certification.
Except for anonymous ciphersuites, server certificates are required for SSL connections. That is, you need to set a server certificate object in the SSLParams object before constructing a server socket.
However, client certificates are optional. To request client certificates, use the flag setRequestClientCert in the SSLParams class, before constructing an SSLServer-Socket.

Question 9: How do I obtain the certificate of the peer? In other words, if I am a client, how do I see the server's certificate, and vice versa?

All the samples, in the PubSub and the Ptp directory, contain details, on how the client can retrieve and authenticate the server's digital certificates.
Similarly, the server can also retrieve and authenticate the client's certificate.

Question 10: How are certificates checked? What is a root CA fingerprint?

Certificates are checked by obtaining the public key of the signer, and verifying the certificate cryptographically.
In practice, the signer's public key is obtained from a certificate. This means that a certificate chain consisting of the certificate of the entity and the certificate of the signer is used by SSL to authenticate the entity.
A certificate chain consists of an arbitrary number of certificates, each of which has signed a predecessor in the chain. The root certificate, also known as the root CA certificate, is the certificate with no predecessor.
FioranoMQ does not perform client-or server-side authentication. The developer, using FioranoMQ SSL needs to code the authentication logic.

Question 11: How do I create a certificate chain for use with an SSL server?

To create a certificate chain for use with an SSL server, you need to have your Security Manager implement the Server Security Manager

Your Security Manager has to implement the following method:
public SSLParams getSSLParams () { return m_params; }

m_params represents SSLParams containing the SSLCertificate. To create an SSLCertificate object, and initialize the field certificateList:
SSLCertificate cert = new SSLCertificate(); cert.certificateList = new Vector();

The Vector certificate list corresponds to the certificate chain. Now, add the first element to the certificate chain, corresponding to the server certificate:
cert.certificateList.addElement(new X509(new File("server-cert.der")));

This is the server certificate. The following certificate in the chain is the certificate of the entity that signed the server certificate, usually, the CA certificate:
cert.certificateList.addElement(new X509(new File("ca-cert.der")));

Finally, you need to set the private key of the server certificate. An example is:
cert.privateKey = new PrivateKeyPKCS8(new File("server-key.der"));

Then, you have created a certificate chain object that you can now, set in the SS-LParams context object before the SSL connection, using:
m_params.setServerCert(cert);

After the SSLParams are created, you need to set these params to the Server-SecurityManager and pass it on to FioranoInitialContext.
MyServerSecurityManager serverCertificateHandler = new MyServerSecurityManager (); ic = new FioranoInitialContext (serverCertificateHandler)

All connections issued from the client now uses the properties set in these certificates.
A complete working example of My Server Security Manager can be found in all the sample directories.

Question 12: How is it possible to trust a root CA certificate, if there is no way of verifying that it has been signed by another certificate?

The answer is in the certificate fingerprint mechanism, supported by SSLava. It is possible to create a unique digital fingerprint corresponding to any digital data by using a hash algorithm such asMD5 or SHA. SSLava uses a 16-byte MD5 certificate fingerprints to store fingerprints of root CA certificates that it trusts.

During the SSL handshake, SSLava verifies each certificate in the certificate chain. When it reaches the root CA certificate, it computes the hash of the root CA certificate and compares it against the trusted fingerprint list. If each certificate is verified correctly, and the root CA fingerprint is on the trusted list, then the certificate chain is considered to be trusted.

The trusted root CA fingerprints are stored in the array, SSLParams.rootCAFinger-prints, and can be set at runtime using the SSLParams method setRootCAFinger-prints(byte).

• To compute a root CA fingerprint, use the MD5test program found in the test/ directory, and pass as the argument the DER encoded root CA certificate. This is a 16 byte value.
• To customize the certificate verification procedure, you should use the SSLCertificateVerifier class. Please refer to the on-line documentation, in $FMP_DIR/docs/ PhaosHTMLDocs directory.

ACL/ACE based Security

Question 13: What is Access Control List (ACL) based security? What granularity of security does it provide?

ACL/ACE based security allows the security policy for an application to be controlled externally, through an administration tool. FioranoMQ implements a comprehensive security model with complete support for ACL/ACE based security. ACL"s are attached to destinations (Topics and Queues), allowing the administrator to control access to topics. Access permissions can be set to:

• Publish to a Topic/Queue.
• Create a normal subscription on a Topic/Queue.
• Create a durable subscription on a Topic/Queue.

FioranoMQ incorporates a security system that is highly granular. Apart from the ACL/ACE based security restrictions on users to access created Destinations, the FioranoMQ server also supports selective sharing of data across servers. Every server can be administered to selectively import and export messages from other servers. Multi-level enterprise security is a necessity for integrating business processes that extend beyond corporate boundaries. FioranoMQ servers provide for built-in firewalls for incoming as well as outgoing messages. The built-in firewall support is provided using Access Control Lists and Access-Control Entries that restrict incoming as well as outgoing messages from the FioranoMQ server. Additional security concerns are addressed by providing publish To () APIs. These APIs allow application developers to selectively publish messages to one or more server(s) in the enterprise network. The server(s) can be identified by either a unique fully-qualified server name or by a unique (InetAddress, port) tuple. Additional proprietary APIs have been added to the FioranoPublisher class to support this feature.

Question 14: Are there any limitations on the use of ACL with Applets?

Netscape communicator, does not come bundled with java.security package, and so ACL/ACE features of FioranoMQ cannot be used by an Applet executing within Netscape. Reference to the following FioranoMQ runtime classes, using Netscape's VM throws a java.lang.VerifierError to occur.
fiorano.jms.rtl.User fiorano.jms.rtl.Administrator fiorano.jms.rtl.UserGroup fiorano.jms.rtl.Neighbour
If your JMS Applet is running on Netscape Communicator, it needs to use Fiorano's ACL/ACE based Security APIs, place ACL/ACE based Java 2 Security APIs in the local machine's CLASSPATH.

Question 15: How to use ACL based security with FioranoMQ?

For more information refer to the FioranoMQ Security section.