Explizites Freigeben von bestimmten Java-Applets im Browser via Deployment-Config (Sicherheitswarnung deaktivieren)

1. Einleitung

Wie Ihr wahrscheinlich wisst hat Oracle seit der Java Runtime 7 Update 21 einen zwingenden Bestätigungsdialog für Java-Applets welche im Browser ausgeführt werden, eingeführt.


Dies fördert auf jeden Fall die Sicherheit im Browser erheblich, jedoch gibt es sicher Einige unter euch bei denen dies die Usability beim Endanwender nicht erlaubt, z.B. in Unternehmen, und Anwendungen die von vielen Nutzern genutzt werden.

Diese Anleitung gibt einen Leitfaden, wie man bestimme Applets in eine Whitelist befördert, und die Ausführung des Applets dann nicht mehr vom Enduser bestätigt werden muss.

2. Benötigte Tools

• Java JDK

Hinweis: Alle hier verwendeten Kommandozeilen-Tools befinden sich im bin-Verzeichnis des Java JDK:
Hinweis: Unter Punkt 10 gibt es ein Batch-Script das die folgenden Schritte zusammenfasst.

3. Erstellen eines Ruleset (ruleset.xml)

Zu aller erst müssen wir festlegen welche Internet-Seiten wir freischalten möchten. Dazu erstellen wir eine XML-Datei mit dem Namen ruleset.xml
Wo das Stammverzeichnis eingetragen wird seht ihr ja. Für ein Beispiel geben wir die Demo-Applets auf der Oracle-Seite zur Ausführung frei. Die Ausführung ohne Bestätigung legt das <action permission="run" /> fest. Sollen z.B. Applets auf einer bestimmten Seite nicht ausgeführt werden dürfen machen wir das mit <action permission="block" />.

