Vad är skillnaden mellan SSL och SSH? Vilket är säkrare?

SSL och SSH ger båda kryptografin element för att bygga en tunnel för konfidentiell datatransport med kontrollerad integritet. För den delen använder de liknande tekniker och kan drabbas av samma typ av attacker, så de borde ge liknande säkerhet (dvs. god säkerhet) förutsatt att de båda är korrekt implementerade. Att båda finns är ett slags NIH syndrom: SSH-utvecklarna borde ha återanvänt SSL för tunneldelen (SSL-protokollet är tillräckligt flexibelt för att rymma många variationer, inklusive att inte använda certifikat).

De skiljer sig åt vad som finns runt tunneln. SSL använder traditionellt X.509-certifikat för att meddela server- och klientens offentliga nycklar; SSH har sitt eget format. SSH kommer också med en uppsättning protokoll för vad som går inuti tunneln (multiplexering av flera överföringar, lösenordsbaserad autentisering i tunneln, terminalhantering …) medan det inte finns något sådant i SSL , eller, mer exakt, när sådana saker används i SSL anses de inte vara en del av SSL (till exempel när man gör lösenordsbaserad HTTP-autentisering i en SSL-tunnel säger vi att den är en del av ”HTTPS”, men det fungerar verkligen på ett sätt som liknar vad som händer med SSH).

Konceptuellt kan du ta SSH och ersätta tunneldelen med den från SSL. Du kan också ta HTTPS och ersätta SSL-saken med SSH-med-datatransport och en krok för att extrahera serverns offentliga nyckel från sitt certifikat. Det finns ingen vetenskaplig omöjlighet och, om det görs ordentligt, skulle säkerheten förbli densamma. Det finns dock ingen utbredd uppsättning konventioner eller befintliga verktyg för det.

Så vi använder inte SSL och SSH för samma saker, men det beror på vilka verktyg som historiskt följde med implementeringarna av dessa protokoll, inte på grund av en säkerhetsrelaterad skillnad. Och den som implementerar SSL eller SSH skulle rekommenderas att titta på vilken typ av attacker som testades på båda protokollen.

Kommentarer

• Bra jobbat. Och faktiskt, eftersom SSH är lättare att konfigurera än SSL, många tunnelar http (inte https) inuti SSH, t.ex. för att göra fjärrsystemadministration med en web GUI-verktyg som ebox eller webmin.
• Bara för att påpeka, det ’ är inte riktigt sant att SSH-killarna ” borde ” ha använt SSL: SSH designades mycket specifikt för att ha en liten attackyta och vara mycket säker. SSHv2 har inga problem och fallgropar i SSL / TLS, så går med en mindre sak som de u förstod bra, med mindre komplexitet, kom de ut med något som passar bättre för deras situation. Det beror på hur paranoid du är: SSL är inte ’ t oanvändbar, beroende på applikation, men SSH ’ design gör det acceptabelt i situationer / säkerhetsgrupper där SSL helt enkelt inte är betrodda.
• @NicholasWilson ” SSH ’ s design gör det acceptabelt i situationer / säkerhetsgrupper där SSL helt enkelt är inte tillförlitlig ” som …
• SSL och SSH utvecklades parallellt (båda släpptes 1995), så om SSH till och med kunde ha använt SSL är inte klart. Huruvida det borde ha använt samtida SSL 2.0 är också mycket tveksamt 🙂
• SSH 2.0 var en fullständig omskrivning av protokollet och dök upp någon gång runt 1999, så att man kunde ha återanvänt SSL 3.0 eller till och med TLS 1.0. Men naturligtvis verkar TLS vara bunden till X.509, vilket skrämmer utvecklare bort.

Från en strikt kryptografisk synpunkt ger de båda autentiserad kryptering, men i två olika sätt.

SSH använder den så kallade Encrypt-and-MAC, det vill säga det krypterade meddelandet placeras bredvid en meddelandeautentiseringskod (MAC) för det tydliga meddelandet för att lägga till integritet. Det har inte visat sig att det alltid är helt säkert (även om det i praktiska fall borde vara tillräckligt).

SSL använder MAC-då-kryptera: en MAC ställs intill den klara texten, då är de båda krypterade . Det här är inte heller det bästa, eftersom det i vissa blockkrypteringslägen delar av MAC kan vara gissningsbara och avslöjar något på krypteringen. Detta ledde till sårbarheter i TLS 1.0 (BEAST attack).

Så de har båda potentiella teoretiska svagheter. Den starkaste metoden är Encrypt-then-MAC (lägg till en MAC för det krypterade meddelandet), som implementeras, t.ex. i IPsec ESP.

Kommentarer

