Mikä on ero SSL: n ja SSH: n välillä? Mikä on turvallisempi?

Sekä SSL että SSH tarjoavat salauksen Elementit luovat tunnelin luottamukselliseen tiedonsiirtoon tarkistetulla eheydellä.Tässä osassa he käyttävät samankaltaisia tekniikoita ja saattavat kärsiä samanlaisista hyökkäyksistä, joten niiden on tarjottava samanlainen turvallisuus (eli hyvä turvallisuus) olettaen, että ne molemmat toteutetaan asianmukaisesti. Se, että molemmat ovat olemassa, on eräänlainen NIH -oireyhtymä: SSH-kehittäjien olisi pitänyt käyttää SSL uudelleen tunneliosassa (SSL-protokolla on riittävän joustava monien muunnelmien, mukaan lukien ei käytä varmenteita).

Ne eroavat tunnelin ympärillä olevista asioista. SSL käyttää perinteisesti X.509-varmenteita palvelimen ja asiakkaan julkisten avainten ilmoittamiseen; SSH: lla on oma muoto. SSH: ssä on myös joukko protokollia siitä, mitä sisälle tunneliin (multipleksointi useita siirtoja, salasanapohjaisen todennuksen suorittaminen tunnelissa, päätelaitteiden hallinta …), vaikka SSL: ssä ei ole sellaista tai tarkemmin sanottuna, kun tällaisia asioita käytetään SSL: ssä, niiden ei katsota olevan osa SSL: ää (esimerkiksi kun teemme salasanapohjaista HTTP-todennusta SSL-tunnelissa, sanomme, että se on osa ”HTTPS”, mutta se toimii todella samalla tavalla kuin mitä tapahtuu SSH: n kanssa).

Käsitteellisesti voit ottaa SSH: n ja korvata tunnelin osan SSL: llä. Voit myös ottaa HTTPS: n ja korvata SSL-asian SSH: llä – tiedonsiirrolla ja koukulla palvelimen julkisen avaimen purkamiseksi varmenteestaan. Tieteellistä mahdottomuutta ei ole, ja jos se tehdään oikein, turvallisuus säilyy ennallaan. Siihen ei kuitenkaan ole olemassa laajaa käytäntöjen tai olemassa olevien työkalujen joukkoa.

Joten emme käytä SSL: ää ja SSH: tä samoihin asioihin, mutta se johtuu siitä, mitkä työkalut ovat historiallisesti mukana näiden sovellusten toteuttamisessa. ei tietoturvaan liittyvän eron takia. Ja SSL: n tai SSH: n käyttöönottajan on hyvä tutkia, minkälaisia hyökkäyksiä molempiin protokolliin yritettiin.

Kommentit

• Hyvä työ. Ja itse asiassa, koska SSH on helpompi asentaa kuin SSL, monet ihmiset tunnelivat http: ää (ei https: ää) SSH: n sisällä, esimerkiksi järjestelmän etähallintaa verkon kautta Graafisen käyttöliittymän työkalu, kuten ebox tai webmin.
• Huomautettakoon, että ’ ei ole totta, että SSH-kaverit ” olisi ” pitänyt käyttää SSL: ää: SSH on suunniteltu hyvin spesifisesti pieneksi hyökkäyspinnaksi ja erittäin turvalliseksi. SSHv2: lla ei ole mitään ongelmia ja SSL / TLS: n sudenkuoppia, joten menee pienemmän asian kanssa, että he u Ymmärtivät hyvin, vähemmän monimutkaisella tavalla, he keksivät jotain paljon paremmin heidän tilanteeseensa. Se riippuu kuinka paranoidista olet: SSL ei ole ’ t käyttökelvoton sovelluksesta riippuen, mutta SSH ’ -suunnittelu tekee siitä hyväksyttävän tilanteissa / turvallisuusyhteisöt, joissa SSL: ää ei yksinkertaisesti luoteta.
• @NicholasWilson ” SSH ’ suunnittelu tekee siitä hyväksyttävän tilanteissa / turvallisuusyhteisöissä, joissa SSL yksinkertaisesti ei luoteta ”, kuten …
• SSL ja SSH kehitettiin rinnakkain (molemmat julkaistiin vuonna 1995), joten onko SSH edes Voisiko käyttää SSL: ää, ei ole selvää. Onko sen pitänyt käyttää nykyaikaista SSL 2.0: ta, on myös hyvin epäilyttävää 🙂
• No, SSH 2.0 kirjoitti protokollan kokonaan uudelleen ja ilmestyi jonkin aikaa noin vuonna 1999, joten yksi olisi voinut käyttää uudelleen SSL 3.0: ta tai jopa TLS 1.0: ta. Mutta tietysti TLS näyttää olevan sidottu X.509: ään, joka pelottaa kehittäjät pois.

