Es gibt eine laufende Diskussion über die Sicherheits- und Vertrauensarbeitsgruppe für NHIN Direct hinsichtlich des IP-zu-Domänen-Zuordnungsproblems, das mit herkömmlichem SSL erstellt wird . Wenn ein HISP (wie von NHIN Direct definiert) Tausende von NHIN Direct "Health Domains" für Provider hosten will, dann wird es "künstlich überhöhte Kosten" geben, eine IP für jede dieser Domains kaufen zu müssen.
Da Apache und OpenSSL kürzlich TLS mit Unterstützung für die SNI-Erweiterung veröffentlicht haben, ist es möglich, SNI als Lösung für dieses Problem auf der Serverseite zu verwenden. Wenn wir jedoch entscheiden, dass zulassen Server-Implementierungen der NHINDirect-Transportschicht TLS + SNI unterstützen sollen, müssen wir erfordern , dass alle Clients auch SNI unterstützen. OpenSSL-basierte Clients sollten dies standardmäßig tun, und man könnte uns immer dazu überreden, einen TLS + SNI-fähigen Client als Proxy zu implementieren, wenn Ihre gegebene Programmiersprachen-SSL-Implementierung SNI nicht unterstützt. Es scheint, dass native Java-Anwendungen, die OpenJDK verwenden, SNI noch nicht unterstützen, aber ich kann von diesem Projekt keine direkte Antwort erhalten. Ich weiß, dass es OpenSSL-Java-Bibliotheken gibt, aber ich habe keine Ahnung, ob dies als praktikabel betrachtet werden könnte.
Können Sie mir eine "State of the Art" -Übersicht geben, wo TLS + SNI-Unterstützung für Java-Clients ist? Ich brauche eine Java-Implementierungsperspektive dazu.
Ich arbeite am selben Projekt wie ftrotter.
Beachten Sie die Anforderung der Unterstützung für Tausende von Domänen. Ich glaube nicht, dass SANs den Senf aus zwei Gründen senken werden. Erstens wird die Größe des Zertifikats enorm, was wahrscheinlich zu Leistungsproblemen führen wird. Zweitens werden diese Domains häufig kommen und gehen, besonders in den frühen Tagen von NHIN Direct. Die operative Last, das Zertifikat jedes Mal aktualisieren zu müssen, wenn eine Domain kommt oder geht, wird inakzeptabel sein, IMHO.
Auf Anfrage von ftrotter habe ich etwas über das Thema Java, TLS und SNI gegoogelt und andere Wege gefunden, um das zu implementieren, was zu einer namensbasierten virtuellen Hosting-Situation mit einem Zertifikat pro virtuellem Host führt. Folgendes habe ich mir ausgedacht:
JSSE (Java Secure Socket Extension) unterstützt TLS und hat "teilweise Unterstützung" für TLS + SNI. Ich habe keine Ahnung, was partielle Unterstützung in diesem Zusammenhang bedeutet. Der Kommentar, den ich sehe, deutet darauf hin, dass die vorhandene Unterstützung nicht ausreicht, um named-basierte virtuelle Hosts zu erstellen, was wir im Grunde brauchen.
Ich habe einen Artikel gefunden, der behauptet, die JSK-Version von JSSE werde TLS + SNI (vom 20.11.2008) unterstützen, und ich habe eine gefunden, die behauptet, sie gewonnen zu haben 't (vom 27.02.2009). Keine von beiden ist besonders verbindlich.
Einige der Leute, die an OpenJDK 7 arbeiteten, diskutierten die Probleme beim Hinzufügen von SNI-Unterstützung zu JSSE im Februar-März 2009, einschließlich des Postens eines Quell-Patches. (Der Thread beginnt hier: Ссылка ). OpenJDK7 wird nicht vor September 2010 veröffentlicht werden. Ich habe keine Ahnung, wann die Java 7-Plattform veröffentlicht wird.
Es gibt auf java.sun.com überhaupt nichts Substanzielles, also weiß ich wirklich nicht, was Suns Pläne überhaupt sind.
Es gibt anscheinend eine andere Möglichkeit, namensbasierte virtuelle Hosts zu erreichen, die anscheinend weitgehend kompatibel ist, indem ein einzelnes Zertifikat pro Hosting-Server verwendet wird, das mehrere allgemeine Namen und mehrere Subjekt-Altnamen enthält. Siehe Ссылка und Verschiedene Zertifikate für dieselbe Tomcat-Anwendung über Konnektoren bereitstellen?
Dieser Ansatz würde wirklich große Zertifikate (aufgrund all dieser CNs und SANs) erstellen, wenn Sie viele virtuelle Hosts haben. Einer der Leute bei NHIN Direct's kürzlichem persönlichen Treffen sprach über die Unterstützung von Tausenden von virtuellen Hosts. Meine Vermutung ist, dass dadurch viele Implementierungen durchbrochen werden. Außerdem muss jedes Mal, wenn Sie einen virtuellen Host hinzufügen oder entfernen, das Zertifikat aktualisiert werden, wie eine lächerliche Betriebslast.
Zusammengefasst scheint der aktuelle Java-Stand der Technik für namensbasiertes virtuelles Hosting mit separaten Zertifikaten pro virtuellem Host "nicht zu sein". Außerdem ist nicht klar, wann oder ob es hinzugefügt wird.
Stimmt jemand zu oder nicht? Weiß jemand, ob das OpenJDK-Projekt eine "Rückportierung" der SNI-Unterstützung für Java 6 beabsichtigt?
JavaSE 7 hat SNI-Unterstützung in JSSE.
Beachten Sie, dass es ein Problem damit gibt, wie Sie hier lesen können:
SSL-Handshake-Warnung : unrecognized_name Fehler seit dem Upgrade auf Java 1.7.0
Es ist auch möglich, mit einigen Zeilen das originale Sun JDK (bootclasspath) zu patchen, um Server SNI zum Laufen zu bringen.
Klasse: sun.security.ssl.ServerHandshaker
Feld hinzufügen
%Vor%Patch-Methode clientHello (diese Zeilen hinzufügen)
%Vor%Patch-Methode setupPrivateKeyAndChain (ändern)
%Vor%Fügen Sie der Klasse sun.security.ssl.ServerNameExtension
hinzu %Vor%Tags und Links java ssl client-side