HTTPS ist HTTP innerhalb von SSL. SSL ist ein Tunnelprotokoll: Es funktioniert über einen vorhandenen bidirektionalen Datenstrom und stellt einen bidirektionalen Datenstrom bereit. Die beiden an SSL beteiligten Parteien sind der Client und der Server , die zwei Rollen innerhalb des SSL-Protokolls sind. Es ist nicht erforderlich, dass diese Rollen den Begriffen "Client" und "Server" des zugrunde liegenden Transportprotokolls zugeordnet sind.

Beispielsweise kann ein Setup vorgestellt werden, in dem das Client-System (C) initiiert eine TCP-Verbindung zum Server (S), und dann initiiert der Server einen SSL-Handshake, der als SSL-Client fungiert (dh die Nachricht ClientHello sendet, anstatt auf eine zu warten eingehender ClientHello ). Dies vertauscht die Rollen beider Computer und auch die Sicherheitsgarantien: Der Computer S hat eine gute Vorstellung von der Identität des verbundenen Clients C, aber der Client C ist sich nicht sicher, mit welchem ​​Server S er spricht (einem Angreifer) hätte die Kommunikation abfangen und umleiten können). Je nach Kontext kann dies angemessen sein oder auch nicht.

Dies weicht jedoch von HTTPS ab, bei dem der TCP-Client auch der SSL-Client ist und dieser Client das erwartet Server, um ein Zertifikat anzuzeigen, das der Client anhand seiner bekannten, vertrauenswürdigen Zertifizierungsstelle überprüft und das den erwarteten Servernamen enthält (wie aus der URL extrahiert, siehe Abschnitt 3.1). . Entsprechend unterstützen vorhandene Clients (Webbrowser) die Umkehrung von SSL-Rollen nicht. Wenn Ihre Situation die Verwendung von Browsern erfordert, müssen Sie natürlich nur die in Browsern verfügbaren Funktionen verwenden.

SSL unterstützt einige zertifikatlose Cipher Suites. Die "DH_anon" -Cipher-Suites gelten als schwach, da sie überhaupt keine Authentifizierung implizieren (daher sind Man-in-the-Middle-Angriffe möglich). Die PSK -Verschlüsselungssuiten implizieren die gegenseitige Authentifizierung von Client und Server in Bezug auf ein gemeinsames Geheimnis. Wenn das gemeinsame Geheimnis eine geringe Entropie aufweist (z. B. ein Kennwort ), sind SRP -Verschlüsselungssuiten besser.

Auch hier sind diese Verschlüsselungssuiten besser sind (noch) nicht in Mainstream-Browsern verfügbar (obwohl einige Leute daran arbeiten). Sie erfordern ein gemeinsames Geheimnis (Schlüssel oder Passwort), eine Bedingung, die in Ihrem spezifischen Kontext möglicherweise leicht zu erreichen ist oder nicht.

Wenn die Kenntnis der Serveridentität unwichtig ist, können Sie dies tun Geben Sie dem Server ein selbstsigniertes Zertifikat sowie Anweisungen für Clients, wie ihr Browser das Serverzertifikat akzeptieren kann, ohne zu laut zu kriechen (siehe diese Frage als Ausgangspunkt). Dies wird "normalem SSL" zugeordnet, was zwei Vorteile hat:

• Bestehende Browser unterstützen dies.
• Wenn der Server ein Zertifikat vorlegt, wie falsch es auch sein mag, ist es zulässig im Gegenzug nach einem client -Zertifikat fragen, das die Art der Authentifizierung liefert, nach der Sie suchen. Und Webbrowser unterstützen Client-Zertifikate für SSL.

Beachten Sie, dass das selbstsignierte Zertifikat den öffentlichen Serverschlüssel enthält. Obwohl dieser öffentliche Schlüssel nicht validiert wird, wird er dennoch zum Aktivieren des Schlüsselaustauschs verwendet. Sie müssen daher einen geeigneten Schlüsseltyp und eine geeignete Schlüssellänge verwenden (z. B. RSA 2048). Verwenden Sie alternativ eine der "DHE" -Cipher-Suites. In diesem Fall wird der öffentliche Serverschlüssel nur für Signaturen verwendet, um die Daten nicht tatsächlich zu schützen, also ( in Ihrem speziellen Fall ), deren Größe und Geheimhaltung wird unwichtig.

