Wat is het verschil tussen SSL en SSH? Welke is veiliger?

SSL en SSH bieden beide de cryptografische elementen om een tunnel te bouwen voor vertrouwelijk datatransport met gecontroleerde integriteit.Voor dat deel gebruiken ze vergelijkbare technieken en kunnen ze te maken krijgen met dezelfde soort aanvallen, dus ze moeten vergelijkbare beveiliging bieden (dwz goede beveiliging), ervan uitgaande dat ze beide correct zijn geïmplementeerd. Dat beide bestaan is een soort NIH -syndroom: de SSH-ontwikkelaars hadden SSL moeten hergebruiken voor het tunnelgedeelte (het SSL-protocol is flexibel genoeg om veel variaties op te nemen, waaronder door geen certificaten te gebruiken).

Ze verschillen over de dingen die zich rond de tunnel bevinden. SSL gebruikt traditioneel X.509-certificaten voor het aankondigen van openbare server- en cliëntsleutels; SSH heeft zijn eigen formaat. SSH wordt ook geleverd met een reeks protocollen voor wat binnen de tunnel gaat (meerdere overdrachten multiplexen, wachtwoordgebaseerde authenticatie uitvoeren binnen de tunnel, terminalbeheer …) terwijl zoiets niet bestaat in SSL , of beter gezegd, wanneer dergelijke dingen worden gebruikt in SSL, worden ze niet beschouwd als onderdeel van SSL (bijvoorbeeld bij wachtwoordgebaseerde HTTP-authenticatie in een SSL-tunnel zeggen we dat het onderdeel is van HTTPS, maar het werkt echt op een manier die vergelijkbaar is met wat er gebeurt met SSH).

Conceptueel zou je SSH kunnen nemen en het tunneldeel vervangen door dat van SSL. Je zou ook HTTPS kunnen nemen en het SSL-ding kunnen vervangen door SSH-met-datatransport en een hook om de openbare server-sleutel uit het certificaat te halen. Er is geen wetenschappelijke onmogelijkheid en als het goed wordt gedaan, blijft de beveiliging hetzelfde. Daar is echter geen wijdverbreide set van conventies of bestaande tools voor.

Dus we gebruiken SSL en SSH niet voor dezelfde dingen, maar dat komt door welke tools in het verleden met de implementaties van die protocollen, niet vanwege een veiligheidsgerelateerd verschil. En wie SSL of SSH implementeert, doet er goed aan om te kijken naar wat voor soort aanvallen op beide protocollen zijn geprobeerd.

Opmerkingen

• Goed gedaan. En in feite, aangezien SSH gemakkelijker in te stellen is dan SSL, tunnelen veel mensen http (niet https) binnen SSH, bijvoorbeeld om systeembeheer op afstand uit te voeren met een web GUI-tool zoals ebox of webmin.
• Om erop te wijzen, het ‘ is niet helemaal waar dat de SSH-jongens ” zou ” SSL hebben gebruikt: SSH is zeer specifiek ontworpen om een klein aanvalsoppervlak te hebben en zeer veilig te zijn. SSHv2 heeft geen van de problemen en valkuilen in SSL / TLS, dus gaan met een kleiner ding dat zij u Als ze het goed begrepen, met minder complexiteit, kwamen ze met iets dat veel beter bij hun situatie paste. Het hangt ervan af hoe paranoïde je bent: SSL isn ‘ t onbruikbaar, afhankelijk van de applicatie, maar het ontwerp van SSH ‘ maakt het acceptabel in situaties / security communities waar SSL simpelweg niet vertrouwd wordt.
• @NicholasWilson ” SSH ‘ s ontwerp maakt het acceptabel in situaties / beveiligingsgemeenschappen waar SSL eenvoudig wordt niet vertrouwd ” zoals …
• SSL en SSH werden parallel ontwikkeld (beide worden in 1995 uitgebracht), dus of SSH ook maar kon hebben gebruikt SSL is niet duidelijk. Of het de huidige SSL 2.0 had moeten gebruiken is ook erg twijfelachtig 🙂
• Welnu, SSH 2.0 was een volledige herschrijving van het protocol en verscheen ergens rond 1999, zodat men had SSL 3.0 of zelfs TLS 1.0 kunnen hergebruiken. Maar natuurlijk lijkt TLS verbonden te zijn met X.509, wat ontwikkelaars afschrikt.

Dit is geen redelijke vergelijking om te maken. SSL is een algemene methode voor het beschermen van gegevens die over een netwerk worden getransporteerd, terwijl SSH een netwerktoepassing is om in te loggen en gegevens te delen met een externe computer.

De transportlaagbescherming in SSH is vergelijkbaar met SSL, dus wat “veiliger” is, hangt af van wat uw specifieke bedreigingsmodel vereist en of de implementaties van elk de problemen aanpakken die u probeert op te lossen.

SSH heeft dan een gebruikersauthenticatielaag die SSL mist (omdat het het niet nodig heeft – SSL hoeft alleen de twee verbindingsinterfaces te authenticeren die SSH ook kan doen). In UTF-8 art:

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

