1

I have an implementation of reactor pattern in which I load the SSLContext when a TransportListener (Basically a listener listening on a given port for HTTPS connections.) is starting.

Then I call the same init() method again (through a JMX call to a listener's method)

sslContext.init(keyManagers, trustManagers, null);

once I add or remove a certificate to/from the trust store. I have to reload the SSLContext in order to avoid any down time in the listener.

So this is the problem I'm currently facing.

Suppose a request come to the listener and an connection is established. If I reload the SSLContext object before the response is returned to the client, will that affect the connection's SSLEngine object's wrap process which encrypts the payload before sending?

Note : I have validated that the same SSLContext object is being passed to all the SSLEngines.The SSLContext object is passed to several other objects when the Listener is starting. For example, I have a connection pool to which I have to pass this SSLContext object. Therefore creating a new SSLContext object will completely break the existing connections is the connection pool. That is why i'm trying to use the same SSLContext object.

Imesha Sudasingha
  • 3,462
  • 1
  • 23
  • 34
  • 1
    There was nothing preventing you from testing this for yourself *before* deciding it is what you 'have to' do. There is nothing stopping you from starting to use a *new* `SSLContext` whenever you load a new certificate: this will also avoid any downtime in the listener. You can't pass the same `SSLSession` to any `SSLEngines` at all, let alone to multiple ones. Do you mean `SSLContext`? – user207421 Sep 01 '16 at 21:00
  • ...and you can modify the truststore without setting up a new context. – eckes Sep 01 '16 at 22:25
  • I have tested this for all other use cases. But I am unable to reproduce a scenario like what I have mentioned above (modify the sslcontext before sending the response but after receiving the request). @eckes I do not have a problem with modifying the trust store. What I need is to reload the trust store at run time without restarting the `Listener`. – Imesha Sudasingha Sep 02 '16 at 01:34
  • @EJP I can't really understand what you are saying. What i'm saying is, the SSLContext object is passed to several other objects when the `Listener` is starting. For example, I have a connection pool to which I have to pass this `SSLContext` object. Therefore creating a new `SSLContext` object will completely break the flow. That is why i'm trying to use the same SSLContext object. – Imesha Sudasingha Sep 02 '16 at 01:37
  • You need to read your own post. What you *actually said* was, and I quote, 'the same `SSLSession` object is being passed to all the `SSLEngines`'. Please clarify. And 'therefore creating a new SSLContext object will completely break the existing connections [in] the connection pool' is just a guess, not an established fact. – user207421 Sep 02 '16 at 01:50
  • @EJP Sorry, i updated it. I'm passing the `SSLContext` object. Where I'm confused is, I do not have a way to verify whether the existing connections use the current `SSLContext` object when wrapping and unwrapping data? – Imesha Sudasingha Sep 02 '16 at 01:57
  • They do if they have to engage in a re-handshake, as they have to access cipher suites, protocols, trusted certificates, private keys, etc. And I don't know what 'passing an `SSLContext` to an `SSLEngine`' means. `SSLEngines` are created *from* `SSLContexts.` – user207421 Sep 02 '16 at 01:59
  • I dont see a reason the reinit with a new context. The trust manager is queried on each new connection, it immediatelly will pick up changes. You just need to use an provider which can actually be modified. It does of yourse not work for established sessions (unless you force a renegotiaion which is frowned upon anyway) – eckes Sep 02 '16 at 21:39
  • @eckes what do you mean by a provider? – Imesha Sudasingha Sep 03 '16 at 01:59
  • An implementation providing the TrustManager interface which is mutable. – eckes Sep 04 '16 at 17:37

1 Answers1

0

You need to think this through. If you have an established connection, it has already had a certificate exchange, successfully, so it has no need of new certificates, so no need of a new or reinitialized SSLContext, up to and including partial handshakes, e.g. to rekey the current session, or request a client certificate. It shouldn't use the SSLContext at all for anything short of a full handshake.

What you need to do is starting using a new SSLContext for all the new connections that are going to need the new certificate. You don't need to do anything to existing connections, by definition.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Sorry for the confusion. i updated it. I'm passing the `SSLContext` object. What i want to know is, whether the existing socket connections, which use `SSLEngine` objects to wrap and unwrap get affected by changing the `SSLContext` object's trust managers. That is a problem only in a scenario where a request has received but the response is yet to be sent. Is there a possibility of incoming connection being unwrapped using a set of keys and response being wrapped using a separate set of keys which will break the communication is the above scenario? – Imesha Sudasingha Sep 02 '16 at 02:03
  • The session keys are in the `SSLSession`, not the `SSLContext`, but I still don't see why you think you need to reinitialize the `SSLContext of an existing connection. – user207421 Sep 02 '16 at 02:22
  • That means, `SSLEngine` only use `SSLContext` for the hand shake. Therefore afterwards, a change in the `SSLContext` do not affect the existing `SSLSession` or `SSLEngine` of a connection/socket if it is not a handshake. Am I correct? – Imesha Sudasingha Sep 02 '16 at 02:25
  • As far as I can see that should be correct. If it's a partial handshake, e.g. to rekey the current session, or request a client certificate, it shouldn't use the `SSLContext` at all. – user207421 Sep 02 '16 at 03:28
  • ok. Thanks for your help. Can you add that part also to the answer so that i can accept it as the answer :) – Imesha Sudasingha Sep 02 '16 at 04:48