Uploaded image for project: 'Trapperkeeper (moved to puppet.atlassian.net)'
  1. Trapperkeeper (moved to puppet.atlassian.net)
  2. TK-125

Provide option for disabling SSL session reuse in clj-http-client

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed
    • Normal
    • Resolution: Won't Fix
    • None
    • None
    • TrapperKeeper
    • Normal
    • 1 - 1-5% of Customers
    • 3 - Serious
    • 4 - $$$$$
    • Hide
      CS Triage looked into this issue in relation to wanting to load balance PuppetDBs which requires a shared certificate across PDB instances. Sharing a cert across PDB is frustrating to setup and it would be nice to avoid

      However our intention for future large scale architectures is to co-locate PDB on each compile master which should reduce or remove the need for this. The triage scoring reflects this.
      Show
      CS Triage looked into this issue in relation to wanting to load balance PuppetDBs which requires a shared certificate across PDB instances. Sharing a cert across PDB is frustrating to setup and it would be nice to avoid However our intention for future large scale architectures is to co-locate PDB on each compile master which should reduce or remove the need for this. The triage scoring reflects this.

    Description

      By default, any SSL handshake completed by an clj-http-client request where the server returns an SSL session id results in the client attempting to resume the SSL session for a request made on a new connection. In some scenarios it may be desirable to not have the client try to resume SSL sessions, e.g., to protect the client from an SSL renegotation attack until a proper remediation path can be found or when multiple servers having different certificates are hidden behind a load balanced virtual ip address and session reuse is not desirable / practical. See SERVER-207 for some discussion on the issues session caching presents around load-balanced virtual ip addresses.

      In order to disable session caching, a new "allow session creation" option could be exposed as a "client option" alongside the other SSL-related options. For compatibility, it would probably be best to allow SSL sessions to be created/resumed by default so that clients can take advantage of the performance benefits of renegotiation.

      I'm not sure of the best way to do this. In async.clj, there is some code which sets up desired protocols and ciphers via an SSLIOSessionStrategy. If clj-http-client were to derive a class from SSLIOSessionStrategy which provides an implementation for the protected initializeEngine method, setEnableSessionCreation could be called with true or false, as desired, on the SSLEngine parameter supplied to the method. I haven't tried doing this yet, so not sure if this would actually work.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              jeremy.barlow Jeremy Barlow
              Erik Dasher Erik Dasher
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support