SSL Refactor concepts

Introduction

The SslManagerServiceImpl class is responsible to implement the SslManagerService APIs, providing support for the creation of an SSLSocketFactory used to manage SSL sessions but also to manage the certificates and private keys installed in the SSL key store. The SSLManagerServiceImpl is a Configurable Component where the user can specify some service-related parameters, like:

• the default protocol for the SSL Session
• enable or disable the hostname verification
• the key store path
• the key store password
• the cypher suites to use.

Being responsible for the key store management implies that the SSL Manager Service needs to deal with keystore password changes, keeping an alignment between the password received by the Configuration Service and the actual key store password. For a further matter of security, the service should be able to update the key store password at the first framework boot, in order to prevent the possibility that an attacker can know in advance the key store password.

Requirements

Following, a breakdown of the requirements identified for an SslManagerService implementation.

• the service should be able to access the key store provided by the default installation
• the service should be able to access a custom key store provided by the user, that will specify the corresponding access password via a property in the kura.properties file
• during the first boot, the default password should be changed to a random one and persisted
• the service should support key store password change from the Configuration Service / Configuration Admin. The update can be triggered by
  • a change requested via the Web UI
  • a snapshot uploaded from the Web UI or from a remote source
  • a configuration rollback
• in case the key store does not exist or is not accessible, the instantiation of an SSL session should not be possible.

Facts

An inconsistency between the password kept by the Configuration Admin and the key store's password is possible. This can be determined, for example, if a password change is requested in Web UI and then the framework is stopped. It could happen that the changes registered in the snapshot are not passed to the final service and the key store password is, then, not updated. This requires an entity, for example, the Crypto Service, capable to keep the consistency with the actual keystore password. The Crypto Service has an API that allows to receive the key store password only when effectively updated, allowing to recover the key store when there are inconsistencies between the password in Configuration Admin and the password needed to access the key store.

Proposed solution

The SSL Service implementation should be able to meet the specified requirements. To do so, a default key store should be provided out of the box, for example containing only the certificates needed to connect to the Eclipse MQTT broker. If needed, the user will have to customize the provided key store or change it with a custom one, in order to be able to securely connect to a different MQTT endpoint. At first framework boot, the SSL Manager Service implementation will try to access, if exists, to the specified key store and will change the default password with a random one that will be persisted, in an encrypted form, by the Configuration Service (in the snapshot) and by the Crypto Service. During the first password update with the random one, the SSL Service is responsible to update the Configuration Service with the updated configuration.

During normal execution, the password held by the Configuration Admin and the Crypto Service implementation must be consistent. Inconsistencies can be due to a password change and are solved by an update of the password held by the Crypto Service implementation, and a corresponding update of the key store with the password provided by the Configuration Service.

To simplify the management, the key store has private keys passwords equal to the key store password.