Re: Neue ssh-Konfiugration auf shell

[Christian Weisgerber <naddy@xxxxxxxxxxxx>]

Marc Haber:

> Meine Idee wäre gewesen, alles abzuschalten, was sha-1-hashes verwendet.
> Nach meine Verständnis fallen dort ssh-rsa wie auch ecdsa-sha-* hinein.

Die Verfahren heißen ecdsa-sha2-*. "SHA2". Passend zur 256-, 384-
und 521(!)-Bit Kurve werden SHA-256, SHA-384 und SHA-512 verwendet.
(RFC5656)

Analog für die Schlüsselvereinbarungen ecdh-sha2-*. (RFC5656)

SHA-1 wird bei diesen EC-Verfahren nicht verwendet.

> Im Gegensatz zu dem Stand von gestern ist inziwschen ecdsa-nistp-256 wieder
> erlaubt; das wird in der Nutzerbasis tatsächlich benutzt.  IMO sollte man
> das genauso wie RSA2048 oder kleiner so langsam eigentlich rauswerfen.

Naja, die Stärke ist etwa die von Ed25519.

> Wie stehst Du zu Compress bei ssh? Ich bin da nie bewusst vom default
> abgewichen. Der hat sich doch mehrfach geändert, oder? Nachdem ich jetzt
> nachgelesen und nachgedacht habe, würde ICH zu einem Compression no
> tendieren.

Ganz allgemein ist Kompression, also eigentlich die Dekompression,
problematisch, weil die Länge der Daten wächst und man bei
Implementierungsfehlern prompt einen Überlauf hat. Dazu kommen die
endlosen Seitenkanal- und Orakel-Angriffe, die dazu geführt haben,
dass man Kompression bei TLS1.3 ganz aufgegeben hat.

Der Unterschied zum ursprünglichen "zlib" und dem von OpenSSH
verwendeten "zlib@xxxxxxxxxxx" ist, dass Letzteres erst nach
erfolgreicher Authentisierung aktiviert wird, um die Angriffsfläche
zu verkleinern.

Der Aufsatz von Bäumer/Brinkmann bastelt jetzt ein etwas kompliziertes
Angriffsszenario ("a network attacker with access to a forwarded
TCP port and a web attacker executing JavaScript in the victim’s
browser via a malicious site"), aber ja, wenn man gegenüber den
Standardeinstellungen irgendetwas verschärfen will, dann ist
"Compression no" ein guter Kandidat. Zitat sshd_config(5):

    Compression applies to all traffic that flows over the SSH
    connection.  If untrusted traffic (such as an open port-forward)   
    is permitted over the connection alongside trusted traffic, then   
    compression may leak information about session contents.  For      
    this reason, it is not recommended to enable compression for       
    connections that share trusted and untrusted traffic.

Puhh. Ich frage nochmal nach, ob man die Standardeinstellung von
OpenSSH nicht ändern will.

-- 
Christian "naddy" Weisgerber                          naddy@xxxxxxxxxxxx

-- 
Unix User Group Rhein-Neckar e.V.: https://www.uugrn.org
Archiv und An-/Abmeldung:          https://mail2.uugrn.org
Social Media:                      https://social.uugrn.org