Jaký je rozdíl mezi SSL a SSH? Co je bezpečnější?

SSL i SSH poskytují kryptografické prvky pro vybudování tunelu pro důvěrný přenos dat se zkontrolovanou integritou. Pro tuto část používají podobné techniky a mohou trpět stejným druhem útoků, takže by měly poskytovat podobné zabezpečení (tj. dobré zabezpečení) za předpokladu, že jsou oba správně implementovány. To, že oba existují, je jakýmsi syndromem NIH : vývojáři SSH měli pro tunel znovu použít SSL (protokol SSL je dostatečně flexibilní, aby vyhověl mnoha variantám, včetně nepoužívají certifikáty).

Liší se ve věcech, které jsou kolem tunelu. SSL tradičně používá certifikáty X.509 k ohlašování veřejných klíčů serveru a klienta; SSH má svůj vlastní formát. SSH také přichází se sadou protokolů pro to, co prochází uvnitř tunelu (multiplexování několika přenosů, provádění ověřování na základě hesla v tunelu, správa terminálu …), zatímco v SSL nic takového neexistuje , nebo přesněji, když se takové věci používají v SSL, nejsou považovány za součást SSL (například když provádíme ověřování HTTP založené na heslech v tunelu SSL, říkáme, že je součástí „HTTPS“, ale opravdu to funguje podobným způsobem, jaký se děje s SSH).

Koncepčně byste mohli vzít SSH a nahradit tunelovou část tu ze SSL. Dalo by se také vzít HTTPS a nahradit SSL věc s SSH-s-datovým transportem a háčkem k extrakci veřejného klíče serveru z jeho certifikátu. Neexistuje žádná vědecká nemožnost a pokud by byla provedena správně, bezpečnost by zůstala stejná. K tomu však neexistuje žádná rozšířená sada konvencí ani stávající nástroje.

Takže nepoužíváme SSL a SSH pro stejné věci, ale je to kvůli tomu, jaké nástroje historicky přicházejí s implementacemi těchto protokoly, ne kvůli rozdílu souvisejícím se zabezpečením. A kdokoli implementuje SSL nebo SSH, bylo by dobré se podívat, jaké útoky byly na obou protokolech vyzkoušeny.

Komentáře

• Dobrá práce. A protože SSH je snadnější nastavit než SSL, mnoho lidí tuneluje uvnitř SSH http (ne https), např. pro vzdálenou správu systému s webem Nástroj grafického uživatelského rozhraní, jako je ebox nebo webmin.
• Jen pro zdůraznění, ‚ není úplně pravda, že kluci SSH “ měl “ použít SSL: SSH byl navržen velmi konkrétně, aby měl malou útočnou plochu a byl velmi bezpečný. SSHv2 nemá žádný problém a úskalí v SSL / TLS, takže jít s menší věcí, kterou u nerozuměli dobře, ale s menší složitostí přišli s něčím mnohem lépe vyhovujícím jejich situaci. Záleží na tom, jak jste paranoidní: SSL není ‚ t nepoužitelný, v závislosti na aplikaci, ale díky SSH ‚ designu je přijatelný v situacích / bezpečnostní komunity, kde SSL prostě není důvěryhodné.
• @NicholasWilson “ SSH ‚ díky designu je přijatelný v situacích / bezpečnostních komunitách, kde SSL jednoduše není důvěryhodný “ jako …
• SSL a SSH byly vyvíjeny paralelně (oba byly vydány v roce 1995), takže ať už SSH dokonce mohl použít SSL není jasné. Zda měl použít současný SSL 2.0, je také velmi pochybné 🙂
• No, SSH 2.0 byl úplným přepsáním protokolu a objevil se někdy kolem roku 1999, takže jeden mohl znovu použít SSL 3.0 nebo dokonce TLS 1.0. Samozřejmě se TLS zdá svázán s X.509, což vývojáře děsí.

Toto není rozumné srovnání. SSL je obecná metoda ochrany dat přenášených po síti, zatímco SSH je síťová aplikace pro přihlášení a sdílení dat se vzdáleným počítačem.

Ochrana transportní vrstvy v SSH má podobnou schopnost jako SSL, takže to, co je „bezpečnější“, závisí na tom, co vyžaduje váš konkrétní model ohrožení a zda implementace každé z nich řeší problémy, se kterými se snažíte vypořádat.

SSH pak má vrstvu ověřování uživatelů, která SSL postrádá (protože ji nepotřebuje – SSL potřebuje pouze ověřit dvě spojovací rozhraní, která SSH může také dělat). V umění UTF-8:

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

