General

This task is not just about the socket definition itself, it is also about a standard approach for defining a SSLContext which is then associated with either a listener or an outbound connection of some sort.

[WFLY-1136] Common mechanism for all secure socket definitions - JBoss Issue Tracker

This article at the moment is a bit of a brain dump just to capture the various considerations.

Key Areas

• Initialisation of KeyStore for KeyManager and TrustManager use.
  • Can use default of JKS or switch to PKCS12.
    • Both are file based, both should consider reloading of modified files.
• KeyManagerFactory - Option for alternative providers.
• TrustManagerFactory - Option for alternative providers.
  • Alternative providers and additional config is a route to OCSP
• SSLContext - Again provider related.

One remaining issue is that there is a remaining set of options / SSLParameters to be set on the SSLEngine instance after it is created.  Different IO libraries may use this in different ways, some could use the SSLSocket and SSLServerSocket directly, other could use the SSLEngine on sockets they manage - this is the point where common config becomes tricky.  We could have our own SSLContext to set parameters on the SSLEngine before it is returned or we could have a common approach to config defined that we translate / transform to the relevant IO libraries.  Most importantly we must not forget this special area of configuration.

Management and Subsystems

Implementation to be used for both management and subsystem defined services, bare minimum requirement of common XML schema and management operations.

Socket Binding Style

A lot of these definitions are actually referencing resources local to the host, e.g. local security provider settings or local file based key and trust stores - should this be following an approach closer to socket bindings so that the SSLContext definition is only referenced from the subsystem rather than within the subsystem?  It is going to be need to be definable at the host level anyway for the purpose of management.

Providers

File based stores such as JKS and PKCS#12 need to be supported, also enable other providers for things like PKCS#11

Worth considering is also support for SunMSCAPI  like providers to enable usage of windows keystores/truststores as well as usage of Windows native crypto lib usage.

OpenSSL Certificates [WFLY-319] OpenSSL SSL certificate support for domain management security realms (http and native interface) - JBoss Iss…

Advanced Configuration

The additional providers could be configured and registered by WildFly.

[WFLY-2904] Add advanced PKCS#11 support to security realms. - JBoss Issue Tracker

[WFLY-2890] Add support for PKCS#11 configuration within security realms. - JBoss Issue Tracker

Store Merging

Discussed below is an option for providing admin capabilities to accept trusted certificates after a failed connection, another option to consider is the merging of multiple stores into one before initialising a TrustManager, e.g. a store central on a machine plus a WildFly specific local store.  This may be useful in scenarios where WildFly can not update a central store but could make updates to it's own local store.

Additional Settings

Supported algorithms.

[WFLY-375] Add support to specify ciphers available with Remoting - JBoss Issue Tracker

SecureRandom

We should be able to configure SecureRandom algorithms & provider.

OpenSSL

Can OpenSSL be wrapped simply?

OCSP

Ensure OCSP can be enabled, either using a native or custom implementation.

At this point we are talking about OCSP occurring whilst the TrustManager is validating the certificate from the remote side of the connection, one option is to switch to a PKIX provider when creating the TrustManager: -

Security.setProperty("ocsp.enabled", "true");
Security.setProperty("ocsp.responderURL", "http://localhost:8888");


TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance("PKIX");
PKIXBuilderParameters pkixParams = new PKIXBuilderParameters(trustStore, new X509CertSelector());
pkixParams.setRevocationEnabled(true);
CertPathTrustManagerParameters ctmp = new CertPathTrustManagerParameters(pkixParams);
trustManagerFactory.init(ctmp);

Another option is to wrap the default TrustManager implementation with our own and make our own PKI calls after the preliminary validation.

For some of the items we are considering we may want our own X509TrustManager anyway to wrap the provider we use, or it could even become a Provider simplified impl in it's own right.  At the moment wrapper feels better as it allows underlying impls to be swapped out but worth further thought.

Audit Logging

It goes without saying that these needs to be protected by access control and audit logged accordingly - however it should also be usable by audit logging: -

[WFLY-2955] Audit logging should also be able to use PKCS#11 for keystores. - JBoss Issue Tracker

This does introduce an additional query for access control, if we had a central definition of the SSLContexts should that definition also categorise them? i.e. highlight the ones for auditing compared to the ones for development.

Vault

Vault to store the passwords and vault needing a reference to a keystore?  Maybe vault integration with other providers.

Additional Management

In addition to the common definitions we may also want operations to work with the stores e.g. adding and removing or generating certificates, need to think how this would work across a domain.

This leads to the next step of being able to strongly push administrators into enabling SSL.

[WFLY-2890] Add support for PKCS#11 configuration within security realms. - JBoss Issue Tracker

Simplified Management

Another aspect to consider is capabilities to cache certificates received from clients that we rejected during the connection, administrators could be provided with operations to mark these certificates as acceptable so that subsequent attempts will be allowed.

e.g. The KeyStore manipulation we have within the CLI to add trusted certificates to a store either temporarily or permanently after a confirmation with the end user.

Authentication

Traditionally we allow for a SSL session to be started and then handle authentication at a later point and verify if we have an established SSL session with a peer principal.  Where the trust manager is verifying the remote certificate it should actually be able to perform an authentication check and possibly even an authorization check to verify the user is even allowed to connect.

Additional /Alternative Certificate Locations

We may want to consider ditching the configured stores entirely, possibly LDAP or database to load certificates?

One problem is that the HTTPS connector of the web container serves up requests for all web apps but each app may have it's own security requirements, maybe we want to merge the stores from each deployment?

PikcetLink based certificates?  Haven't looked yet if any cross over with KeyCloak.

Real Time Management

Closely related we need some big enhancements to the administration of the current status of the connections to and from the server, one area related to this is the management of the active SSLSessions, from a management perspective it should be possible to list information about these and even possibly invalidate active sessions.

As an example if it was identified that a users private key had been compromised after measures have been taken to prevent the use of that key again all sessions for that user could be invalidated.

Note: Other items can be attached to a SSLSession, this could help return additional useful information.

Related

Similar approach will be needed for Kerberos, the difference being that for Kerberos we are looking for a populated Subject but the other requirements are still very similar e.g. for inbound and outbound calls, aspects of configuration being specific to a host, used in management and the application server.