Care este diferența dintre SSL și SSH? Care este mai sigur? (Securitatea informațiilor, Criptare, Tls, Rețea, Ssh)

Am1rr3zA a intrebat.

Care este diferența dintre SSH și SSL? Care dintre ele este mai sigură, dacă puteți să le comparați împreună?
Care dintre ele are mai multe vulnerabilități potențiale?

Comentarii

    17

  • Aceasta nu este o întrebare reală. Comparați mere și portocale. Ar fi util să explicați de ce doriți să știți, deoarece acest lucru ar putea ghida răspunsurile. De exemplu, doriți să implementați o soluție de acces securizat și căutați cea mai ușor de securizat? –  > Por Rory Alsop.
  • @Rory Nu cred, deoarece știu că ambele fac o treabă similară (nu compar mere și portocale), dar poate mă înșel, așa că devin recunoscător dacă comunitatea îmi arată greșeala mea. –  > Por Am1rr3zA.
  • @Am1rr3zA, nu este tocmai corect că fac o treabă similară. În practică, SSL și SSH sunt utilizate de obicei în scopuri diferite: SSH este cel mai adesea utilizat pentru conectarea de la distanță, iar SSL pentru acces web criptat. –  > Por D.W..
  • @D.W. Se pare că uneori sunt folosite pentru același lucru, de ex. SFTP pare să se bazeze pe SSH, , în timp ce FTPS se bazează pe SSL. –  > Por Jonas.
  • În propriul lor element, fiecare are un punct forte. Așa că priviți-o din perspectiva unui hacker. Pe care dintre ele ai prefera să le spargi? De asemenea, întrebarea ar trebui pusă „Care este mai sigur pentru scopul de…XYZ” Deoarece a pus întrebarea fără a oferi scopul, de aici toată lumea s-a blocat. Exemplul meu cu safe vs. logon arată două scopuri diferite (care este locul unde oamenii afirmau „Hei, aceste două protocoale și securitatea lor de obicei nu servesc aceeași funcție în utilizare” și asta este absolut corect. Unul poate fi totuși, eventual, „mai sigur” decât celălalt. –  > Por user30885.
8 răspunsuri
Thomas Pornin

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

Ele diferă în ceea ce privește lucrurile care se află în jurul tunelului. SSL utilizează în mod tradițional certificate X.509 pentru a anunța cheile publice ale serverului și ale 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 pe bază de parolă în interiorul tunelului, gestionarea terminalelor…), în timp ce în SSL nu există așa ceva sau, mai exact, atunci când astfel de lucruri sunt folosite în SSL, nu sunt considerate ca făcând parte din SSL (de exemplu, atunci când se face autentificarea HTTP pe bază de parolă într-un tunel SSL, spunem că face parte din „HTTPS”, dar în realitate funcționează într-un mod similar cu ceea ce se întâmplă cu SSH).

Din punct de vedere conceptual, ați putea lua SSH și să înlocuiți partea de tunel cu cea din SSL. De asemenea, ați putea lua HTTPS și să înlocuiți partea de SSL cu SSH-with-data-transport și un cârlig pentru a extrage cheia publică a serverului din certificatul acestuia. Nu există nicio imposibilitate științifică și, dacă se face corect, securitatea ar rămâne aceeași. Cu toate acestea, nu există un set de convenții larg răspândit sau instrumente existente pentru acest lucru.

Așadar, nu folosim SSL și SSH pentru aceleași lucruri, dar acest lucru se datorează instrumentelor care au însoțit din punct de vedere istoric implementările acestor protocoale, nu din cauza unei diferențe legate de securitate. Și oricine implementează SSL sau SSH ar fi bine să analizeze ce fel de atacuri au fost încercate asupra ambelor protocoale.

