The code:

public static void main(String[] args) throws Exception {
        System.out.println(javax.net.ssl.SSLContext.getDefault().get
Provider());
        System.out.println(javax.net.ssl.SSLContext.getDefault().get
Protocol());
 }

returns this from the command line:

SunJSSE version 1.8

Default

I believe this won't trip the issue I'm seeing because the error coming
when from the password check, which is not occurring from the command line.
The SSL test cases do cause a password check and that's where the error is
generated when comparing the digests.





Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Apr 4, 2018 at 5:26 PM, Martin Gainty <mgai...@hotmail.com> wrote:

> 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.ssl.SSLContext.getDefault().get
> Provider());
>         System.out.println(javax.net.ssl.SSLContext.getDefault().get
> Protocol());
>     }
>
> 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.
> 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.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> 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>
> 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.ssl.SSLContext.getDefault().get
> Provider());
>         System.out.println(javax.net.ssl.SSLContext.getDefault().get
> Protocol());
>     }
>
> ...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>
> 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
> : > > 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.UnrecoverableKey
> Exception:
> : >> : 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
> : >> For additional commands, e-mail: dev-h...@lucene.apache.org
> : >>
> : >>
> : >
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>

Reply via email to