Nein. Gemäß den Spezifikationen von HTTPS wird ein Zertifikat benötigt, da sich ein Server gegenüber dem Client identifiziert. Das Zertifikat muss nicht gültig sein, dh das Zertifikat muss nicht von einer Zertifizierungsstelle ausgestellt und signiert werden, der der Browser standardmäßig vertraut.

HTTPS (HTTP über TLS) basiert auf dieser Idee Wir müssen sicherstellen, dass wir tatsächlich mit demselben Webserver verbunden sind, mit dem wir eine Verbindung herstellen möchten. Tatsächlich werden Sie feststellen, dass viele Webserver-Software nicht einmal die bidirektionale HTTPS-Authentifizierung unterstützt.

Natürlich gibt es Ausnahmen (anonyme Cipher Suites) , Pre-Shared Keys usw.), aber alle haben ihre eigenen Probleme. Beispielsweise unterstützt Mozilla in seinen Produkten keine anonymen Cipher Suites. Chrome ist kürzlich denselben Weg gegangen. Pre-Shared Keys weisen die regulären Bereitstellungsprobleme auf, die die Verschlüsselung mit öffentlichen Schlüsseln erheblich erleichtern.

Fazit: Sie benötigen ein Serverzertifikat für HTTPS.

Nein. In dem Moment, in dem Sie den TLS-Austausch starten, müssen Sie Ihren eigenen öffentlichen Schlüssel bereitstellen.

Außerdem würde dies niemals funktionieren. Es gibt so gut wie keine MITM-Angriffe, die nur "passiv" sind. Ein Angreifer kann die Daten ändern, solange er sie schnüffeln kann.

Und der Angreifer kann einfach so tun, als wäre er der Client, indem er die Verbindung abfängt, bevor TLS gestartet wird (in Vanilla HTTPS funktioniert dies nicht, da das Vertrauen des gefälschten Webserver-Zertifikats nicht hergestellt werden kann), und sein eigenes präsentieren cert als Client-Zertifikat.

Außerdem benötigt RSA zwei Schlüssel. Sie müssen Text mit Ihrem privaten Schlüssel und dem öffentlichen Schlüssel des Clients verschlüsseln. Ein öffentlicher Schlüssel geht Hand in Hand mit einem Zertifikat, daher benötigen Sie eines.

Sie müssen über ein Zertifikat verfügen, das Sie jedoch selbst erstellen können.

Für SSL (das von HTTPS bereitgestellt wird) ist ein Zertifikat für die sichere Kommunikation erforderlich, da dies die Grundlage für die Verschlüsselung ist und zur Authentifizierung verwendet wird, dass der Server der ist, für den sie sich ausgeben.

Wenn Sie selbst ein Zertifikat erstellen, haben Ihre Benutzer keinen Grund, dem Zertifikat zu vertrauen, es sei denn, sie wissen bereits, dass es korrekt ist (da es keine unabhängige Überprüfung Ihrer Identität gibt), aber es bietet nur die Verschlüsselung Gut und bestätigt jemandem, der zum zweiten Mal eine Verbindung herstellt, dass er eine Verbindung zu demselben Server wie zuvor herstellt.

nur eine kurze Änderung: Sie mischen Server-Zertifikate , die für die Bereitstellung von HTTP_ S _ - Diensten erforderlich sind, und Client-Zertifikate Diese werden zur Authentifizierung eines Clients verwendet.

Obwohl Client-Cert als Certs bezeichnet wird, hat es nichts mit Verschlüsselung zu tun. Sie sind gerade dabei, den Client gegen einen Dienst zu authentifizieren. Client-Zertifikate werden mit einer Art PKI generiert, bei der eine Berechtigung mit einem ROOT-Zertifikat in der Lage ist, CLient-Zertifikate zu generieren und zu signieren.

Apache kann die Authentifizierung über Client- durchführen. Zertifikate sowie VPN