Browserhersteller beenden Unterstützung für Java-Applets der NPAPI-Schnittstelle: Was ist zu tun?

Einleitend gilt es zunächst folgende Fragen zu klären:

Was ist NPAPI?
NPAPI ist eine API, mit der Plugins für Webbrowser entwickelt werden. Sie wird für die Integration von Plugins, z.B. Java-Applets, verwendet.

Was ist ein Java-Applet?
Ein Java-Applet ist ein Computerprogramm, das im Webbrowser ausgeführt wird, um auf Webseiten eine Interaktion zwischen Nutzer und Programm zu erlauben, ohne dass Daten zum Server geschickt werden müssen.

Wofür benötigt man überhaupt das Applet bzw. die NPAPI- Schnittstelle?
Da Applet ist erforderlich für den Zugriff aus dem Browser auf externe Hardware wie den Kartenleser für die Signaturkarte. Die NPAPI-Schnittstelle ermöglicht die Verbindung von Applet und Browser. Das Applet ist nötig für die Ansteuerung auf clientseitige Hardware (Kartenleser).

Cloud-Dienst

Was haben die Browserhersteller jetzt vor?

In einem ersten Schritt wird die Möglichkeit der Ausführung zunächst nur blockiert bzw. erschwert. In einem zweiten Schritt soll dann die Ausführung von Java-Applets aus Sicherheitsgründen im Browser ganz untersagt werden.

Der erste Browser, für den uns dieses Problem trifft, ist der Google Chrome-Browser in Version 42.
Für unsere Kunden bedeutet das im ersten Schritt einen erhöhten Verwaltungsaufwand. Dieser entsteht, weil das Reaktivieren der Applet-Unterstützung für den Normalanwender nur schwierig zu bewerkstelligen ist und somit durch unseren Kunden per Onlinewartung durchgeführt werden muss. Die Reaktivierung soll nach Angaben von Google noch bis Herbst 2016 funktionieren. Generell planen alle Browserhersteller, Applets sogar noch bis Ende 2016 zu unterstützen.

Doch auch die „Post-NPAPI-Ära“ stellt für die SecCommerce- Kunden kein Problem dar!
Wir bieten unseren Kunden bereits heute die Möglichkeit, dieses Problem zu vermeiden, indem sie ihre im Einsatz befindliche Signaturkomponente (das SecSigner-Applet ) oder Authentifizierungskomponente (den SecAuthenticator) mit einem Update um den Web Start erweitern. Damit ist eine Ausführung von Applets im Browser nicht mehr erforderlich.

Java in Chrome

Auch wenn Chrome hier schon für Unruhe sorgt, sehen wir noch nicht, dass die Applets wirklich entfernt werden, oder dass, wenn Chrome diesen Schritt geht, andere Browser nachziehen werden.
Aber selbst wenn dem so sein sollte, so haben wir schon vor langer Zeit damit begonnen, erfolgreich eine Zwei-Faktor-Authentifizierung zu bauen, die ganz ohne Java-Applets oder Client-Installation auskommt, und die für den Benutzer noch wesentlich bequemer in der Handhabung und somit auch weniger fehleranfällig ist: Die SecSign ID.

Java in Mozilla Firefox

Bereits jetzt unterbindet Firefox die automatische Ausführung von Java aufgrund der bekannten Sicherheitsproblematik, erlaubt jedoch noch seine Aktivierung. Auch hier soll die Unterstützung spätestens Ende 2016 auslaufen.

Was sind die Gründe für das Ende der Unterstützung?

Wie oben bereits angedeutet, gibt es folgende Sicherheitsprobleme:

NPAPI-Schnittstelle als Schwachstelle
Die NPAPI-Schnittstelle wird immer weniger benötigt und gilt mittlerweile als eine Art Methusalem in der virtuellen Welt. Sie gilt inzwischen als veraltet und verursacht eine Menge Probleme, auch was die Leistung betrifft. Ausschlaggebend waren jedoch die befürchteten Schwächen. Die NPAPI-Schnittstelle ist daher z.B. in der aktuellen Version 42 des Chrome-Browsers von Google als Standardeinstellung schon deaktiviert.
Laut Google soll die Reaktivierung aber noch bis Herbst 2016 ermöglicht werden.

Inwieweit betrifft das die Arbeit mit dem SecSigner?

Der am häufigsten genutzte SecSigner ist die SecSigner Java- Anwendung, da Java sich im Laufe der Jahre bewährt hat. Zahlreiche Warnungen beim Ausführen von Applets sowie Browsereinstellungen machen jedoch die Arbeit letztlich schwieriger. Indem Sie Ihren SecSigner als Web Start nutzen, können Sie Ihren Benutzern deren Arbeit vereinfachen.

Falls für den konkreten Anwendungsfall eine fortgeschrittene Signatur ausreicht, kann demnächst auch mit unserer SecSignApp auf dem Smartphone oder Tablet signiert werden. Dort kommt kein Java zum Einsatz, und die Bedienung ist komfortabler, da weder Smartcard noch Kartenleser nötig sind.
Auch werden wir, sobald die eIDAS-Verordnung verabschiedet wurde, zahlreiche Webschnittstellen anbieten, die Sie nutzen können, um Fernsignaturen durchzuführen. Auch hier wird dann weder ein Applet noch eine Web Start-Komponente nötig sein.

Der SecSigner kann als Java-Applet, als Java-Applikation, als Java- Web Start-Applikation oder in einer nativen Anwendung über die Wrapper-DLL ausgeführt werden. Die Entscheidung liegt also bei Ihnen, welche Aufrufvariante Sie wählen. Wenn Ihnen Applets nicht mehr zukunftsfähig erscheinen, könnten Sie Ihre Anwendung auf Web Start umstellen.

Häufige Fehler im Umgang mit Applets oder Web Start Applikationen

Die Fehlermeldung zeigt, dass dieser Browser das Java-Applet nicht startet. Darauf haben wir keinen Einfluss, denn unser Java- Applet läuft ja noch gar nicht. Das bedeutet im Klartext, dass der Administrator dieses PCs oder der Hersteller des Browsers die Angelegenheit untersuchen muss .
Admin-Rechte sind zum Start von Java-Applets normalerweise nicht nötig, aber der Administrator kann im Browser je nach Wunsch und Bedarf Regeln konfiguriert haben.
Grundsätzlich startet der SecSigner im Internet Explorer. Sie können das auf unserer Webseite mit dem Online-SecSigner testen.

Wenn Sie auf Ihrer Webseite ein Login mit Name und Passwort verwenden, möchten wir Sie bei der Gelegenheit auf unser sicheres Two-Factor-Login SecSign ID aufmerksam machen. Dabei befindet sich ein privater 2048-Bit-RSA-Schlüssel auf dem Smartphone des Anwenders, mit dem dieser sich authentifiziert. Es werden keine vertraulichen Daten (z.B. Passwörter) im Browser eingegeben und können somit auch nicht durch Phishing gestohlen werden. Auch der private Schlüssel wird selbstverständlich niemals übertragen, sondern verschlüsselt und durch das patentierte SafeKey-Verfahren geschützt auf dem Smartphone verwahrt. Unsere Plugins stehen Ihnen zur Einbindung in Webseiten kostenlos zur Verfügung.

Bei der SecSign ID muss der Benutzer im Browser nur seinen selbstgewählten und nicht vertraulichen Benutzernamen angeben. Die SecSign ID-Schnittstellen gibt es in so gut wie jeder Programmiersprache, und auch die Integration ist sehr einfach. Das Sicherheitsniveau gleicht dem einer Authentifizierung mit einer Smartcard.

Was ist Web Start, und wie startet man die Anwendung damit?

Mit dem Java Web Start können Java-Anwendungen aus Internet heruntergeladen und ausgeführt werden.
Anwendungen können mit damit schnell und immer mit der aktuellen Version aktiviert werden, da die Software bei jedem Start nach der neuesten Version sucht. Aufwändige Einbindungen oder Aktualisierungen fallen hier nicht an. Wird eine Java-Anwendung erstmals heruntergeladen, startet Java Web Start automatisch.

Ansonsten gibt es verschieden Wege, Java Web Start zu starten:

  • Anklicken eines entsprechenden Links auf einer Webseite – Über eine Verknüpfung z.B. auf Ihrem Desktop
  • Mit dem Java-Anwendungscache-Viewer
  • Über die Eingabe der Eingabeaufforderung javaws jnlp_url

Wie übergebe ich Dateien (z.B. PDFs) an das SecSigner Applet oder die SecSigner Web Start-Bibliothek?

Der Parameter DocumentURL in der jnlp-Datei teilt dem SecSigner mit, von welcher URL er das zu signierende Dokument laden kann. Alternativ kann mit dem Parameter DocumentBase64 das Dokument Base64-kodiert direkt angegeben werden.

So können Sie dem SecSigner direkt für den Aufruf ein Dokument übergeben, so dass der Benutzer durch Auswählen des „Signieren“- Buttons in Ihrer Webseite in einem Schritt das zu signierende Dokument angezeigt bekommt und nur noch den eigentlichen Signiervorgang durchführen muss.
Nach der Signatur bzw. Verschlüsselung sendet der SecSigner die Signaturdatei bzw. das verschlüsselte Dokument mittels HTTP-Post an den Server zurück. Die nötige URL erhält der SecSigner über den Parameter PostURL in der jnlp-Datei.

Der Benutzer muss sich also nicht darum kümmern, wie das signierte Dokument an die weiterverarbeitenden Prozesse in Ihrem Webservice oder der Applikation gelangt.