Met betrekking tot de kwestie waartegen er meer potentiële aanvallen zijn, lijkt het duidelijk dat SSH een groter aanvalsoppervlak heeft. Maar dat is gewoon omdat SSH een geheel applic ation erin ingebouwd: het aanvalsoppervlak van SSL + welke applicatie je ook moet bieden kan niet worden vergeleken omdat we niet genoeg informatie hebben.

Opmerkingen

• -1 Het is een redelijke vergelijking. U gaat er ten onrechte van uit dat OP SSL vergelijkt met het Unix-programma ssh (1) . SSH is eigenlijk een ander protocol dat transportlaagbeveiliging biedt, dat toevallig speciale voorzieningen heeft voor externe shells en externe uitvoering.
• +1 @jpillora hoewel ik het ermee eens ben dat het logisch is om de twee te vergelijken, is de term SSH wordt doorgaans niet gebruikt om te verwijzen naar de subset van het SSH-protocol dat transportlaagbeveiliging afhandelt die direct vergelijkbaar zou zijn met SSL / TLS. Het wordt bijna uitsluitend gebruikt met verwijzing naar het toepassingslaagprotocol dat verschilt van SSL / TLS op de manier die in dit antwoord wordt beschreven.
• @freb zoals ze ‘ opnieuw verwezen in het algemeen verandert niets aan de waarheid van de zaak. SSH is een protocol dat wordt gebruikt als de transportlaag voor het hulpprogramma ssh. Het geaccepteerde en meest gestemde antwoord weerspiegelt dit feit.
• @jpillora Ik bedoelde alleen dat ik niet ‘ denk dat het SSH-transportlaagprotocol is wat de meeste mensen zouden bedoelen gezien de formulering van de vraag. Gezien het antwoord dat als correct werd geaccepteerd, moet het echter zijn geweest wat OP vroeg.
• @freb Juist, de meeste mensen denken dat gezien de bewoordingen, waardoor het nog belangrijker is om deze veelvoorkomende misvatting.

Vanuit strikt cryptografisch oogpunt bieden ze allebei geverifieerde versleuteling, maar in twee verschillende manieren.

SSH gebruikt de zogenaamde Encrypt-and-MAC, dat wil zeggen dat het gecodeerde bericht naast een berichtauthenticatiecode (MAC) van het duidelijke bericht wordt geplaatst om integriteit toe te voegen. Het is niet bewezen dat dit altijd volledig veilig is (zelfs als dit in de praktijk voldoende zou moeten zijn).

SSL maakt gebruik van MAC-then-Encrypt: een MAC wordt naast de gewone tekst geplaatst, dan zijn ze beide versleuteld . Dit is ook niet de beste, omdat bij sommige blokcijfermodi delen van de MAC kunnen worden geraden en iets op het cijfer kunnen onthullen. Dit leidde tot kwetsbaarheden in TLS 1.0 (BEAST-aanval).

Ze hebben dus beide potentiële theoretische zwakheden. De sterkste methode is Encrypt-then-MAC (voeg een MAC van het gecodeerde bericht toe), die bijvoorbeeld is geïmplementeerd in IPsec ESP.

Opmerkingen

• SSH ‘ s binaire pakketprotocol is encrypt-and-MAC, waarbij voor elk bericht met platte tekst (m) de cijfertekst E (m) ++ MAC (m) (aaneengesloten versleuteld bericht met MAC), versus SSL die E (m ++ MAC (m)) doet. SSH is echter veel meer dan alleen het binaire pakketprotocol (sleutelbeheer, externe shell-client / server, bestandsoverdracht, enz.), Terwijl SSL (nu TLS genoemd) slechts het transportlaagprotocol is dat wordt gebruikt in andere protocollen die in de nodige functionaliteit (bijv. HTTPS, FTPS, IMAPS etc.). Zie ook vergelijking van EtM, E & M, MtE op: crypto.stackexchange.com / Questions / 202
• Helemaal mee eens, er is veel meer dan wat ik schreef; dat ‘ is wat ik bedoelde met mijn incipit ” vanuit een strikt cryptografisch oogpunt “.
• BEAST is niet gerelateerd aan MtE en is te wijten aan bekend-IV met CBC (in SSL3 en TLS1.0) – wat SSH2 ook wel en niet corrigeerde, hoewel het CTR als alternatief kreeg voordat zowel het als TLS AEAD = GCM kregen (TLS ook CCM) (en beide ChaCha / Poly) als een beter alternatief. De op MtE + CBC-padding gebaseerde aanvallen zijn POODLE en Lucky13.
• Ik heb een oplossing die MAC-then-Encrypt veilig maakt voor elk cijfer met output size = input size en geen zwakke data-invoer in het cijfer core.
• dit antwoord is verouderd omdat dit niet is wat TLS vandaag doet.

