Consider security transition mode

[macintux]

Today, there are effectively two ways to enable security in a production environment:

1. Configure all applications to handle both secure and insecure Riak nodes; if a node doesn't allow STARTTLS, fall back to insecure requests.
2. Stop all applications, restart the entire cluster, start all applications in "secure mode"

The 2nd option is more secure but much more disruptive, and doesn't allow for mistakes. If an application isn't ready for security but that fact isn't discovered until the cutover, the user is entirely out of luck.

The 1st option is much more work and coordination for large environments. All applications will need to be touched, but to force them all to handle both secure and insecure operations leaves open the possibility that a misconfiguration or middleman attack could expose data in the future (plus the extra work and possibility of bugs this imposes on users).

If we had a multi-stage security enablement process, wherein security is turned on in one step, and enforced in a later step, users could manage application transitions more gracefully.

There are still security implications to that model, but I think the alternatives are worse. Last time I suggested this I was shouted down quite noisily, but I'd like it to be considered again more formally.

[bkerley]

As implemented in basho/riak-ruby-client#149 , basho/riak-python-client#326 , and basho/riak-java-client#371 , clients refuse to connect to non-starttls-enabled nodes if they have security configured.

Previous discussion has cited the consequences of clients willing to connect to non-authenticated nodes making it easier to MITM them.

Having transition modes on the Riak cluster for this and other security features (i.e. no OCSP -> try OCSP, warn on failure -> try OCSP, fail on failure) could be valuable though.

[macintux]

To be clear, I'm proposing something different from what @bkerley thinks I am. I think.

Step 1: Riak servers turn on security but still allow clients to connect without encryption or authentication
Step 2: Applications are upgraded to support security
Step 3: Riak servers are instructed to enforce security

I'm not proposing that clients fall back to insecure connectivity if the servers don't support security. That is the option that users are today forced to consider to get around our all or nothing approach, and what I would like to avoid.

[bkerley]

I concur (and hope I cleared up my above post :P ).