SSH, SSL en HTTPS
Johnny Schaap (3665224)
Inhoudsopgave 1. Inleiding
………………………………………………………………………………………………………… pagina 2
2. SSL/TLS …..………………………………………………………………………………………………………… 2.1. Geschiedenis ……………………………………………………………………………………………. 2.2. API en Sockets …………………………………………………………………………………………… 2.3. Verbinding ………………………………………………………………………………………………… 2.4. Message Authentication Code(MAC) …………………………………………………………. 2.5. Certificaten(PKI) ……………………………………………………………………………………….. 2.6. Zwakheden ………………………………………………………………………………………………
pagina 3 pagina 3 pagina 3 pagina 3 pagina 5 pagina 5 pagina 5
3. HTTPS ……………………………………………….……………………………………………………………… pagina 7 3.1. Geschiedenis …………………………………………………………………………………………….. pagina 7 3.2. Valide Webpagina’s …………………………………………………………………………………… pagina 7 3.3. SSL/TLS en Certificaten(PKI) ..…………………………………………………………………….. pagina 7 3.4. Zwakheden ………………………………………………………………………………………………… pagina 7 4. SSH ……………………………………………………………………………………………………………………. 4.1. Geschiedenis .……………………………………………………………………………………………. 4.2. Authenticatie……………………………………………………………………………………………… 4.3. Gebruik en Werking …………………………………………………………………………………… 4.4. Zwakheden ..……………………………………………………………………………………………….
pagina 10 pagina 10 pagina 10 pagina 10 pagina 11
5. Conclusie …………………………………………………………………………………………………………… pagina 12 6. Bronnen ……………………………………………………………………………………………………………. pagina 12
1
1. Inleiding Wanneer een apparaat verbinding maakt met een netwerk of het internet, zijn er een aantal protocollen die van belang zijn om de communicatie tussen twee apparaten te doen verlopen. De communicatie is opgesplitst in zeven lagen (volgens het OSI-model) die samen het doel hebben om data over te brengen. Deze zeven lagen heten: Applicatie-, Presentatie-, Sessie-, Transport-, Netwerk, Datalink- en Fysieke laag. Natuurlijk kan deze data versleuteld worden en is authenticatie van het apparaat nodig. Deze twee dingen worden vooral in de applicatie- en presentatielaag geregeld. Het Secure Sockets Layer (SSL) protocol is een encryptie protocol. Dit protocol werd verbeterd en later omgedoopt tot Transport Layer Security (TLS). Het protocol wordt gebruikt om onder andere de server te authentiseren. Dit wordt gedaan door middel van certificaten. Wanneer is vastgesteld dat de server echt is wie hij zegt dat hij is, vindt de communicatie tussen de server en cliënt plaats via symmetrische cryptografie in de vorm van block-cipher. De sleutel voor deze communicatie wordt door middel van asymmetrische cryptografie afgesproken. Bij TLS kan de programmeur zelf kiezen welk cryptografisch algoritme hij wilt gebruiken. Het Hypertext Transfer Protocol Secure (HTTPS) is eigenlijk een HTTP-verbinding bovenop een SSLverbinding. Hierbij verstuurt de webserver dus zijn gegevens naar de webcliënt door middel van de encryptie die gebruikt wordt in het SSL/TLS protocol. Het nadeel van HTTPS tegenover HTTP is dat bij HTTPS de hele pagina moet worden geladen. Bij HTTP kan de cliënt de pagina opbouwen uit de gegevens die zijn opgeslagen in de cache. Bij HTTPS moet dus alle data over het netwerk worden verstuurd en ontcijferd worden. Met Secure Shell (SSH)-protocol is het mogelijk commando’s van één apparaat aan een ander apparaat te geven. Omdat we niet willen dat elk willekeurig persoon commando’s kan geven, wordt gebruik gemaakt van authenticatie door middel van asymmetrische cryptografie. Commando’s worden ook versleuteld. Naast het versturen van commando’s ondersteunt SSH ook Tunneling, Port Forwarding en File Transfer.
2
2. SSL/TLS Secure Socket Layer (SSL) is een protocol dat wordt gebruikt om een TCP-verbinding binnen een netwerk te beveiligen. De opvolger van SSL, Transport Layer Security (TLS), is gestandaardiseerd door het Internet Engineering Task Force (IEFT). Het protocol dat hier wordt behandeld is de nieuwste versie van TLS. Het verschil tussen SSL en TLS is dat men bij TLS zelf bepaalt welk algoritme men gebruikt voor de sleuteluitwisseling. SSL gebruikt namelijk standaard Diffie-Hellman.
2.1 Geschiedenis SSL is ontwikkeld door Netscape en is gebaseerd op eerdere TCP-beveiligingen, zoals Woo. TCP verbindingen zijn verbindingen die vooraf eerst een hand-shake-fase doen en zijn verbinding georiënteerd. SSL wordt tegenwoordig ondersteund door alle (populaire) webbrowsers. Bijna alle betalingen over het web wordt tegenwoordig gedaan met behulp van een SSL-protocol. Een webpagina die gebruik maakt van SSL is te herkennen aan de URL. Die begint namelijk met “https:” in plaats van “http:”.
2.2 API en Sockets TLS heeft een simpele Application Programmer Interface (API) die gebruik maakt van sockets (een methode om communicatie tussen verschillende processen te laten verlopen, bijvoorbeeld over het internet). In feiten wordt met TLS een extra sublaag in het OSI-model toegevoegd. We krijgen namelijk tussen de applicatie- en transportlaag een extra socket (de TLS-socket) gevolgd door de TLS sublaag. Hierna komt er zoals bij een normale verbinding een TCP-socket en dan de transportlaag. Er zijn enkele libaries beschikbaar op het internet te vinden om je applicatie te beveiligen met een TLSprotocol.
2.3 Verbinding TLS heeft drie fases waarin het protocol werkt om een verbinding aan te gaan. Deze zijn: Hand shake, key derivation en Data Transfer.
Figuur 2.1: Een SSL-verbinding opzetten. 3
Bij de hand-shake-fase wil Alice een verbinding aangaan met Bob. Hoe dit gebeurt, is te zien in figuur 2.1. Hierbij moeten drie dingen gebeuren, namelijk: -
Er moet een TCP-verbinding worden gemaakt met Bob. (Verbinden) Alice moet kunnen verifiëren dat Bob echt Bob is. (Authentiseren) Alice moet Bob een hoofdsleutel sturen die ze beide zullen gebruiken om sleutels te generen voor deze verbinding. De sleutels die zij zullen genereren zullen gebruikt worden voor symmetrische cryptografie en berichtauthenticatie. (sleutel management)
In de verbindingsfase stuurt Alice dus een verzoek voor een TCP-verbinding, waarna Bob de verbinding accepteert. Tijdens deze fase wordt er ook een keuze gemaakt uit een beveiligings- en MAC-algoritme (zie 2.4 voor uitleg) die beide apparaten ondersteunen. Alice stuurt hier een lijst van algoritmes die zij ondersteunt plus een nonce. Bob stuurt de gekozen algoritmes terug plus een certificaat en een nonce. Deze nonces zijn unieke nummers en gebruikt worden zodat er geen ‘connection replay attack’ gedaan kan worden. In de authenticatiefase controleert Alice het certificaat van Bob. Dit certificaat is ondertekend dus Alice weet zeker dat Bob ook echt Bob is. Het certificaat bevat tevens de publieke sleutel van Bob. Alles over de werking van het certificaat is te vinden in paragraaf 2.5. In de sleutelmanagementsfase genereert Alice een hoofdsleutel die dan versleuteld wordt met Bob’s publieke sleutel. Deze wordt dan verstuurd naar Bob en hij ontcijfert deze met zijn geheime sleutel. Zo weten ze beide de hoofdsleutel die gebruikt wordt voor deze TLS sessie. Bij de key derivation-fase genereren Bob en Alice allebei vier sleutels aan de hand van de eerdere genoemde hoofdsleutel. Ze genereren een EA en EB, waarbij EA is bedoeld voor de datastroom van Alice naar Bob te versleutelen en EB voor de datastroom van Bob naar Alice te versleutelen. Ook genereren ze MA en MB (De MAC-sleutels). Deze laatste twee worden gebruikt om de integriteit van het bericht te verifiëren. Als er gebruik gemaakt wordt van Cipher Block Chaining moeten er ook nog twee initialisatie vectoren gegenereerd worden. Om er zeker van te zijn dat de ‘hand shake’ acties niet aangepast zijn door Oscar, sturen Alice en Bob ook nog een MAC van al hun hand-shakeberichten. In de data transferfase wordt de data in kleine stukjes geknipt en bij elk stukje wordt de MAC eraan geplakt. Ook wordt er nog een sequencenummer bij de MAC toegevoegd. Dit laatste wordt gedaan zodat Oscar niet de volgorde van de pakketjes kan veranderen of pakketjes er dubbel kan inzetten. Elk stukje wordt daarna door een hashfunctie gehaald en deze wordt samen met het originele bericht verstuurd. Elk pakketje heeft een type (hand shake of applicatie data), versie (van TLS), lengte (van data), data en een MACstukje. Hiervan worden de laatste twee stukjes versleuteld. Om de TCP-verbinding (en dus ook de TLS -verbinding) te sluiten, moet Bob een TCPFIN-bericht sturen. Deze is niet versleuteld en kan dus door Oscar worden verstuurd. Dan wordt de verbinding dus verbroken voordat alle data binnen is. Om dit te voorkomen wordt er voor een TCPFIN-bericht eerst een TLS-datablock verstuurd waarin staat dat de verbinding verbroken (Closure) wordt. Wordt TCPFIN voor de TLS-closure ontvangen, dan weet Alice dat er iets niet klopt.
4
2.4 Message Authentication Code(MAC) Message Authentication Code(MAC) wordt gebruikt om te kunnen verifiëren of de data die ontvangen is niet is aangepast door een man-in-the-middle. Wat de zender als het ware doet is zijn bericht b plus sleutel k hashen met bijvoorbeeld SHA-1. De zender stuurt vervolgens zijn bericht b samen met de gehashte waarde van (b, k) naar de ontvanger, dus (b, H(b, k)). Als de ontvanger het bericht ontvangt zal hij (b, k) hashen. Wanneer de berekende H(b, k) niet overeenkomt met de ontvangen H(b, k), betekent dit dat het bericht b niet klopt. Hieruit kunnen we concluderen dat iemand het bericht heeft veranderd (het is natuurlijk ook mogelijk dat er een aantal bits zijn omgevallen, maar over het algemeen zal er error correctie plaatsvinden in deze gevallen). Echter kan Oscar, onze man-in-the-middle, zelf een b verzinnen en de bijbehorende H(b, k) berekenen. Dat is waar encryptie van pas komt. Omdat in TLS het bericht(b) en het gehashte bericht(MAC) allebei ook nog eens worden versleuteld, kan Oscar niet zijn eigen gekozen bericht b en de bijbehorende MAC verzenden. Hij moet het eerst versleutelen. Dit kan niet want hij weet de juiste sleutel niet. Wat hij nog wel kan doen is wat waardes veranderen in het versleutelde bericht die Bob naar Alice stuurt. Omdat hij de bijbehorende MAC niet kan toevoegen (want hij weet het originele bericht b niet, hij kan H(b, k) niet berekenen zonder (b, k) en kan hij deze H(b, k) niet juist versleutelen zonder de sleutel), weet de ontvanger dat er iemand het bericht heeft veranderd en het bericht dus niet klopt.
2.5 Certificaten (PKI) De certificaten zijn van cruciaal belang. Maar wat is een certificaat nu eigenlijk? Een certificaat heeft een aantal gegevens. Zo bevat deze de naam van de eigenaar, zijn publieke sleutel, de geldigheidsduur, de uitgever van het certificaat (de Certificate Authority (CA)), de locatie van de Certificate Revocation List (een lijst met alle ongeldige certificaten) en een versleuteling (met de private sleutel van de CA) van gehashte bovenstaande gegevens. Dit laatste is als het ware het watermerk. Dit watermerk is te controleren door zelf de eerdere gegevens te hashen, daarna met de openbare sleutel van de CA het watermerk te ontcijferen en als laatste de beide uitkomsten te vergelijken. Wanneer deze niet overeen komen, is het geen geldig certificaat. Eigenlijk bestaat er een ketting van certificaten. De root CA heeft een certificaat uitgegeven aan een kind, ook wel tekenen genoemd. Deze kan vaak ook certificaten uitgeven. Dit zijn dan intermediaire CA’s. De webpagina waarvan we het certificaat wil valideren is dan het bladcertificaat. De meeste browsers accepteren een ketting van maximaal 20 CA’s. Wat er gebeurt bij het valideren, is eigenlijk naar de laag boven het huidige certificaat kijken en controleren of het een geldig certificaat is. Weet deze laag het ook niet, dan wordt er in een laag daarboven gekeken tot we bij de root zijn gekomen. Uiteindelijk weten we dan of een certificaat echt is of niet.
2.6 Zwakheden Omdat TLS met certificaten werkt, kan men zich niet zomaar voordoen als een ander. Door de werking van de certificaten kan het certificaat ook niet worden vervalst. Wat echter nog wel mogelijk is, is een eigen certificaat uitgeven en zelf dienen als intermediaire CA. Wanneer er een certificaat wordt uitgegeven, staat er in dat certificaat ook een booleaanse waarde waarin staat of deze ook 5
andere certificaten mag uitdelen. Bij wat oudere implementaties van TLS en bij SSL wordt er geen check gedaan op deze waarde. Wanneer er een valide website, zeg www.example.nl, een certificaat heeft, kan deze een certificaat uitgeven voor, zeg www.paypal.com. Wanneer we onszelf als server van paypal.com voordoen en de door ons gemaakte certificaten sturen, wordt er bij de CA example.com gekeken of het certificaat geldig is. Omdat wij ook de CA zijn, kunnen wij zeggen dat het certificaat geldig is. Hierdoor kunnen wij dus eigenlijk de cliënt laten denken dat wij de server zijn voor paypal.com en gaan zij een SSL-verbinding met ons aan. Dit is precies wat de SSLsniff-applicatie, gemaakt door toughtcrime, doet. In figuur 2.2 zien we een certificaat keten waar er een vals certificaat wordt uitgegeven. Deze aanval is nog succesvol op oudere implementaties, maar in de nieuwere implementaties wordt gekeken of de laag erboven wel een certificaat mocht uitgeven door een check te doen op de booleaanse waarde.
Daarnaast is er een hand-shake-situatie nodig, waarin alles in plaintext verstuurd wordt. Bovendien kan de bestemming van pakketjes niet versleuteld worden, omdat het dan niet duidelijk is waar het heen gestuurd moet worden over het netwerk. Hierdoor kun je weten tussen wie, en hoe lang, er data wordt verstuurd.
Figuur 2.2: Een certificaat keten met een vals certificaat. Het rode certificaat en de rode pijl zijn acties en entiteiten die eigenlijk niet mogen.
6
3. HTTPS Hypertext Transfer Protocol Secure (HTTPS) is een combinatie van twee ander bestaande protocollen. Het huidige HTTP-protocol wordt namelijk uitgebreid met een TLS-verbinding. Bij het HTTP-protocol worden de gegevens in plaintext verstuurd. HTTPS zorgt er voor dat de gegevens versleuteld worden. Tegenwoordig wordt HTTPS alleen toegepast bij hoge-risico-pagina’s zoals betalingen omdat het versleutelen en ontcijferen veel processingtijd kost. Bovendien kan men bij HTTP de gegevens uit een cache laden en is dit niet het geval bij HTTPS. Dit zorgt ervoor dat HTTPS voor meer dataverkeer en processingtijd zorgt.
3.1 Geschiedenis De geschiedenis van HTTPS is eigenlijk hetzelfde als die van TLS. HTTP bestond al een tijdje, en omdat Netscape beveiligde dataoverdracht wilde hebben voor hun webbrowsers, werd HTTP gecombineerd met het door Netscape ontwikkelde SSL. Hierdoor ontstond HTTPS. HTTPS zoals we die nu kennen verschilt alleen in de SSL-verbinding die gebruikt wordt. Dit is namelijk niet meer de oorspronkelijke SSL, maar de nieuwe, verbeterde TLS.
3.2 Valide Webpagina’s De bedoeling van HTTPS is om door middel van SSL/TLS veilig informatie versturen over een onveilig kanaal. Hier is het erg belangrijk dat authenticatie plaatsvindt van de server. Dit gebeurt door certificaten die door CA’s (Certificate Authorities) zijn uitgegeven. De meeste browsers zijn zo geïmplementeerd dat zij een waarschuwing geven wanneer er een certificaat wordt gestuurd dat niet overeenkomt met wie de server claimt te zijn.
3.3 SSL/TLS en Certificaten(PKI) Zoals al eerder gezegd kan men zien wanneer een HTTPS-protocol wordt gebruikt. Wanneer dit het geval is begint de URL met “https://”. Omdat er een verbinding moet worden gemaakt voordat de SSL/TLS een verbinding kan opzetten, weet de man-in-the-middle wel wie er met elkaar aan het communiceren zijn aan de hand van de IP-adressen en de domeinnaam. De inhoud van de berichten is echter onbekend. Het is natuurlijk belangrijk dat men een certificaat heeft. Maar hoe komt men nou aan een dergelijk certificaat? Er zijn een aantal mogelijkheden. Men kan naar een CA gaan om een certificaat te krijgen of kopen, ze kunnen een eigen CA maken of ze maken gebruik van een peerto-peer CA. Soms wil de server ook nog authenticatie hebben van de cliënt, zodat niet iedereen alles kan zien. Dit wordt gedaan met behulp van namen, emailadressen, wachtwoorden etc.
3.4 Zwakheden Een zwakheid van HTTPS is vergelijkbaar met die van SSL/TLS. Net als bij SSL/TLS is hier namelijk ook een hand-shake-fase nodig. Dus ook hier kan men, vanwege de plaintext in deze fase, weten hoe lang, en tussen wie, er data wordt verstuurd.
7
Een andere zwakheid zit hem in een psychologisch aspect. Mensen bezoeken vaak een HTTPS-pagina via een link op een HTTP-website. Mensen typen vaak niet “https://” voor hun URL. Dit zorgt er voor dat ze automatisch naar een “http://” website gaan. Op die website zit vaak een button die de cliënt doorstuurt naar de “https://” website. Echter kijkt nooit iemand naar deze URL, en kan men deze ook niet zomaar zien bij een button. Wat men hierop heeft bedacht is feedback. Men maakte eerst gebruikt van positieve feedback (zoals een veiligheidsicoontje en andere feedback in de browser zelf), maar tegenwoordig wordt ook negatieve feedback gebruikt (bijvoorbeeld een waarschuwing in de browser wanneer er een vals certificaat wordt verstuurd). Vaak klikken mensen dit alsnog door omdat ze geen idee hebben wat dit inhoudt. Wat we dus kunnen doen is de cliënt naar onze server doorsturen, een vals certificaat afgeven en, omdat men de waarschuwing toch weg klikt, de SSLverbinding met ons aan te laten gaan. Een aanval met een technischer aspect is een man-in-the-middle aanval. Wat we hierbij doen is al het verkeer dat voorbij komt doorsturen naar de server. Zodra de cliënt een SSL-verbinding aanvraagt (dus een “https://” aanvraag) gaat Oscar een SSL-verbinding aan met de server in naam van de cliënt. Oscar stuurt de cliënt echter een http:// versie van de aanvraag terug naar de cliënt. Zo komt al de informatie die de cliënt stuurt naar Oscar in plaintext en stuurt hij deze door via de SSLverbinding naar de server. Hierdoor komt er geen negatieve feedback meer. De valse positieve feedback kunnen we alleen op de webpagina zelf geven (door middel van tekst en icoontjes) en niet in de browser. Waar we nu nog wel omheen moeten werken zijn de cookies en caches. Men kan namelijk al eens eerder hebben ingelogd en door middel van cookies kan men dan inloggen zonder het wachtwoord te geven. Hier kunnen we omheen komen door alle cookies een TTL geven. Als wij dan de verbinding overnemen, sturen we een bericht naar de cliënt om de cookies te verwijderen nadat hun TTL is verlopen. Zo moet men na een tijdje hun wachtwoord alsnog invullen. Zo verkrijgt Oscar ongemerkt de wachtwoorden. Dit is precies wat de SSLStrip-applicatie van thoughtcrime doet. Dit kun je zien in figuur 3.1. Er is echter nog één probleem. Dat is namelijk de positieve feedback die de browser en de URL geeft. De URL bevat namelijk geen “https://” link en de browser geeft geen positieve feedback(geen groene adres balk als er een SSL verbinding is). Hier is een oplossing voor.
Figuur 3.1: De werking van SSL Strip. 8
Om dit op te lossen moeten we eerst een andere aanval bespreken. Dit zijn de zogenaamde Homograph-attacks. Wat men hierbij doet is een website maken waarbij de URL hetzelfde oogt als de originele webpagina en vraagt hiervoor een certificaat aan. Een simpel voorbeeld is paypai.com. Wanneer je de ‘i’ als hoofdletter typt, ziet men vaak het verschil niet en kun je de website nabouwen. Een wat subtielere aanpak is om de ‘/’-es in de URL te vervangen. Er zijn namelijk heel veel andere tekens die hierop lijken. Als Oscar deze link op zijn pagina plaatst, en de cliënt klikt deze aan, zal de cliënt denken dat hij op een “https://” webpagina zit van bijvoorbeeld paypal.com/inloggen terwijl deze eigenlijk gewoon een kopie is. Zo kan Oscar alle gegevens ontvangen die hij kiest. Echter is dit een gerichte aanval en kan men vaak niet alle data maar een gericht deel van de data onderscheppen. Een combinatie van de vorige twee is een aanval die een ernstig probleem oplevert. Als men de echte “https://” vervangt door een zelfgemaakte “https://” webpagina in plaats van de “http://” versie van de echte pagina, zal ook de browser positieve feedback geven. De cliënt denkt dat hij met de echte website communiceert via een SSL-verbinding. Oscar heeft dus alle informatie die in real time wordt verstuurd. Een voordeel is dat Oscar ook weer de verbinding kan verbreken wanneer hij heeft wat hij nodig heeft en, zonder dat ze het door hebben, communiceren de cliënt en de echte server met elkaar verder. Bij een test door thoughtcrime bleek iedereen voor deze aanval te vallen. Wat kunnen we tegen deze aanvallen doen? We kunnen ten eerste al het dataverkeer in een netwerk laten verlopen via HTTPS. Echter kost dit heel veel processingtijd en wil men dit niet. Bovendien zijn er wat minder populaire browsers die niet eens SSL/TLS ondersteunen. Een andere oplossing is cliënt certificaten te gebruiken. Dit is echter een praktisch onmogelijke taak.
9
4. SSH Zoals in de inleiding is gezegd zorgt het Secure Shell-protocol (SHH) ervoor dat men commando’s van één apparaat aan een ander apparaat kan geven via een shell. Een shell is in principe een interface. We praten hier voornamelijk over command-line shell, maar is ook toe te passen op graphical shells. Om er zeker van te zijn dat niet iedereen elk apparaat kan bedienen wordt er gebruikt gemaakt van authenticatie door middel van asymmetrische cryptografie. Het gevolg is dat er geen wachtwoord gehardcoded hoeft te worden. Er is natuurlijk wel de mogelijkheid om een wachtwoord op de server te zetten voor extra veiligheid. Het programma dat op de cliënt, Alice, draait wordt ook SSH genoemd. Het programma dat op de server draait heet SSHD (Secure Shell Daemon).
4.1 Geschiedenis SSH is ontwikkeld door een Finse onderzoeker nadat er een password-sniffing attack werd gedaan op de universiteit waar hij werkte. Zijn doel was om de wachtwoorden die over het internet werden verstuurd, te versleutelen zodat een afluisteraar niet achter het wachtwoord kan komen. Deze versie werd gauw wereldwijd gebruikt maar over de jaren bleken er drie zwakheden in het ontwerp te zitten. Men kon namelijk data toevoegen aan de datastroom, men kon het laatste blok van 3DES aanpassen en een tussenliggende kwaadwillende server kon authenticatie naar de echte server doorsturen, waardoor deze toegang krijgt tot de server. Men ontwikkelede Open SSH, wat eigenlijk gewoon een open source versie is van SSH. Omdat de huidige versie van SSH een aantal zwakheden had werd deze aangepast. Versie 2 had een betere manier om sleutels te delen, deze kon men namelijk nu zelf kiezen, en werd er MAC (zie 3.4 voor uitleg) gebruikt voor het controleren of de data niet aangepast werd.
4.2 Authenticatie Authenticatie vindt plaats door middel van asymmetrische cryptografie. De server stuurt een random nummer, versleuteld met de publieke sleutel van de cliënt, naar de cliënt. De cliënt stuurt daarna dit random nummer terug naar de server(deze is natuurlijk ook versleuteld). Wanneer blijkt dat dit nummer niet klopt, blijkt dat de cliënt niet de eigenaar is van de publieke sleutel, en krijgt deze dus geen toegang tot de server. De toegestane publieke en private sleutels staan opgeslagen in een file en de gebruiker kan deze zelf aanpassen.
4.3 Gebruik en Werking SSH wordt tegenwoordig voornamelijk gebruikt om commando’s te sturen naar een ander apparaat. Dit wordt gedaan via een shell. Andere features die SSH heeft is Tunnel en Port Forwarding. Bovendien ondersteunt het X11-verbindingen en kan SSH veilig grotere blokken data versturen door middel van SSH-filetransfer of Secure-copy-protocollen.
10
In principe heeft SSH drie lage: Transport-, User Authenticatie- en connectielaag. De transport laag zorgt ervoor dat de sleutel wordt verstuurd en dat de server geauthentiseerd wordt. Tevens stuurt deze laag een nieuwe sleutel na een bepaalde tijd of aantal bytes. De user authenticatielaag vraagt om een authenticatie van de cliënt. Dit wordt gedaan door bijvoorbeeld wachtwoorden, publieke sleutels of keyboardinteractie. In de connectie laag worden er kanalen aan gemaakt waarover data kan worden verstuurd. Hier zijn drie verschillende type kanalen: direct-tcpip (cliënt-to-server), forwarded-tcpip (server-to-cliënt) en shell (terminal shells).
4.4 Zwakheden Een zwakheid in SSH ligt in de authenticatie. De SSH-server kan namelijk ook vragen om een wachtwoord. Door middel van een man-in-the-middle aanval kan Oscar zich voordoen als de server. Omdat authenticatie plaatsvindt via asymmetrische cryptografie, kan Oscar zeggen dat hij de server is en de publieke sleutel van zichzelf geven. Als de cliënt dat het wachtwoord stuurt naar Oscar, kan hij dit ontcijferen. Zo heeft hij het wachtwoord en kan hij inloggen op de echte server en doen wat hij wil. Deze aanval is echter niet mogelijk wanneer de server en cliënt ooit eerder met elkaar hebben gecommuniceerd want SSH onthoudt de sleutels van het apparaat waarmee is gecommuniceerd.
11
5. Conclusie SSL/TLS, HTTPS en SSH zijn gestandaardiseerde protocollen die wereldwijd worden gebruikt. Alle drie zijn ze redelijk betrouwbaar. SSL/TLS beveiligen de TCP-verbinding door een sleutel uit te wisselen via asymmetrische cryptografie en vervolgens te communiceren met een symmetrisch cryptografisch algoritme. HTTPS is eigenlijk een HTTP-verbinding die SSL/TLS gebruikt om zijn HTTP-elementen te verzenden. SSH is een protocol dat ervoor zorgt dat één apparaat in het netwerk een ander kan besturen door middel van commands in een shell. Echter zijn de SSL/TLS soms nog wel kwetsbaar voor aanvallen waar Oscar valse certificaten uitgeeft. Dit komt omdat bij sommige implementaties van autorisatie controle niet wordt gekeken of degene die het certificaat heeft uitgegeven ook werkelijk een certificaat mocht uitgeven. De oplossing is er al, en zolang iedereen de nieuwe implementatie gebruikt, is dit geen probleem. Vooral HTTPS is erg kwetsbaar. Oscar kan met een man-in-the-middle attack in combinatie met een Homograph-attack de gebruiker aan de cliënt kant compleet voor de gek houden. Zo kan Oscar alle gegevens zien die worden verstuurd door de cliënt. Op het moment is de enige oplossing alle verbindingen over HTTPS te laten verlopen zodat we niet via de HTTP onze aanval kunnen starten of we kunnen cliënt certificaten gebruiken. Beide zijn echter niet praktisch en het kost te veel onnodige processingtijd en moet er veel meer data over het netwerk worden verstuurd. Ook SSH is niet zonder zwakheden. Door spoofing kan men namelijk de wachtwoorden onderscheppen. Ook hier is een oplossing voor. Dit is namelijk user authenticatie gebruiken op een andere manier dan wachtwoorden.
6. Bronnen Kurose J.F. & Ross K.W. (2009) “Computer Networking: A top down approach”, Addison-Wesley. M. Marlinspike, “SSLSnif”, http://www.thoughtcrime.org/software/sslsniff/ M. Marlinspike, “SSLStrip”, http://www.thoughtcrime.org/software/sslstrip/ , on Blackhat 2009. CERT, “Multiple Vulnerabilities in SSH Implementations“, http://www.cert.org/advisories/CA-200236.html “HTTP Secure”, http://en.wikipedia.org/wiki/HTTP_Secure “Secure Shell”, http://en.wikipedia.org/wiki/Secure_Shell “Secure Socket Layer”, http://en.wikipedia.org/wiki/Secure_Socket_Layer “OSI”, http://en.wikipedia.org/wiki/OSI “Certificaat (PKI)”, http://nl.wikipedia.org/wiki/Certificaat_(PKI) “Certificate Revocation List”, http://nl.wikipedia.org/wiki/Certificate_revocation_list
12