• SSH ’ s binära paketprotokoll är krypterat-och-MAC där det för varje klartextmeddelande (m) skickar krypteringstexten E (m) ++ MAC (m) (sammanfoga krypterad meddelande med MAC), mot SSL som gör E (m ++ MAC (m)). SSH är dock mycket mer än bara dess binära paketprotokoll (nyckelhantering, fjärrskalklient / server, gör filöverföring, etc), medan SSL (nu kallad TLS) är bara transportlagerprotokollet som används i andra protokoll som lägger till i nödvändig funktionalitet (t.ex. HTTPS, FTPS, IMAPS etc.). Se även jämförelse av EtM, E & M, MtE at: crypto.stackexchange.com / frågor / 202
• Helt överens, det finns mycket mer än vad jag skrev; att ’ är vad jag menade med min incipit ” ur en strikt kryptografisk synvinkel ”.
• BEAST är inte relaterat till MtE och beror på känd-IV med CBC (i SSL3 och TLS1.0) – vilket SSH2 också gör och inte korrigerade, även om det fick CTR som ett alternativ innan både det och TLS fick AEAD = GCM (TLS också CCM) (och båda ChaCha / Poly) som ett bättre alternativ. De MtE + CBC-utfyllnadsbaserade attackerna är POODLE och Lucky13.
• Jag har en lösning som gör MAC-then-Encrypt säker för alla chiffer som har utmatningsstorlek = ingångsstorlek och ingen svag datainmatning i chifferet kärna.
• det här svaret är föråldrat eftersom TLS inte gör det idag.

Jag tror att det finns en aspekt av denna jämförelse som förbises. user185 kom nära men kom inte riktigt dit. Jag håller med om att det här är äpplen och apelsiner och känns bättre än äpplen jämfört med att vara HTTPS och SSH. HTTPS och SSH använder olika lager av OSI-modellen och krypterar därför data på olika gånger i överföringen. Då skulle de riktiga frågorna man borde ställa i linje med när är dessa data krypterade och okrypterade under överföringen. Detta kommer att avslöja dina potentiella attackytor. Med HTTPS, när paketet tas emot av en enhet i destinationsnätverket (webbserver, gränsrouter, belastningsutjämnare, etc …) är det okrypterat och spenderar resten av resan i klartext. Många menar att detta inte är en stor sak eftersom trafiken är intern vid den här gången, men om nyttolasten innehåller känslig data, lagras den okrypterad i loggfilerna för varje nätverksenhet som den passerar igenom tills den når sin slutliga destination. Med SSH specificeras målenheten vanligtvis och överföringen krypteras tills den når den här enheten. Det finns sätt att omkryptera HTTPS-data men det här är extra steg som de flesta glömmer att ta när man implementerar en HTTPS-lösning i sin miljö.

SSL är ett protokolllager som är abstraherat från innehållet som tunnlas. SSH är en säker version av shell (SH), den var inte utformad för att innehålla ett abstrakt lager under den, den var speciellt utformad för att bära skaltrafik. Så även om kryptooperationer används i båda, och dessa kryptooperationer till och med kan vara desamma, är syftet och därför övergripande design helt annorlunda.

Tänk på att det finns specifika skillnader (som har citerats ovan ), men de flesta om inte alla dessa skillnader är rotade i syftet med de olika protokollen.

Kommentarer

• -1 Du antar felaktigt att OP jämför SSL med unix-programmet ssh (1) . SSH är faktiskt ett annat protokoll som tillhandahåller säkerhet för transportskikt, vilket råkar ha speciella bestämmelser för fjärrskal och fjärrkörning.

Om du verkligen letar efter SSH vs SSL (TLS) är svaret SSH.

Av en anledning till att SSH vinner över SSL är det sättet det utför autentisering på. På grund av denna anledning när du använder FTP använder du SSH-protokoll (SFTP) snarare än FTPS (FTP över SSL).

SSH används i företagsnätverk för:

• ger säker åtkomst för användare och automatiserade processer
• interaktiva och automatiserade filöverföringar
• utfärdande av fjärrkommandon

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

Kommentarer

• ” Av en anledning vinner SSH över SSL är det sätt det utför autentisering ” Har du en källa eller förklaring till detta påstående?
• I SSH har man två alternativ för att ansluta servern. Med nyckelbaserat autentiseringsalternativ måste man först skapa en SSH-privatnyckel och en offentlig nyckel i förväg. Vilket inte är mycket extra arbete. Detta är också överväga bästa säkerhetspraxis. SSL har så många versioner den senaste är TLS1.2.Vilket betyder att det ’ ännu inte är säkert, men håller på att bli bättre.
• TLS har också certifikat på klientsidan. Du förklarar inte varför SSH ” vinner ”.
• Om du ska kopiera / klistra in någonstans, se till att du citerar din källa.
• ” SSL har så många versioner ” Så, 6 versioner är ” så många ”? OpenSSH finns på version 7.7. ” Vilket betyder att det ’ ännu inte är säkert, men håller på att bli bättre. ” Din logik är ingen mening här.

Problemet är tvåfaldigt, det ” Det är inte bara krypteringens styrka och svaghet, men det är enkelhet och bekvämlighet med leveransen. Så ur affärsperspektiv är SSL / TLS enklare och enklare eftersom det bara kräver en webbläsare och antingen ett offentligt eller privat cert.

Och SSH kräver antingen applikationen eller tunn klient installerad för att kunna använda den. Det är mer ett problem ur ett användarinternetklientperspektiv och support.