Pokud jde o problém, proti kterému existuje více potenciálních útoků, zdá se být jasné, že SSH má větší útočnou plochu. Ale je to jen proto, že SSH má celý applic do ní zabudovaná: útočná plocha SSL + jakékoli aplikace, kterou potřebujete poskytnout nelze srovnávat, protože nemáme dostatek informací.

Komentáře

• -1 Je to rozumné srovnání. Nesprávně předpokládáte, že OP porovnává SSL s unixovým programem ssh (1) . SSH je vlastně další protokol poskytující zabezpečení transportní vrstvy, který má zvláštní ustanovení pro vzdálené skořápky a vzdálené spuštění.
• +1 @jpillora, i když souhlasím, má smysl tyto dva porovnávat, termín SSH je obvykle se nepoužívá k označení podmnožiny protokolu SSH, který zpracovává zabezpečení transportní vrstvy, které by bylo přímo srovnatelné s SSL / TLS. Používá se téměř výlučně v odkazu na protokol aplikační vrstvy, který se liší od SSL / TLS způsobem popsaným v této odpovědi.
• @freb tak, jak ‚ Obecné doporučení nemění pravdivost věci. SSH je protokol, který se používá jako transportní vrstva pro nástroj ssh. Přijatá a nejhlasovanější odpověď tuto skutečnost odráží.
• @jpillora Měl jsem na mysli jen to, že si nemyslím, že protokol transportní vrstvy SSH je tím, co by většina lidí myslela ‚ vzhledem k formulaci otázky. Avšak vzhledem k tomu, že odpověď byla přijata jako správná, muselo to být to, na co se OP ptal.
• @freb Správně, většina lidí si myslí, že vzhledem k frázi, díky níž je ještě důležitější opravit tuto společnou mylná představa.

Z přísného kryptografického hlediska poskytují oba ověřené šifrování, ale ve dvou různé způsoby.

SSH používá takzvaný Encrypt-and-MAC, to znamená, že šifrovaná zpráva je umístěna vedle autentizačního kódu zprávy (MAC) jasné zprávy, aby se zvýšila integrita. Není prokázáno, že je vždy plně bezpečný (i když v praktických případech by to mělo stačit).

SSL používá MAC-then-Encrypt: MAC je umístěn vedle čistého textu, oba jsou šifrovány . Ani to není nejlepší, protože u některých režimů blokové šifry lze části MAC uhodnout a odhalit něco na šifře. To vedlo k chybám zabezpečení v protokolu TLS 1.0 (útok BEAST).

Takže oba mají potenciální teoretické slabiny. Nejsilnější metodou je Encrypt-then-MAC (přidání MAC šifrované zprávy), která je implementována např. V IPsec ESP.

Komentáře

• SSH ‚ s binární paketový protokol je encrypt-and-MAC, kde pro každou prostou zprávu (m) pošle ciphertext E (m) ++ MAC (m) (zřetězit šifrovaný zpráva s MAC), oproti SSL, které dělá E (m ++ MAC (m)). SSH je však mnohem víc než jen jeho binární paketový protokol (správa klíčů, klient / server vzdáleného prostředí, provádí přenos souborů atd.), Zatímco SSL (nyní nazývaný TLS) je pouze protokol transportní vrstvy, který se používá v jiných protokolech, které přidávají v potřebné funkčnosti (např. HTTPS, FTPS, IMAPS atd.). Viz také srovnání EtM, E & M, MtE na adrese: crypto.stackexchange.com / questions / 202
• Plně souhlasím, je toho mnohem víc, než jsem napsal; to ‚ to, co jsem měl na mysli se svým incipit “ z přísného kryptografického hlediska „.
• BEAST nesouvisí s MtE a je způsoben známým IV s CBC (v SSL3 a TLS1.0) – což SSH2 také dělá a neopravuje, ačkoli dostal CTR jako alternativu dříve než on i TLS dostali AEAD = GCM (TLS také CCM) (a oba ChaCha / Poly) jako lepší alternativu. Útoky založené na polstrování MtE + CBC jsou POODLE a Lucky13.
• Mám řešení, díky kterému je MAC-then-Encrypt bezpečný pro jakoukoli šifru, která má výstupní velikost = velikost vstupu a žádný slabý vstup dat do šifry jádro.
• tato odpověď je zastaralá, protože to dnes TLS nedělá.

Myslím, že je zde jeden aspekt tohoto srovnání, který byl přehlédnut. user185 se přiblížil, ale docela se tam nedostal. Souhlasím s tím, že se jedná o jablka a pomeranče a cítím lepší srovnání jablka s jablky, než je HTTPS a SSH. HTTPS a SSH využívají různé vrstvy modelu OSI, a proto šifrují data na různých časy v přenosu. Skutečné otázky, na které byste se měli ptát, by byly v duchu toho, kdy jsou tato data šifrována a nezašifrována během přenosu. To odhalí vaše potenciální povrchy útoku. S HTTPS, jakmile paket přijme zařízení v cílová síť (webový server, hraniční směrovač, nástroj pro vyrovnávání zatížení atd.) je nezašifrovaná a zbytek své cesty tráví v prostém textu. Mnoho lidí by tvrdilo, že to není velký problém, protože provoz je interní na tentokrát, ale pokud užitečné zatížení obsahuje citlivá data, ukládá se nešifrované do souborů protokolu každého síťového zařízení, kterým prochází, dokud se nedostane do svého konečného cíle. U SSH je obvykle určeno cílové zařízení a přenos je šifrován, dokud nedosáhne tohoto zařízení. Existují způsoby, jak znovu zašifrovat data HTTPS, ale jedná se o další kroky, které většina zapomene podniknout při implementaci řešení HTTPS v jejich prostředí.

ssh je jako klíč (soukromý) a zámek (veřejný)

ssl je jako dveře a cihly.

ssl poskytuje zabezpečené spojení mezi dva počítačové servery. např. Váš a ten, ke kterému se připojujete.

ssh je způsob, jakým se připojující počítač může sám ověřit a získat přístup.

Komentáře

• Komentář “ a cihly “ vůbec nevysvětlujete. SSL má také veřejné a soukromé klíče. SSL lze také použít k ověření klienta. SSH také poskytuje zabezpečené spojení mezi klientem a serverem.

SSL je vrstva protokolu, která je odebráno z tunelovaného obsahu. SSH je zabezpečená verze shellu (SH), nebyl navržen tak, aby obsahoval abstraktní vrstvu pod ním, byl navržen speciálně pro přenos provozu shellu. Ačkoli se krypto operace používají v obou a tyto krypto operace mohou být dokonce stejné, účel a celkový design je tedy zcela odlišný.

Mějte na paměti, že existují určité rozdíly (jak bylo uvedeno výše) ), ale většina, ne-li všechny tyto rozdíly, jsou zakořeněny ve smyslu různých protokolů.

Komentáře

• -1 Chybně vytváříte předpoklad že OP porovnává SSL s unixovým programem ssh (1) . SSH je ve skutečnosti další protokol poskytující zabezpečení transportní vrstvy, který má speciální opatření pro vzdálené skořápky a vzdálené spuštění.

Pokud opravdu hledáte SSH vs SSL (TLS), odpověď je SSH.

Z jednoho důvodu, proč SSH vyhrává přes SSL, je způsob, jakým provádí ověřování. Z tohoto důvodu při použití FTP používejte spíše protokol SSH (SFTP) než FTPS (FTP přes SSL).

SSH se používá v podnikových sítích pro:

• zajištění bezpečného přístupu pro uživatele a automatizované procesy
• interaktivní a automatizovaný přenos souborů
• vydávání vzdálených příkazů

zdroj: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

komentáře

• “ Z jednoho důvodu SSH vyhrává přes SSL je způsob, jakým provádí ověřování “ Máte zdroj nebo vysvětlení pro toto tvrzení?
• V SSH máte dvě možnosti připojení k serveru. S možností ověřování na základě klíče bude nejprve nutné vygenerovat předem soukromý klíč SSH a veřejný klíč. Což není moc další práce. Toto je také považováno za nejlepší bezpečnostní postupy. SSL má tolik verzí, nejnovější je TLS1.2.Což znamená, že ‚ ještě není tak bezpečný, ale stále se zlepšuje.
• TLS má také certifikáty na straně klienta. Nevysvětlujete, proč SSH “ vyhrává „.
• Pokud budete odněkud kopírovat / vkládat, nezapomeňte uvést svůj zdroj.
• “ SSL má tolik verzí “ Takže 6 verzí je “ tolik „? OpenSSH je ve verzi 7.7. “ Což znamená, že ‚ ještě není tak bezpečný, ale v procesu zlepšování. “ Vaše logika zde nemá smysl.

Problém je dvojí, to “ není to jen síla a slabost šifrování. Ale je to snadné a pohodlné doručení. Z obchodního hlediska je tedy SSL / TLS pohodlnější a jednodušší, protože vyžaduje pouze prohlížeč a buď veřejný, nebo soukromý certifikát.

A SSH k jeho použití vyžaduje buď nainstalovanou aplikaci, nebo tenkého klienta. To je z pohledu a podpory internetového klienta uživatele větší problém.