Die zweite Regel ohne Angabe einer URL besagt das für alle anderen Seiten Standardmäßig eine Bestätigung angefordert wird. Diese Regel sollte als letztes im Ruleset eingefügt werden (Die Reihenfolge zählt!"). Will man alle anderen Seiten blocken setzt man bei dieser letzten Regel <action permission="block" /> so hat man dann eine Whitelist eingerichtet.

Was damit sonst noch alles möglich ist könnt Ihr hier nachlesen.

Sonderfälle (Verwendung des SHA256 Hash einer JAR-Datei):

Bei bestimmten Seiten die eine Java-Workspace-Datei des Typs *.jnlp laden ist es oft nötig den Zertifikatshash der verwendeten JAR-Dateien ebenfalls im ruleset zu hinterlegen. Dazu macht man folgendes um an den SHA256 Hash des JAR-Files zu kommen:
Die Anwendung im Browser laden und die zusätzlichen JAR-Dateien in den Cache laden lassen. Diese werden im Verzeichnis
in einem der diversen Unterverzeichnisse abgelegt, aber, jetzt kommt es, diese haben nicht die Endung *.jar sondern kryptische Namen. Man kann sie nur anhand eines Hex-Editors, anhand der Größe, oder des Datums als JAR-Dateien identifizieren. Dann wird diese Datei kopiert, mit der Endung *.jar versehen, und mit folgender Befehlszeile lässt man sich dann den Hash anzeigen:
In der Ausgabe steht dann auf der ersten Seite von More folgendes:
Hier nehmen wir alle hexadezimalen Zahlen hinter SHA256: und entfernen daraus die Doppelpunkte; dies ist dann der Hash welcher mit folgender Rule zusätzlich in die XML-Datei eingetragen wird.
Aber wie oben schon erwähnt, ist auf die Reihenfolge zu achten; diese Regel also noch vor der Default-Regel einfügen!

4. Verpacken des Ruleset in einem JAR-Archiv

Unsere XML-Datei muss nun in ein JAR-Archiv gepackt werden welche den Namen DeploymentRuleSet.jar bekommen muss. Dies geschieht mit dem Kommandozeilentool jar.exe im bin-Verzeichnis des JDK.
ACHTUNG ! Zu Beachten gilt es hier, dass man sich beim Ausführen des Befehls im selben Verzeichnis wie die ruleset.xml befinden sollte, damit diese nicht in einem Unterordner innerhalb der JAR-Datei landet. Am einfachsten ist es wenn Ihr die ruleset.xml im JDK-Verzeichnis erstellt oder aber den gesamten Pfad zur jar.exe in der Befehlszeile angebt.


Überprüfen könnt Ihr das z.B. mit dem JavaDecompiler

Dieses JAR-Archiv muss nun mit einem Zertifikat signiert werden, damit es akzeptiert wird. Dies machen wir nun in den nächsten Schritten.

5. Erstellen eines Zertifikats-Keystore

Für das Beispiel erstellen wir ein selbstsigniertes Zertifikat.
Hier verwenden wir für das Zertifikat den Alias-Namen myalias und das Passwort GEHEIM. Das Zertifikat wird dann in einen Keystore mit dem Namen keystore.jks gespeichert.
Nach drücken von ENTER, werden die Informationen für das Zertifikat abgefragt die man alle entsprechend einträgt:

6. Signieren der DeploymentRuleSet.jar

Da wir nun den entsprechenden Zertifikats-Store zur Verfügung haben können wir das JAR-File damit signieren:
Da dieses Zertifikat ja ein selbstsigniertes Zertifikat ist müssen wir es erst noch in den Zertifikatsspeicher von Windows in die "Vertrauenswürdige Stammzertifizierungsstellen" importieren, wenn wir nur den Internet Explorer als Browser verwenden wollen (wie man das Zertifikat global für alle Browser freischaltet steht unter Punkt 7). Dazu exportieren wir das Zertifikat aus dem Keystore in eine Datei:
Um es nun zu importieren klicken wir doppelt auf das Zertifikat, wählen "Zertifikat installieren", klicken auf weiter, wählen dann "Alle Zertifikate in folgendem Speicher speichern", aktivieren die Option Physikalischen Speicher anzeigen und dann den Ordner "Vertrauenswürdige Stammzertifizierungsstellen\Lokaler Computer". Abschließend alle Dialoge mit OK abschließen. Zusätzlich stellen wir sicher das die Option Zertifikate und Schlüssel im Browser-Keystore verwenden in den Java-Einstellungen gesetzt ist:

7. Verwenden von anderen Browsern als dem Internet Explorer

Wenn man auch andere Browser als den Internet-Explorer verwenden möchte (Firefox, etc) muss man das selbstsignierte Zertifikat in den Java-CA-Zertifikatsstore importieren. Wenn Ihr das nicht benötigt könnt Ihr zu Punkt 8 übergehen.

7.1 Importieren des eigenen Zerfifikats in den CA-Keystore von Java

(Dabei muss der Pfad je nach Java-Version(32/64-Bit) und der Pfad zum eigenen Zertifikat entsprechend angepasst werden. Den Alias können wir frei wählen, er sollte aber eindeutig sein)

32-Bit Java Runtime 7
64-Bit Java Runtime 7
Es kommt dann eine Passwortabfrage für den CA-Store, das Passwort lautet changeit. Danach muss man den Import noch mit der Eingabe von Ja bestätigen. Ab jetzt vertraut Java dem Zertifikat. Eventuell geöffnete Browserfenster müssen einmal geschlossen und wieder geöffnet werden.

7.2 (Bei Bedarf) Entfernen des Zertifikates aus dem CA-Keystore

Will man das eigene Zertifikat wieder aus dem CA-Store entfernen genügt folgender Befehl
(Hierbei verwenden wir wieder den Alias den wir beim Import verwendet haben; auch hier wird man wieder nach dem Passwort für den Keystore gefragt (changeit). Nachdem man es eingegeben hat, wird das Zertifikat entfernt und im Erfolgsfall keine Meldung ausgegeben.)

32-Bit Java Runtime:
64-Bit Java Runtime:

8. Kopieren der DeploymentRuleSet.jar in das Java-Deployment-Verzeichnis

Abschließend kopieren wir die signierte DeploymentRuleSet.jar in folgenden Ordner:
Um zu überprüfen ob das Ruleset erfolgreich erkannt wurde, öffnen wir die Java-Einstellungen in der Systemsteuerung von Windows und wechseln auf den Tab Sicherheit. Dort sollte nun ein Link erscheinen mit dem man das Ruleset und dessen Details anzeigen kann.



Nun kann man mit einem Browser z.B. die Demo Applets von Oracle ansehen ohne eine Bestätigung abnicken zu müssen:
http://www.oracle.com/technetwork/java/index-135948.html

9. Verwenden von gültigen Zertifikaten zum Signieren

Das selbstsignierte Zertifikat genügt bereits für Testzwecke. Im Produktivbetrieb sollte aber ein Zertifikat einer bekannten Certification Authority (CA) vorhanden sein. Um ein solches Zertifikat zu erhalten, sind zwei Schritte durchzuführen:

9.1 Zertifikatsantrag (Certificate Signing Request) erstellen

Es muss ein Zertifikatsantrag für das Schlüsselpaar im Keystore erstellt werden, der an die CA übermittelt wird. Die CA prüft diesen Antrag gemäß ihren Richtlinien und erteilt dann das Zertifikat. Der Zertifikatsantrag kann mit dem folgenden Kommando generiert werden:
Die so erzeugte Datei muss dann zusammen mit weiteren Daten, die von der CA gewünscht werden, an diese übermittelt werden.

9.2 Zertifikat in den Keystore importieren

Hat die CA das Zertifikat ausgestellt, wird es zugeschickt oder kann heruntergeladen werden. Dann muss es noch in den Keystore importiert werden. Dies erfolgt mit:

10. Batchdatei zur einfachen Erstellung der DeploymentRuleSet.jar

Für all diejenigen unter euch die das ganze etwas beschleunigen möchten, hier noch ein Batch-File das die nötigen Schritte zusammenfasst. Speichert euch den Code als *.bat oder *.cmd in einem Verzeichnis eurer Wahl zusammen mit eurer erstellten ruleset.xml Datei, passt die Variablen in den Zeilen 4,6,8 und 10 entsprechend an eure Umgebung an und startet das Script.
Alle Pfadangaben bitte ohne abschließenden Backslash

Viel Spaß

Grüße @colinardo
Falls der Beitrag gefällt, seid so nett und unterstützt mich durch eine kleine Spende / If you like my contribution please support me and donate

Updates

Datum	Änderungen / Hinweise
03.06.2014	+ Punkt 10: Batch-Script zur Vereinfachung der ganzen Prozedur hinzugefügt + Expliziterer Hinweis mit Bildern auf die Wichtigkeit der Pfade beim Erstellen der JAR-Datei
15.01.2014	Seit Java Runtime 7 Update 51 gibt es auch ein Interface in den Java-Einstellungen um Seiten explizit freizugeben. Bei Verwendung dieser Liste wird jedoch trotzdem noch ein Dialog angezeigt der bestätigt werden muss. Wird dennoch ein Deployment-Ruleset verwendet haben diese Vorrang vor den Einstellungen im Dialog.

---------------------------------------
<ruleset version="1.0+">
  <rule>
    <id location="https://a*****.i.d******.com" />
    <action permission="run" />
  </rule>
  <rule>
    <id location="https://d*******-y****.a**.c******.net" />
    <action permission="run" />
  </rule>
  <rule>
    <id location="http://g*****.a****.c******.net" />
    <action permission="run" />
  </rule>
  <rule>
    <id location="http://53.***.**.*" />
    <action permission="run" />
  </rule>
  <rule>
    <id />
    <action permission="default" />
  </rule>
 </ruleset>
---------------------------------------------------