[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
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
Patch I'm committing. NOTE: the larger patch from a couple of days ago has
extracting this from security.json should we want to pursue that at some point.
> 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-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}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
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 (yck, 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}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
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
Slight modification to use a system variable that defaults to 1024.
Running full test suite now, if all goes well I intend to check this in
sometime in the next couple of days.
Thanks Jeremy!
> 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
> Attachments: 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}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Martini updated SOLR-9609:
-
Attachment: SOLR-9609.patch
> 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
> Attachments: 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}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Martini updated SOLR-9609:
-
Description:
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}
{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.
was:
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}
{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 this now everything seems to work great.
> 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
> Attachments: 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}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[
https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Martini updated SOLR-9609:
-
Attachment: solr.log
> 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
> Attachments: 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}
> 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 this now everything seems to work great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
