Mi a különbség az SSL és az SSH között? Melyik a biztonságosabb?

Az SSL és az SSH egyaránt biztosítja a titkosítást elemekkel alagutat építenek a bizalmas adatátvitelhez, ellenőrzött integritással. Ebből a részből hasonló technikákat alkalmaznak, és azonos típusú támadásoktól szenvedhetnek, ezért hasonló biztonságot (azaz jó biztonságot) kell nyújtaniuk, feltéve, hogy mindkettőjüket megfelelően végrehajtják. Az, hogy mindkettő létezik, egyfajta NIH szindróma: Az SSH fejlesztőknek újrafelhasználniuk kellett az SSL-t az alagút részében (az SSL protokoll elég rugalmas ahhoz, hogy számos variációt befogadjon, beleértve az tanúsítványok nélkül).

Különböznek az alagút körüli dolgokban. Az SSL hagyományosan X.509 tanúsítványokat használ a szerver és az ügyfél nyilvános kulcsainak bejelentésére; Az SSH saját formátummal rendelkezik. Ezenkívül az SSH protokollcsomaggal rendelkezik az alagút belsejében (több átvitel multiplexelése, jelszóalapú hitelesítés az alagútban, terminálkezelés …), miközben az SSL-ben ilyen nincs , vagy pontosabban, ha ilyen dolgokat használnak az SSL-ben, akkor nem tekinthetők az SSL részének (például amikor SSL-alagútban végezünk jelszó alapú HTTP-hitelesítést, azt mondjuk, hogy az a “HTTPS” része, de valóban hasonló módon működik, mint az SSH-val).

Koncepció szerint felveheti az SSH-t, és kicserélheti az alagút részét az SSL-re. Felveheti a HTTPS-t is, és lecserélheti az SSL-t SSH-re adatátvitellel és egy kampóval, hogy kivonja a szerver nyilvános kulcsát a tanúsítványából. Nincs tudományos lehetetlenség, és megfelelő végrehajtás esetén a biztonság változatlan marad. Ehhez azonban nincsenek széles körű konvenciók vagy létező eszközök.

Tehát nem ugyanazokra a dolgokra használjuk az SSL-t és az SSH-t, de ez annak köszönhető, hogy ezek az eszközök milyen történelmileg jártak együtt ezek megvalósításával. protokollok, nem a biztonsággal kapcsolatos különbségek miatt. És aki SSL-t vagy SSH-t hajt végre, annak tanácsos megnéznie, hogy milyen támadásokat próbáltak meg mindkét protokollon.

Megjegyzések

• Jó munka. És valójában, mivel az SSH-t könnyebb beállítani, mint az SSL-t, sokan alagutaznak http-et (nem https-t) az SSH-n belül, például távoli rendszeradminisztrációt végeznek egy web segítségével GUI eszköz, például az ebox vagy a webmin.
• Csak azért, hogy felhívjam a figyelmet, ‘ nem egészen igaz, hogy az SSH srácok ” ” SSL-t kellett volna használnia: Az SSH-t kifejezetten úgy tervezték, hogy kis támadási felülettel rendelkezzen és nagyon biztonságos legyen. Az SSHv2-nek nincsenek problémái, és buktatók az SSL / TLS-ben, tehát egy kisebb dologgal jár, hogy u jól megértve, kevésbé bonyolultan, valami sokkal jobban megfelelnek a helyzetüknek. Ez attól függ, mennyire paranoiás vagy: Az SSL az alkalmazás függvényében nem ‘ t használhatatlan, de az SSH ‘ kialakítása miatt ez helyzetekben elfogadható / biztonsági közösségek, ahol az SSL egyszerűen nem megbízható.
• @NicholasWilson ” SSH ‘ s kialakítása elfogadhatóvá teszi olyan helyzetekben / biztonsági közösségekben, ahol az SSL egyszerűen nem megbízható “, mint például …
• Az SSL és az SSH párhuzamosan kerültek kifejlesztésre (mindkettő 1995-ben jelent meg), tehát akár az SSH is használhatta az SSL-t nem világos. Az is nagyon kétséges, hogy kellett volna-e a korabeli SSL 2.0-t használni 🙂
• Nos, az SSH 2.0 a protokoll teljes átírása volt, és valamikor 1999 körül jelent meg, így az SSL 3.0 vagy akár a TLS 1.0 újrafelhasználható. De természetesen a TLS úgy tűnik az X.509-hez van kötve, ami elrettenti a fejlesztőket.

