Care este diferența dintre SSL și SSH? Care este mai sigur?

SSL și SSH oferă ambele criptografice elemente pentru a construi un tunel pentru transportul confidențial de date cu integritate verificată. Pentru acea parte, utilizează tehnici similare și pot suferi același tip de atacuri, deci ar trebui să ofere o securitate similară (adică o bună securitate) presupunând că ambele sunt implementate corect. Că ambele există este un fel de sindrom NIH : dezvoltatorii SSH ar fi trebuit să reutilizeze SSL pentru partea tunel (protocolul SSL este suficient de flexibil pentru a se potrivi multor variante, inclusiv nu folosesc certificate).

Ele diferă în ceea ce privește lucrurile din jurul tunelului. SSL folosește în mod tradițional certificate X.509 pentru anunțarea cheilor publice ale serverului și clientului; SSH are propriul format. De asemenea, SSH vine cu un set de protocoale pentru ceea ce merge în interiorul tunelului (multiplexarea mai multor transferuri, efectuarea autentificării bazate pe parolă în tunel, gestionarea terminalelor …) în timp ce nu există așa ceva în SSL sau, mai exact, atunci când astfel de lucruri sunt folosite în SSL, acestea nu sunt considerate a face parte din SSL (de exemplu, atunci când faceți autentificare HTTP bazată pe parolă într-un tunel SSL, spunem că face parte din „HTTPS”, dar funcționează într-adevăr într-un mod similar cu ceea ce se întâmplă cu SSH).

Conceptual, puteți lua SSH și înlocuiți partea tunelului cu cea din SSL. Puteți, de asemenea, să luați HTTPS și să înlocuiți chestia SSL cu SSH-with-data-transport și un cârlig pentru a extrage cheia publică a serverului din certificatul său. Nu există imposibilitate științifică și, dacă se face corect, securitatea ar rămâne aceeași. Cu toate acestea, nu există un set larg de convenții sau instrumente existente pentru asta.

Deci, nu folosim SSL și SSH pentru aceleași lucruri, ci asta datorită instrumentelor care au venit în mod istoric cu implementările celor protocoale, nu din cauza unei diferențe legate de securitate. Și oricine implementează SSL sau SSH ar fi bine sfătuit să analizeze ce tip de atacuri au fost încercate pe ambele protocoale.

Comentarii

• Slujbă bună. Și, de fapt, deoarece SSH este mai ușor de configurat decât SSL, mulți oameni tunelează http (nu https) în SSH, de exemplu, pentru a face administrarea de la distanță a sistemului cu un web Instrument GUI, cum ar fi ebox sau webmin.
• Doar pentru a sublinia, ‘ nu este chiar adevărat că tipii SSH ” ar trebui ” să fi folosit SSL: SSH a fost conceput special pentru a avea o suprafață mică de atac și pentru a fi foarte sigur. SSHv2 nu are niciuna dintre probleme și capcane în SSL / TLS, așa că mergeți cu un lucru mai mic pe care îl u Înțelese bine, cu mai puțină complexitate, au ieșit cu ceva mult mai potrivit pentru situația lor. Depinde cât de paranoic sunteți: SSL nu este ‘ t inutilizabil, în funcție de aplicație, dar designul SSH ‘ îl face acceptabil în situații / comunități de securitate în care SSL pur și simplu nu este de încredere.
• Designul @NicholasWilson ” SSH ‘ îl face acceptabil în situații / comunități de securitate în care SSL pur și simplu nu este de încredere ” precum …
• SSL și SSH au fost dezvoltate în paralel (ambele fiind lansate în 1995), deci dacă SSH chiar ar fi putut să folosesc SSL nu este clar. Dacă ar fi trebuit să folosească SSL 2.0 contemporan este și el foarte dubios 🙂
• Ei bine, SSH 2.0 a fost o rescriere completă a protocolului și a apărut ceva timp în jurul anului 1999, astfel încât s-ar fi putut reutiliza SSL 3.0 sau chiar TLS 1.0. Dar, desigur, TLS pare legat de X.509, ceea ce îi sperie pe dezvoltatori.

Aceasta nu este o comparație rezonabilă. SSL este o metodă generală pentru protejarea datelor transportate pe o rețea, în timp ce SSH este o aplicație de rețea pentru conectarea și partajarea datelor cu un computer la distanță.

Protecția stratului de transport din SSH are o capacitate similară cu SSL, deci ceea ce este „mai sigur” depinde de ceea ce solicită modelul dvs. specific de amenințare și dacă implementările fiecăruia abordează problemele cu care încercați să vă ocupați.

SSH are apoi un strat de autentificare a utilizatorului care nu are SSL (deoarece nu are nevoie de el – SSL trebuie doar să autentifice cele două interfețe de conectare pe care SSH le poate face și ele). În UTF-8 art:

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

