[
https://issues.apache.org/jira/browse/SOLR-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494075#comment-17494075
]
Mike Drob commented on SOLR-15965:
----------------------------------
Even if we release 9.0, if we're planning to release 8.11.2 then should we not
mentioned that path in the 9.0 upgrade docs? Or do we have the ability to go
back and edit them easily now that Antora is publishing all of the versions
([~houston] do you know?)
I agree that having multiple upgrade paths outlined is probably more confusing
than helpful. You can see from my conversation on the PR with Tomas that it's
something that went through a few iterations.
What about:
{noformat}
SOLR-15965: Internode communication secured by PKI Authentication has changed
formats. For detailed information, see PKI Authentication Plugin.
A rolling upgrade from Solr 8 to Solr 9 requires the following multiple restart
sequence:
1. Upgrade to Solr 9 and set system properties: solr.pki.sendVersion=v1 and
solr.pki.acceptVersions=v1,v2. This will allow Solr 9 nodes to send messages to
Solr 8 nodes while the upgrade is in progress.
2. Restart with solr.pki.sendVersion=v2 (default, can be unset) and
solr.pki.acceptVersions=v1,v2. This will force all nodes to send the new header.
3. (Optional) Restart with system property solr.pki.acceptVersions=v2 (default,
can be unset) to prevent outdated nodes from connecting to your cluster.
{noformat}
Replacing the bulleted list with a numbered list, providing a little bit more
rationale. After 8.11.2 is released, we can add a line like "When upgrading
from 8.11.2 or newer, you can optionally skip step #1)
> Would be cool if we had a tool e.g. {{bin/solr upgradehelp --from
> <from-version|solr-url>}}
In a separate issue, please :)
> PKIAuthenticationPlugin uses encryption instead of signatures
> -------------------------------------------------------------
>
> Key: SOLR-15965
> URL: https://issues.apache.org/jira/browse/SOLR-15965
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
> Reporter: Mike Drob
> Assignee: Mike Drob
> Priority: Blocker
> Fix For: 9.0, 8.11.2
>
> Time Spent: 1h 40m
> 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.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