Comentarii

  • Bună treabă. Și, de fapt, din moment ce SSH este mai ușor de configurat decât SSL, mulți oameni fac tuneluri http (nu https) în interiorul SSH, de exemplu pentru a face administrare de sistem la distanță cu un instrument de interfață grafică web precum ebox sau webmin. –  > Por nealmcb.
  • 28

  • Doar pentru a sublinia, nu este chiar adevărat că cei de la SSH „ar trebui să” să fi folosit SSL: SSH a fost conceput în mod special pentru a avea o suprafață de atac mică și pentru a fi foarte sigur. SSHv2 nu are niciuna dintre problemele și capcanele din SSL/TLS, așa că, mergând pe un lucru mai mic, pe care l-au înțeles bine, cu mai puțină complexitate, le-a ieșit ceva mult mai potrivit pentru situația lor. Depinde cât de paranoic ești: SSL nu este 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. –  > Por Nicholas Wilson.
  • @NicholasWilson „Designul SSH îl face acceptabil în situațiile/comunitățile de securitate în care SSL pur și simplu nu este de încredere„, cum ar fi… –  > Por curiousguy.
  • SSL și SSH au fost dezvoltate în paralel (ambele fiind lansate în 1995), deci dacă SSH chiar și ar putea să fi folosit SSL nu este clar. Dacă a fost ar fi trebuit să o facă să fi folosit actualul SSL 2.0 este, de asemenea, foarte dubios 🙂 – utilizator185
  • Ei bine, SSH 2.0 a fost o rescriere completă a protocolului și a apărut în jurul anului 1999, astfel încât s-ar fi putut reutiliza SSL 3.0 sau chiar TLS 1.0. Dar, bineînțeles, TLS apare să fie legat de X.509, ceea ce îi sperie pe dezvoltatori. –  > Por Thomas Pornin.
utilizator185

Nu este o comparație rezonabilă de făcut. SSL este o metodă generală de protejare a datelor transportate printr-o rețea, în timp ce SSH este o aplicație de rețea pentru conectarea și schimbul de date cu un computer la distanță.

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

SSH are apoi un strat de autentificare a utilizatorului, ceea ce lipsește la SSL (deoarece nu are nevoie de el – SSL trebuie doar să autentifice cele două interfețe de conectare, ceea ce SSH poate face și el). Î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 doar pentru că SSH are o întreagă aplicație încorporată în el: suprafața de atac a SSL + orice aplicație pe care trebuie să o oferiți nu poate fi comparată, deoarece nu avem suficiente informații.

Comentarii

  • -1 Este o comparație rezonabilă. Faceți în mod incorect presupunerea că OP compară SSL cu programul unix ssh(1). SSH este, de fapt, un alt protocol care asigură securitatea nivelului de transport, care se întâmplă să aibă prevederi speciale pentru shell-uri și execuții de la distanță. –  > Por jpillora.
  • +1 @jpillora deși sunt de acord că are sens să le comparăm pe cele două, termenul SSH nu este utilizat în mod obișnuit pentru a se referi la subansamblul protocolului SSH care se ocupă de securitatea stratului de transport, care ar fi direct comparabil cu SSL/TLS. Este folosit aproape exclusiv cu referire la protocolul de nivel de aplicație care diferă de SSL/TLS în modul descris în acest răspuns. –  > Por freb.
  • @freb modul în care se face referire la ele în general nu schimbă adevărul problemei. SSH este un protocol care este utilizat ca nivel de transport pentru utilitarul ssh. Răspunsul acceptat și cel mai votat reflectă acest fapt. –  > Por jpillora.
  • @jpillora Am vrut doar să spun că nu cred că protocolul SSH de nivel de transport este ceea ce majoritatea oamenilor ar vrea să spună având în vedere formularea întrebării. Cu toate acestea, având în vedere răspunsul acceptat ca fiind corect, trebuie să fi fost ceea ce a cerut OP. –  > Por freb.
  • @freb Corect, majoritatea oamenilor cred că, având în vedere formularea, ceea ce face și mai importantă corectarea acestei concepții greșite comune. –  > Por jpillora.