În ceea ce privește problema împotriva căreia există mai multe atacuri potențiale, pare clar că SSH are o suprafață de atac mai mare. Dar asta este doar pentru că SSH are un întreg aplic acțiune integrată în ea: suprafața de atac a SSL + orice aplicație pe care trebuie să o furnizați nu poate fi comparată deoarece nu avem suficiente informații.

Comentarii

• -1 Este o comparație rezonabilă. Faceți greșit presupunerea că OP compară SSL cu programul unix ssh (1) . SSH este de fapt un alt protocol care asigură securitatea stratului de transport, care se întâmplă să aibă dispoziții speciale pentru shell-uri la distanță și execuție la distanță.
• +1 @jpillora, în timp ce sunt de acord că are sens să le comparăm pe cele două, termenul SSH este nu este de obicei folosit pentru a se referi la subsetul protocolului SSH care gestionează securitatea stratului de transport care ar fi direct comparabil cu SSL / TLS. Este folosit aproape exclusiv în referință la protocolul stratului de aplicație care diferă de SSL / TLS în modul descris în acest răspuns.
• @freb modul în care acestea ‘ Referirea în general nu schimbă adevărul problemei. SSH este un protocol care este folosit ca strat de transport pentru utilitarul ssh. Răspunsul acceptat și cel mai votat reflectă acest fapt.
• @jpillora Pur și simplu am vrut să spun că nu cred ‘ că nu cred că protocolul SSH de strat de transport este ceea ce ar însemna majoritatea oamenilor având în vedere formularea întrebării. Cu toate acestea, având în vedere răspunsul care a fost acceptat drept corect, trebuie să fi fost ceea ce întreba OP.
• @freb Corect, majoritatea oamenilor cred că, având în vedere expresia, ceea ce face chiar mai importantă corectarea acestui lucru comun concepție greșită.

Din punct de vedere criptografic strict, ambele oferă criptare autentificată, dar în două căi diferite.

SSH folosește așa-numitul Encrypt-and-MAC, adică mesajul cifrat este juxtapus la un cod de autentificare a mesajului (MAC) al mesajului clar pentru a adăuga integritate. Acest lucru nu este dovedit a fi întotdeauna complet sigur (chiar dacă în cazuri practice ar trebui să fie suficient).

SSL folosește MAC-apoi-Criptare: un MAC este juxtapus la textul clar, apoi ambele sunt criptate . Nici acesta nu este cel mai bun, deoarece în unele moduri de cifrare bloc, părțile MAC pot fi ghicibile și pot dezvălui ceva pe cifră. Acest lucru a dus la vulnerabilități în TLS 1.0 (atac BEAST).

Deci au ambele potențiale slăbiciuni teoretice. Cea mai puternică metodă este Encrypt-then-MAC (adăugați un MAC al mesajului cifrat), care este implementat, de exemplu, în IPsec ESP.

Comentarii

• SSH ‘ protocolul de pachet binar este criptat-și-MAC unde pentru fiecare mesaj în format text simplu (m) trimite textul cifrat E (m) ++ MAC (m) mesaj cu MAC), versus SSL care face E (m ++ MAC (m)). Cu toate acestea, SSH este mult mai mult decât protocolul său de pachete binare (gestionarea cheilor, clientul / serverul shell la distanță, transferul de fișiere etc.), în timp ce SSL (numit acum TLS) este doar protocolul stratului de transport care este utilizat în alte protocoale care adaugă în funcționalitatea necesară (de exemplu, HTTPS, FTPS, IMAPS etc.). Vedeți, de asemenea, comparația dintre EtM, E & M, MtE la: crypto.stackexchange.com / questions / 202
• Total acceptat, există mult mai mult decât ceea ce am scris; că ‘ este ceea ce am vrut să spun cu incipit ” dintr-un punct de vedere strict criptografic „.
• BEAST nu este legat de MtE și se datorează cunoscut-IV cu CBC (în SSL3 și TLS1.0) – ceea ce SSH2 face și nu a corectat, deși a primit CTR ca alternativă înainte ca acesta și TLS să obțină AEAD = GCM (TLS, de asemenea, CCM) (și ambele ChaCha / Poly) ca o alternativă mai bună. Atacurile bazate pe căptușeala MtE + CBC sunt POODLE și Lucky13.
• Am o soluție care face ca MAC-apoi-criptarea să fie sigură pentru orice cifru care are dimensiunea de ieșire = dimensiunea de intrare și nu are date de intrare slabe în cifru nucleu.
• acest răspuns este învechit, deoarece nu asta face TLS astăzi.