Tiukasta salauksen näkökulmasta molemmat tarjoavat todennetun salauksen, mutta kahtena eri tavoin.

SSH käyttää ns. Salaa ja MAC: ää, eli salattu viesti rinnastetaan selkeän viestin MAC-koodiin (eheyden lisäämiseksi). Tämän ei ole osoitettu olevan aina täysin turvallinen (vaikka käytännön tilanteissa sen pitäisi riittää).

SSL käyttää MAC-then-Encrypt: MAC rinnastetaan selkeään tekstiin, sitten ne molemmat salataan. . Tämä ei myöskään ole paras, koska joissakin lohkosalaustiloissa MAC: n osat voidaan arvata ja paljastaa jotain salassa. Tämä johti haavoittuvuuksiin TLS 1.0: ssa (BEAST-hyökkäys).

Joten heillä on molemmat potentiaalisia teoreettisia heikkouksia. Vahvin menetelmä on Encrypt-then-MAC (lisää salatun viestin MAC), joka toteutetaan esimerkiksi IPsec ESP: ssä.

Kommentit

• SSH ’ binaarinen pakettiprotokolla on salattu ja MAC, jossa se lähettää jokaiselle selkokieliselle viestille (m) salakirjoituksen E (m) ++ MAC (m) (ketjutettu salattu) viesti MAC: n kanssa), verrattuna SSL: ään, joka tekee E (m ++ MAC (m)). SSH on kuitenkin paljon muutakin kuin vain sen binaarinen pakettiprotokolla (avaimen hallinta, etäkuoren asiakas / palvelin, siirtää tiedostoja jne.), Kun taas SSL (nyt nimeltään TLS) on vain siirtokerrosprotokolla, jota käytetään muissa protokollissa, jotka lisäävät tarvittavissa toiminnoissa (esim. HTTPS, FTPS, IMAPS jne.). Katso myös EtM: n, E & M, MtE: n vertailu: crypto.stackexchange.com / questions / 202
• Täysin samaa mieltä, on paljon enemmän kuin mitä kirjoitin; että ’ s mitä tarkoitin aloitteellani ” tiukasta kryptografisesta näkökulmasta ”.
• BEAST ei liity MtE: hen ja johtuu tunnetusta IV: stä CBC: n kanssa (SSL3: ssa ja TLS1.0: ssa) – mitä SSH2 myös tekee eikä korjannut, vaikka se sai CTR: n vaihtoehtona ennen kuin sekä se että TLS saivat AEAD = GCM (TLS myös CCM) (ja molemmat ChaCha / Poly) parempana vaihtoehtona. MtE + CBC -pehmustepohjaiset hyökkäykset ovat POODLE ja Lucky13.
• Minulla on ratkaisu, joka tekee MAC-then-Encrypt -ominaisuudesta turvallisen kaikille salakirjoille, joiden ulostulokoko = syötekoko ja joilla ei ole heikkoa tietojen syöttämistä salakirjoitukseen. ydin.
• tämä vastaus on vanhentunut, koska TLS ei tee sitä tänään.

