Proxy-Server und MITM<\/h3>\n
Setzt ein Unternehmen Proxy-Server zur \u00dcberwachung\/Filterung ein, brechen diese TLS-Verschl\u00fcsselungen auf und verschl\u00fcsseln neu. Es ist hier also keine Ende-zu-Ende Verschl\u00fcsselung bis zum Client mehr, sondern nur bis zum Proxyserver im Unternehmensnetz. Oder gegebenenfalls dem Anbieter, wenn jemand meint, externe Clouddienste wie ZScaler zu nutzen. In jedem Falle l\u00e4sst sich die Integrit\u00e4t der urspr\u00fcnglich genutzten Verschl\u00fcsselung nicht mehr sicherstellen, weswegen der Client dem Proxyserver vertrauen muss. Bei einem internen Unternehmensdienst reicht die unternehmenseigene Zertifizierungsstelle. Im Falle eines externen Dienstes muss man zus\u00e4tzlich dessen Root-Zertifikat vertrauen. Ansonsten brechen Clients die Verbindung ab, da nicht vertrauensw\u00fcrdige Zertifikate bzw. Zertifizierungsstellen als Sicherheitsrisiko gesehen werden.<\/p>\n
Wo liegt der TrustStore von Java?<\/h2>\n
Standardm\u00e4\u00dfig in $JAVA_HOME\/jre\/lib\/security\/cacerts<\/strong>, wobei $JAVA_HOME<\/strong> der Basis-Ordner der Java-Installation ist. Wenn ihr Java als Archiv herunterladet und es entpackt, ist dies (ohne Unterordner f\u00fcr die Version) das Heimverzeichnis. Im Folgenden Beispiel von Adoptium OpenJDK<\/a> der Inhalt von jdk-11.0.20.1+1<\/strong> im Archiv:<\/p>\n Bei einer h\u00e4ndischen Installation w\u00fcrde man dessen Inhalt in ein beliebiges Verzeichnis (gerne \/opt f\u00fcr h\u00e4ndisch installierte, optionale Software) entpacken, beispielsweise \/opt\/openjdk-11<\/strong>. <\/p>\n Der TrustStore l\u00e4ge dort in \/opt\/openjdk-11\/lib\/security\/cacerts<\/strong>:<\/p>\n Anders kann es aussehen, wenn man Java \u00fcber die Paketverwaltung der Distribution installiert. Auf einem Suse Linux Enterprise (SLES) habe ich ihn beispielsweise in \/usr\/java\/latest\/lib\/security\/cacerts<\/strong> gefunden, bzw. in einem Unterordner f\u00fcr die jeweilige Version mit Build unter \/usr\/java<\/strong>. Der Pfad kann variieren, je nachdem welche GNU\/Linux-Distribution und welche Java-Distribution ihr nutzt. Sollte v\u00f6llige Unklarheit herrschen, kann man sich $JAVA_HOME <\/strong>ausgeben lassen. Ist dies nicht gesetzt, kann man sich den Pfad von Java auch \u00fcber die Properties ausgeben lassen:<\/p>\n Der TrustStore von Java ist keine Textdatei mit einer Zertifikatskette, sondern eine Bin\u00e4rdatei: Seit Java wird PKCS12 verwendet. Sie muss mit keytool<\/strong> bearbeitet werden, was wiederum in $JAVA_HOME<\/strong>\/bin liegt. Mit dem Befehl -list<\/strong> kann man sich einen \u00dcberblick verschaffen, welche Zertifikate darin liegen. Hier sind es 143 St\u00fcck, die Ausgabe mit den Pr\u00fcfsummen wurde gek\u00fcrzt. Bei jeder Operation fordert das Keytool zur Eingabe eines Passwortes auf. Dies lautet standardm\u00e4\u00dfig changeit<\/strong> und wird – wie unter GNU\/Linux \u00fcblich – beim Tippen nicht angezeigt:<\/p>\n In den meisten F\u00e4llen wird man den TrustStore um ein neues (Root-) Zertifikat erweitern wollen, dies funktioniert mit dem Befehl -importcert<\/strong>.<\/p>\n Das Alias meine-ca<\/em>-2023 ist eine frei w\u00e4hlbare Bezeichnung, die jedoch innerhalb des TrustStore einzigartig sein muss. Mit -file<\/strong> gebt ihr den Pfad zur Zertifikatsdatei an. Nachdem ihr mit yes<\/strong> best\u00e4tigt habt, dem Zertifikat zu vertrauen, wird es importiert. Falls das Zertifikat bereits existiert, aber unter einem anderen Alias importiert wurde, warnt euch das Werkzeug.<\/p>\n M\u00f6chte man etwa ein ausgelaufenes Zertifikat entfernen, ist dies mit -delete<\/strong> m\u00f6glich. Identifiziert wird es anhand des beim hinzuf\u00fcgen definierten Aliases:<\/p>\n Standardm\u00e4\u00dfig l\u00e4dt Java den TrustStore aus dem oben Pfad $JAVA_HOME\/jre\/lib\/security\/cacerts<\/strong>. In vielen F\u00e4llen ist das auch in Ordnung. Doch es gibt Szenarien (z.B. zum testen), in denen man lieber einen anderen laden m\u00f6chte. Hierf\u00fcr gibt es zwei Eigenschaften (Properties), die man an Java jeweils mit -D \u00fcbergeben kann:<\/p>\n Zum Start einer Java-Anwendung kann der Aufruf wie folgt aussehen:<\/p>\n Java ist nicht gerade als leichtgewichtiges, effiziente Plattform bekannt. Durchaus auch dank Spezialisten wie Atlassian: Die haben es geschafft, relativ einfache Anwendungen wie z.B. Bitbucket so aufzubl\u00e4hen, dass sie mehrere Minuten (!) zum Starten ben\u00f6tigen. Und das auf leistungsstarken Servern mit 6 Xeon-Kernen. Gogs, GitTea & diverse weitere realisieren das in Sekunden auf einem Raspberry Pi, ohne tausende Dollar propriet\u00e4re Lizenzgeb\u00fchren daf\u00fcr zu verlangen – tr\u00e4ge Software ist offensichtlich kein Naturgesetz. Jedenfalls ist es mit solchen Monstern extrem z\u00e4h, derartiges zu testen. Statt mich noch mehr \u00fcber Atlassians Qualit\u00e4t<\/em> aufzuregen, habe ich mir daher eine simple Klasse geschrieben, die eine HTTP-Abfrage durchf\u00fchrt:<\/p>\n M\u00f6chte man eine interne CA testen, sollte man die Adresse auf eine anpassen, die ein entsprechendes Zertifikat verwendet. Um den Code zu kompilieren, wird das JDK ben\u00f6tigt. Das JRE kann kompilierte Anwendungen nur ausf\u00fchren. Falls ihr das Gl\u00fcck habt, an einer Anwendung zu arbeiten, die (richtigerweise) nur das JRE mitbringt: Ermittelt die Version und ladet euch das JDK in der gleichen herunter. F\u00fcr Tests reicht eine manuelle Installation \u00fcber das Archiv (siehe oben) v\u00f6llig aus, die l\u00f6scht man danach sowieso wieder. Ich nehme in diesem Beispiel die gleiche Version in $JAVA_HOME<\/strong> und kann nun in einer kleinen, kompakten Anwendung sehr effektiv ausprobieren, ob der TrustStore funktioniert.<\/p>\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2023\/10\/grafik.png\")
<\/a><\/figure>\n<\/div>\nsudo mkdir \/opt\/openjdk-11\nsudo chown $USER \/opt\/openjdk-11\n\ntar --strip-components=1 -xf OpenJDK11U-jdk_x64_linux_hotspot_11.0.20.1_1.tar.gz -C \/tmp\/openjdk-11<\/code><\/pre>\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2023\/10\/grafik-1.png\")
<\/a><\/figure>\n<\/div>\njava -XshowSettings:properties -version 2>&1 > \/dev\/null | grep 'java.home'\n java.home = \/usr\/lib\/jvm\/java-21-openjdk<\/code><\/pre>\nEinsehen, Hinzuf\u00fcgen und \u00e4ndern von Zertifikaten<\/h2>\n
$JAVA_HOME\/bin\/keytool -list -cacerts -file $JAVA_HOME\/lib\/security\/cacerts\nEnter keystore password:\nKeystore type: JKS\nKeystore provider: SUN\nYour keystore contains 143 entries\n...<\/code><\/pre>\n$JAVA_HOME\/bin\/keytool -importcert -alias meine-ca-2023 -keystore $JAVA_HOME\/lib\/security\/cacerts -file meine-ca-2023.crt\nEnter keystore password:\nOwner: ...\nTrust this certificate? [no]: yes\nCertificate was added to keystore<\/code><\/pre>\n$JAVA_HOME\/bin\/keytool -delete -alias meine-ca-2023 -keystore $JAVA_HOME\/lib\/security\/cacerts<\/code><\/pre>\nVerwenden des Stores & Fehlersuche<\/h2>\n
\n
java -Djavax.net.ssl.trustStore=\/tmp\/cacert-test -Djavax.net.ssl.trustStorePassword=changeit WebserviceDemo<\/code><\/pre>\nTests mit einfachem HTTP-Aufruf<\/h2>\n
import java.io.IOException;\nimport java.net.URI;\nimport java.net.http.HttpClient;\nimport java.net.http.HttpRequest;\nimport java.net.http.HttpResponse;\n\npublic class WebserviceDemo { \n\tpublic static void main (String[] args) throws IOException, InterruptedException {\n \tHttpClient client = HttpClient.newHttpClient();\n \tHttpRequest request = HttpRequest.newBuilder()\n .uri(URI.create("https:\/\/api.ipify.org?format=json"))\n .build();\n\t HttpResponse<String> response = client.send(request,\n HttpResponse.BodyHandlers.ofString()); \n\t System.out.println(response.body());\n }\n}<\/code><\/pre>\n$JAVA_HOME\/bin\/javac WebserviceDemo.java\n$JAVA_HOME\/bin\/java -Djavax.net.ssl.trustStore=\/tmp\/cacert-test -Djavax.net.ssl.trustStorePassword=changeit WebserviceDemo<\/code><\/pre>\nFehlersuche mit Debug-Parametern<\/h2>\n