9. Sicherheitsüberlegungen

Sicherheitsüberlegungen

Um den gesamten Abschnitt der Sicherheitsüberlegungen zugänglicher zu machen, wurden die Sicherheitsüberlegungen für die Transport-, Authentifizierungs- und Verbindungsdokumente hier zusammengetragen.

Das Transportprotokoll [SSH-TRANS] bietet einen vertraulichen Kanal über ein unsicheres Netzwerk. Es führt Server-Host-Authentifizierung, Schlüsselaustausch, Verschlüsselung und Integritätsschutz durch. Es leitet auch eine eindeutige Sitzungs-ID ab, die von höherstufigen Protokollen verwendet werden kann.

Das Authentifizierungsprotokoll [SSH-USERAUTH] bietet eine Reihe von Mechanismen, die zur Authentifizierung des Client-Benutzers gegenüber dem Server verwendet werden können. Einzelne im Authentifizierungsprotokoll spezifizierte Mechanismen verwenden die vom Transportprotokoll bereitgestellte Sitzungs-ID und/oder hängen von den Sicherheits- und Integritätsgarantien des Transportprotokolls ab.

Das Verbindungsprotokoll [SSH-CONNECT] spezifiziert einen Mechanismus zum Multiplexen mehrerer Datenströme (Kanäle) über den vertraulichen und authentifizierten Transport. Es spezifiziert auch Kanäle für den Zugriff auf eine interaktive Shell, für Proxy-Forwarding verschiedener externer Protokolle über den sicheren Transport (einschließlich beliebiger TCP/IP-Protokolle) und für den Zugriff auf sichere Subsysteme auf dem Server-Host.

9.1. Pseudo-Zufallszahlengenerierung

Dieses Protokoll bindet jeden Sitzungsschlüssel an die Sitzung, indem es zufällige, sitzungsspezifische Daten in den Hash einschließt, der zur Erzeugung von Sitzungsschlüsseln verwendet wird. Es sollte besonders darauf geachtet werden, dass alle Zufallszahlen von guter Qualität sind. Wenn die Zufallsdaten hier (z. B. Diffie-Hellman (DH) Parameter) pseudo-zufällig sind, dann sollte der Pseudo-Zufallszahlengenerator kryptographisch sicher sein (d. h. seine nächste Ausgabe ist nicht leicht zu erraten, selbst wenn alle vorherigen Ausgaben bekannt sind) und darüber hinaus muss dem Pseudo-Zufallszahlengenerator geeignete Entropie hinzugefügt werden. [RFC4086] bietet Vorschläge für Quellen von Zufallszahlen und Entropie. Implementierer sollten die Bedeutung der Entropie und die gut gemeinte, anekdotische Warnung über die Schwierigkeit der korrekten Implementierung von Pseudo-Zufallszahlengenerierungsfunktionen beachten.

Die Menge der für einen bestimmten Client oder Server verfügbaren Entropie kann manchmal geringer sein als erforderlich. In diesem Fall muss man entweder auf Pseudo-Zufallszahlengenerierung trotz unzureichender Entropie zurückgreifen oder sich weigern, das Protokoll auszuführen. Letzteres ist vorzuziehen.

9.2. Filterung von Steuerzeichen

Bei der Anzeige von Text für einen Benutzer, wie z. B. Fehler- oder Debug-Meldungen, SOLLTE die Client-Software alle Steuerzeichen (außer Tabulator, Wagenrücklauf und Zeilenumbruch) durch sichere Sequenzen ersetzen, um Angriffe durch Senden von Terminal-Steuerzeichen zu vermeiden.

9.3. Transport

9.3.1. Vertraulichkeit

Es liegt außerhalb des Umfangs dieses Dokuments und der Secure Shell Working Group, spezifische Chiffren zu analysieren oder zu empfehlen, außer denen, die in der Industrie etabliert und akzeptiert sind. Zum Zeitpunkt der Erstellung dieses Dokuments umfassen häufig verwendete Chiffren 3DES, ARCFOUR, twofish, serpent und blowfish. AES wurde von den US Federal Information Processing Standards als [FIPS-197] veröffentlicht, und die kryptographische Gemeinschaft hat AES ebenfalls akzeptiert. Wie immer sollten Implementierer und Benutzer die aktuelle Literatur überprüfen, um sicherzustellen, dass keine kürzlich aufgetretenen Schwachstellen in den in Produkten verwendeten Chiffren gefunden wurden. Implementierer sollten auch überprüfen, welche Chiffren als relativ stärker als andere gelten, und sollten deren Verwendung den Benutzern gegenüber relativ schwächeren Chiffren empfehlen. Es würde als gute Form betrachtet werden, wenn eine Implementierung einen Benutzer höflich und unauffällig darauf hinweist, dass eine stärkere Chiffre verfügbar ist und verwendet werden sollte, wenn eine schwächere aktiv ausgewählt wird.

Die "none"-Chiffre wird zum Debuggen bereitgestellt und SOLLTE NICHT für andere Zwecke verwendet werden. Ihre kryptographischen Eigenschaften sind in [RFC2410] ausreichend beschrieben, was zeigen wird, dass ihre Verwendung nicht der Absicht dieses Protokolls entspricht.

Die relativen Vorzüge dieser und anderer Chiffren können auch in der aktuellen Literatur gefunden werden. Zwei Referenzen, die Informationen zu diesem Thema bieten können, sind [SCHNEIER] und [KAUFMAN]. Beide beschreiben den CBC-Modus der Operation bestimmter Chiffren und die Schwäche dieses Schemas. Im Wesentlichen ist dieser Modus theoretisch anfällig für Chosen-Ciphertext-Angriffe aufgrund der hohen Vorhersagbarkeit des Beginns der Paketsequenz. Diese Attacke wird jedoch als schwierig angesehen und nicht als vollständig praktikabel betrachtet, insbesondere wenn relativ große Blockgrößen verwendet werden.

Darüber hinaus kann ein weiterer CBC-Modus-Angriff durch Einfügen von Paketen mit SSH_MSG_IGNORE gemildert werden. Ohne diese Technik kann ein spezifischer Angriff erfolgreich sein. Damit dieser Angriff (allgemein als Rogaway-Angriff [ROGAWAY], [DAI], [BELLARE] bekannt) funktioniert, müsste der Angreifer den Initialisierungsvektor (IV) des nächsten zu verschlüsselnden Blocks kennen. Im CBC-Modus ist dies die Ausgabe der Verschlüsselung des vorherigen Blocks. Wenn der Angreifer noch keine Möglichkeit hat, das Paket zu sehen (d. h. es befindet sich in den internen Puffern der SSH-Implementierung oder sogar im Kernel), dann wird dieser Angriff nicht funktionieren. Wenn das letzte Paket an das Netzwerk gesendet wurde (d. h. der Angreifer hat Zugriff darauf), dann kann er den Angriff verwenden.

Im optimalen Fall müsste ein Implementierer nur dann ein zusätzliches Paket hinzufügen, wenn das Paket an das Netzwerk gesendet wurde und keine anderen Pakete auf die Übertragung warten. Implementierer möchten möglicherweise überprüfen, ob ungesendete Pakete auf die Übertragung warten; leider ist es normalerweise nicht einfach, diese Information vom Kernel oder den Puffern zu erhalten. Wenn keine ungesendeten Pakete vorhanden sind, SOLLTE ein Paket mit SSH_MSG_IGNORE gesendet werden. Wenn jedes Mal, wenn der Angreifer den IV kennt, der für das nächste Paket verwendet werden soll, ein neues Paket zum Stream hinzugefügt wird, dann wird der Angreifer nicht in der Lage sein, den richtigen IV zu erraten, daher wird der Angriff niemals erfolgreich sein.

Als Beispiel betrachten Sie den folgenden Fall:

Client Server

TCP(seq=x, len=500) ----> enthält Record 1

[500 ms vergehen, kein ACK]

TCP(seq=x, len=1000) ----> enthält Records 1,2

ACK

Der Nagle-Algorithmus + TCP-Neuübertragungen bedeuten, dass die beiden Datensätze in ein einzelnes TCP-Segment zusammengefasst werden.
Record 2 ist nicht am Anfang des TCP-Segments und wird es nie sein, weil es ACKed wird.
Dennoch ist der Angriff möglich, weil Record 1 bereits gesehen wurde.

Wie dieses Beispiel zeigt, ist es unsicher, das Vorhandensein von ungefilterten Daten in den TCP-Puffern als Leitfaden dafür zu verwenden, ob ein leeres Paket benötigt wird, da die Puffer beim zweiten write() den nicht-ACKed Record 1 enthalten werden.

Andererseits ist die folgende Situation völlig sicher:

Client Server

TCP(seq=x, len=500) ----> enthält SSH_MSG_IGNORE

TCP(seq=y, len=500) ----> enthält Data

Vorausgesetzt, dass der IV für den zweiten SSH-Datensatz festgelegt wird, nachdem die Daten für das Data-Paket bestimmt wurden, sollten die folgenden Operationen durchgeführt werden:

vom Benutzer lesen Null-Paket verschlüsseln Datenpaket verschlüsseln

9.3.2. Datenintegrität

Dieses Protokoll erlaubt es, den Datenintegritätsmechanismus zu deaktivieren. Implementierer SOLLTEN vorsichtig sein, diese Funktion für andere Zwecke als das Debuggen offenzulegen. Benutzer und Administratoren SOLLTEN explizit gewarnt werden, wenn der "none"-MAC aktiviert ist.

Solange der "none"-MAC nicht verwendet wird, bietet dieses Protokoll Datenintegrität.

Da MACs eine 32-Bit-Sequenznummer verwenden, könnten sie nach dem Senden von 232 Paketen beginnen, Informationen preiszugeben. Das Befolgen der Rekeying-Empfehlungen sollte diesen Angriff jedoch verhindern. Das Transportprotokoll [SSH-TRANS] empfiehlt Rekeying nach einem Gigabyte an Daten, und das kleinstmögliche Paket ist 16 Bytes. Daher SOLLTE Rekeying nach maximal 228 Paketen erfolgen.

9.3.3. Replay

Die Verwendung eines MAC außer "none" bietet Integrität und Authentifizierung. Darüber hinaus stellt das Transportprotokoll eine eindeutige Sitzungskennung bereit (teilweise an Pseudo-Zufallsdaten gebunden, die Teil des Algorithmus- und Schlüsselaustauschs sind), die von höherstufigen Protokollen verwendet werden kann, um Daten an eine bestimmte Sitzung zu binden und das Replay von Daten aus früheren Sitzungen zu verhindern. Beispielsweise verwendet das Authentifizierungsprotokoll ([SSH-USERAUTH]) dies, um das Replay von Signaturen aus früheren Sitzungen zu verhindern. Da Public-Key-Authentifizierungsaustausche kryptographisch an die Sitzung gebunden sind (d. h. an den anfänglichen Schlüsselaustausch), können sie nicht erfolgreich in anderen Sitzungen wiedergegeben werden. Beachten Sie, dass die Sitzungs-ID öffentlich gemacht werden kann, ohne die Sicherheit des Protokolls zu beeinträchtigen.

Wenn zwei Sitzungen dieselbe Sitzungs-ID haben (Hash der Schlüsselaustausche), dann können Pakete von einer gegen die andere wiedergegeben werden. Es muss betont werden, dass die Chancen eines solchen Vorkommens bei Verwendung moderner kryptographischer Methoden unnötig zu erwähnen minimal sind. Dies gilt umso mehr bei der Spezifikation größerer Hash-Funktionsausgaben und DH-Parameter.

Die Replay-Erkennung mit monoton steigenden Sequenznummern als Eingabe für den MAC oder HMAC in einigen Fällen wird in [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025] und [RFC4120] beschrieben. Das zugrunde liegende Konstrukt wird in [RFC2104] diskutiert. Im Wesentlichen stellt eine unterschiedliche Sequenznummer in jedem Paket sicher, dass zumindest diese eine Eingabe in die MAC-Funktion eindeutig ist und eine nicht wiederkehrende MAC-Ausgabe liefert, die für einen Angreifer nicht vorhersagbar ist. Wenn die Sitzung jedoch lange genug aktiv bleibt, wird diese Sequenznummer überlaufen. Dieses Ereignis kann einem Angreifer die Möglichkeit bieten, ein zuvor aufgezeichnetes Paket mit einer identischen Sequenznummer wiederzugeben, jedoch nur, wenn die Peers seit der Übertragung des ersten Pakets mit dieser Sequenznummer nicht neu verschlüsselt haben. Wenn die Peers neu verschlüsselt haben, wird das Replay erkannt, da die MAC-Prüfung fehlschlagen wird. Aus diesem Grund muss betont werden, dass Peers VOR einem Überlauf der Sequenznummern neu verschlüsseln MÜSSEN. Natürlich, wenn ein Angreifer tatsächlich versucht, ein erfasstes Paket wiederzugeben, bevor die Peers neu verschlüsselt haben, dann wird der Empfänger des doppelten Pakets den MAC nicht validieren können und es wird verworfen. Der Grund, warum der MAC fehlschlagen wird, ist, dass der Empfänger einen MAC basierend auf dem Paketinhalt, dem gemeinsamen Geheimnis und der erwarteten Sequenznummer formuliert. Da das wiedergegebene Paket nicht diese erwartete Sequenznummer verwenden wird (die Sequenznummer des wiedergegebenen Pakets wird bereits vom Empfänger übergangen worden sein), wird der berechnete MAC nicht mit dem mit dem Paket empfangenen MAC übereinstimmen.

9.3.4. Man-in-the-Middle

Dieses Protokoll macht keine Annahmen oder Vorkehrungen für eine Infrastruktur oder Mittel zur Verteilung der öffentlichen Schlüssel von Hosts. Es wird erwartet, dass dieses Protokoll manchmal ohne vorherige Überprüfung der Assoziation zwischen dem Server-Host-Schlüssel und dem Server-Hostnamen verwendet wird. Eine solche Verwendung ist anfällig für Man-in-the-Middle-Angriffe. Dieser Abschnitt beschreibt dies und ermutigt Administratoren und Benutzer, die Bedeutung der Überprüfung dieser Assoziation vor dem Start einer Sitzung zu verstehen.

Es gibt drei Fälle von Man-in-the-Middle-Angriffen zu berücksichtigen. Der erste Fall ist, wenn ein Angreifer ein Gerät zwischen dem Client und dem Server platziert, bevor die Sitzung initiiert wird. In diesem Fall versucht das Angriffsgerät, den legitimen Server zu imitieren und wird seinen öffentlichen Schlüssel dem Client anbieten, wenn der Client eine Sitzung initiiert. Würde es den öffentlichen Schlüssel des Servers anbieten, dann könnte es die Übertragungen zwischen dem legitimen Server und dem Client nicht entschlüsseln oder signieren, es sei denn, es hätte auch Zugriff auf den privaten Schlüssel des Hosts. Das Angriffsgerät wird auch gleichzeitig eine Sitzung zum legitimen Server initiieren und sich als Client ausgeben. Wenn der öffentliche Schlüssel des Servers vor dieser Sitzungsinitiierung sicher an den Client verteilt wurde, wird der vom Angriffsgerät dem Client angebotene Schlüssel nicht mit dem auf dem Client gespeicherten Schlüssel übereinstimmen. In diesem Fall SOLLTE dem Benutzer eine Warnung gegeben werden, dass der angebotene Host-Schlüssel nicht mit dem auf dem Client zwischengespeicherten Host-Schlüssel übereinstimmt. Wie in Abschnitt 4.1 beschrieben, kann der Benutzer frei sein, den neuen Schlüssel zu akzeptieren und die Sitzung fortzusetzen. Es wird EMPFOHLEN, dass die Warnung dem Benutzer des Client-Geräts ausreichende Informationen liefert, damit der Benutzer eine informierte Entscheidung treffen kann. Wenn der Benutzer wählt, die Sitzung mit dem gespeicherten öffentlichen Schlüssel des Servers (nicht dem zu Beginn der Sitzung angebotenen öffentlichen Schlüssel) fortzusetzen, dann werden die sitzungsspezifischen Daten zwischen dem Angreifer und dem Server unterschiedlich zwischen der Client-zu-Angreifer-Sitzung und den Angreifer-zu-Server-Sitzungen sein, aufgrund der oben diskutierten Zufälligkeit. Daraus wird der Angreifer nicht in der Lage sein, diesen Angriff zum Funktionieren zu bringen, da der Angreifer nicht in der Lage sein wird, Pakete, die diese sitzungsspezifischen Daten vom Server enthalten, korrekt zu signieren, da er nicht den privaten Schlüssel dieses Servers hat.

Der zweite zu berücksichtigende Fall ist ähnlich dem ersten Fall, da er auch zum Zeitpunkt der Verbindung auftritt, aber dieser Fall weist auf die Notwendigkeit der sicheren Verteilung von Server-öffentlichen Schlüsseln hin. Wenn die Server-öffentlichen Schlüssel nicht sicher verteilt werden, dann kann der Client nicht wissen, ob er mit dem beabsichtigten Server spricht. Ein Angreifer kann Social-Engineering-Techniken verwenden, um Server-Schlüssel an ahnungslose Benutzer weiterzugeben und kann dann ein Man-in-the-Middle-Angriffsgerät zwischen dem legitimen Server und den Clients platzieren. Wenn dies zugelassen wird, dann werden die Clients Client-zu-Angreifer-Sitzungen bilden, und der Angreifer wird Angreifer-zu-Server-Sitzungen bilden und wird in der Lage sein, den gesamten Verkehr zwischen den Clients und den legitimen Servern zu überwachen und zu manipulieren. Server-Administratoren werden ermutigt, Host-Schlüssel-Fingerabdrücke zur Überprüfung durch Mittel verfügbar zu machen, deren Sicherheit nicht auf der Integrität der tatsächlichen Host-Schlüssel beruht. Mögliche Mechanismen werden in Abschnitt 4.1 diskutiert und können auch gesicherte Webseiten, physische Papierstücke usw. umfassen. Implementierer SOLLTEN Empfehlungen geben, wie dies am besten mit ihrer Implementierung durchgeführt werden kann. Da das Protokoll erweiterbar ist, können zukünftige Erweiterungen des Protokolls bessere Mechanismen zur Bewältigung der Notwendigkeit bieten, den Host-Schlüssel des Servers vor der Verbindung zu kennen. Beispielsweise sind das Verfügbarmachen des Host-Schlüssel-Fingerabdrucks über eine sichere DNS-Suche oder die Verwendung von Kerberos ([RFC4120]) über GSS-API ([RFC1964]) während des Schlüsselaustauschs zur Authentifizierung des Servers Möglichkeiten.

Im dritten Man-in-the-Middle-Fall können Angreifer versuchen, Pakete während der Übertragung zwischen Peers zu manipulieren, nachdem die Sitzung hergestellt wurde. Wie in Abschnitt 9.3.3 beschrieben, ist ein erfolgreicher Angriff dieser Art sehr unwahrscheinlich. Wie in Abschnitt 9.3.3 nimmt diese Argumentation an, dass der MAC sicher ist und dass es undurchführbar ist, Eingaben für einen MAC-Algorithmus zu konstruieren, um eine bekannte Ausgabe zu geben. Dies wird in Abschnitt 6 von [RFC2104] viel detaillierter diskutiert. Wenn der MAC-Algorithmus eine Schwachstelle hat oder schwach genug ist, dann kann der Angreifer möglicherweise bestimmte Eingaben spezifizieren, um einen bekannten MAC zu erzeugen. Damit könnten sie möglicherweise den Inhalt eines Pakets während der Übertragung ändern. Alternativ kann der Angreifer möglicherweise die Algorithmus-Schwachstelle oder -Schwäche ausnutzen, um das gemeinsame Geheimnis zu finden, indem er die MACs von erfassten Paketen überprüft. In beiden Fällen könnte ein Angreifer ein oder mehrere Pakete konstruieren, die in einen SSH-Stream eingefügt werden könnten. Um dies zu verhindern, werden Implementierer ermutigt, allgemein akzeptierte MAC-Algorithmen zu verwenden, und Administratoren werden ermutigt, die aktuelle Literatur und Diskussionen zur Kryptographie zu verfolgen, um sicherzustellen, dass sie keinen MAC-Algorithmus mit einer kürzlich entdeckten Schwachstelle oder Schwäche verwenden.

Zusammenfassend ist die Verwendung dieses Protokolls ohne zuverlässige Assoziation der Bindung zwischen einem Host und seinen Host-Schlüsseln inhärent unsicher und NICHT EMPFOHLEN. Es kann jedoch in nicht sicherheitskritischen Umgebungen notwendig sein und wird dennoch Schutz vor passiven Angriffen bieten. Implementierer von Protokollen und Anwendungen, die auf diesem Protokoll laufen, sollten diese Möglichkeit im Hinterkopf behalten.

9.3.5. Denial of Service

Dieses Protokoll ist für die Verwendung über einen zuverlässigen Transport konzipiert. Wenn Übertragungsfehler oder Nachrichtenmanipulation auftreten, wird die Verbindung geschlossen. Die Verbindung SOLLTE wiederhergestellt werden, wenn dies geschieht. Denial-of-Service-Angriffe dieser Art (Drahtschneider) sind fast unmöglich zu vermeiden.

Darüber hinaus ist dieses Protokoll anfällig für Denial-of-Service-Angriffe, da ein Angreifer den Server zwingen kann, die CPU- und speicherintensiven Aufgaben des Verbindungsaufbaus und Schlüsselaustauschs ohne Authentifizierung durchzuführen. Implementierer SOLLTEN Funktionen bereitstellen, die dies erschweren, beispielsweise indem sie nur Verbindungen von einer Teilmenge von Clients zulassen, von denen bekannt ist, dass sie gültige Benutzer haben.

9.3.6. Verdeckte Kanäle

Das Protokoll wurde nicht entwickelt, um verdeckte Kanäle zu eliminieren. Beispielsweise können das Padding, SSH_MSG_IGNORE-Nachrichten und mehrere andere Stellen im Protokoll verwendet werden, um verdeckte Informationen zu übermitteln, und der Empfänger hat keine zuverlässige Möglichkeit zu überprüfen, ob solche Informationen gesendet werden.

9.3.7. Forward Secrecy

Es sollte beachtet werden, dass die Diffie-Hellman-Schlüsselaustausche perfekte Forward Secrecy (PFS) bieten können. PFS ist im Wesentlichen definiert als die kryptographische Eigenschaft eines Schlüsseletablierungsprotokolls, bei der die Kompromittierung eines Sitzungsschlüssels oder eines langfristigen privaten Schlüssels nach einer bestimmten Sitzung nicht die Kompromittierung früherer Sitzungen verursacht [ANSI-T1.523-2001]. SSH-Sitzungen, die aus einem Schlüsselaustausch unter Verwendung der in Abschnitt Diffie-Hellman-Schlüsselaustausch von [SSH-TRANS] beschriebenen Diffie-Hellman-Methoden (einschließlich "diffie-hellman-group1-sha1" und "diffie-hellman-group14-sha1") resultieren, sind sicher, selbst wenn privates Verschlüsselungs-/Authentifizierungsmaterial später offengelegt wird, aber nicht, wenn die Sitzungsschlüssel offengelegt werden. Angesichts dieser Definition von PFS hat SSH also PFS. Diese Eigenschaft wird jedoch nicht auf Anwendungen oder Protokolle übertragen, die SSH als Transport verwenden. Die Transportschicht von SSH bietet Vertraulichkeit für Passwort-Authentifizierung und andere Methoden, die auf geheimen Daten beruhen.

Natürlich, wenn die DH-privaten Parameter für Client und Server offengelegt werden, dann wird der Sitzungsschlüssel offengelegt, aber diese Elemente können nach Abschluss des Schlüsselaustauschs weggeworfen werden. Es ist erwähnenswert, dass diese Elemente nicht in den Auslagerungsbereich gelangen sollten und dass sie so bald wie möglich nach Abschluss des Schlüsselaustauschs aus dem Speicher gelöscht werden sollten.

9.3.8. Reihenfolge der Schlüsselaustausch-Methoden

Wie im Abschnitt über Algorithmus-Verhandlung von [SSH-TRANS] angegeben, sendet jedes Gerät eine Liste bevorzugter Schlüsselaustausch-Methoden. Die bevorzugteste Methode ist die erste in der Liste. Es wird EMPFOHLEN, dass die Algorithmen nach kryptographischer Stärke sortiert werden, die stärksten zuerst. Zusätzliche Anleitung dazu wird in [RFC3766] gegeben.

9.3.9. Verkehrsanalyse

Die passive Überwachung eines Protokolls kann einem Angreifer einige Informationen über die Sitzung, den Benutzer oder protokollspezifische Informationen geben, die er sonst nicht sammeln könnte. Zum Beispiel wurde gezeigt, dass die Verkehrsanalyse einer SSH-Sitzung Informationen über die Länge des Passworts liefern kann - [Openwall] und [USENIX]. Implementierer sollten das SSH_MSG_IGNORE-Paket zusammen mit der Einbeziehung zufälliger Längen von Padding verwenden, um Versuche der Verkehrsanalyse zu vereiteln. Andere Methoden können auch gefunden und implementiert werden.

9.4. Authentifizierungsprotokoll

Der Zweck dieses Protokolls ist die Durchführung der Client-Benutzer-Authentifizierung. Es wird angenommen, dass dies über ein sicheres Transportschichtprotokoll läuft, das bereits die Servermaschine authentifiziert, einen verschlüsselten Kommunikationskanal eingerichtet und eine eindeutige Sitzungskennung für diese Sitzung berechnet hat.

Es sind mehrere Authentifizierungsmethoden mit unterschiedlichen Sicherheitsmerkmalen zulässig. Es liegt an der lokalen Richtlinie des Servers zu entscheiden, welche Methoden (oder Kombinationen von Methoden) er für jeden Benutzer zu akzeptieren bereit ist. Die Authentifizierung ist nicht stärker als die schwächste zulässige Kombination.

Der Server kann nach wiederholten erfolglosen Authentifizierungsversuchen in eine Schlafperiode übergehen, um die Schlüsselsuche für Angreifer zu erschweren. Es sollte darauf geachtet werden, dass dies nicht zu einem Selbst-Denial-of-Service-Vektor wird.

9.4.1. Schwacher Transport

Wenn die Transportschicht keine Vertraulichkeit bietet, SOLLTEN Authentifizierungsmethoden, die auf geheimen Daten beruhen, deaktiviert werden. Wenn sie keinen starken Integritätsschutz bietet, SOLLTEN Anfragen zur Änderung von Authentifizierungsdaten (z. B. eine Passwortänderung) deaktiviert werden, um zu verhindern, dass ein Angreifer den Chiffretext unbemerkt modifiziert oder die neuen Authentifizierungsdaten unbrauchbar macht (Denial of Service).

Die oben genannte Annahme, dass das Authentifizierungsprotokoll nur über einen sicheren Transport läuft, der den Server zuvor authentifiziert hat, ist sehr wichtig zu beachten. Personen, die SSH bereitstellen, werden an die Konsequenzen von Man-in-the-Middle-Angriffen erinnert, wenn der Client keine sehr starke a priori Assoziation des Servers mit dem Host-Schlüssel dieses Servers hat. Insbesondere für den Fall des Authentifizierungsprotokolls kann der Client eine Sitzung mit einem Man-in-the-Middle-Angriffsgerät bilden und Benutzeranmeldeinformationen wie Benutzername und Passwort preisgeben. Selbst in Authentifizierungsfällen, in denen keine Benutzeranmeldeinformationen preisgegeben werden, kann ein Angreifer immer noch Informationen erhalten, die er nicht haben sollte, indem er Tastenanschläge erfasst, ähnlich wie ein Honeypot funktioniert.

9.4.2. Debug-Nachrichten

