the other way to determine your default provider is to dump java.security:
cat $JAVA_HOME/jre/lib/security/java.security
hoss suggests you determine the default provider and default protocol with this
simple test:
public static void main(String[] args) throws Exception {
System.out.println(javax.net<http://javax.net/>.ssl.SSLContext.getDefault().getProvider());
System.out.println(javax.net<http://javax.net/>.ssl.SSLContext.getDefault().getProtocol());
}
what do you see for either test?
Martin
______________________________________________
________________________________
From: Joel Bernstein <joels...@gmail.com>
Sent: Wednesday, April 4, 2018 3:35 PM
To: lucene dev
Subject: Re: TestSSLRandomization is failing everytime
The code below ran fine from the command line and from a basic test case:
System.out.println(javax.net<http://javax.net>.
javax.net - This domain may be for sale!<http://javax.net/>
javax.net
{domain} has been informing visitors about topics such as {related1}. Join
thousands of satisfied visitors who discovered {related2}. This domain may be
for sale!
ssl.SSLContext.getDefault().getProvider());
System.out.println(javax.net<http://javax.net>.ssl.SSLContext.getDefault().getProtocol());
The source code that throws the exception in JavaKeyStore.engineLoad is:
if (password != null) {
byte computed[], actual[];
computed = md.digest();
actual = new byte[computed.length];
dis.readFully(actual);
for (int i = 0; i < computed.length; i++) {
if (computed[i] != actual[i]) {
Throwable t = new UnrecoverableKeyException
("Password verification failed");
throw (IOException)new IOException
("Keystore was tampered with, or "
+ "password was incorrect").initCause(t);
}
}
}
Notice that it's simply comparing the bytes from two digests.
The digests are prepared using a SHA digest, notice that it just specifies SHA,
which must choose the default SHA digest for the system it's on. If
it choses a different SHA digest the password would not match. My best bet
right now is that I've changed my default SHA digest to be something
other then what was used to create the passwords for the test framework:
/**
* To guard against tampering with the keystore, we append a keyed
* hash with a bit of whitener.
*/
private MessageDigest getPreKeyedHash(char[] password)
throws NoSuchAlgorithmException, UnsupportedEncodingException
{
int i, j;
MessageDigest md = MessageDigest.getInstance("SHA");
byte[] passwdBytes = new byte[password.length * 2];
for (i=0, j=0; i<password.length; i++) {
passwdBytes[j++] = (byte)(password[i] >> 8);
passwdBytes[j++] = (byte)password[i];
}
md.update(passwdBytes);
for (i=0; i<passwdBytes.length; i++)
passwdBytes[i] = 0;
md.update("Mighty Aphrodite".getBytes("UTF8"));
return md;
}
Joel Bernstein
http://joelsolr.blogspot.com/
On Wed, Apr 4, 2018 at 2:11 PM, Joel Bernstein
<joels...@gmail.com<mailto:joels...@gmail.com>> wrote:
Thanks Hoss, I will give this a try.
Joel Bernstein
http://joelsolr.blogspot.com/
On Wed, Apr 4, 2018 at 1:42 PM, Chris Hostetter
<hossman_luc...@fucit.org<mailto:hossman_luc...@fucit.org>> wrote:
: I suspect I hosed something to do with my root certs on my local machine.
: Fairly recently I was playing around with these certs while doing some SSL
: work for Alfresco. This should be fun to fix...
if that's your suspicion, i would start by testing out a simple java app
that does nothing but...
public static void main(String[] args) throws Exception {
System.out.println(javax.net<http://javax.net>.ssl.SSLContext.getDefault().getProvider());
System.out.println(javax.net<http://javax.net>.ssl.SSLContext.getDefault().getProtocol());
}
...if thta fails on the commandline, then ou definitely hozed your
machine.
If that *does* work on the commandline, then try the same code in a
trivial Junit test that just subclasses LuceneTestCase -- NOT
SolrTestCaseJ4 -- to see if the problem is somewhere in our ant/lucene
build setup, independent of any Solr SSL randomization.
:
: Joel Bernstein
: http://joelsolr.blogspot.com/
:
: On Wed, Apr 4, 2018 at 12:29 PM, Joel Bernstein
<joels...@gmail.com<mailto:joels...@gmail.com>> wrote:
:
: > Ok, so it does sounds like a local problem then. Nothing much has changed
: > locally. I'm still using the same Mac and Java version:
: >
: > defaultuildsMBP:clone2 joelbernstein$ java -version
: >
: > java version "1.8.0_40"
: >
: > Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
: >
: > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
: >
: > I'll try running on a newer version of Java.
: >
: >
: >
: > Joel Bernstein
: > http://joelsolr.blogspot.com/
: >
: > On Wed, Apr 4, 2018 at 12:19 PM, Chris Hostetter
<hossman_luc...@fucit.org<mailto:hossman_luc...@fucit.org>
: > > wrote:
: >
: >>
: >> : Subject: Re: TestSSLRandomization is failing everytime
: >>
: >> : When I run locally I get this stack trace:
: >>
: >> would be helpful to konw the branch, and the GIT SHA ... and if you can
: >> reproduce if you checkout an older branch/SHA where you know you didn't
: >> see this failure in the past (ex: the last SHA you committed, where you
: >> should have run all tests to be certain you didn't break anything)
: >>
: >> Personally I can't reproduce on master/8e276b90f520d ...
: >>
: >> Let's look at the exception...
: >>
: >> : [junit4] > Caused by: java.lang.RuntimeException: Unable to
: >> : initialize 'Default' SSLContext Algorithm, JVM is borked
: >> :
: >> : [junit4] > at
: >> : org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.<clinit>(T
: >> estMiniSolrCloudClusterSSL.java:67)
: >> :
: >> : [junit4] > ... 40 more
: >> :
: >> : [junit4] > Caused by: java.security.NoSuchAlgorithmException:
: >> Error
: >> : constructing implementation (algorithm: Default, provider: SunJSSE,
: >> class:
: >> : sun.security.ssl.SSLContextImpl$DefaultSSLContext)
: >>
: >> At first glance, it sounds like your JVM is completley jacked and doesn't
: >> have any SSL support?
: >>
: >> The code throwing that exception is litterally...
: >>
: >> DEFAULT_SSL_CONTEXT = SSLContext.getDefault();
: >>
: >> ...ie: your JVM is saying the *default* SSL Algorithm, as choosen by the
: >> JVM config, doens't exist ... but if we look farther down...
: >>
: >> : [junit4] > Caused by: java.io.IOException: Keystore was tampered
: >> : with, or password was incorrect
: >> ...
: >> : [junit4] > Caused by: java.security.UnrecoverableKeyException:
: >> : Password verification failed
: >>
: >> ...well that's interesting. We do provide our own keystore when using
: >> SSLTestConfig, but I honestly don't know off the top of my head if that's
: >> even in use when this code is running?
: >>
: >> Can you tell us *ANYTHING* about the machine/jvm where you are running
: >> this, and or what might have changed on your end since hte last time you
: >> ran all tests w/o failure? what OS? new laptop? new java install? if you
: >> "git co releases/lucene-solr/7.2.0" does this test pass? if so can you
: >> "git bisect" to track down when it starts failing? etc...
: >>
: >>
: >>
: >> -Hoss
: >> http://www.lucidworks.com/
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail:
dev-unsubscr...@lucene.apache.org<mailto:dev-unsubscr...@lucene.apache.org>
: >> For additional commands, e-mail:
dev-h...@lucene.apache.org<mailto:dev-h...@lucene.apache.org>
: >>
: >>
: >
:
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscr...@lucene.apache.org<mailto:dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail:
dev-h...@lucene.apache.org<mailto:dev-h...@lucene.apache.org>