Ik denk dat er een aspect van deze vergelijking is dat over het hoofd werd gezien. user185 kwam in de buurt, maar kwam er niet helemaal uit. Ik ben het ermee eens dat dit appels en sinaasappels zijn en voel me beter appels vergeleken met appels als HTTPS en SSH. HTTPS en SSH gebruiken verschillende lagen van het OSI-model en versleutelen daarom de gegevens op verschillende keer in de verzending. De echte vragen die u zich zou moeten stellen, zijn bijvoorbeeld wanneer deze gegevens worden versleuteld en niet-versleuteld tijdens de verzending. Dit zal uw potentiële aanvalsoppervlakken onthullen. Met HTTPS, zodra het pakket is ontvangen door een apparaat in het bestemmingsnetwerk (webserver, borderrouter, load balancer, enz.), het is niet-versleuteld en brengt de rest van zijn reis door in platte tekst. Velen zouden beweren dat dit geen probleem is, aangezien het verkeer intern is op deze keer, maar als de payload gevoelige gegevens bevat, wordt deze onversleuteld opgeslagen in de logbestanden van elk netwerkapparaat dat het passeert totdat het zijn eindbestemming bereikt. Met SSH wordt meestal het bestemmingsapparaat gespecificeerd en de transmissie wordt gecodeerd totdat deze dit apparaat bereikt. Er zijn manieren om de HTTPS-gegevens opnieuw te versleutelen, maar dit zijn extra stappen die de meesten vergeten te nemen bij het implementeren van een HTTPS-oplossing in hun omgeving.

ssh is als een sleutel (privé) en het slot (openbaar)

ssl is als de deur en de stenen.

ssl biedt een veilige link tussen de twee computerservers. bijv. de jouwe en degene met wie je verbinding maakt.

ssh is hoe de verbindende computer zichzelf kan verifiëren en toegang kan krijgen.

Reacties

• Je legt de ” deur en stenen ” opmerking helemaal niet uit. SSL heeft ook openbare en privésleutels. SSL kan ook worden gebruikt voor client-authenticatie. SSH biedt ook een veilige link tussen de client en de server.

SSL is een protocollaag die wordt geabstraheerd van de inhoud die wordt getunneld. SSH is een veilige versie van shell (SH), het is niet ontworpen om er een abstracte laag onder te bevatten, het is specifiek ontworpen om shell-verkeer te dragen. Dus hoewel crypto-bewerkingen in beide worden gebruikt, en die crypto-bewerkingen zelfs hetzelfde kunnen zijn, is het doel, en daarom het algehele ontwerp, behoorlijk verschillend.

Houd er rekening mee dat er specifieke verschillen zijn (zoals hierboven vermeld ), maar de meeste, zo niet al deze verschillen zijn geworteld in het doel van de verschillende protocollen.

Opmerkingen

• -1 U doet de veronderstelling onjuist dat OP vergelijkt SSL met het Unix-programma ssh (1) . SSH is eigenlijk een ander protocol dat transportlaagbeveiliging biedt, dat speciale voorzieningen heeft voor externe shells en uitvoering op afstand.

Als u echt op zoek bent naar SSH versus SSL (TLS), dan is het antwoord SSH.

Een van de redenen waarom SSH SSL wint, is de manier waarop het authenticatie uitvoert. Gebruik daarom bij het gebruik van FTP het SSH-protocol (SFTP) in plaats van FTPS (FTP over SSL).

SSH wordt in bedrijfsnetwerken gebruikt voor:

• veilige toegang bieden aan gebruikers en geautomatiseerde processen
• interactieve en geautomatiseerde bestandsoverdrachten
• opdrachten op afstand geven

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

opmerkingen

• ” Eén reden waarom SSH wint van SSL is de manier waarop het authenticatie uitvoert ” Heb je een bron of verklaring voor deze bewering?
• In SSH heb je twee opties om verbinding te maken met de server. Met sleutelgebaseerde authenticatie-optie, zal men eerst een SSH private key en public key moeten genereren. Dat is niet veel extra werk. Dit is ook een overweging van de beste beveiligingspraktijken. SSL heeft zoveel versies dat de nieuwste TLS1.2 is.Wat betekent dat het ‘ nog niet zo veilig is, maar bezig is om beter te worden.
• TLS heeft ook client-side certificaten. Je legt niet uit waarom SSH ” ” wint.
• Als je ergens vandaan gaat kopiëren / plakken, zorg ervoor dat u uw bron vermeldt.
• ” SSL heeft zoveel versies ” Dus 6 versies zijn ” zo veel “? OpenSSH is op versie 7.7. ” Wat betekent dat het ‘ nog niet zo veilig is, maar in voorbereiding is om beter te worden. ” Uw logica slaat hier niet op.

Het probleem is tweeledig, it ” Het is niet alleen de kracht en de zwakte van de versleuteling, maar het is het gemak van de levering. Dus vanuit zakelijk oogpunt is SSL / TLS handiger en gemakkelijker omdat het alleen een browser en een openbaar of privé-certificaat vereist.

En SSH vereist dat de applicatie of de thin client is geïnstalleerd om het te gebruiken. Dat is meer een probleem vanuit het perspectief en de ondersteuning van een internetclient van de gebruiker.