Alex Deparvu created SOLR-16551:
-----------------------------------

             Summary: Provide a way to disable the PKIAuthenticationPlugin
                 Key: SOLR-16551
                 URL: https://issues.apache.org/jira/browse/SOLR-16551
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
          Components: Authentication
    Affects Versions: 8.6.3
            Reporter: Alex Deparvu


The PKIAuthenticationPlugin [0] plugin will secure inter-node communication by 
injecting a custom header that will allow any destination node to verify 
tampering of message by checking against source node's public key. This header 
also contains a TTL value that exists to prevent replay attacks (default is 5 
seconds).

Under very high load for increased periods of time, messages can start to 
expire, causing a spike in authorization errors. by trial and error, increasing 
the TTL value high enough seems to help the cluster get over the hump, but 
setting it too high will raise security concerns. 
This begs the question: is there any circumstance under which it is safe to 
disable the "header sign and check with TTL" mechanism. It seems that enabling 
inter-node encryption [1] can provide sufficient protection in transit so that 
the header approach would no longer be required.

I am opening this ticket to gather feedback from the community. First, is this 
something that others have seen (heavy load can lead to 401s on inter-node 
requests). Second, is the approach to disable the PKI plugin sensible or would 
it cause more confusion and/or security troubles?



[0] 
https://solr.apache.org/guide/solr/latest/deployment-guide/authentication-and-authorization-plugins.html#pkiauthenticationplugin
[1] https://solr.apache.org/guide/solr/latest/deployment-guide/enabling-ssl.html




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to