Uploaded image for project: 'Erlang/OTP'
  1. Erlang/OTP
  2. ERL-1016

Improve ssl handshake to support more use cases

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 22.0
    • Fix Version/s: None
    • Component/s: ssl
    • Labels:
      None

      Description

      Hello,

      In RabbitMQ we have been investigating how to serve more than one certificate on the same listening socket. This is necessary when the client does not support ECDSA for example, and is something done by various websites such as Wikipedia. The relevant RabbitMQ ticket is https://github.com/rabbitmq/rabbitmq-server/issues/2060

      We are at a point where we figured we can use ssl:handshake_continue to change the certfile/keyfile options. We want to provide a different certificate based on the ciphers supported by the client.

      The issue however is that there seems to be no interface to obtain this cipher list nor any other information found in the client hello, except for the extensions. Unfortunately the information we want is not an extension and is not returned by ssl:handshake when using handshake,hello.

      Right now we have a rough proof of concept on the RabbitMQ ticket that uses sys:get_state to retrieve the cipher list from the client hello and then makes some decision based on that list. It would be great to have an interface to obtain this information.

      Of note is that ssl:connection_information does not return when you are in the middle of the handshake. Maybe the function could be modified to return client hello information when in that state. Considering the documentation does not list what values are returned by the function it's probably OK to make it return different values than normal in that state? In which case we would return client hello information.

      Alternatively the information could be added to Ext from the ssl:handshake return value. It wouldn't be just extensions anymore but maybe that's OK? However in that case ssl:connection_information should be patched to return an error while in the handshake state.

      This ticket is meant to discuss what a good solution for this would be, I will happily send a PR afterwards.

        Attachments

          Activity

            People

            Assignee:
            otp_team_ps Team PS
            Reporter:
            essen essen
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: