SSH, Linux und die stetige Veränderung von Sicherheit – II

In dieser Miniserie von Blog-Beiträgen (s. auch SSH, Linux und die stetige Veränderung von Sicherheit - I/) befasse ich mich ein wenig mit SSH.

Für mich liefert dieses Protokoll im Zeichen der letztjährigen Entwicklungen ein Beispiel dafür, unter welchen Aspekten ein Systemadministrator heute Sicherheitsvorkehrungen einordnen und gestalten muss. Es liefert aber auch ein Beispiel dafür, in welche Schieflage die Diskussion von Sicherheit in der IT insgesamt geraten ist und wie notwendig es wäre, eine grundsätzliche Debatte über die Rolle aller daran Beteiligten, inklusive staatlicher Organe, zu führen. Aber ein Schritt nach dem anderen.

Eine unruhe-weckende Publikation aus dem Jahr 2015

Nach ersten veröffentlichten Ergebnissen im Mai letzten Jahres erschien im Oktober 2015 eine Publikation, die klar und deutlich vermittelte, dass zumindest damalige Implementierungen von TLS, SSH aber auch IPsec/IKE einen gemeinsamen Schwachpunkt aufwiesen. Wer sich regelmäßig um Sicherheitsthemen kümmert, kennt das entsprechende Paper unter dem Titel "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" von Adrian et al., 2015, vermutlich schon. Es kann unter folgendem Link eingesehen werden:
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf.

Das Paper weist auf Schwächen in bestimmten Varianten des grundlegenden "Diffie-Hellman-Merkle"-Verfahrens [DHM] zur initialen Vereinbarung kryptographischer Schlüssel hin. Das asymmetrische DHM-Verfahren kommt in einer Reihe von Protokollen zur Verschlüsselung von Kommunikationskanälen zwischen Computern zum Einsatz. Passende Übersichtsartikel finden sich unter
https://weakdh.org/
https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html
https://www.schneier.com/blog/archives/2015/10/breaking_diffie.html
https://threatpost.com/prime-diffie-hellman-weakness-may-be-key-to-breaking-crypto/115069/
http://thehackernews.com/2015/10/nsa-crack-encryption.html

Das Interessante an der genannten Veröffentlichung war für mich Folgendes:

  • Sie zeigt auf, dass die Schwäche eines einzelnen grundlegenden kryptographischen Verfahrens Auswirkungen auf mehrere Standardprotokolle für den sicheren Datenaustausch in Netzwerken und im Internet haben kann.
  • Sie verdeutlicht, dass man bzgl. potentieller Angriffsszenarien immer alle Voraussetzungen, Phasen und Umsetzungsebenen der eingesetzten Protokolle im Blick haben muss. Und das schließt letztlich auch die benutzten mathematischen Algorithmen und daraus abzuleitende Konsequenzen ein.

Worum ging es?

Sichere Verbindungen zwischen Computern orientieren sich meist an dem Prinzip, dass das Brechen einer verschlüsselten Sitzung nicht zur Dekryptierung anderer bereits aufgezeichneter Datenströme führen darf. Man spricht auch von sog. "Forward Secrecy".

Ein Ansatz dazu ist die sitzungsspezifische Vereinbarung von Schlüsseln hinreichender Stärke für die anschließende eigentliche Kommunikationsverschlüsselung. Die Computer tauschen hierzu in einer initialen Kommunikationsphase öffentlich zugängliche Informationen und Parameter aus, die dann u.a. zur Berechnung eines gemeinsam genutzten (symmetrischer) Krypto-Schlüssels herangezogen werden. Natürlich muss das sog. "Key-Exchange-Verfahren" [KEX] so sicher sein, dass der Schlüssel aus den ausgetauschten öffentlich zugänglichen Informationen für Dritte NICHT ableitbar ist. Wie man das grundsätzlich erreicht, bespreche ich in einem Nachfolge-Artikel.

An dieser Stelle sind für das Verständnis zunächst nur drei Dinge wichtig, wobei wir uns im Moment mehr um das Wording und nicht um Details kümmern:

  • Das DHM-Verfahren wird von SSH in verschiedenen Ausprägungen genutzt. Darunter gibt es eine sog. FFC-Variante ("Finite Field Cryptography"), in deren Rahmen Gruppen von Parametern als Grundlage des konkreten KEX-Verfahrens ausgetauscht werden. Basis der FFC-Verfahren sind u.a. große Primzahlen und bestimmte multiplikative Operationen auf endlichen Zahlengruppen, die sich durch Modulo-Operationen zyklisch reproduzieren lassen. Die Publikation von Adrian et al. bezog sich auf FFC-Verfahren. Daneben gibt es Verfahren, die Operationen auf sog. "elliptischen Kurven" über definierten Zahlengruppen nutzen (EC : Elliptic Curve; ECC: Elliptic Curve Cryptography). Auch in EC basierten DHM-Verfahren spielen Primzahlen eine große Rolle.
  • In DHM-basierten KEX-Verfahren vom Typ FFC ist u.a. die Größe der Primzahlen (genauer deren Länge in Bits) entscheidend für die Sicherheit des gesamten Verfahrens. Diese Primzahlen und weitere Parameter müssen bestimmte Eigenschaften erfüllen. Sie sind in der Praxis daher Teil sog. vordefinierter Parametergruppen. Ein bestimmtes definiertes DHM-KEX-Verfahren vom Typ FFC nutzt also eine ganz bestimmte Parametergruppe und wird in der Regel auch nach dieser Gruppe bezeichnet. Welche Parametergruppen bereitstehen, hängt u.a. von der Implementierung des Protokolls ab - und nicht zuletzt auch davon, wer aus welchen Gründen solche Parametergruppen erzeugt und empfohlen hat.
  • Die konkrete KEX-Variante, die das SSH-Protokoll über den DHM-Prozess zur Schlüsselvereinbarung für eine bestimmte neue Computer-Verbindung nutzt, ist das Ergebnis eines initialen Verhandlungsprozesses: Das KEX-Verfahren wird von den beiden betroffenen Computer-Systemen nach bestimmten Regeln aus einer Menge möglicher und verfügbarer Verfahren ausgewählt. Die verfügbaren Verfahren können vom Systemadministrator festgelegt oder eingeschränkt werden. Die Auswahl eines konkreten FFC-Verfahrens bedeutet u.a. auch die Auswahl einer bestimmten vordefinierten Parametergruppe.

Bei DHM-KEX-Verfahren geht es also um Methoden, wie zwei Systeme im Vorfeld einer z.B. unter SSH verschlüsselten Kommunikation aus ausgetauschten Parametern einen konkreten gemeinsamen und für Dritte nicht reproduzierbaren Schlüssel für die Kryptierung des nachfolgenden Informationsstroms berechnen können. Das ernüchternde Ergebnis der genannten Untersuchung war, dass es zumindest mit den Ressourcen eines Staates möglich ist, bestimmte FFC-Varianten von DHM-KEX-Verfahren, die 2015 noch in der Praxis benutzt und von Servern angeboten wurden, zu brechen. Nämlich dann, wenn die verwendeten Primzahlen eine bis dato als sicher eingeschätzte Länge von 1024Bit oder weniger hatten. Dies betraf ganz bestimmte, im Einsatz befindliche vordefinierte Parametergruppen.

Ein potentieller Angriff würde sich also nicht gegen das eigentliche Verschlüsselungsverfahren von SSH, sondern auf das initiale KEX-Verfahren richten - mit dem Ziel, den Schlüssel des später eingesetzten, an sich sicheren Verschlüsselungsverfahrens in Erfahrung zu bringen. Bei dieser Attacke lohnt es sich übrigens durchaus, sowohl die initial öffentliche als auch die nachfolgende verschlüsselte Kommunikation für einen spätere Auswertung aufzuzeichnen.

Wer war zur Behebung der erkannten Schwächen zu addressieren?

Nach der Untersuchung von Adrian et al. steht und fällt die Sicherheit sowohl von SSH als auch anderen Protokollen damit, ob die von ihnen kritisierten FFC-Parametergruppen durch das DHM-Verfahren de facto herangezogen werden oder nicht. Hierauf hat u.a. der Systemadministrator durch Konfigurationseinstellungen Einfluss - wenn auch begrenzt. Er muss aber natürlich wissen, dass und wo es da ein Problem gibt und was konkret bei der Konfiguration seines Sicherheitsprotokolls zu tun ist.

Die genannte Untersuchung konnte im Zuge experimenteller Analysen aber auch belegen, dass die im Internet vorfindbaren Implementierungen von SSL/TLS bzw. SSH noch weitere Schwächen bis Fehler aufwiesen. Insgesamt wurde eine Lücke zwischen Erkenntnissen der Kryptographie und der algorithmischen Umsetzung bzw. Implementierung in konkreten SW-Paketen beklagt. Ein wichtiger Nachweis wurde im SSL/TLS-Umfeld durch die sog. "Logjam"-Attacke geführt. Neben Systemadministratoren sind also auch SW-Hersteller - und im Fall von Linux ggf. auch Distributoren anzusprechen. Im Falle von SSH sollten u.a. als schwach erkannte DHM-KEX-Verfahren standardmäßig aus der Implementierung für das jeweilige Betriebssystem ausgeschlossen werden.

Eine erste Reaktion des BSI

Wie ernst wurden nun die Ergebnisse der Untersuchung von offizieller Seite genommen? Man sollte meinen, dass die oben diskutierten Erkenntnisse eine dedizierte, klare und umfassende Warnung auch deutscher Bundesbehörden an Systemadministratoren zur Folge hätten haben müssen. Man würde nach Studium der verfügbaren Unterlagen zudem meinen, dass eine solche Warnung konkrete Hinweise zur Konfiguration u.a. von (Open-) SSH hätte beinhalten sollen.

Nun schielt man bei solchen Fragen in Deutschland auch als Open-Source-Anhänger fast zwangsläufig auf das BSI, das sich jährlich zur Sicherheitslage äußerst und dankenswerter Weise regelmäßig technische Richtlinien für sicherheitsrelevante Verfahren veröffentlicht bzw. aktualisiert. Ich möchte an dieser Stelle einzelne Empfehlungen des BSI gar nicht in Frage stellen. Mir geht es im Moment nur darum, ob die Themen der oben genannten Veröffentlichung in hinreichender Weise aufgegriffen wurden.

In seinem jährlichen Bericht "Die Lage der IT-Sicherheit in Deutschland 2015" vom November 2015 taucht auf S. 16 der Hinweis auf die sog. Logjam-Attake im TLS-Umfeld auf; nachgeordnet wird auch das allgemeinere und aus meiner Sicht wichtigere Thema der generellen Schwäche von KEX-Verfahren zur Festlegung von Kryptierungsschlüsseln unter DHM kurz angesprochen. Zitat: ..." Sie konnten dadurch die beim TLS-Verbindungsaufbau ausgetauschten geheimen Schlüssel nahezu in Echtzeit berechnen. Die Ergebnisse sind auch auf andere Einsatzbereiche dieses Schlüsselaustauschverfahrens übertragbar. Mit einem höheren Aufwand für die Vorberechnungen lassen sich zudem potenziell auch DLP-Fälle lösen, die eher dem Stand der Technik entsprechen. Die französischen Forscher geben beispielsweise Argumente dafür, dass die NSA in der Lage sei, das DLP auf ausgewählten Gruppen zu 1.024 Bit Primzahlen schnell zu lösen." Auf die Publikation von Adrian et. al. wird explizit hingewiesen.

Benannt werden die "anderen Einsatzbereiche" (u.a. SSH, IPSec) aber leider nicht konkret. Vor allem aber Hinweise/Links zu weiteren Informationen bzgl. konkret zu treffenden Maßnahmen bzgl. der Konfiguration dieser Protokolle werden im BSI-Papier unverständlicherweise nicht gegeben.

Die im Februar 2016 erschienene technische Richtlinie BSI TR-02102-1 zum Thema "Kryptographische Verfahren: Empfehlungen und Schlüssellängen" und die Richtlinie TR-02102-4 für SSH sprechen das Thema hinreichender Primzahl- und Schlüssellängen natürlich an und die empfohlenen Längen sind sehr wohl hinreichend. Die Publikation von Adrian et al. wird dort aber leider überhaupt nicht erwähnt. Immerhin drängt die TR-02102-4 darauf, bestimmte KEX-Algorithmen unter SSH nicht mehr zu nutzen oder zumindest in der Priorität herabzusetzen.

Die Richtlinien arbeiten jedoch nicht klar heraus, wer eigentlich einen Einfluss auf die Liste bereitgestellter KEX-Verfahren sowie zugehöriger Parametergruppen und Primzahllängen in bestimmten SSH-Implementierungen hat und wer diese Liste wie begrenzen bzw. wie beeinflussen kann: der Hersteller und/oder der System-Administrator?

Ich finde, solche für die Praxis wichtigen Punkte sollten in einer technischen Richtlinie eigentlich klar und unmissverständlich behandelt werden. Ferner würde ich mir neben grundsätzlichen Empfehlungen auch ein Eingehen auf die wichtigsten am Markt vertretenen Implementierungen wünschen.

Zur anderen Empfehlungen des BSI - im Besonderen zum Einsatz bestimmter sog. "Elliptischer Kurven" als Grundlage von DHM unter SSH später mehr.

Die späte, aber richtige Reaktion des CERT-EU

Das offizielle Europa reagierte mit erheblicher Zeitverzögerung. Das CERT-EU Security Whitepaper 16-002, "Weaknesses in Diffie-Hellman Key Exchange Protocol" vom Juli 2016 (!)
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_16-002_Weaknesses%20in%20Diffie-Hellman%20Key%20v1_0.pdf
nimmt aber explizit Bezug auf die Ergebnisse der Studie von Adrian et. al.. Deren große Bedeutung auch für SSH, IKE/IPSec etc. wird klar herausgearbeitet.

Die Einordnung des DHM-Verfahrens als kritische und grundlegende Technologie verschiedener sicherheitsrelevanter Protokolle erfolgt aus meiner Sicht klar und deutlich; Zahlen aus der Studie für die verschiedenen betroffenen Sicherheitsprotokolle wurden zitiert. Die Logjam-Attake wurde als TLS-Besonderheit diskutiert. Im Rahmen der weitergehenden Empfehlungen (z.B. zum Einsatz "Elliptischer Kurven-Algorithmen" im Rahmen von DHM) wird explizit auf weitere kritische und aktuelle Untersuchungen hingewiesen. Danach wendet sich das CERT-EU-Papier explizit an Systemadministratoren und gibt Hinweise bzgl. verschiedener betroffene Systeme und Protokoll-Implementierungen - auch und vor allem im Open-Source-Umfeld. U.a. OpenSSH wird ein eigenes Kapitel gewidmet, in dem (relativ) klare Vorgaben enthalten sind.

Einschätzungen

In jedem Fall signalisierte die Veröffentlichung des CERT-EU White Papers eindrücklich, dass man das durch Adrian et al. aufgeworfene Problem ernst zu nehmen hatte - auch und vor allem als normaler Systemadministrator. Die Art der in der Untersuchung von Adrian et al. besprochenen Schwächen der KEX-Verfahren ist zudem nicht geeignet, allein auf Updates zu vertrauen. Man muss sich als Administrator schon um die konkrete Konfiguration von SSH bzw. OpenSSH kümmern. Daran lässt das Cert-EU-Paper kaum Zweifel.

Nach meiner Einschätzung kamen die Bedeutung und die Reichweite der Ergebnisse von Adrian et al. für die Praxis von Systemadministratoren in den BSI-Papieren dagegen leider nicht so recht zur Geltung. In den später aktualisierten technischen Richtlinien TR-02102-1 bzw. -4 kam die Studie gar nicht vor - auch wenn die Vorgaben für FFC-Verfahren (im BSI-Papier unter DLIES-Verfahren zu finden) selbst den Anforderungen aus der Studie Genüge leisten. So blieb der Handlungsbedarf für Administratoren eher unklar. Man hätte als Leser der BSI-Publikationen auch darauf vertrauen können, dass sich die notwendigen Maßnahmen über Updates der SW-Hersteller erledigen würden.

Das White Paper des CERT-EU hingegen zeichnete sich dadurch aus, dass es sich gezielt mit dem Thema DHM befasste (Titel: "Weaknesses in Diffie-Hellman Key Exchange Protocol"). Als Administrator wurde man sozusagen geordnet in Unruhe und danach in Aktivität versetzt. Die Hinweise zu den betroffenen Protokollen und notwendigen Änderungen waren hinlänglich, um sich dann im Detail um die etwa für OpenSSH vorhandenen Konfigurationsmöglichkeiten zu kümmern. Aus den Informationen zu OpenSSH in der damaligen Version ging zudem klar hervor, dass man als Administrator bestimmte KEX-Verfahren explizit ausschließen sollte. Ehrlich gesagt, hätte ich mir eine ähnlich prägnante Publikation von Seiten des BSI gewünscht.

Das Thema Sicherheit umfassend adressieren

Für Administratoren ist die wichtigste Erkenntnis aus der Untersuchung von Adrian et al. die, dass sie gefordert sind, bei der konkreten Implementierung und Konfiguration von SSH entweder bestimmte KEX-Verfahren explizit auszuschließen oder mit eigenen, speziell generierten Parametergruppen zu unterfüttern. Mindestens für letzteres MUSS man sich aber um Vor- und Nachteile kryptographischer Verfahren kümmern. SW-Pakete einzuspielen allein reicht in keinem Fall !

Ich habe das Paper insgesamt jedoch sehr viel weitergehenden Appell verstanden: Die ganze Kette der Herstellung, Bereitstellung, Installation und Konfiguration der heutigen zentralen, sicherheitsrelevanten Protokolle und Verfahren sowie die zugehörige Informationspolitik ist eigentlich einem Review zu unterziehen.

Protokolle wie TLS oder eben SSH erfordern grundsätzlich den Einsatz verschiedener kryptographischer Verfahren, die in unterschiedlichen Phasen der Computerinteraktion für spezifische Zwecke zum Einsatz kommen. Angriffe auf die Sicherheit und Manipulationen sind in allen Phasen der Protokollabwicklung und auf alle Ebenen der eingesetzten Verfahren möglich. Deshalb sind auch zugrundeliegende mathematische Algorithmen zu hinterfragen. Konsequenzen bzgl. deren Implementierung bzw. die konkrete Konfiguration durch den Systemadministrator sind regelmäßig ins Verhältnis zu neuen Möglichkeiten der Kryptoanalyse zu setzen. Die Veröffentlichung von Adrian et al. adressierte letztlich all diese Ebenen; die einleitenden Ausführungen der Autoren stellten für mich auch eine Art Appell dar:

Wenn es um Sicherheit in der IT geht, ist das Zusammenwirken vieler Glieder einer Kette zu betrachten. Und welches das schwächste Glied und an welcher Stelle es zu Manipulationen kommt, ist nicht immer offenkundig. Hinzu kommt: Die Informationsverbreitung zu erkannten Schwächen muss sich in adäquater und expliziter Weise an alle wenden, die etwas zu tun haben, um die Schwächen in der Praxis zu beheben.

SSH, Linux und die stetige Veränderung von Sicherheit – I

Setzt man sich mit IT-Sicherheit auseinander, so ist eine der faszinierenden, aber auch erschreckenden Tatsachen die, dass als sicher eingeschätzte Fundamente mit der Zeit erodieren. Das gilt für Open-Source-SW ebenso wie für Produkte proprietärer Hersteller. Auch bei konsequenter Update-Politik bleibt immer ein Rest an Unsicherheit.

Im Open-Source-Bereich erlebte SSL/TLS in der OpenSSL-Implementierung mit dem "Heartbleed-Bug" ein abruptes und unsanftes Erwachen aus dem Dornröschen-Schlaf. Dann kam der "Shellshock"-Bug. Ursache waren in beiden Fällen echte SW-Fehler, die sich beheben ließen. Für den Linux-Server-Administrator erschöpfte sich die notwendige Reaktion im Einspielen zeitnah bereitgestellter Updates der Linux-Distribution seines Vertrauens. Aber reicht das immer? Und wenn schon Bugs vorhanden sind - wer sagt einem, dass nicht auch viel grundsätzlichere, z.B. algorithmische Schwächen unsere aktuellen Security-Tools kennzeichnen? So fragt man sich als besorgter Admin immer mal wieder:

Wie sieht es eigentlich mit SSH - genauer OpenSSH - aus?

Unzweifelhaft gehört SSH zu den zentralen Handwerkszeugen, die den Alltag von Systemadministratoren nicht nur im Linux-Umfeld prägen. Ohne SSH kein SFTP, ohne SSH keine sichere Remote-Serveradministration, ohne SSH kein VPN over SSH (z.B. in problematischen Staaten). Es ist wohl keine Übertreibung zu sagen: Ist SSH bedroht, fallen Grundfesten der IT-Sicherheit. Auch im Linux-Umfeld. Trägt man konkrete Verantwortung für die Geheimhaltung von Unternehmensdaten steht deshalb früher oder später die Frage im Raum:

Muss man sich im Falle der Installation und Konfiguration von SSH neben Updates ggf. auch mit Kryptokomponenten befassen, die jenseits der praxisnahen Erzeugung von Schlüsseln für "Public Key"-Authentifizierungsverfahren liegen? Und wer gibt einem im Zweifel dafür vertrauenswürdige Richtlinien an die Hand? Fragen genug für ein paar Blog-Beiträge.

Begründeter Anlass zur Sorge?

Seit ziemlich genau einem Jahr gab es mehrfach Anlass, sich um die SSH-Konfiguration auf eigenen Servern Gedanken bis Sorgen zu machen. Das begann mit einer Untersuchung, deren Ergebnisse erstmals im Mai 2015 diskutiert und dann auf einer Sicherheitstagung im Herbst 2015 präsentiert und als Paper veröffentlicht wurden. Gegenstand des Papers sind potentielle Schwächen eines asymmetrischen Krypto-Verfahrens (Diffie-Hellman-Merkle [DHM]), das u.a. im Rahmen von SSH, TLS und IKE/IPsec zum Einsatz kommt. Ich fand es wenig beruhigend, wie die Studie nachvollziehbar vermittelte, dass ca. 25% aller SSH-Verbindungen mit den Ressourcen eines Staates angreifbar sein sollten.

Ich selbst ordne eine solche Thematik weniger unter dem Blickwinkel einer Totalüberwachung durch mehr oder weniger freundlich gesinnte Sicherheitsorgane irgendwelcher Staaten ein, als vielmehr unter dem Aspekt einer potentiellen und durch Staaten gestützten Wirtschafts- und Industriespionage. Ein wichtiger Punkt für unseren deutschen Mittelstand und darunter gerade für kleinere innovative Firmen, die auf Open-Source setzen.

Auch die praktischen Konsequenzen für System-Administratoren trugen nicht gerade zu meiner Nachtruhe bei:

Aus meiner Sicht waren über Konfigurationseinstellungen mathematische Verfahren einzuschränken oder zumindest zu priorisieren, die unter DHM und damit auch SSH zum Einsatz kommen. Ein besseres Verständnis setzte eine intensivere Auseinandersetzung mit Krypto-Verfahren und deren Vertrauenswürdigkeit voraus. Das Ergebnis entsprechender Recherchen war wiederum nicht als Beruhigungsmittel geeignet. Und zu guter Letzt äußerten sich NSA-Vertretern vor kurzem ganz grundsätzlich zur Zukunft asymmetrischer kryptographischer Verfahren. Die getroffenen Aussagen betreffen u.a. auch SSH und wurden von Experten unterschiedlich gewertet, was wiederum eher zur Verwirrung bzgl. der praktischen Konsequenzen beitrug.

Zeit also für eine kleine Auseinandersetzung mit diesen Punkten. Eine Grundsatzdiskussion, ob man nicht-europäischen Herstellern proprietärer Betriebssystem-Software, die aufgrund der Gesetzeslage im eigenen Land ggf. mit Geheimdiensten zusammenarbeiten müssen, bzgl. der sicheren Implementierung von kryptographischen Systemkomponenten trauen kann, erspare ich mir dabei. Ich beschränke mich hier auf Konsequenzen für Linux-Systeme.

Gliederung der Beitragsserie

Nicht jeder Linux-Admin kennt Grundlagen der Kryptographie. Um die Risiken klarer einzuordnen, ist aber zumindest ein oberflächlicher Blick hinter die Kulissen notwendig. Leser, die mit den Grundlagen (symmetrische Kryptographie, asymmetrische Verfahren, Faktorisierung großer Zahlen, Primzahlen, Modulo-Operationen) vertraut sind, werden sich dagegen mit einigen Ausführungen langweilen. Ich teile deshalb die Auseinandersetzung in mehrere Beiträge auf, die je nach Lust und Laune auch übersprungen werden können.

  • Zunächst möchte ich oben genannte Schlüsselpublikation aus dem letzten Jahr in Erinnerung rufen - und hierzu ein paar Links zusammenstellen. Dabei möchte ich auch einen Blick darauf werfen, wie die Untersuchung vom BSI bzw. CERT-EU verarbeitet wurde. Für Systemadministratoren war die Konsequenz abzuleiten, sich nicht nur mit SSH-Updates sondern auch mit Konfigurationseinstellungen von SSH zu befassen.
  • In einem weiteren Beitrag wende ich mich dann ein paar Details der diagnostizierten Schwächen im initialen Schlüsselaustausch zu. Aus den dortigen Ausführungen sollte einerseits klar werden, wie wichtig die Absicherung des initialen "Key Exchange"-Verfahrens ist [KEX]. In Kombination mit den Untersuchungen aus 2015 ergibt sich, dass der vorsichtige Administrator bestimmte KEX-Verfahren in seiner SSH-Konfiguration eigener Server ausschließen wird; selbst wenn der SSH-Standard sie erfordert.
  • Anschließend möchte ich kurz auf Alternativen zum klassischen Diffie-Hellmann-Verfahren eingehen. Ohne auf Details einzugehen, ist auch dort darauf hinzuweisen, dass bestimmte sog. Elliptic Curve basierte KEX-Verfahren u.U. mit Vorsicht zu genießen sind, selbst wenn sie nicht die 2015 entdeckten Schwächen aufweisen. Dies deuten zumindest andere Untersuchungen an.
  • In einem weiteren Teil möchte ich dann auf etwas Banales hinweisen, das aber in der Praxis von sog. "günstigen" Linux-Implementierungen durchaus eine Rolle spielen kann - nämlich die Kollision von Upgrade- und Update-Politik in nur zeitweise mit Sicherheitsupdates versorgten Linux-Distributionen. Ich werfe dabei einen Blick auf 2016 offiziell verfügbare Updates zu OpenSSH für eine bestimmte Opensuse-Variante.
  • Ein weiterer Teil stellt dann konkrete Hinweise zur Konfiguration von SSH bzgl. DHM zusammen.
  • Ein letzter Artikel befasst sich mit dem Abrücken ausgerechnet der NSA von bestimmten Grundlagen asymmetrischer Krypto-Verfahren.