Hvad er forskellen mellem SSL og SSH? Hvilket er mere sikkert?

SSL og SSH leverer begge kryptografien elementer til at opbygge en tunnel til fortrolig datatransport med kontrolleret integritet. For den del bruger de lignende teknikker og kan lide af samme type angreb, så de skal give lignende sikkerhed (dvs. god sikkerhed) forudsat at de begge er korrekt implementeret. At begge eksisterer er en slags NIH syndrom: SSH-udviklerne skulle have genbrugt SSL til tunneldelen (SSL-protokollen er fleksibel nok til at rumme mange variationer, inkl. ting der ikke bruger certifikater).

De adskiller sig med hensyn til de ting, der er omkring tunnelen. SSL bruger traditionelt X.509-certifikater til annoncering af server- og klientens offentlige nøgler; SSH har sit eget format. SSH leveres også med et sæt protokoller for, hvad der går inde i tunnelen (multiplexing af flere overførsler, udførelse af adgangskodebaseret godkendelse i tunnelen, terminaladministration …), mens der ikke er sådan noget i SSL , eller mere præcist, når sådanne ting bruges i SSL, betragtes de ikke som en del af SSL (for eksempel når man udfører adgangskodebaseret HTTP-godkendelse i en SSL-tunnel, siger vi, at det er en del af “HTTPS”, men det fungerer virkelig på en måde svarende til hvad der sker med SSH).

Konceptuelt kan du tage SSH og erstatte tunneldelen med den fra SSL. Du kan også tage HTTPS og erstatte SSL-tingen med SSH-med-datatransport og en krog for at udtrække serverens offentlige nøgle fra sit certifikat. Der er ingen videnskabelig umulighed, og hvis det gøres ordentligt, ville sikkerheden forblive den samme. Der er dog intet udbredt sæt konventioner eller eksisterende værktøjer til det.

Så vi bruger ikke SSL og SSH til de samme ting, men det skyldes de værktøjer, der historisk fulgte med implementeringerne af disse protokoller, ikke på grund af en sikkerhedsrelateret forskel. Og den, der implementerer SSL eller SSH, anbefales at se på, hvilken type angreb der blev prøvet på begge protokoller.

Kommentarer

• Godt job. Og faktisk, da SSH er nemmere at konfigurere end SSL, tunnelerer mange mennesker http (ikke https) inde i SSH, f.eks. for at foretage ekstern systemadministration med et web GUI-værktøj som ebox eller webmin.
• Bare for at påpege, er det ‘ ikke helt rigtigt, at SSH-fyrene ” skulle ” have brugt SSL: SSH blev designet meget specifikt til at have en lille angrebsflade og være meget sikker. SSHv2 har ingen af problemerne og faldgruber i SSL / TLS, så gå med en mindre ting, som de u forstod godt, med mindre kompleksitet, kom de ud med noget, der var meget bedre egnet til deres situation. Det afhænger af, hvor paranoid du er: SSL er ikke ‘ t ubrugelig, afhængigt af applikationen, men SSH ‘ s design gør det acceptabelt i situationer / sikkerhedssamfund, hvor SSL simpelthen ikke er tillid til.
• @NicholasWilson ” SSH ‘ s design gør det acceptabelt i situationer / sikkerhedssamfund, hvor SSL simpelthen er ikke tillid til ” såsom …
• SSL og SSH blev udviklet parallelt (begge blev frigivet i 1995), så om SSH endda kunne have brugt SSL er ikke klart. Om det skulle have brugt den moderne SSL 2.0 er også meget tvivlsomt 🙂
• Nå, SSH 2.0 var en fuldstændig omskrivning af protokollen og dukkede op et stykke tid omkring 1999, så man kunne have genbrugt SSL 3.0 eller endda TLS 1.0. Men selvfølgelig ser TLS ud at være bundet med X.509, hvilket skræmmer udviklere væk.

Fra et strengt kryptografisk synspunkt leverer de begge godkendt kryptering, men i to forskellige veje.

SSH bruger den såkaldte Encrypt-and-MAC, dvs. den krypterede meddelelse sidestilles med en meddelelsesgodkendelseskode (MAC) i den klare meddelelse for at tilføje integritet. Dette er ikke bevist, at det altid er helt sikkert (selvom det i praktiske tilfælde skulle være nok).

SSL bruger MAC-derefter-krypter: En MAC sidestilles med den klare tekst, så er de begge krypteret . Dette er heller ikke det bedste, da det i nogle blokcipher-tilstande kan dele af MAC være gættelige og afsløre noget på chifferet. Dette førte til sårbarheder i TLS 1.0 (BEAST-angreb).

Så de har begge potentielle teoretiske svagheder. Den stærkeste metode er Encrypt-then-MAC (tilføj en MAC for den krypterede meddelelse), som f.eks. Implementeres i IPsec ESP.

Kommentarer