Szigorú kriptográfiai szempontból mindketten hitelesített titkosítást biztosítanak, de kettőben különböző utak.

Az SSH az úgynevezett Titkosítás és MAC-t használja, vagyis a titkosított üzenetet a tiszta üzenet üzenet-hitelesítési kódjával (MAC) egészítik ki az integritás növelése érdekében. Ez nem bizonyítottan mindig teljesen biztonságos (még akkor is, ha a gyakorlati esetekben elegendőnek kell lennie).

Az SSL MAC-then-Encrypt parancsot használ: a MAC a tiszta szöveg mellé kerül, majd mindkettő titkosítva van . Ez sem a legjobb, mivel egyes blokkos titkosítási módoknál a MAC egyes részei kitalálhatók és felfedhetnek valamit a rejtjelen. Ez sebezhetőséghez vezetett a TLS 1.0-ban (BEAST támadás).

Tehát mindkét elméleti gyengeséggel rendelkeznek. A legerősebb módszer az Encrypt-then-MAC (adja hozzá a titkosított üzenet MAC-ját), amelyet például az IPsec ESP-ben valósítanak meg.

Megjegyzések

• SSH ‘ s bináris csomag protokoll titkosítás és MAC, ahol minden sima szöveges üzenethez (m) elküldi az E (m) ++ MAC (m) titkosítást (titkosítva összefűzve) üzenet MAC-val), szemben az SSL-lel, amely E (m ++ MAC (m)). Az SSH azonban sokkal több, mint pusztán bináris csomagprotokollja (kulcskezelés, távoli shell kliens / szerver, fájltovábbítás stb.), Míg az SSL (most TLS-nek hívják) csak a szállítási réteg protokollja, amelyet más protokollokban használnak, amelyek hozzáadják a szükséges funkcionalitásban (pl. HTTPS, FTPS, IMAPS stb.). Lásd még az EtM, E & M, MtE összehasonlítását: crypto.stackexchange.com / questions / 202
• Teljesen egyetértésben sokkal több van, mint amit írtam; hogy ‘ s amit incipit ” -re gondoltam szigorú kriptográfiai szempontból “.
• A BEAST nem kapcsolódik az MtE-hez, és a CBC-vel kapcsolatos ismert IV-nek köszönhető (SSL3 és TLS1.0 formátumban) – amit az SSH2 is csinál, és nem javított, bár a CTR-t alternatívaként kapta meg, mielőtt mind a TLS, mind az AEAD = GCM (TLS is CCM) (és mind a ChaCha / Poly) jobb alternatíva lett. Az MtE + CBC kitöltő alapú támadások POODLE és Lucky13.
• Van egy olyan megoldásom, amely biztonságossá teszi a MAC-majd titkosítást minden olyan titkosító számára, amelynek kimeneti mérete = bemeneti méret és nincs gyenge adatbevitel a titkosításba. mag.
• ez a válasz elavult, mivel a TLS ma nem ezt teszi.

