[
https://issues.apache.org/jira/browse/SOLR-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544466#comment-17544466
]
ASF subversion and git services commented on SOLR-15965:
--------------------------------------------------------
Commit a236335e11da126e5ba424c881388fd2f4d6d7f4 in lucene-solr's branch
refs/heads/branch_8_11 from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a236335e11d ]
SOLR-15965 Use proper signatures for SolrAuth (#2641)
Internode communication secured by PKI Authentication has changed formats. This
commit allows for smoother upgrades from 8.x to 8.11 to 9.0
> PKIAuthenticationPlugin uses encryption instead of signatures
> -------------------------------------------------------------
>
> Key: SOLR-15965
> URL: https://issues.apache.org/jira/browse/SOLR-15965
> Project: Solr
> Issue Type: Bug
> Components: Authentication
> Reporter: Mike Drob
> Assignee: Mike Drob
> Priority: Blocker
> Fix For: 9.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> 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|https://words.filippo.io/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|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/security/PKIAuthenticationPlugin.java#L191].
> 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.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
