OpenSSH ukončí podporu algoritmu ssh-rsa. Co přesně to znamená?

V poznámkách k vydání verze 8.3 vývojáři zopakovali varování o budoucím odstranění podpory algoritmu ssh-rsa, které proběhlo bez povšimnutí už při vydání verze 8.2 a dokonce jsme na na něj upozorňovali ve zprávičce.

Internet si tentokrát všiml a začal nepatrně panikařit, aspoň soudě podle počtu reakcí na tento tweet:

important announcement from OpenSSH. pic.twitter.com/lsTkz04hZU

— Julio (@juliocesarfort) May 27, 2020

Čtenář bez hlubší znalosti protokolu SSH může snadno propadnout panice. Podívá-li se totiž třeba do souboru ~/.ssh/authorized_keys, najde tam seznam povolených klíčů:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmeq0hFwVgqm… 

Stejně tak, nahlédneme-li do souboru ~/.ssh/known_hosts, objevíme podobně identifikované serverové klíče:

www.nebezi.cz,2001:1528:132:70::ebe2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQA… 

Znamená to tedy, že budoucí verze OpenSSH přestanou podporovat RSA klíče? Je tedy nutné urychleně přejít na klíče založené na jiných algoritmech?

Ponořme se do standardů SSH

Abychom na otázky dokázali odpovědět, pojďme se ponořit na stranu 15 dokumentu RFC 4253, který standardizuje transportní vrstvu protokolu SSH:

 The "ssh-rsa" key format has the following specific encoding:

    string    "ssh-rsa"
    mpint     e
    mpint     n

 Here the 'e' and 'n' parameters form the signature key blob.

 Signing and verifying using this key format is performed according to
 the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

 The resulting signature is encoded as follows:

    string    "ssh-rsa"
    string    rsa_signature_blob 

Je zde vidět, že týž řetězec ssh-rsa v protokolu označuje jak samotný veřejný klíč RSA s parametry e a n, tak i algoritmus elektronického podpisu pomocí tohoto klíče. A protože k implementaci elektronického podpisu je kromě klíče potřeba také vytvořit otisk podepisované zprávy, dokument zde napevno předepisuje použití funkce SHA-1. A to je přesně ten důvod, proč tento algoritmus není možné nadále bezpečně používat.

Problém je v SHA-1, nikoli v RSA

Odpověď na výše uvedené otázky tedy samozřejmě zní: Nikoli. Klíče založené na RSA budou fungovat nadále stále stejně, budou-li dostatečně dlouhé. Standard popisující výměnu klíčů byl v březnu 2018 v dokumentu RFC 8332 rozšířen o podporu algoritmů, které pro podpis s klíči typu RSA používají otisky z rodiny SHA-2, konkrétně rsa-sha2-256 a rsa-sha2-512. Tento dokument také explicitně zmiňuje, že se stávajícími RSA klíči nic v nepořádku není a není tedy potřeba měnit jejich kódování:

 Since RSA keys are not dependent on the choice of hash function, the
 new public key algorithms reuse the "ssh-rsa" public key format as
 defined in [RFC4253]:

 string    "ssh-rsa"
 mpint     e
 mpint     n

 All aspects of the "ssh-rsa" format are kept, including the encoded
 string "ssh-rsa".  This allows existing RSA keys to be used with the
 new public key algorithms, without requiring re-encoding or affecting
 already trusted key fingerprints. 

Podpora pro RFC 8332 byla přidána v OpenSSH verze 7.2, které vyšlo už v únoru 2016. Pořadí preferencí algoritmů pro výměnu klíče je nastaveno tak, že algoritmus ssh-rsa se použije jen v případě, že novější algoritmy podporovány nejsou.

Máte-li tedy přiměřeně aktuální verzi OpenSSH na straně serveru i klienta, můžete RSA klíče používat nadále úplně stejně a žádné změny si nevšimnete. Pakliže z nějakého důvodu musíte používat starší verzi, případně jinou implementaci protokolu SSH, která RFC 8332 nepodporuje, budete mít menší či větší problém.

Serverové klíče mohou pozlobit

Už dnes můžeme vyzkoušet, které servery dosud použití SHA-2 s RSA klíči nepodporují, jednoduše tak, že v nastavení svého klienta podporu pro starý algoritmus vypneme:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host 