Cred că există un aspect al acestei comparații care a fost trecut cu vederea. user185 s-a apropiat, dar nu a ajuns destul de departe. Sunt de acord că acestea sunt mere și portocale și simt o comparație mai bună între mere și HTTPS și SSH. HTTPS și SSH utilizează diferite straturi ale modelului OSI și, prin urmare, criptează datele la diferite ori în transmisie. Apoi, întrebările reale pe care ar trebui să le puneți ar fi de aceeași linie când sunt criptate și necriptate aceste date în timpul transmisiei. Acest lucru vă va dezvălui potențialele suprafețe de atac. Cu HTTPS, odată ce pachetul este primit de un dispozitiv din rețeaua de destinație (server web, router de frontieră, balansator de sarcină etc …) este necriptată și își petrece restul călătoriei în text simplu. Mulți ar susține că acest lucru nu este o problemă importantă, deoarece traficul este intern la de data aceasta, dar dacă încărcătura utilă conține date sensibile, este stocată necriptată în fișierele jurnal ale fiecărui dispozitiv de rețea prin care trece până când ajunge la destinația finală. Cu SSH, de obicei, dispozitivul de destinație este specificat și transmisia este criptată până ajunge la acest dispozitiv. Există modalități de a cripta din nou datele HTTPS, dar aceștia sunt pași suplimentari pe care majoritatea uită să-i facă atunci când implementează o soluție HTTPS în mediul lor.

ssh este ca o cheie (privată) iar încuietoarea (publică)

ssl este ca ușa și cărămizile.

ssl oferă o legătură sigură între două servere de computer. De exemplu, al tău și cel la care te conectezi.

ssh este modul în care computerul care se conectează se poate verifica singur și poate avea acces.

Comentarii

• Nu explicați deloc comentariul ” ușă și cărămizi „. SSL are, de asemenea, chei publice și private. SSL poate fi utilizat și pentru autentificarea clientului. SSH oferă, de asemenea, o legătură sigură între client și server.

SSL este un strat de protocol care este extras din conținutul în tunel. SSH este o versiune sigură a shell-ului (SH), nu a fost conceput pentru a conține un strat abstract sub el, a fost conceput special pentru a transporta traficul shell-ului. Deci, deși operațiunile de criptare sunt utilizate în ambele, iar acele operații de criptare ar putea fi chiar aceleași, scopul și, prin urmare, designul general este destul de diferit.

Rețineți că există diferențe specifice (așa cum s-a menționat mai sus) ), dar majoritatea, dacă nu toate aceste diferențe, sunt înrădăcinate în scopul diferitelor protocoale.

Comentarii

• -1 Faceți presupoziția incorect că OP compară SSL cu programul unix ssh (1) . SSH este de fapt un alt protocol care asigură securitatea stratului de transport, care se întâmplă să aibă dispoziții speciale pentru shell-uri la distanță și execuție la distanță.

Dacă într-adevăr căutați SSH vs SSL (TLS), atunci răspunsul este SSH.

Dintr-un motiv pentru care SSH câștigă SSL este modul în care efectuează autentificarea. Din acest motiv, atunci când utilizați FTP, utilizați protocolul SSH (SFTP), mai degrabă decât FTPS (FTP peste SSL).

SSH este utilizat în rețelele corporative pentru:

• asigurarea accesului securizat pentru utilizatori și a proceselor automate
• transferuri interactive și automate de fișiere
• emiterea de comenzi la distanță

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

Comentarii

• ” Dintr-un motiv, SSH câștigă SSL este modul în care efectuează autentificare ” Aveți o sursă sau o explicație pentru această afirmație?
• În SSH aveți două opțiuni pentru conectarea serverului. Cu opțiunea de autentificare bazată pe cheie, va trebui mai întâi să generați o cheie privată SSH și o cheie publică în prealabil. Ceea ce nu înseamnă multă muncă suplimentară. Acest lucru este, de asemenea, luat în considerare cele mai bune practici de securitate. SSL are atât de multe versiuni, cea mai recentă este TLS1.2.Ceea ce înseamnă că ‘ nu este încă atât de sigur, dar este în proces de îmbunătățire.
• TLS are și certificate de partea clientului. Nu explicați de ce SSH ” câștigă „.
• Dacă aveți de gând să copiați / lipiți de undeva, asigurați-vă că citați sursa dvs.
• ” SSL are atât de multe versiuni ” Deci, 6 versiuni sunt ” atâtea „? OpenSSH este în versiunea 7.7. ” Ceea ce înseamnă că ‘ nu este încă atât de sigur, dar este în proces de îmbunătățire. ” Logica ta nu are sens aici.

Problema este dublă, este ” Nu este doar forța și slăbiciunea criptării, ci este ușurința și comoditatea livrării. Deci, din perspectiva afacerii, SSL / TLS este mai convenabil și mai ușor, deoarece necesită doar un browser și un certificat public sau privat.

Și SSH necesită fie aplicația, fie un client subțire instalat pentru a-l utiliza. Aceasta este mai mult o problemă din perspectiva și asistența clientului de Internet al utilizatorilor.