Mielestäni tässä vertailussa on yksi näkökohta, joka jätettiin huomiotta. user185 tuli lähelle, mutta ei päässyt sinne. Olen samaa mieltä siitä, että nämä ovat omenoita ja appelsiineja, ja tunnen paremman omenoiden ja omenoiden vertailun olevan HTTPS ja SSH. HTTPS ja SSH käyttävät OSI-mallin eri kerroksia ja salaavat sen vuoksi tiedot eri tavoin kertaa lähetyksessä. Sitten todelliset kysymykset, jotka sinun pitäisi kysyä, ovat samankaltaisia kuin milloin nämä tiedot salataan ja salaamattomina lähetyksen aikana. Tämä paljastaa mahdolliset hyökkäyspinnasi. HTTPS: n avulla, kun laite vastaanottaa paketin kohdeverkko (verkkopalvelin, rajareititin, kuormituksen tasapainotin jne.) on salaamaton ja viettää loppumatkansa pelkkänä tekstinä. Monet väittävät, että tämä ei ole iso juttu, koska liikenne on sisäistä tällä kertaa, mutta jos hyötykuorma sisältää arkaluontoista tietoa, se tallennetaan salaamattomana jokaisen läpi kulkevan verkkolaitteen lokitiedostoihin, kunnes se saavuttaa lopullisen määränpäänsä. SSH: n avulla tyypillisesti kohdelaite määritetään ja Lähetys on salattu, kunnes se saavuttaa tämän laitteen. HTTPS-tietoja voidaan salata uudelleen, mutta nämä ovat ylimääräisiä vaiheita, jotka useimmat unohtavat toteuttaa ottaessaan käyttöön HTTPS-ratkaisun ympäristössään.

SSL on protokollakerros, joka on tiivistetty tunneloitavasta sisällöstä. SSH on suojattu versio kuoresta (SH), sitä ei ole suunniteltu sisällyttämään abstraktia kerrosta sen alle, se on suunniteltu erityisesti kuoriliikenteen kuljettamiseen. Joten vaikka salausoperaatioita käytetään molemmissa, ja nämä salausoperaatiot voivat jopa olla samat, tarkoitus ja niiden yleinen suunnittelu on melko erilainen.

Muista, että on olemassa erityisiä eroja (kuten edellä on mainittu ), mutta suurin osa, ellei kaikki nämä erot juurtuvat eri protokollien tarkoituksiin.

Kommentit

• -1 Oletat väärin oletuksen että OP vertaa SSL: ää unix-ohjelmaan ssh (1) . SSH on oikeastaan toinen protokolla, joka tarjoaa siirtokerroksen turvallisuuden, jolla satunnaisesti on erityissäännöksiä etäkuorista ja etäsuorittamisesta.

Jos etsit todella SSH vs SSL (TLS), vastaus on SSH.

Yhdestä syystä, miksi SSH voittaa SSL: n, on tapana, jolla se suorittaa todennuksen. Tästä syystä, kun käytät FTP: tä, käytä SSH-protokollaa (SFTP) pikemminkin kuin FTPS: ää (FTP over SSL).

SSH: tä käytetään yritysverkoissa seuraaviin tarkoituksiin:

• turvallisen pääsyn tarjoaminen käyttäjille ja automatisoidut prosessit
• vuorovaikutteiset ja automatisoidut tiedostojen siirrot
• etäkomentojen antaminen

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

kommentit

• ” Yhdestä syystä SSH voittaa SSL: n on tapa, jolla se suorittaa todennuksen ” Onko sinulla lähde tai selitys tälle väitteelle?
• SSH: ssä on kaksi vaihtoehtoa yhdistää palvelin. Avainpohjaisen todennusvaihtoehdon avulla ensin on luotava SSH-yksityinen avain ja julkinen avain etukäteen. Mikä ei ole paljon lisätyötä. Tässä on otettava huomioon myös parhaat turvallisuuskäytännöt. SSL: llä on niin monta versiota, viimeisin on TLS1.2.Tämä tarkoittaa, että se ’ ei ole vielä niin turvallista, mutta on parhaillaan parantumassa.
• TLS: llä on myös asiakaspuolen varmenteita. Et selitä, miksi SSH ” voittaa ”.
• Jos aiot kopioida / liittää jostain, varmista, että mainitset lähteen.
• ” SSL: llä on niin monta versiota ” Joten 6 versiota on ” niin monta ”? OpenSSH on versiossa 7.7. ” Mikä tarkoittaa sitä, että ’ ei ole vielä niin turvallinen, mutta parhaillaan paranee. ” Logiikallasi ei ole mitään järkeä tässä.

Ongelma on kaksinkertainen, se ” Se ei ole vain salauksen vahvuus ja heikkous, vaan se on myös toimituksen helppous ja helppous. Joten liiketoiminnan näkökulmasta SSL / TLS on kätevämpää ja helpompaa, koska se vaatii vain selaimen ja joko julkisen tai yksityisen varmenteen.

Ja SSH vaatii joko sovelluksen tai ohennetun asiakkaan asennuksen sen käyttämiseen. Se on enemmän ongelma käyttäjän Internet-asiakkaan näkökulmasta ja tuesta.