Vlákno názorů k článku High Performance SSH/SCP: rychlé přenosy souborů bezpečným kanálem od Jamamoto - Kdyby se radši místo vymýšlení rovnáků na ohýbáky...

Způsob ověření serveru je ale není věc protokolu, pouze otázka implementace – i v HTTPS klidně můžete důvěřovat jenom jednomu konkrétnímu certifikátu. Stejně tak i v HTTPS může server ověřovat klienta, několika různými způsoby, stejně jako u SSH – jménem a heslem, výzvou a odpovědí, certifikátem nebo nestandardními prostředky třeba přes Kerberos.

Používat SSL tak, že ověřím pouze, že certifikát podepsala nějaká veřejná CA. V lepším případě, že sedí doménové jméno, to je docela hloupé použití na cokoliv jiného než na veřejné služby. To (předem domluvená) výměna souborů mezi dvěma firmami typicky není. A už vůbec to není případ kopírování souborů uvnitř firmy. Takže ano, pokud neumíš použít správně HTTPS nebo jiné SSL spojení, tak je SSH lepší. Ale ve skutečnosti je SSH jen o malý chlup lepší, protože málokdo kontroluje, že host key je správný při prvním připojení. Dokonce naopak vidím často vypnutou striktní kontrolu host key, kvůli občasné reinstalaci serverů. Takže vás SSH v běžném použití prakticky nechrání před přihlášením se na podvržený počítač. To už to SSL alespoň teoreticky zkontroluje, že se připojujete k serveru majitele domény.

Pokud se pak přihlašujete jménem a heslem, (protože třeba hloupě napojený LDAP), tak jste právě jméno a heslo vyzradil útočníkovi. Pokud se přihlašujete soukromým klíčem tak jste na tom trochu lépe, útočník neudělá MITM, ale to v SSL teoreticky také neudělá (i když z jiného důvodu).

Podle mne je správná cesta určit jakou úroveň zabezpečení požadujete a podle toho vybrat CA kterým budete důvěřovat. Udělat si vlastní CA, která bude ověřovat interní služby je jednoduché a je to v SSL velmi vhodné. A dokonce to lze udělat i v SSH, čímž může odpadnout otravné ověřování host_keys!

Na začátku byla řeč o standardizaci nového protokolu. Pro nový protokol by bylo nutné psát nové klienty, takže můžeme předpokládat nové klienty nebo upravení těch stávajících i u WebDAVu. Přihlášení klientským certifikátem je podle mne běžnou vlastností WebDAV klientů, ten seznam důvěryhodných certifikátů nezávislý na systému bude větší problém. Ale problém je v klientských WebDAV aplikacích, nikoli v HTTP knihovnách, ty to podporují běžně. Průchodnost všude platí, síťové prvky nijak nezjistí, jakým způsobem klient ověřuje serverový certifikát. Že je vyžadováno přihlášení klientským certifikátem může proxy zjistit, ale nikdy jsem neslyšel o tom, že by to nějaká blokovala (jedině pokud dělá MitM). Pořád bude HTTPS průchozí mnohem častěji, než SSH.