Securing The Transport Layer In JBOSS

 

If you were to create a mission-critical application with just the bare concepts we have learnt until now, you are not guaranteed to be shielded from all security threats. For example, if you needed to design a payment gateway, where the credit card information is transmitted by means of an EJB or Servlet, using just the authorization and authentication stack is really not enough.

In order to prevent disclosure of critical information to unauthorized individuals or systems, you have to use a protocol that provides encryption of the information. Encryption is the conversion of data into a form that cannot be understood by unauthorized people. Conversely, decryption is the process of converting encrypted data back into its original form, so it can be understood.

The protocols, which are used to secure the communication, are SSL and TLS, the latter being considered a replacement for the older SSL.

There are two basic techniques for encrypting information: symmetric encryption (also called secret key encryption) and asymmetric encryption (also called public key encryption).

Symmetric encryption is the oldest and best-known technique. It is based on a secret key, which is applied to the text of a message to change the content in a particular way. As long as both the sender and recipient know the secret key, they can encrypt and decrypt all messages that use this key. These encryption algorithms typically work fast and are well suited for encrypting blocks of messages at once.

One significant issue with symmetric algorithms is the requirement of a safe administrative organization to distribute keys to users. This generally results in more overhead from the administrative aspect while the keys remain vulnerable to unauthorized disclosure and potential abuse.

For this reason, a mission-critical enterprise system usually relies on the asymmetric encryption algorithms, which tend to be easier to employ, manage, and make it ultimately more secure.

Asymmetric cryptography, also known as Public key cryptography, is based on the concept that the key used to encrypt is not the same used to decrypt the message. In practice, each user holds a couple of keys: the public key which is distributed to other parties and the private key which is kept in secret. Each message is encrypted with the recipient’s public key and can only be decrypted (by the recipient) with his/her private key.

Using asymmetric encryption you can be sure that your message cannot be disclosed by a third-party, however, you still have one vulnerability.

Suppose you want to exchange some valuable information with a business partner and so you are requesting his/her public key by telephone or by e-mail. A fraudulent user intercepts your e-mail or simply listens to your conversation and quickly sends you afake e-mail with his/her public key. Now, even if your data transmission is secured, it will be directed to the wrong person!

In order to solve this issue, we need a document that verifies that the public key belongs to an individual: this document is called a digital certificate or public key certificate. A digital certificate consists of a formatted block of data that contains the name of the certificate holder (which may be either a user or a system name) and the holder’s public key, as well as the digital signature of a Certification Authority (CA) for authentication. The certification authority attests that the sender’s name is the one associated with the public key in the document.

Simple authentication and client authentication

In the previous example, we have depicted a simple authentication (also called server authentication). In this scenario, the only party, which needs to prove its identity, is the server.

SSL, however, is able to perform a mutual authentication (also called a client or two-way authentication) in case the server requests a client certificate during the SSL handshake over the network.

The client authentication requires a client certificate in x.509 format from a CA. The x.509 format is an industry-standard format for SSL certificates. In the next section, we will explore the available tools to generate digital certificates and also how to have your certificates signed by a CA.

Enabling the Secure Socket Layer on JBoss AS

JBoss AS uses the Java Secure Socket Extension (JSSE)), which is bundled in the J2SE to leverage the SSL/TLS communication.

An Enterprise application can be secured at two different locations: at HTTP level and RMI level . HTTP communication is handled by the web subsystem within the standalone.xml/domain.xml file. Securing the RMI transport is, on the other hand, not always a compelling requirement of your applications. Actually, in most production environments, JBoss AS is placed behind a firewall.

As you can see from the following diagram, this implies that your EJBs are not directly exposed to un-trusted networks, which usually connect through the web server placed into a demilitarized zone.

In order to get started with JBoss AS and SSL, we need, first of all, a tool which generates a public key/private key pair in the form of an X509 certificate for use by the SSL server sockets. This is covered in the next section.

Certificate management tools

One tool that can be used to set up a digital certificate is key tool, a key and certificate management utility that ships with the Java SE. It enables users to administer their own public/private key pairs and associated certificates for use in self-authentication (where the user authenticates himself or herself to other users or services) or data integrity and authentication services, using digital signatures. It also allows users to cache the public keys (in the form of certificates) of their communicating peers.

The key tool stores the keys and certificates in a file termed as keystore, a repository of certificates used for identifying a client or a server. Typically, a keystore contains one client or one server’s identity, which are protected by using a password. Let’s see an example of keystore generation:

keytool -genkey -keystore jboss.keystore -storepass mypassword – keypass mypassword -keyalg RSA -validity 180 -alias as7book -dname “cn=Francesco Marchioni,o=PackPub,c=GB”

Frequently asked Jboss Interview Questions

This command creates the keystore named jboss.keystore in the working directory and assigns it the password mypassword. It generates a public/private key pair for the entity whose “distinguished name” has a common name of Francesco Marchioni, an organization of PacktPub and two-letter country code of GB.

The aftermath of this action will be a self-signed certificate (using the RSA signature algorithm) that includes the public key and the distinguished-name information. This certificate will be valid for 180 days and is associated with the private key in a key store entry referred to in the tutorial.

Securing the HTTP communication with a self-signed certificate

Now let’s see how you can use this keystore file to secure your JBoss web channel. Open the server configuration file (standalone.xml/domain.xml) and reach the web subsystem.

Now, update the connector information by adding the SSL element which contains the keystoreFile and keyStorePass information with data from your certificate:You have to restart JBoss AS to activate changes. You should see at the bottom of your console the following log which will inform you about the new HTTPS channel running on port 8443.

INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http–127.0.0.1-8443

The following screen is what will be displayed by the Internet Explorer browser if you try to access any web application on the secured channel (for example, if we deployed the SecuredApp via https://localhost:8443/SecuredApp).

What happened? once you have established a secure connection with the web server, the server certificate has been sent to the browser. Because the certificate has not been signed by any recognized CA, the browser security sandbox warns the user about the potential security threat.

This is an in-house test, so we can safely proceed by choosing Continue to this website. That’s all you need to do in order to activate the Secure Socket Layer with a self-signed certificate.

Securing the HTTP communication with certificate signed by a CA

Having your certificate signed requires issuing a certificate-signing request (CSR) to a CA, which returns a signed certificate to be installed on your server. This implies a cost for your organization, which depends on how many certificates you are requesting, the encryption strength and other factors.

So, at the first generate a CSR using the newly created keystore and keyentry: keytool -certreq -keystore jboss.keystore -alias as7book -storepass
mypassword -keypass mypassword -keyalg RSA -file certreq.csr
This will create a new certificate request named certreq.csr, bearing the format:
—–BEGIN NEW CERTIFICATE REQUEST—–
. . . . . .
—–END NEW CERTIFICATE REQUEST—–
The previous certificate needs to be transmitted to the CA. For example supposing you
have chosen Verisign (https://www.verisign.com) as CA:

At the end of the enrollment phase, the CA, which will return a signed, certificate that needs to be imported into your keychain. Suppose that you have saved your CA certificate in a file named signed_ca.txt:

keytool -import -keystore jboss.keystore -alias testkey1 -storepass mypassword -keypass mypassword -file signed_ca.txt

Here, the the -import option is used to add a certificate or certificate chain to the list of trusted certificates as specified by the –keystore parameter and identified by the – alias. The parameter –storepass specifies the password which is used to protect the integrity of the keystore. If the -keypass option is not provided at the command line,
and the private key password is different from the keystore password, the user is prompted for it.

Now, your web browser will recognize your new certificate as being signed by a CA, so it won’t complain that it cannot validate the certificate.