Pokud server použití SHA-2 nepodporuje, může dojít jen ke zobrazení známého varování o neshodě serverového klíče:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:DjdLezehMlzzMyOQZ3qpkX79aF19abq4Uz3yzr/glwA.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/user/.ssh/known_hosts:42
ECDSA host key for host has changed and you have requested strict checking.
Host key verification failed. 

To proto, že už od OpenSSH verze 5.7, která vyšla v lednu 2011, jsou podporovány i jiné algoritmy serverových klíčů, konkrétně ECDSA a později Ed25519. Ve výchozím nastavení server nabízí všechny klíče zároveň a je na klientovi, kterému dá přednost. Klienti obvykle preferovali algoritmus RSA, ovšem nepohrdnou ani serverovým klíčem založeným na jiných algoritmech. Jen logicky dojde k neshodě otisku klíče ECDSA s uloženým otiskem klíče RSA.

Aby k těmto problémům nedocházelo, obsahuje OpenSSH už od verze 6.8 rozšíření UpdateHostKeys , umožňující po úspěšném navázání spojení aktivně uložit do souboru ~/.ssh/known_hosts otisky všech klíčů, které server nabízí. Tato funkce byla dlouho ve výchozím stavu vypnutá, podle manuálové stránky má být zapnutá ve výchozím stavu od verze 8.2, poznámky k vydání však i u verze 8.3 tvrdí, že bude zapnutá někdy v budoucnosti. Rozhodně se ji však vyplatí zapnout manuálně už teď, nenapadá mě žádný negativní efekt takového nastavení.

Pokud se po výše uvedeném pokusu o spojení objeví pouze jednoduchá chyba:

Unable to negotiate with 2001:db8::1 port 22: no matching host key
type found. Their offer: ssh-rsa 

Znamená to, že server buď žádné jiné klíče než RSA nepodporuje, nebo je nemá vygenerovány. Pro druhý jmenovaný případ může pomoci zavolat na serveru ssh-keygen -A a restartovat službu ssh. Pokud server skutečně nic jiného než RSA nepodporuje, není nám pomoci. Dá se ovšem předpokládat, že i po ukončení podpory algoritmu ssh-rsa jej bude možné explicitně aktivovat v nastavení klienta, podobně jako dnes můžeme explicitně aktivovat některé zastaralé šifry, které jsou stále potřeba třeba pro přístup ke starým síťovým prvkům.

Uživatelské klíče problém mít nebudou, certifikáty už ho mají

Problém se samozřejmě týká i uživatelských klíčů – klient ve verzi starší než 7.2 se nebude schopen autentizovat RSA klíčem k budoucí verzi SSH serveru, který podporu algoritmu ssh-rsa ukončí. Prakticky to ale nejspíš problém nebude, desktopová prostředí se obvykle aktualizují mnohem svižněji než serverová.

Co však problém už je, jsou OpenSSH certifikáty. Takový certifikát je totiž vlastně soubor obsahující veřejný klíč, identifikaci držitele a oprávnění, kterýžto je podepsaný klíčem certifikační autority. Pokud certifikační autorita používá klíč typu RSA, vyrábělo OpenSSH až do verze 8.1 certifikáty podepsané právě algoritmem ssh-rsa, tedy s otiskem SHA-1. Protože v případě certifikátů má útočník v podstatě neomezenou dobu na přípravu kolize, bylo toto vyhodnocenou jako vysoké riziko a podpora těchto certifikátů byla s okamžitou platností odstraněna přímo ve verzi 8.2.

Pokud tedy používáte certifikáty, kde klíč autority používá RSA, tyto certifikáty přestaly s verzí 8.2 fungovat. Je třeba je přegenerovat s verzí 8.2 nebo novější; takové certifikáty ale zase nebudou fungovat ve verzích starších než 7.2. Pro širší kompatibilitu se tedy může hodit změnit algoritmus klíče autority na Ed25519 nebo dokonce ECDSA, čímž se zpětná kompatibilita certifikátu rozšíří až do verze 6.5, resp. 5.7.

Šifrování se vyvíjí, původní SSH verze 2 už neplatí

Ukončení podpory starého algoritmu tedy není žádný zásadní problém, představuje však jistý milník. Od této chvíle už nelze používat nic z toho, co bylo součástí původních otevřených standardů pro protokol SSH verze 2 – nejprve byla s verzí OpenSSH 7.0 v roce 2015 ukončena podpora pro klíče typu DSA, po odstranění podpory RSA v původní podobě v tomto standardu už nezbude nic. Nezbývá, než přijmout to jako fakt, kryptografické služby prostě málokdy přežijí víc než 20 let.