[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024

["Erick Erickson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-9609:
---------------------------------
    Attachment: SOLR-9609.patch

So here's a first cut at what it would take to move this to security.json (hey, it compiles, but it's _completely_ untested).

The reason I'm putting this up is that putting this value in security.json starts to get...messy and I'm wondering if the elegance of putting this in security.json outweighs the messiness.

The basic problem is that CryptoKeys doesn't have access to SecurityConfig. So we can either pass CoreContainer down to CryptoKeys (yuuuuck, talk about architectural badness) or have CryptoKeys take a length for this buffer. 

The second option requires that the caller get the new value from the SecurityConfig object if it's different than the default and pass that in to the c'tor. Which I made the PKIAuthenticationPlugin do.

Unless we make the default CryptoKeys c'tor private, any new classes using CryptoKeys has to remember to get the value from security.json which could be forgotten. I suppose we can just deprecate the default c'tor and then caveat emptor. My guess is that just making the default c'tor private is unacceptable as it breaks back-compat.

All this to allow different buffer lengths to be chosen. So is it really worth it? It seems we have several options:
1> go ahead and put it in security.json because it's the right thing to do.
2> allow it to be configurable with a sysvar, which is much easier.
3> hard code it to some future-friendly value like 4096. This assumes that having a value larger than necessary is OK.

Or am I missing some way to get around this mess?

P.S. there's a nocommit in there (should we really have a main method in CryptoKeys?) and I'll take out a change in the PKI test unless we deprecate the default c'tor in CryptoKeys if we decide to put this in security.json after all.



> Change hard-coded keysize from 512 to 1024
> ------------------------------------------
>
>                 Key: SOLR-9609
>                 URL: https://issues.apache.org/jira/browse/SOLR-9609
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Jeremy Martini
>            Assignee: Erick Erickson
>         Attachments: SOLR-9609.patch, SOLR-9609.patch, SOLR-9609.patch, solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password in the configuration file, we extended JdbcDataSource to create our own custom implementation. Our dataSource config now looks something like this:
> {code:xml}
> <dataSource type="com.foo.FooDataSource" driver="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the password. However, this seems to cause an issue when we try use Solr in a Cloud Configuration (using Zookeeper). The error is "Strong key gen and multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
>     keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
>     throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt it, and now everything seems to work great.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org