Seite 2: Anwender- und Entwicklersicht

Inhaltsverzeichnis

Die Sicht des Anwenders

Der Anwender bekommt übrigens bis hier nur wenig von den beschriebenen Aktivitäten mit. Startet er die bereitgestellte Webseite über seinen Browser, weist dieser ihn lediglich einmal grundsätzlich auf den aktiven Inhalt hin (siehe Beispiel-Screenshots IE und Chrome). Das geschieht aber allein aufgrund der Tatsache, dass es sich um ein Java-Applet handelt, und ist abhängig von der gewählten Sicherheitseinstellung im Browser. Hier spielt weder das oben genannte Java Control Panel noch eine andere Sicherheitseinstellung von Java eine Rolle.

Bestätigt der Anwender nun, dass er Java wirklich ausführen will, startet das Browser-Plug-in die Java Virtual Maschine und führt die Anwendung aus. Erst hier folgt die erste Hinweismeldung von Java (s. Abb. 4)

Dabei sind die Meldungen von Java im Browser vielfältig in Form und Farbe und doch alle sehr ähnlich aufgebaut. In Abhängigkeit des durch Oracle eingeschätzten Risiko-Levels werden die Meldungen, die auf weniger risikoreiche Anwendungen hinweisen, mit dem Java-Logo oder einem blauen Schild mit einem "i" (für Information) darin dargestellt (Abb. 5).

Meldungen mit einem gelb hinterlegten Ausrufezeichen (Schild oder Dreieck, vgl. Abb. 4) informieren den Anwender über ein entsprechend höheres Risiko. Das gelbe Dreieck erscheint bei nicht vertrauenswürdigen oder abgelaufenen Zertifikaten, das Schild bei unsignierten Anwendungen oder bei Anwendungen mit ungültigem Zertifikat. Bisher gab es also nur ein einheitliches Gelb für alle Dialoge, die auf nicht signierte Inhalte hingewiesen haben. Die Interpretation der textuellen Details oder auch den Unterschied zwischen Schild und Dreieck mussten sich die Anwender irgendwann aneignen. Viele kennen den Unterschied vermutlich bis heute nicht. Mit dem nun vorliegenden Java 7 Update 21 werden diese Dialoge ein wenig konkreter. Bei bestimmten Kombinationen erscheint ein zusätzlicher Text in roter Schrift. Die neue Kennzeichnung bestimmt die Kombination der folgenden Attribute:

• signierte beziehungsweise nicht signierte Anwendung
• nicht vertrauenswürdiges, abgelaufenes oder ungültiges Zertifikat
• Anwendung erfordert Sandbox oder volle Berechtigung

Zukünftig hat beispielsweise die Java-Bestätigungsmeldung für eine nicht signierte Anwendung einen zusätzlichen in Rot dargestellten Text, und Oracle weist auf einer separaten Webseite darauf hin, dass diese Art von Anwendungen besser nicht ausgeführt werden soll.

Das blaue, vertrauenswürdige Ausrufezeichen und das Java-Logo werden nur noch bei Anwendungen angezeigt, die mit einem gültigen Zertifikat von einer vertrauten CA signiert wurden. Eine vollständige Auflistung der Kombinationen und der dazugehörigen Anzeigen findet sich auf der Webseite von Oracle.

Hintergrund für den Entwickler

Für den Entwickler bedeuten die Änderungen erst einmal, dass die Mehrzahl der Endanwender die Sicherheitsstufe nicht mehr auf "niedrig" oder individuell einstellen kann. Daraus resultiert, dass es nicht mehr so einfach ungewollt zum Ausführen nicht signierter Java-Anwendungen im Browser kommen kann. Auch wenn sich die dem Schieberegler entsprechenden Einstellungen in den "Erweiterten Einstellungen" des Java Control Panel durchaus noch vornehmen lassen, ändert sich an den Anwendungen selbst nichts. Allerdings ist es nun dringend zu empfehlen, Java-Anwendungen, die im Browser laufen sollen, mit einem gültigen Zertifikat zu signieren, wenn man ohne die neuen Warnungen auskommen will oder muss. Der grundsätzliche Prozess funktioniert einfach. Alles beginnt mit einem RSA-Schlüssel-Paar. Das lässt sich auf unterschiedliche Weise erstellen. Am einfachsten geht es mit dem Keytool aus Java.

keytool -genkey -keyalg rsa -alias HeiseDemo

Nach dem Ausführen wird man nach einer Handvoll Angaben gefragt. Diese beantwortet man entsprechend. Im Beispiel wird ein neues Schlüsselpaar mit den folgenden Attributen erzeugt:

CN=Markus Eisele, OU=Developer Channel, O=heise.de, L=Hannover, 
       ST=Niedersachsen, C=DE 

Für das Schlüsselpaar ist noch ein Passwort zu vergeben. Das geschieht ebenfalls durch das Keytool. Das Schlüsselpaar wird im Java Keystore abgelegt. Nun ist die eigentliche Zertifikatssignaturanfrage (Certificate Signing Request) zu generieren (PKCS#10). Das geschieht mit dem Befehl:

keytool -certreq -alias HeiseDemo -file myapplet.csr

Diese Aktion ist erneut mit dem Keystore-Passwort zu bestätigen. Typischerweise wird der Inhalt des Zertifikat-Requests an eine Certificate Authority (CA) gesendet. Der große Unterschied liegt hierbei in der Art der CA. Nur die 79 öffentlichen CAs, die im Keystore von Java bekannt sind, bringen den gewünschten Effekt. Oracle hat einen separaten Prozess, über den Firmen ihre Root CAs in die JVM bringen können. Für Endanwender oder große Firmen ist das kaum eine Option, da die Anforderungen umfänglich sind. Da bleibt zumeist nur der Rückgriff auf eine der bekannteren, öffentlichen CAs. Die verlangen allerdings Geld für ihre Dienstleistungen.

Die gewählte CA signiert den Request und schickt ein "PKCS#7 Public Key"-Zertifikat (bspw. cert.p7c) zurück. Es wurde von der öffentlichen Root CA signiert und lässt sich damit von der Java Runtime (JVM) validieren. Dieses ist nun ebenfalls in den Keystore zu importieren:

keytool -import -alias HeiseDemo -trustcacerts -file cert.p7c

Nach erneuter Eingabe des Keystore-Passworts steht das Zertifikat zum Signieren des Applets zur Verfügung. Das übernimmt ein weiteres JDK-Werkzeug:

jarsigner -verbose -signedjar AppletDemo.jar unsigned_Applet.jar HeiseDemo

Nach der obligatorischen Eingabe des Keystore-Passworts erscheint die Log-Ausgabe, die die konkreten Änderungen in der Jar-Datei ausgibt:

updating: META-INF/MANIFEST.MF
   adding: META-INF/MYAPPLET.SF
   adding: META-INF/MYAPPLET.RSA
   adding: appletdemo/
  signing: appletdemo/AppletDemo$1.class
  signing: appletdemo/AppletDemo.class

Damit ist das Applet signiert und wird ohne Probleme vom Browser ausgeführt. Darüber hinaus ist der Browser-Dialog von Java nun blau hinterlegt (vgl. Abb. 5) und suggeriert dem Endanwender eine deutlich höhere Vertrauenswürdigkeit.