Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-16045

[SOLR 8] PKIAuthenticationPlugin uses encryption instead of signatures

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • None
    • 8.11.2
    • Authentication
    • None

    Description

      Our PKIAuthenticationPlugin uses a very weak cipher when sending SolrAuth header information. There are several factors involved here:

      • The Java cipher suite represented by RSA/ECB/NoPadding is completely deterministic.
      • The only way to rotate a server's public key is via restart because we have no way to reload the PublicKeyHandler.

      An older example of why ECB is a poor choice for data integrity is the ECB Penguin

      A mitigation to the associated risk here is that all transport should already be occurring over a secure channel (i.e. HTTPS), so the risk of a man-in-the-middle attack is low. However, there are other concerns.

      RSA/ECB/NoPadding does not include a MAC, so is susceptible to false parsing. If the encryption key has rotated then we are susceptible to issues like SOLR-15961

      Further, in cases where the parsing fails, we can end up logging the plaintext and cipher text of the authentication header. Even without the plaintext, and having only the cipher text, it would not be too challenging for an attacker to extract a key given that they know the format of the header to be SolrAuth <nodeName> base64(enc(<user> <timestamp>)) and user is often the literal $ string and timestamp is a recent long in millis.

      There are other, better, more modern cipher algorithms that can be used, and I am still researching which ones would work for us, what key initialization would look like, etc. Additionally, changing this on upgrade would not permit a rolling restart. At a minimum, we would need a "bridge" 8.11.2 release so that users can upgrade from 8.x -> 8.11.2 -> 9.0. In this scenario, we would need the following behavior:

        encryption decryption
      8.x RSA/ECB/NoPadding RSA/ECB/NoPadding
      8.11.2 RSA/ECB/NoPadding RSA/ECB/NoPadding
      OR New Alg
      9.x New Alg New Alg

      Alternative options are to discard rolling restart capability going from 8->9, ask users to disable PKI Authentication for their clusters, or require users to bridge via 9.0 before upgrading to further 9.x releases. None of those alternatives sound palatable to me, but the community may disagree.

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            mdrob Mike Drob
            mdrob Mike Drob
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment