Java 7 - Probleme mit neuen JSSE Features
Mit Java 7 sind in den SSL/TLS Provider von Oracle einige neue Funktionen eingezogen. Darunter der schon lange erwartete Support für TLSv1.1 und TLSv1.2, aber auch die Unterstützung der TLS Extensions u.A. für die Server Name Indication(SNI).
Letzteres wird dazu verwendet virtuelle Hosts auf einem SSL Port zu unterstützen: Bisher konnte ein SSL Server nämlich nicht wissen an welchen (der potentiell vielen) virtuellen Dienste hinter einer IP Adresse sich der SSL Client wenden will. Besonders ärgerlich ist dies im Fall von HTTP/s, dort ist es die Regel dass Hoster sehr viele Kunden-Domains hinter ein und der selben IP-Adresse betreiben. In HTTP/1.1 wird der gewünschte Servername in der Anfrage mitgegeben (Host: Header). So kann der HTTP Server entscheiden welche Webseiten er ausliefern soll.
Im Falle des SSL Server Zertifikats (welches im SSL Handshake schon vor der HTTP Anfrage ausgetauscht wird), kann dies der Webserver aber nicht. Er muss raten welches Zertifikat er dem Client präsentieren soll, und das schlägt natürlich in der Regel fehl. Mit der Extension wird der Servername auch im Handshake mitgeschickt, und der Server kann sein Zertifikat passend auswählen.
Problem bei der Geschichte ist: der Server darf auf eine solche Namensanfrage mit einem SSL Alert (Warning) reagieren. In dieser sagt er, dass er sich für den angefragten Host nicht zuständig fühlt. Das kommt bei aktuellen Webserver Installationen häufig vor, weil diese einfach nicht korrekt eingerichtet sind (und die modernen Browser die SNI unterstützen diese Warnung auch einfach ignorieren). Da das zurückgelieferte Default Zertifikat oftmals den richtigen Hostnamen (in einer der Attribute) enthält, klappt der gesicherte Handschlag im Alltag dennoch. Nicht jedoch mit Java 7 SSL Clients, JSSE macht daraus eine fatale Exception:
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
at sun.security.ssl.ClientHandshaker.handshakeAlert
at sun.security.ssl.SSLSocketImpl.recvAlert
at sun.security.ssl.SSLSocketImpl.readRecord
at sun.security.ssl.SSLSocketImpl.performInitialHandshake
at sun.security.ssl.SSLSocketImpl.startHandshake
at sun.security.ssl.SSLSocketImpl.startHandshake
at sun.net.www.protocol.https.HttpsClient.afterConnect
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream
Ich habe deswegen einen Bugreport aufgemacht, jedoch wurde dieser wieder kommentarlos geschlossen. Falls Sie nun trotz Oracle's widerstreben die Notwendigkeit haben mit einem Web Server zu kommunizieren der SNI nicht richtig eingerichtet hat, so bleiben nur 2 Möglichkeiten über:
a) TLS aus der Liste der unterstützten Protokolle entfernen - mit einem SSLv3 Handshake wird kein Extension Record übertragen, und entsprechend klappt auch der Handshake (solange der Server SNI nicht benötigt).
b) den SSL Socket so initialisieren, dass die SSLEngine den Host nicht kennt. Dieser sogenannte Host hint wird für mehrere Dinge verwendet, kann aber auch weggelassen werden. Erreichen kann man dies, indem man den Socket statt mit s=factory.createSocket(name, port);
mit "s=factory.createSocket(); s.connect(name,port);" erzeugt.
Übrigens ist dies ein ziemlich unerwartetes Verhalten: SSL mit Kerberos Authentifizierung würde nur auf die erste Art und Weise funktionieren, da hierfür die Identität des Servers bekannt sein muss.
Der Punkt a) ist ein schneller Fix, kommt aber in der Praxis eigentlich nicht in Frage, da man mit Java 7 ja eher daran Interesse hat TLSv1.1 oder TLSv1.2 zu verwenden um Lücken wie z.B. den BEAST-Angriff auszuschließen. Daher bleibt es nur übrig entweder den Anwendungscode zu ändern (oder wenn man diesen nicht selbst geschrieben hat, wie im Falle einer häufig verwendeten URLConnection oder beim Apache HTTPClient) oder aber mindestens eine eigene SSLSocketFactory zu implementieren, die auf die 2-stufige Erzeugung des SSLSockets aufsetzt.
Update: Ich habe in den Sourcen grade eine System Property gefunden, mit der man abschalten kann, dass der ClientHandshaker die SNI Extention sendet. Dies lässt sich als Work around gut verwenden: System.setProperty("jsse.enableSNIExtension", "false"); (muss vor der Verwendung von SSL Klassen im Programm, oder auf der Command Line gesetzt werden).
Comments
Display comments as Linear | Threaded