Bei der Gestaltung von Debug-Nachrichten sollte besondere Vorsicht walten. Diese Nachrichten können überraschende Mengen an Informationen über den Host offenbaren, wenn sie nicht ordnungsgemäß entworfen sind. Debug-Nachrichten können deaktiviert werden (während der Benutzer-Authentifizierungsphase), wenn hohe Sicherheit erforderlich ist. Administratoren von Host-Maschinen sollten alle Anstrengungen unternehmen, um alle Ereignisbenachrichtigungsnachrichten zu kompartimentieren und sie vor ungerechtfertigter Beobachtung zu schützen. Entwickler sollten sich der sensiblen Natur einiger normaler Ereignis- und Debug-Nachrichten bewusst sein und möchten Administratoren möglicherweise Anleitungen geben, wie diese Informationen von unbefugten Personen ferngehalten werden können. Entwickler sollten erwägen, die Menge an sensiblen Informationen zu minimieren, die Benutzer während der Authentifizierungsphase gemäß den lokalen Richtlinien erhalten können. Aus diesem Grund wird EMPFOHLEN, dass Debug-Nachrichten zum Zeitpunkt der Bereitstellung zunächst deaktiviert sind und eine aktive Entscheidung eines Administrators erfordern, um ihre Aktivierung zu ermöglichen. Es wird auch EMPFOHLEN, dass eine Nachricht, die diese Bedenken zum Ausdruck bringt, dem Administrator eines Systems präsentiert wird, wenn die Maßnahme ergriffen wird, Debug-Nachrichten zu aktivieren.

9.4.3. Lokale Sicherheitsrichtlinie

Der Implementierer MUSS sicherstellen, dass die bereitgestellten Anmeldeinformationen den angegebenen Benutzer validieren, und MUSS auch sicherstellen, dass die lokale Richtlinie des Servers dem Benutzer den angeforderten Zugriff erlaubt. Insbesondere kann es aufgrund der flexiblen Natur des SSH-Verbindungsprotokolls nicht möglich sein, zum Zeitpunkt der Authentifizierung die lokale Sicherheitsrichtlinie zu bestimmen, falls vorhanden, die anzuwenden sein sollte, da die Art des angeforderten Dienstes zu diesem Zeitpunkt nicht klar ist. Beispielsweise kann eine lokale Richtlinie einem Benutzer den Zugriff auf Dateien auf dem Server erlauben, aber nicht das Starten einer interaktiven Shell. Während des Authentifizierungsprotokolls ist jedoch nicht bekannt, ob der Benutzer auf Dateien zugreifen, versuchen wird, eine interaktive Shell zu verwenden, oder sogar beides. In jedem Fall, wenn eine lokale Sicherheitsrichtlinie für den Server-Host existiert, MUSS sie korrekt angewendet und durchgesetzt werden.

Implementierer werden ermutigt, eine Standard-Lokalrichtlinie bereitzustellen und ihre Parameter Administratoren und Benutzern bekannt zu machen. Nach Ermessen der Implementierer kann diese Standardrichtlinie in Richtung "anything-goes" gehen, wo keine Einschränkungen für Benutzer auferlegt werden, oder sie kann in Richtung "übermäßig restriktiv" gehen, in welchem Fall die Administratoren aktiv Änderungen an den anfänglichen Standardparametern vornehmen müssen, um ihren Bedürfnissen gerecht zu werden. Alternativ kann es ein Versuch sein, etwas Praktisches und sofort Nützliches für die Systemadministratoren bereitzustellen, damit sie nicht viel Aufwand betreiben müssen, um SSH zum Laufen zu bringen. Welche Wahl auch immer getroffen wird, sie muss wie oben gefordert angewendet und durchgesetzt werden.

9.4.4 Public-Key-Authentifizierung

Die Verwendung der Public-Key-Authentifizierung setzt voraus, dass der Client-Host nicht kompromittiert wurde. Sie setzt auch voraus, dass der private Schlüssel des Server-Hosts nicht kompromittiert wurde.

Dieses Risiko kann durch die Verwendung von Passphrasen für private Schlüssel gemildert werden; dies ist jedoch keine durchsetzbare Richtlinie. Die Verwendung von Smartcards oder anderer Technologie, um Passphrasen zu einer durchsetzbaren Richtlinie zu machen, wird vorgeschlagen.

Der Server könnte sowohl Passwort- als auch Public-Key-Authentifizierung verlangen; dies erfordert jedoch, dass der Client sein Passwort dem Server preisgibt (siehe den Abschnitt über Passwort-Authentifizierung unten.)

9.4.5. Passwort-Authentifizierung

Der Passwort-Mechanismus, wie im Authentifizierungsprotokoll spezifiziert, setzt voraus, dass der Server nicht kompromittiert wurde. Wenn der Server kompromittiert wurde, wird die Verwendung der Passwort-Authentifizierung eine gültige Benutzername/Passwort-Kombination dem Angreifer offenbaren, was zu weiteren Kompromittierungen führen kann.

Diese Schwachstelle kann durch die Verwendung einer alternativen Form der Authentifizierung gemildert werden. Beispielsweise macht die Public-Key-Authentifizierung keine Annahmen über die Sicherheit auf dem Server.

9.4.6. Host-basierte Authentifizierung

