Securing Administration in GlassFish Server 3.1 - 3: Admin Message Encryption
By tjquinn on Feb 27, 2011
If you are an administrator of a GlassFish installation, you will see
some new facets of administrative security in GlassFish Server 3.1. In
this series of blogs I describe three key aspects: admin
authentication, remote administration, and admin message encryption.
Some of this will be familiar to you if you have worked with earlier
releases of GlassFish, and some will be new.
Remember that convenience and security are often at odds with each
other. We have tried hard to keep the out-of-the-box experience with
GlassFish Server 3.1 convenient while not creating security problems.
And we have tried to make it very easy to run in a very secure
Part 1: Admin Authentication
Part 2: Remote Administration
Part 3: Admin Message Encryption
When you install GlassFish Server or create a new domain, GlassFish does not encrypt admin message traffic. This means that admin messages could be intercepted, spoofed, or falsified. To guard against this, when you enable secure admin using
GlassFish encrypts all admin traffic using SSL/TLS. (As described in earlier parts of this blog series, before you run enable-secure-admin shut down all instances, leaving only the DAS running. Then after you enable secure admin you can restart the DAS and start up any instances you want.) Remember also that after you run the enable-secure-admin command GlassFish allows remote administration.
Turn off encryption using
which also disables remote administration.
Several things work differently when you encrypt admin traffic.
Default Self-signed Certificates
GlassFish Server creates two self-signed certificates when you install it or create a new domain.
One, as in past releases of GlassFish, is used in the DAS for SSL server authentication to clients. You will notice this the first time you use asadmin or some other admin client to contact the DAS. Because the cert is self-signed, there is no trusted certificate chain to a certificate authority. Because of this, admin clients such as asadmin will display the cert and ask you if you want to trust it. Once you accept the DAS cert from a given domain asadmin remembers it and will not ask you about that cert again.
This cert is also used in GlassServer 3.1 to authenticate the DAS to remote instances so those instances can trust that the admin messages actually come from the DAS.
The second self-signed cert which GlassFish generates is used by the instances for SSL server authentication to clients. You will rarely see evidence of this cert yourself, although if you use the monitoring add-on (which allows you to connect directly to instances to retrieve monitoring information) asadmin will ask you whether you trust that cert.
Although it's more than we want to talk about here, you can use your own certificates and private keys instead of the generated, self-signed ones. If your certs are from a certificate authority then they will be trusted automatically and admin clients will not ask you if you want to trust them.
Certificates and Authentication
How does this help with security? With secure admin disabled, the DAS insists that you log in using valid administrator credentials. But you do not really know that it's the DAS you are talking to. Someone could have started a different process at the admin port (by default, 4848) to capture your admin username and password for illicit use later. But when the server uses SSL certificate authentication, you can be confident that you are actually talking to the DAS - if you trust the cert, that is. This is why clients prompt users about self-signed certs. Now, you know you are talking to the DAS - thanks to the SSL server authentication - and the DAS knows you are a valid administrator - thanks to the admin user and password you provide.
Beyond that, the DAS and the instances use SSL mutual authentication.
That is, the DAS uses its certificate to authenticate itself to the
instances, and the instances use their certificate to authenticate
themselves to the DAS. This way the DAS and the instances have
confidence that the messages have not been compromised in flight -
either intercepted or spoofed - and that the sender and receiver of the
admin messages are who they claim to be.
SSL and Encryption
When you enable secure admin, GlassFish Server encrypts all admin messages among admin clients, the DAS, and the instances. Notably, it encrypts the username and password along with the rest of the message so no one who might be monitoring network traffic can intercept your credentials and use them to sign in illicitly to the DAS.
In fact, once you enable secure admin, even if you try to connect to the DAS over an open (HTTP) connection the DAS redirects the request to HTTPS. Plus, the asadmin utility will not send the username and password over an insecure connection if secure admin is enabled. This way the sensitive credentials are never sent in the clear - with secure admin enabled, that is.
If you use a browser to send REST requests to the DAS, for example,
the browser automatically follows the redirection request. The DAS will
then prompt the browser for authorization, which means the browser will
automatically prompt you for the admin username and password and then
resubmit the request. Even in this case, with secure admin enabled the
sensitive information is sent only over a secure connection.
Configuring Secure Admin
Java stores keys and certificates as entries in keystores. The keystore identifies each entry using an alias. GlassFish has its own keystore and truststore. When you enable secure admin, GlassFish will by default use the alias s1as to look up the DAS key and certificate and the alias glassfish-instance to look up the instance key and certificate. You can optionally tell GlassFish Server to use different aliases instead.
[--adminalias=alias (default s1as)]
[ --instancealias=alias (default glassfish-instance)]
The enable-secure-admin and disable-secure-admin commands change quite a few parts of the domain's configuration for you. You do not need to worry about the details, but if you are curious you can take a look at your domain's domain.xml file in the config directory before and after you enable secure admin to get a feel for what is happening behind the scenes.