Halberdier

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

SSH utilizează așa-numitul Encrypt-and-MAC, adică mesajul cifrat este juxtapus unui cod de autentificare a mesajului (MAC) al mesajului clar pentru a adăuga integritate. Nu s-a dovedit că acest lucru este întotdeauna complet sigur (chiar dacă în cazuri practice ar trebui să fie suficient).

SSL utilizează MAC-then-Encrypt: un MAC este juxtapus textului clar, apoi ambele sunt criptate. Nici acest lucru nu este cel mai bun, deoarece, în cazul unor moduri de cifrare în bloc, anumite părți din MAC pot fi ghicite și pot dezvălui ceva despre cifru. Acest lucru a dus la vulnerabilități în TLS 1.0 (atacul BEAST).

Așadar, ambele au potențiale puncte slabe teoretice. Cea mai puternică metodă este „Encrypt-then-MAC” (adăugarea unui MAC al mesajului cifrat), care este implementată, de exemplu, în IPsec ESP.

Comentarii

  • Protocolul de pachete binare al SSH este criptare-și-MAC, în care pentru fiecare mesaj în clar (m) trimite textul cifrat E(m)++MAC(m) (concatenarea mesajului criptat cu MAC), spre deosebire de SSL care face E(m++MAC(m)). Cu toate acestea, SSH este mult mai mult decât protocolul său de pachete binare (gestionare a cheilor, client/server de shell la distanță, transfer de fișiere etc.), în timp ce SSL (numit în prezent TLS) este doar protocolul stratului de transport care este utilizat în alte protocoale care adaugă funcționalitatea necesară (de exemplu, HTTPS, FTPS, IMAPS etc.). A se vedea, de asemenea, comparația dintre EtM, E&M, MtE la: crypto.stackexchange.com/questions/202 –  > Por dr jimbob.
  • Pe deplin de acord, există mult mai mult decât ceea ce am scris; asta am vrut să spun prin incipit „din punct de vedere strict criptografic”. –  > Por Halberdier.
  • BEAST nu are legătură cu MtE și se datorează cunoscutului-IV cu CBC (în SSL3 și TLS1.0) – pe care SSH2 de asemenea îl face și nu l-a corectat, deși a primit CTR ca alternativă înainte ca atât el cât și TLS să primească AEAD = GCM (TLS de asemenea CCM) (și ambele ChaCha/Poly) ca o alternativă mai bună. Atacurile MtE+CBC bazate pe padding sunt POODLE și Lucky13. –  > Por dave_thompson_085.
  • Am o soluție care face ca MAC-then-Encrypt să fie sigur pentru orice cifru care are dimensiunea de ieșire = dimensiunea de intrare și nu are date slabe de intrare în nucleul de cifrare. –  > Por Joshua.
  • acest răspuns este depășit, deoarece nu asta face TLS în prezent. –  > Por David 天宇 Wong.
Sam Moore

Cred că există un aspect al acestei comparații care a fost trecut cu vederea. user185 a fost aproape, dar nu a reușit să ajungă acolo. Sunt de acord că acestea sunt mere și portocale și cred că o comparație mai bună între mere și mere ar fi HTTPS și SSH. HTTPS și SSH utilizează straturi diferite ale modelului OSI și, prin urmare, criptează datele în momente diferite ale transmisiei. În acest caz, adevăratele întrebări care ar trebui să fie puse ar fi de genul: când sunt criptate și când sunt necriptate aceste date în timpul transmiterii. Acest lucru vă va dezvălui potențialele suprafețe de atac. În cazul HTTPS, odată ce pachetul este primit de un dispozitiv din rețeaua de destinație (server web, router de frontieră, distribuitor de sarcină etc.), acesta este necriptat și își petrece restul călătoriei în text simplu. Mulți ar putea spune că acest lucru nu este o mare problemă, deoarece traficul este intern în acest moment, dar dacă volumul util conține date sensibile, acesta 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, în mod obișnuit, dispozitivul de destinație este specificat, iar transmisia este criptată până când ajunge la acest dispozitiv. Există modalități de re-criptare a datelor HTTPS, dar aceștia sunt pași suplimentari pe care cei mai mulți uită să îi facă atunci când implementează o soluție HTTPS în mediul lor.