Host-basierte Authentifizierung setzt voraus, dass der Client nicht kompromittiert wurde. Es gibt keine Milderungsstrategien außer der Verwendung von Host-basierter Authentifizierung in Kombination mit einer anderen Authentifizierungsmethode.

9.5. Verbindungsprotokoll

9.5.1. Endpunktsicherheit

Endpunktsicherheit wird vom Verbindungsprotokoll angenommen. Wenn der Server kompromittiert wurde, sind alle Terminal-Sitzungen, Port-Forwarding oder auf dem Host zugegriffenen Systeme kompromittiert. Es gibt hierfür keine mildernden Faktoren.

Wenn der Client kompromittiert wurde und der Server den Angreifer beim Authentifizierungsprotokoll nicht stoppen konnte, sind alle freigelegten Dienste (entweder als Subsysteme oder durch Forwarding) anfällig für Angriffe. Implementierer SOLLTEN Mechanismen für Administratoren bereitstellen, um zu steuern, welche Dienste freigegeben werden, um die Anfälligkeit anderer Dienste zu begrenzen. Diese Kontrollen könnten die Steuerung umfassen, welche Maschinen und Ports bei Port-Forwarding-Operationen anvisiert werden können, welche Benutzer interaktive Shell-Funktionen verwenden dürfen oder welche Benutzer freigegebene Subsysteme verwenden dürfen.

9.5.2. Proxy-Forwarding

Das SSH-Verbindungsprotokoll ermöglicht Proxy-Forwarding anderer Protokolle wie SMTP, POP3 und HTTP. Dies kann ein Anliegen für Netzwerkadministratoren sein, die den Zugriff bestimmter Anwendungen durch Benutzer außerhalb ihres physischen Standorts kontrollieren möchten. Im Wesentlichen kann das Forwarding dieser Protokolle standortspezifische Sicherheitsrichtlinien verletzen, da sie unerkennbar durch eine Firewall getunnelt werden können. Implementierer SOLLTEN einen administrativen Mechanismus bereitstellen, um die Proxy-Forwarding-Funktionalität zu steuern, damit standortspezifische Sicherheitsrichtlinien eingehalten werden können.

Darüber hinaus ist eine umgekehrte Proxy-Forwarding-Funktionalität verfügbar, die wiederum verwendet werden kann, um Firewall-Kontrollen zu umgehen.

Wie oben angegeben, wird Endpunktsicherheit während Proxy-Forwarding-Operationen angenommen. Das Scheitern der Endpunktsicherheit wird alle über Proxy-Forwarding übertragenen Daten kompromittieren.

9.5.3. X11-Forwarding

Eine weitere Form des Proxy-Forwarding, die vom SSH-Verbindungsprotokoll bereitgestellt wird, ist das Forwarding des X11-Protokolls. Wenn die Endpunktsicherheit kompromittiert wurde, kann X11-Forwarding Angriffe gegen den X11-Server ermöglichen. Benutzer und Administratoren sollten als Standard geeignete X11-Sicherheitsmechanismen verwenden, um unbefugte Verwendung des X11-Servers zu verhindern. Implementierer, Administratoren und Benutzer, die die Sicherheitsmechanismen von X11 weiter erforschen möchten, werden eingeladen, [SCHEIFLER] zu lesen und zuvor gemeldete Probleme mit den Interaktionen zwischen SSH-Forwarding und X11 in CERT-Schwachstellen VU#363181 und VU#118892 [CERT] zu analysieren.

X11-Display-Forwarding mit SSH allein ist nicht ausreichend, um bekannte Probleme mit X11-Sicherheit zu beheben [VENEMA]. X11-Display-Forwarding in SSH (oder anderen sicheren Protokollen) in Kombination mit tatsächlichen und Pseudo-Displays, die Verbindungen nur über lokale IPC-Mechanismen akzeptieren, die durch Berechtigungen oder Zugriffskontrolllisten (ACLs) autorisiert sind, behebt jedoch viele X11-Sicherheitsprobleme, solange der "none"-MAC nicht verwendet wird. Es wird EMPFOHLEN, dass X11-Display-Implementierungen standardmäßig zulassen, dass das Display nur über lokales IPC geöffnet wird. Es wird EMPFOHLEN, dass SSH-Server-Implementierungen, die X11-Forwarding unterstützen, standardmäßig zulassen, dass das Display nur über lokales IPC geöffnet wird. Auf Einzelbenutzersystemen kann es vernünftig sein, standardmäßig zuzulassen, dass das lokale Display über TCP/IP geöffnet wird.

Implementierer des X11-Forwarding-Protokolls SOLLTEN den Magic-Cookie-Zugriffsprüfungs-Spoofing-Mechanismus implementieren, wie in [SSH-CONNECT] beschrieben, als zusätzlichen Mechanismus, um unbefugte Verwendung des Proxys zu verhindern.