Hva er forskjellen mellom SSL og SSH? Hva er sikrere?

SSL og SSH gir begge kryptografien elementer for å bygge en tunnel for konfidensiell datatransport med kontrollert integritet. For den delen bruker de lignende teknikker, og kan lide av samme type angrep, så de bør gi lignende sikkerhet (dvs. god sikkerhet) forutsatt at de begge er riktig implementert. At begge eksisterer er en slags NIH syndrom: SSH-utviklerne burde ha brukt SSL på nytt for tunneldelen (SSL-protokollen er fleksibel nok til å imøtekomme mange varianter, inkl. ting som ikke bruker sertifikater).

De er forskjellige på tingene rundt tunnelen. SSL bruker tradisjonelt X.509-sertifikater for å kunngjøre offentlige nøkler til server og klient; SSH har sitt eget format. SSH kommer også med et sett med protokoller for hva som går inne i tunnelen (multipleksing av flere overføringer, utføring av passordbasert autentisering i tunnelen, terminaladministrasjon …) mens det ikke er noe slikt i SSL , eller, mer nøyaktig, når slike ting brukes i SSL, anses de ikke for å være en del av SSL (for eksempel når du gjør passordbasert HTTP-autentisering i en SSL-tunnel, sier vi at det er en del av «HTTPS», men det fungerer virkelig på en måte som ligner på hva som skjer med SSH).

Konseptuelt kan du ta SSH og erstatte tunneldelen med den fra SSL. Du kan også ta HTTPS og erstatte SSL-tingen med SSH-med-datatransport og en krok for å trekke ut den offentlige nøkkelen til serveren fra sertifikatet. Det er ingen vitenskapelig umulighet, og hvis det gjøres riktig, vil sikkerheten forbli den samme. Det er imidlertid ikke noe omfattende sett med konvensjoner eller eksisterende verktøy for det.

Så vi bruker ikke SSL og SSH til de samme tingene, men det er på grunn av hvilke verktøy som historisk fulgte med implementeringene av disse protokoller, ikke på grunn av en sikkerhetsrelatert forskjell. Og den som implementerer SSL eller SSH, anbefales å se på hva slags angrep som ble prøvd på begge protokollene.

Kommentarer

• God jobb. Og siden SSH er lettere å konfigurere enn SSL, er det mange som tunnel http (ikke https) inne i SSH, for eksempel å gjøre ekstern systemadministrasjon med et web GUI-verktøy som ebox eller webmin.
• Bare for å påpeke, er det ‘ ikke helt sant at SSH-gutta » burde » ha brukt SSL: SSH ble designet veldig spesifikt for å ha en liten angrepsflate, og være veldig sikker. SSHv2 har ingen av problemene og fallgruver i SSL / TLS, så går med en mindre ting som de u forstod godt, med mindre kompleksitet, kom de ut med noe som var bedre egnet for deres situasjon. Det kommer an på hvor paranoid du er: SSL er ikke ‘ t ubrukelig, avhengig av applikasjon, men SSH ‘ s design gjør det akseptabelt i situasjoner / sikkerhetssamfunn der SSL ganske enkelt ikke er klarert.
• @NicholasWilson » SSH ‘ s design gjør det akseptabelt i situasjoner / sikkerhetssamfunn hvor SSL ganske enkelt er ikke klarert » som …
• SSL og SSH ble utviklet parallelt (begge ble utgitt i 1995), så om SSH til og med kunne ha brukt SSL er ikke klart. Om det burde ha brukt den moderne SSL 2.0 er også veldig tvilsomt 🙂
• Vel, SSH 2.0 var en fullstendig omskrivning av protokollen og dukket opp en tid rundt 1999, slik at man kunne ha brukt SSL 3.0 eller TLS 1.0 på nytt. Men selvfølgelig ser TLS ut å være knyttet til X.509, noe som skremmer utviklere unna.

Fra et strengt kryptografisk synspunkt gir de begge autentisert kryptering, men i to forskjellige måter.

SSH bruker den såkalte Encrypt-and-MAC, det vil si at den krypterte meldingen er sidestilt til en meldingsautentiseringskode (MAC) for den klare meldingen for å legge til integritet. Dette er ikke bevist at det alltid er helt sikkert (selv om det i praktiske tilfeller burde være nok).

SSL bruker MAC-så-krypter: En MAC står ved siden av klar tekst, så er de begge kryptert . Dette er heller ikke det beste, ettersom noen krypteringsmodi for blokker kan delene av MAC være gjette og avsløre noe på krypteringen. Dette førte til sårbarheter i TLS 1.0 (BEAST-angrep).

Så de har begge potensielle teoretiske svakheter. Den sterkeste metoden er Encrypt-then-MAC (legg til en MAC av den krypterte meldingen), som er implementert, for eksempel i IPsec ESP.

Kommentarer

