Illegal geworfen von Maven (? SSL-bezogene), wenn Projektabhängigkeiten Herunterladen

Question

Ich bin eine Entwicklungsumgebung auf einer ARM-Maschine, mit den folgenden Versionen von Java und Maven Einrichtung, die beide über apt-get installiert:

(xenial)craig@localhost:~$ mvn -version 
Apache Maven 3.3.9 
Maven home: /usr/share/maven 
Java version: 1.8.0_91, vendor: Oracle Corporation 
Java home: /usr/lib/jvm/java-8-openjdk-armhf/jre 
Default locale: en_US, platform encoding: ANSI_X3.4-1968 
OS name: "linux", version: "3.14.0", arch: "arm", family: "unix" 

(xenial)craig@localhost:~$ java -version 
openjdk version "1.8.0_91" 
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14) 
OpenJDK Zero VM (build 25.91-b14, interpreted mode) 

Wenn ich jedoch ein mvn clean install auf meinem Projekt ausführen, schlägt es fehl, eine POM-Datei herunterzuladen, die existiert. (Ich kann es in meinem Browser besuchen.)

Der Stacktrace ist recht groß, aber die Wurzel zu sein scheint:

Caused by: java.lang.IllegalStateException 
    at sun.security.ec.ECDHKeyAgreement.deriveKey(Native Method) 
    at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:130) 
    at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:163) 
    at javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:648) 
    at sun.security.ssl.ECDHCrypt.getAgreedSecret(ECDHCrypt.java:101) 
    at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1067) 
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) 
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) 
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) 
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) 
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) 
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) 

Es leider nicht viel mehr ist - Maven nicht mit:

Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.jacoco:jacoco-maven-plugin:jar:0.7.6.201602180812 

Und der Stapel endet mit der Ausnahme in deriveKey() geworfen geworfen. Fehle ich eine Crypto-Bibliothek auf meinem Computer?

Dies ist eine Neuinstallation von Xenial (16.04 LTS).

Answer 1

Während der Installation der Oracle JRE der einfache Ausweg ist, hier sind die Anweisungen für den Fall, dass Sie die OpenJDK Zero VM speziell verwenden möchten, sei es mit Maven, SSL, der ECDH-Schlüsselvereinbarung oder einer anderen Krypto-Methode systemeigener Code im Standardkryptoanbieter von OpenJDK.

Ich habe angenommen, dass die ECDHKeyAgreement.deriveKey Methode fehlschlägt, weil es eine native Methode ist und die OpenJDK Zero VM wie in Ubuntu für Raspberry Pi verpackt einfach nicht damit umgehen kann; Ich bin nicht ausgerüstet, um diesen Fehler zu beheben.

Ubuntu packt den BouncyCastle Crypto Provider, der in reinem Java implementiert ist. Sie müssen es die übliche Art und Weise installieren:

sudo apt install libbcprov-java* 

Dann folgen Sie den Anweisungen in /usr/share/doc/libbcprov-java/README.Debian (dies kann auch die Dokumentation installiert) es der Standard-Krypto-Anbieter zu machen. Genauer gesagt, müssen Sie eine Verknüpfung zum Provider jar aus dem ext-Verzeichnis der JRE herstellen, also tun Sie eine update-java-alternatives -l gefolgt von (in meinem Fall - ich habe die Standardeinstellungen in Ubuntu 16.04 Raspberry Pi Server-Installation verwendet - die spezifische JRE Verzeichnis kann in der Zeit ändern):

sudo ln -s /usr/share/java/bcprov.jar /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/ext/bcprov.jar 

dann die /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/security/java.security Datei bearbeiten (den Editor mit sudo) aufgerufen wird, das Hinzufügen der Zeile:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 

... wo die Krypto-Anbieter aufgeführt sind, und das Hinzufügen 1 zu der Priorität der bereits dort, so dass die Liste ähnlich aussieht:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 
security.provider.2=sun.security.provider.Sun 
security.provider.3=sun.security.rsa.SunRsaSign 
security.provider.4=sun.security.ec.SunEC 
security.provider.5=com.sun.net.ssl.internal.ssl.Provider 
security.provider.6=com.sun.crypto.provider.SunJCE 
security.provider.7=sun.security.jgss.SunProvider 
security.provider.8=com.sun.security.sasl.Provider 
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI 
security.provider.10=sun.security.smartcardio.SunPCSC 

Crypto in Java sollte nun funktionieren, wenn auch sehr langsam. Hier ist ein Beispiel Programm, das ich verwendet habe, um zu bestätigen, dass es funktioniert, wenn Sie nicht Maven wollen dafür verwenden:

import java.io.InputStream; 
import java.net.URL; 
import java.net.URLConnection; 

public class URLGet { 
     public static void main(String[] args) { 
       try { 
         URL url = new URL(args[0]); 
         URLConnection urlConnection = url.openConnection(); 
         try (
           InputStream stream = urlConnection.getInputStream(); 
         ) { 
           byte[] buf = new byte[4096]; 
           int read; 
           while ((read = stream.read(buf, 0, buf.length)) > 0) { 
             System.out.write(buf, 0, read); 
           } 
         } 
       } catch (Exception e) { 
         e.printStackTrace(System.err); 
       } 
     } 
} 

Punkt es jede https-URL (zB java URLGet https://www.google.com/), um zu bestätigen, dass Java SSL umgehen kann .