Úgy gondolom, hogy ennek az összehasonlításnak van egy aspektusa, amelyet figyelmen kívül hagytak. A user185 közel járt, de nem jutott el oda. Egyetértek azzal, hogy ezek az alma és a narancs, és jobbnak érzem az almát az almához képest, mint a HTTPS és az SSH. A HTTPS és az SSH az OSI modell különböző rétegeit használja, ezért különböző módon titkosítja az adatokat alkalommal. Akkor a valódi kérdéseket fel kellene tennünk, amikor ezeket az adatokat titkosítjuk és nem titkosítjuk az átvitel során. Ez feltárja a lehetséges támadási felületeket. A HTTPS használatával, ha a csomagot egy eszköz megkapja a célhálózat (webszerver, Border Router, terheléselosztó stb.) nincs titkosítva, és útjának hátralévő részét egyszerű szövegben tölti. Sokan azt állítják, hogy ez nem nagy ügy, mivel a forgalom belső ezúttal, de ha a hasznos teher érzékeny adatokat tartalmaz, azokat titkosítatlanul tárolják minden olyan hálózati eszköz naplófájljában, amelyen áthalad, amíg el nem ér a végcélig. SSH esetén általában a céleszköz van megadva, az átvitel titkosítva van, amíg el nem éri ezt az eszközt. A HTTPS-adatok titkosításának vannak módjai, de ezek olyan extra lépések, amelyeket a legtöbben elfelejtenek megtenni, amikor HTTPS-megoldást alkalmaznak a környezetükben.

Az SSL egy protokollréteg, amely elvonul az alagút tartalmától. Az SSH a shell (SH) biztonságos változata, nem úgy tervezték, hogy absztrakt réteget tartalmazzon alatta, hanem kifejezetten a shell forgalom továbbítására tervezték. Tehát bár kriptográfiai műveleteket használnak mindkettőben, és ezek a kriptográfiai műveletek akár megegyezhetnek is, a cél és az általános tervezés meglehetősen eltérő. ), de ezek a különbségek többnyire, ha nem is, a különböző protokollok céljában gyökereznek. hogy az OP összehasonlítja az SSL-t az unix programmal ssh (1) . Az SSH valójában egy másik protokoll, amely biztosítja a szállítási réteg biztonságát, és történetesen speciális rendelkezéseket tartalmaz a távoli héjak és távoli végrehajtás tekintetében.

Ha valóban SSH-t vagy SSL-t (TLS) keres, akkor a válasz az SSH.

Az SSH az SSL-győzelem egyik oka az, ahogyan a hitelesítést végrehajtja. Ezért az FTP használatakor az SSH protokollt (SFTP) használja, nem pedig az FTPS-t (FTP SSL-en keresztül).

Az SSH-t a vállalati hálózatokban használják:

• biztonságos hozzáférés biztosítása a felhasználók számára és automatizált folyamatok
• interaktív és automatizált fájlátvitel
• távoli parancsok kiadása

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

Megjegyzések

• ” Egy okból az SSH nyeri az SSL-t, és így hajtja végre a hitelesítést ” Van forrása vagy magyarázata ehhez az állításhoz?
• Az SSH-ban két lehetőség van a szerver csatlakoztatására. Kulcsalapú hitelesítési opcióval először SSH magánkulcsot és nyilvános kulcsot kell előállítania. Ami nem sok kiegészítő munka. Ez is vegye figyelembe a legjobb biztonsági gyakorlatokat. Az SSL-nek annyi verziója van, a legújabb a TLS1.2.Ami azt jelenti, hogy ‘ még nem olyan biztonságos, de folyamatban van, hogy egyre jobb legyen.
• A TLS rendelkezik ügyféloldali tanúsítványokkal is. Nem magyarázza el, miért nyeri az SSH ” “.
• Ha másol / beilleszt valahonnan, ne felejtsd el megemlíteni a forrást.
• ” Az SSL-nek annyi verziója van ” Tehát 6 verzió ” ennyi “? Az OpenSSH a 7.7-es verziót használja. ” Ami azt jelenti, hogy ‘ még nem olyan biztonságos, de folyamatban egyre jobb lesz. ” A logikádnak itt nincs értelme.

A probléma kettős, ez ” s nemcsak a titkosítás erőssége és gyengesége, hanem a kézbesítés egyszerűsége és kényelme is. Tehát üzleti szempontból az SSL / TLS kényelmesebb és könnyebb, mert ehhez csak böngészőre és nyilvános vagy privát Certre van szükség. Ez inkább a felhasználó internetes kliensének és támogatásának problémája.