• SSH ‘ s binære pakkeprotokoll er krypterings-og-MAC hvor den for hver enkelt tekstmelding (m) sender krypteringsteksten E (m) ++ MAC (m) (sammenkoblet kryptert melding med MAC), mot SSL som gjør E (m ++ MAC (m)). Imidlertid er SSH mye mer enn bare den binære pakkeprotokollen (nøkkeladministrasjon, ekstern skallklient / server, gjør filoverføring osv.), Mens SSL (nå kalt TLS) bare er transportlagsprotokollen som brukes i andre protokoller som legger til i den nødvendige funksjonaliteten (f.eks. HTTPS, FTPS, IMAPS osv.). Se også sammenligning av EtM, E & M, MtE at: crypto.stackexchange.com / spørsmål / 202
• Helt enig, det er mye mer enn det jeg skrev; at ‘ er det jeg mente med incipit » fra et strengt kryptografisk synspunkt «.
• BEAST er ikke relatert til MtE og skyldes kjent-IV med CBC (i SSL3 og TLS1.0) – noe SSH2 også gjør og ikke korrigerer, selv om den fikk CTR som et alternativ før både den og TLS fikk AEAD = GCM (TLS også CCM) (og begge ChaCha / Poly) som et bedre alternativ. De MtE + CBC-polstringsbaserte angrepene er POODLE og Lucky13.
• Jeg har en løsning som gjør MAC-then-Encrypt trygt for enhver kryptering som har utgangsstørrelse = inngangsstørrelse og ingen svak datainngang i krypteringen kjernen.
• dette svaret er utdatert ettersom dette ikke er hva TLS gjør i dag.

Jeg tror det er ett aspekt ved denne sammenligningen som ble oversett. user185 nærmet seg, men kom ikke helt dit. Jeg er enig i at dette er epler og appelsiner og føler en bedre eple til eple sammenlignet med HTTPS og SSH. HTTPS og SSH bruker forskjellige lag av OSI-modellen og krypterer derfor dataene på forskjellige ganger i overføringen. Da vil de virkelige spørsmålene man bør stille være i tråd med når er disse dataene kryptert og ukryptert under overføringen. Dette vil avsløre dine potensielle angrepsflater. Med HTTPS, når pakken er mottatt av en enhet i destinasjonsnettverket (Web Server, Border Router, load balancer, etc …) det er ukryptert og tilbringer resten av reisen i ren tekst. Mange vil hevde at dette ikke er så farlig siden trafikken er intern kl. denne gangen, men hvis nyttelasten inneholder sensitive data, lagres den ukryptert i loggfilene til hver nettverksenhet den passerer gjennom til den kommer til sitt endelige mål. Med SSH spesifiseres målenheten og overføring er kryptert til den når denne enheten. Det er måter å kryptere HTTPS-data på nytt, men dette er ekstra trinn som de fleste glemmer å ta når de implementerer en HTTPS-løsning i sitt miljø.

SSL er et protokolllag som er abstrahert fra innholdet som blir tunnelert. SSH er en sikker versjon av shell (SH), den var ikke designet for å inneholde et abstrakt lag under den, den ble designet spesielt for å bære skalltrafikk. Så selv om kryptooperasjoner brukes i begge deler, og disse kryptoperasjonene til og med kan være de samme, er formålet og dermed den generelle utformingen ganske annerledes.

Husk at det er spesifikke forskjeller (som er sitert ovenfor) ), men de fleste om ikke alle disse forskjellene er forankret i formålet med de forskjellige protokollene.

Kommentarer

• -1 Du antar feilaktig at OP sammenligner SSL med unix-programmet ssh (1) . SSH er faktisk en annen protokoll som gir transportlagsikkerhet, som tilfeldigvis har spesielle bestemmelser for eksterne skall og ekstern kjøring.

Hvis du virkelig ser etter SSH vs SSL (TLS), er svaret SSH.

Av en grunn til at SSH vinner over SSL, er måten den utfører godkjenning på. På grunn av denne grunnen når du bruker FTP, bruk SSH-protokoll (SFTP) i stedet for FTPS (FTP over SSL).

SSH brukes i bedriftsnettverk for:

• gir sikker tilgang for brukere og automatiserte prosesser
• interaktive og automatiserte filoverføringer
• utstedelse av eksterne kommandoer

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

Kommentarer

• » Av en grunn SSH vinner over SSL er måten den utfører autentisering » Har du en kilde eller forklaring på denne påstanden?
• I SSH har man to alternativer for å koble til serveren. Med nøkkelbasert godkjenningsalternativ må man først generere en SSH privat nøkkel og offentlig nøkkel på forhånd. Noe som ikke er mye merarbeid. Dette er også vurdere beste sikkerhetspraksis. SSL har så mange versjoner den siste er TLS1.2.Noe som betyr at det ‘ ennå ikke er så sikkert, men i ferd med å bli bedre.
• TLS har også sertifikater på klientsiden. Du forklarer ikke hvorfor SSH » vinner «.
• Hvis du skal kopiere / lime inn et sted, sørg for at du siterer kilden.
• » SSL har så mange versjoner » Så 6 versjoner er » så mange «? OpenSSH er på versjon 7.7. » Hvilket betyr at det ‘ er ennå ikke så sikkert, men i ferd med å bli bedre. » Logikken din gir ingen mening her.

Problemet er to ganger, det » Det er ikke bare styrken og svakheten ved krypteringen, men det er enkel og enkel levering. Så fra forretningsperspektiv er SSL / TLS mer praktisk og enklere fordi det bare krever en nettleser og enten en offentlig eller privat sertifisering.

Og SSH krever enten applikasjonen eller tynnklienten installert for å bruke den. Dette er mer et problem fra et brukerinternettklientperspektiv og støtte.