Gibt es eine Möglichkeit, SSL-Zertifikatsdetails mit JavaScript abzurufen?

Question

Ich möchte bestimmte Details zu einem SSL-Zertifikat auf einer bestimmten Website erfassen. Ich weiß, dass dies mit dem openssl-Tool unter Linux/MacOSX ganz einfach ist. Ist das Gleiche oder etwas Ähnliches auch in JavaScript möglich?

Ich weiß, dass der Browser Socket-Verbindungen verarbeitet und dass der SSL-Handshake stattfindet, bevor eine Partei Daten sendet. Jedoch in einer XMLHTTPRequest, würde ich gerne wissen, ob es möglich ist, diese Details als eine Art von Antwort-Code usw. zu erhalten?

Answer 1

Diese Information wird einfach nicht an Javascript weitergegeben, da sie so selten verwendet wird (eigentlich nie, da sie nicht verfügbar ist, aber sie würde selten verwendet werden), dass es nicht als wichtig genug, um das Javascript-Objektmodell hinzufügen ich vermute, ... gleich für jede sehr selten verwendete Funktion links aus etwas.

Natürlich könnte es auch aus Sicherheitsgründen weggelassen worden sein... Ich bin im Moment nicht kreativ genug, um mir etwas einfallen zu lassen, aber ich bin mir sicher, dass auch hier ein Exploit zu finden ist.

Answer 2

Das Zertifikat ist nicht Teil des DOM, daher ist dies nicht möglich. Entschuldigung!

Answer 3

Nein, das ist nicht möglich.

Es ist möglich, über Javascript zu erkennen, ob die aktuell angezeigte Seite über eine SSL-Verbindung läuft (document.location.protocol=="https:"), aber das war's auch schon.

Answer 4

Der aktuelle JS-Sprachstandard stellt keine Zertifikatsinformationen zur Verfügung; darüber hinaus hängt es wahrscheinlich davon ab, wie Sie JavaScript verwenden. Wenn Sie erwarten, dass der Browser des Endbenutzers Zertifikatsinformationen zur Verfügung stellt, dann wird es wirklich problematisch, weil Sie mindestens FF, Chrome, Safari, IE, Edge, ... dazu bringen müssen, sie zur Verfügung zu stellen.

Wie in diesem Artikel erwähnt, ist jedoch Stelle für Informationssicherheit Dies ist keine wünschenswerte Option für diese Browser, da ein Website-Entwickler einen Code schreiben könnte, der fälschlicherweise den Anmeldedaten des Benutzers vertraut.

Es ist nicht so sehr ein Sichtbarkeits-Sicherheitsrisiko, das Javascript daran hindert, auf die aktuellen SSL-Zertifikatsinformationen des Browsers zuzugreifen, sondern eher ein Sicherheitsrisiko der vierten Wand, bei dem sich der JS-Entwickler bewusst sein muss, dass das "vom Benutzer akzeptierte" Zertifikat nicht unbedingt das von der Website bereitgestellte ist. Die HTML-Seite sollte die Sicherheitsprobleme nicht mit clientseitigem Code behandeln, sondern sich darauf verlassen können, dass die Sicherheitsschicht ihre Aufgabe ordnungsgemäß erfüllt. (Ich kann durchaus verstehen, dass man die Sicherheitsebene überprüfen möchte, aber jede Verwaltungsarbeit, die man auf der obersten Ebene leistet, wird entweder nur oberflächlich sein oder eine Überarbeitung der gesamten Biosphäre bedeuten)

Denn nehmen wir einmal an, dass Javascript eine Möglichkeit bietet, mit dem Zertifikat zu arbeiten, dann gibt es keine Möglichkeit, den folgenden Austausch zu stoppen, wenn Bob Mallory bereits vertraut, weil seine Sicherheit gebrochen ist:

Büroangestellter Bob befindet sich auf der einen Seite der großen Firewall von Mega Corp., IT Mallory ist für die Firewall zuständig, die den Datenverkehr in und aus dem Unternehmen leitet, und die fantastische Website von Web Host Alice ist im WWW zu finden.