• SSH ‘ s binære pakkeprotokol er krypteret og MAC, hvor den for hver almindelig tekstbesked (m) sender krypteringsteksten E (m) ++ MAC (m) (sammenkædet krypteret besked med MAC) versus SSL, der gør E (m ++ MAC (m)). SSH er dog meget mere end bare dens binære pakkeprotokol (nøglehåndtering, ekstern shell-klient / server, filoverførsel osv.), Mens SSL (nu kaldet TLS) bare er transportlagsprotokollen, der bruges i andre protokoller, der tilføjer i den nødvendige funktionalitet (f.eks. HTTPS, FTPS, IMAPS osv.). Se også sammenligning af EtM, E & M, MtE at: crypto.stackexchange.com / spørgsmål / 202
• Fuldt aftalt, der er meget mere end hvad jeg skrev; at ‘ er hvad jeg mente med min incipit ” fra et strengt kryptografisk synspunkt “.
• BEAST er ikke relateret til MtE og skyldes kendt IV med CBC (i SSL3 og TLS1.0) – hvilket SSH2 også gør og ikke korrigerede, skønt det fik CTR som et alternativ, før både det og TLS fik AEAD = GCM (TLS også CCM) (og begge ChaCha / Poly) som et bedre alternativ. MtE + CBC-polstringsbaserede angreb er POODLE og Lucky13.
• Jeg har en løsning, der gør MAC-then-Encrypt sikker til enhver chiffer, der har outputstørrelse = inputstørrelse og ingen svag dataindgang i chiffer kerne.
• dette svar er forældet, da dette ikke er, hvad TLS gør i dag.

Jeg tror, der er et aspekt ved denne sammenligning, der blev overset. user185 kom tæt på, men kom ikke helt dertil. Jeg er enig i, at dette er æbler og appelsiner og føler en bedre sammenligning af æbler til æbler for at være HTTPS og SSH. HTTPS og SSH bruger forskellige lag af OSI-modellen og krypterer derfor dataene på forskellige gange i transmissionen. Derefter ville de virkelige spørgsmål, man skulle stille, være i retning af hvornår er disse data krypteret og ukrypteret under transmissionen. Dette afslører dine potentielle angrebsflader. Med HTTPS, når pakken er modtaget af en enhed i destinationsnetværket (Webserver, Border Router, load balancer osv.) er det ikke-krypteret og bruger resten af rejsen i almindelig tekst. Mange vil hævde, at dette ikke er en stor ting, da trafikken er intern kl. denne gang, men hvis nyttelasten indeholder følsomme data, gemmes den ukrypteret i logfilerne på hver netværksenhed, den passerer igennem, indtil den når sin endelige destination. Med SSH specificeres destinationsenheden typisk, og transmission er krypteret, indtil den når denne enhed. Der er måder at genkryptere HTTPS-data på, men det er ekstra trin, som de fleste glemmer at tage, når de implementerer en HTTPS-løsning i deres miljø.

SSL er et protokollag, der er abstraheret fra det indhold, der tunneles. SSH er en sikker version af shell (SH), den var ikke designet til at indeholde et abstrakt lag under den, den var designet specielt til at transportere shell-trafik. Så selvom crypto-operationer bruges i begge dele, og disse crypto-operationer endda kunne være de samme, er formålet, og derfor er det overordnede design helt anderledes.

Husk, at der er specifikke forskelle (som nævnt ovenfor ), men de fleste, hvis ikke alle disse forskelle er rodfæstet i formålet med de forskellige protokoller.

Kommentarer

• -1 Du antager forkert antagelsen at OP sammenligner SSL med unix-programmet ssh (1) . SSH er faktisk en anden protokol, der giver sikkerhed for transportlag, hvilket tilfældigvis har særlige bestemmelser for fjernskaller og fjernudførelse.

Hvis du virkelig leder efter SSH vs SSL (TLS), er svaret SSH.

Af en grund til hvorfor SSH vinder over SSL er den måde, den udfører godkendelse på. På grund af denne grund, når du bruger FTP, skal du bruge SSH-protokol (SFTP) i stedet for FTPS (FTP over SSL).

SSH bruges i virksomhedsnetværk til:

• giver sikker adgang til brugere og automatiserede processer
• interaktive og automatiserede filoverførsler
• udstedelse af fjernkommandoer

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

Kommentarer

• ” Af en grund vinder SSH over SSL den måde, den udfører godkendelse ” Har du en kilde eller forklaring på denne påstand?
• I SSH har man to muligheder for at forbinde serveren. Med nøglebaseret godkendelsesmulighed skal man først oprette en SSH privat nøgle og offentlig nøgle på forhånd. Hvilket ikke er meget ekstra arbejde. Dette overvejes også bedste sikkerhedspraksis. SSL har så mange versioner, den seneste er TLS1.2.Hvilket betyder, at det ‘ ikke er så sikkert endnu, men i færd med at blive bedre.
• TLS har også certifikater på klientsiden. Du forklarer ikke, hvorfor SSH ” vinder “.
• Hvis du vil kopiere / indsætte et sted, sørg for at citere din kilde.
• ” SSL har så mange versioner ” Så 6 versioner er ” så mange “? OpenSSH er på version 7.7. ” Hvilket betyder, at det ‘ er endnu ikke så sikkert, men i færd med at blive bedre. ” Din logik giver ingen mening her.

Problemet er dobbelt så det ” Det er ikke kun krypteringens styrke og svaghed, men det er leveringens lethed og bekvemmelighed. Så fra forretningsperspektiv er SSL / TLS mere bekvemt og lettere, fordi det bare kræver en browser og enten en offentlig eller privat certificering.

Og SSH kræver enten applikationen eller den tynde klient installeret for at bruge den. Dette er mere et problem set fra brugerens internetklientperspektiv og support.