datsusarachris

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

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

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

ssh este modul în care computerul care se conectează se poate verifica și poate obține acces.

Comentarii

  • Nu explicați deloc comentariul cu „ușa și cărămizile”. SSL are, de asemenea, chei publice și private. SSL poate fi utilizat și pentru autentificarea clienților. SSH asigură, de asemenea, o legătură sigură între client și server. –  > Por schroeder.
Gobbly

SSL este un strat de protocol care este abstractizat de conținutul care este tunelat. SSH este o versiune securizată a shell-ului (SH), nu a fost conceput pentru a conține un strat abstract sub el, ci a fost conceput special pentru a transporta traficul shell. Prin urmare, deși în ambele sunt utilizate operații de criptare, iar aceste operații de criptare ar putea fi chiar aceleași, scopul și, prin urmare, concepția generală sunt foarte diferite.

Rețineți că există diferențe specifice (așa cum au fost citate mai sus), dar majoritatea, dacă nu toate aceste diferențe, își au originea în scopul diferitelor protocoale.

Comentarii

  • -1 Faceți în mod incorect presupunerea că OP compară SSL cu programul unix. ssh(1). SSH este, de fapt, un alt protocol care oferă securitate la nivelul de transport, care, din întâmplare, are prevederi speciale pentru shell-uri de la distanță și execuție de la distanță. –  > Por jpillora.
Deep

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

Pentru că unul dintre motivele pentru care SSH câștigă în fața SSL este modul în care realizează autentificarea. Din acest motiv, atunci când utilizați FTP, folosiți protocolul SSH (SFTP) mai degrabă decât FTPS (FTP over SSL).

SSH este utilizat în rețelele corporative pentru:

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

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

Comentarii

  • „Un motiv pentru care SSH câștigă în fața SSL este modul în care realizează autentificarea” Aveți o sursă sau o explicație pentru această afirmație? –  > Por AndrolGenhald.
  • În SSH există două opțiuni de conectare la server. Cu opțiunea de autentificare bazată pe cheie, va trebui mai întâi să se genereze în prealabil o cheie privată și o cheie publică SSH. Ceea ce nu reprezintă prea multă muncă suplimentară. Acest lucru este, de asemenea, considerat cele mai bune practici de securitate. SSL are atât de multe versiuni, cea mai recentă fiind TLS1.2. Ceea ce înseamnă că nu este încă atât de sigur, dar este în curs de îmbunătățire. –  > Por Deep.
  • TLS are, de asemenea, certificate pe partea de client. Nu explicați de ce SSH „câștigă”. –  > Por schroeder.
  • Dacă aveți de gând să faceți copy/paste de undeva, asigurați-vă că vă citați sursa. –  > Por schroeder.
  • „SSL are atât de multe versiuni” Deci, 6 versiuni sunt „atât de multe”? OpenSSH este la versiunea 7.7. „Ceea ce înseamnă că nu este încă atât de sigur, dar în curs de îmbunătățire.” Logica ta nu are niciun sens aici. –  > Por schroeder.
Stanley Hutchinson

Problema este dublă, nu este vorba doar de puterea și slăbiciunea criptării. Ci și ușurința și comoditatea livrării. Deci, din punct de vedere comercial, SSL/TLS este mai convenabil și mai ușor, deoarece necesită doar un browser și un Cert public sau privat.

Iar SSH necesită fie o aplicație, fie un client subțire instalat pentru a fi utilizat. Aceasta este mai mult o problemă din perspectiva clientului de internet al utilizatorului și a suportului.