0. Gemäß der Firmenpolitik der Mega Corp. ist Bob dazu angehalten, Mallorys Aussagen für bare Münze zu nehmen.
1. Bob, der die Website von Alice besuchen möchte, aber keinen direkten Zugang von außen hat, versucht, eine sichere Verbindung durch die Firewall herzustellen, indem er sein Zertifikat hochhält (z. B.: "Ich erkläre hiermit, dass ich Bob bin") und Alice auf sehr umständliche Weise fragt: "Welches Zertifikat habe ich dir geschickt?"
2. Mallory erhält Bobs Anfrage, gibt aber stattdessen ihre eigene weiter (z. B.: "Äh, Bob sagt, ich darf seine Webmail lesen"), und obwohl Mallory Bobs verworrene Frage nicht versteht, wiederholt sie sie gegenüber Alice: "akdvyfenwythnwerhy?".
3. Alice rechnet nach und findet heraus, dass "akdvyfenwythnwerhy?" die Frage "Welches Zertifikat habe ich dir geschickt?" bedeutet und antwortet Mallory mit dem, was sie sieht ("Hallo Bob, hier ist Alice, wie du gesagt hast: Äh, Bob sagt, ich darf seine Webmail lesen").
4. Mallory rechnet ein wenig nach, hat einen Aha-Moment "akdvyfenwythnwerhy?=welches Zertifikat habe ich dir geschickt?", und beantwortet Bobs Frage im Namen von Alice("Hallo Bob, hier ist Alice( Mallory ) sagten Sie: Ich erkläre hiermit, dass ich Bob bin").
5. Bob glaubt, dass das Leben gut ist und liest weiter seine Webmail, denn er weiß, dass Mallory ihn niemals anlügen würde.
6. Mallory ist nun in der Lage, beide Seiten des Gesprächs zu lesen und leitet Bobs Anfrage, seine Webmail zu lesen, an Alice weiter.
7. Alice erhält Bobs Anfrage und sagt: "Hey, Moment mal, Bob, du musst diesen JS-Code ausführen, um zu beweisen, dass du weißt, dass du mit Alice sprichst.
8. Mallory holt sich den Code, führt ihn aus und schickt die Ergebnisse, die besagen, dass sie weiß, dass sie mit Alice spricht, an Alice zurück.
9. Alice sagt: "Das reicht mir, hier ist deine Webmail.
10. Mallory liest Bobs Webmail, bevor sie sie an Bob weitergibt, und alle sind glücklich.

(Hinweis: Ich habe nicht auf den Fall, wenn Sie JS-Server-seitig ausgeführt werden, dann würde es davon abhängen, welches Programm Sie verwenden, um Ihre JS-Code ausführen).

---

Edit 4/4/2018 -- Während das obige nicht falsch ist, ist es mehr aus der Perspektive von eingebettetem und verlinktem JS als über das JS-Objekt `XMLHTTPRequest`; außerdem ist das stärkste Argument gegen die gemeinsame Nutzung von PKI-Details mit `XMLHTTPRequest` folgendes:

Es muss eine klare Trennlinie zwischen dem HTTP-Teil und dem S-Teil des HTTPS-Protokolls bestehen bleiben. JavaScript und seine XMLHTTPRequest Objekt befindet sich auf der HTTP(app layer)-Seite dieser Linie, während der gesamte Zertifikatsaustauschprozess auf der S(trans/sec layer)-Seite dieser Linie stattfindet. Um die Sicherheitsseite atomar (hot-swap-fähig) zu halten, kann ihre interne Arbeitsweise nicht über die Leitung zur Anwendungsseite offengelegt werden; denn es könnte der Tag kommen, an dem die Transport-/Sicherheitsschicht keine PKI-Zertifikate mehr verwendet, um ihren sicheren Kommunikationsdienst zu erleichtern, und wenn dieser Tag kommt, müsste niemand bestehenden JS-Code umschreiben, der sich auf die in diesen Zertifikaten enthaltenen Details verließ, um mit der Ausbreitungswelle fertig zu werden, die dadurch verursacht wird, dass die www-Gemeinschaft langsam ihre bevorzugte Variante einer neuen Sicherheitsschicht annimmt.

Abgesehen davon scheint die Sicherheitsseite auch die Überprüfung von Rechtssubjekten vorzunehmen - zumindest in einigen Fällen wie EV-Zertifikaten -, und das ist IMO ein Manko der RFC7230 Abschnitt 2.7.2 dass sie nicht den Begriff authority der https-URI um eine optionale legalentity die die Sicherheitsschicht verwenden würde, um zu überprüfen, ob die URL, mit der sie kommuniziert, nicht nur der richtige Endpunkt ist, sondern auch unter der Kontrolle der beabsichtigten Geschäftsbeziehung steht.

authority     = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ]
legalentity   = *( unreserved / pct-encoded / sub-delims )