Het SSH Protocol Oriëntatie Richard Peters, augustus 2002

Transcriptie

1 Het SSH Protocol Oriëntatie Richard Peters, augustus 2002

2 Index Het SSH Protocol...1 Index...2 Inleiding...4 Protocol versie...4 Localization...5 Algemene definities/concepten...5 Pakket...5 Datatypes...5 Algoritme en protocol benamingen...6 Genereren van random data...6 De Transport layer...7 Concepten...7 EncryptionAlgorithm...7 PublicKeyAlgorithm...7 MACAlgorithm...7 CompressionAlgorithm...7 KeyExchangeAlgorithm...7 Host key...8 Algemeen...8 Initialisatie...8 Algoritme onderhandeling...8 Sleutel onderhandeling...9 In gebruik nemen van sleutels...9 Details...10 Initialisatie...10 Binair protocol...10 Algoritme onderhandeling...11 Sleutel onderhandeling...13 In gebruik nemen van sleutels...14 De connectie is gereed...14 Services aanvragen...14 De verbinding verbreken...14 Negeer data...15 Debug berichten...15 Onbekende pakketten...15 Bericht nummers...16 Algoritmes...16 Encryptie...16 Integriteit...17 Compressie...17 Key Exchange...17 Public Key Algoritmes...19 Het User Authentication protocol...21 Authenticatie methodes...21 Methode: none...21 Methode: publickey...21 Methode: password...21 Methode: hostbased

3 De Connection layer...22 Kanalen...22 Sessie...22 TCP/IP Forwarding...22 X11 kanalen...22 Problemen...23 Een KeyExchangeAlgorithm dat een PublicKeyAlgorithm nodig heeft dat kan signen én encrypten...23 Het gebruik van disconnection reason codes is niet gespecificeerd...23 Algoritme onderhandeling is niet transparant...24 Het coderen van een hash als mpint...24 C-stijl definities...24 Niet gebruiken van namelist...25 Sommige algoritmes zijn verplicht...25 Referenties...26 Appendix A: Een voorbeeld...28 Appendix B: RSSH

4 Inleiding Het SSH protocol is een protocol dat gebruikt wordt voor het maken van veilige connecties tussen twee computers (server/client). De veel gebruikte TCP/IP connecties vormen geen bescherming tegen afluisteren en het veranderen van data door de verkeerde personen. Ook is er bij een gewone TCP/IP connectie geen zekerheid over of degene aan de andere kant van de connectie wel echt degene is wie je denkt dat hij is. Het SSH protocol lost al deze problemen op. SSH is bedoeld om bovenop een betrouwbare (pakketten gaan niet verloren en komen in de juiste volgorde aan) verbinding te draaien, deze verbinding is in de praktijk TCP/IP. Op dit moment wordt SSH het meest voor remote shell access gebruikt, als Secure Shell, waar de naam SSH vandaan komt. Het is een vervanger voor de unix programmas rsh, rlogin, telnet, etc. Verder wordt het ook voor secure file transfer gebruikt, en als tunnel voor normale TCP/IP connecties, zodat programma s die alleen over TCP/IP werken van SSH gebruik kunnen maken, waardoor die connecties dezelfde beveiliging krijgen als het SSH protocol. Het SSH protocol bestaat uit verschillende lagen: De Transport layer: deze verzorgt 1) vertrouwelijkheid, zodat niemand anders data kan afluisteren van de connectie. 2) integriteit, je bent er zeker van dat de data die je ontvangt ook echt door de server verstuurd is, en niet door een derde gegenereerd is (door bijvoorbeeld bogus tcp pakketten te versturen). 3) server authenticatie, zodat de client zeker weet dat hij een connectie met de server heeft. Dit verhindert zogenaamde Man-in-the-middle attacks. Het User Authetication protocol: Dit protocol biedt verschillende manieren voor de client om zichzelf te authenticeren aan de server. Dit protocol draait bovenop de Transport layer. De Connection layer: De Transport layer maakt een beveiligde tunnel aan voor data. De Connection layer maakt meerdere kanalen aan, allemaal met hun eigen eigenschappen, en zorgt dat data bestemd voor één van deze kanalen aan de andere kant van de connectie in het goede kanaal er weer uit komt. Dit heet multiplexing. De Connection layer draait bovenop de Transport layer en wordt gestart door het User Authentication protocol. Kanaal protocollen, zoals een shell, een file transfer protocol, of een getunnelde TCP/IP connectie. Deze opdeling in verschillende lagen maken het protocol makkelijk te implementeren en uit te breiden. Voor bedrijf-specifieke uitbreidingen zijn steeds methoden aangegeven waarop de bedrijven hun eigen algoritmes/protocollen toe kunnen voegen. Zodoende kan een bedrijf zijn eigen encryptie protocol gebruiken, zonder dat iemand met een client zonder deze extensies opeens niet meer werkt. Protocol versie Op dit moment zijn er twee versies van SSH, versie 1 en 2. Versie 1 schijnt onveilig te zijn en wordt daarom vaak niet meer ondersteund. Versie twee wordt door het ietf (internet engineering taskforce) beschreven in internet- 4

5 drafts, later zullen hier RFC (Request For Comments) pagina s van gemaakt worden. Het protocol dat ik beschrijf is beschreven in deze internet-drafts. Localization Voor het grootste gedeelte wordt over het SSH protocol binaire data gestuurd die door server en client geinterpreteerd worden. In sommige gevallen echter, wordt tekst gestuurd die direct voor de gebruiker is bestemd. Op die plaatsen is de taal meestal instelbaar, de server hoeft echter niet jouw taal te ondersteunen. De internet-draft zegt op al deze plaatsen dat beide kanten de talen en teksten mogen negeren, op een enkele plaats wordt het gebruik ervan zelfs sterk afgeraden. Omdat het eigenlijk nooit voorkomt dat het nuttig is om tekst van de server direct aan de user te tonen, zal ik in dit document verder geen aandacht besteden aan localization. Algemene definities/concepten Pakket Een pakket bestaat uit informatie dat verstuurd wordt over het SSH protocol. De informatie bestaat uit één of meer velden, elk veld is data van een bepaald type. Datatypes Hier wordt beschreven hoe data van een bepaald type wordt opgeslagen en vervolgens verstuurd. boolean: representeert de waardes true en false. True wordt als de waarde 1 opgeslagen, false als 0, beide van het type uint8. uint8: representeert een 8-bits niet-negatief getal. Dit wordt in de tekst een byte genoemd. Als er uint8[n] wordt gebruikt, betekent dit n keer een uint8. uint32: representeert een 32-bits niet-negatief getal. Een waarde wordt opgeslagen als vier uint8 s volgens de big-endian methode: Het meest significante uint8 krijgt de minst significante plaats, etc. string: representeert een rij van variabele lengte van uint8 waardes. De lengte van de string is minimaal 0, maximaal De lengte wordt als een uint32 opgeslagen, daarachter wordt de data geplakt. mpint: deze multiple-precision integer representeert een integer van virtueel ongelimiteerde lengte. Hij wordt opgeslagen in two s complement formaat, voorafgegaan door zijn lengte, de lengte is een uint32 veld. Voorbeelden: o De waarde nul heeft als lengte 0, dit betekent dat er één uint32 wordt opgeslagen met de waarde 0, of de vier uint8 s o De waarde 8 is in één uint8 op te slaan, dus de lengte is 1. De opgeslagen waarde wordt dus o De waarde 255 is niet zo op te slaan: , want dit is gelijk aan het getal 1. Er moet dus een nul voor worden gezet, zodat de lengte 2 wordt. De data wordt namelist: representeert een lijst van namen, gescheiden door komma s. Een naam moet een lengte groter dan nul hebben, en mag geen komma bevatten. In het protocol wordt de namelist alleen voor 5

6 benamingen van algoritmes en subprotocollen gebruikt, en niet voor binaire data, zodat de restrictie dat een naam geen komma mag bevatten geen problemen oplevert. block: representeert 1 of meerdere velden. Het formaat van het block wordt door de omstandigheden gespecificeerd. Een block dat bestaat uit bv. een string en een uint32 wordt verkregen door de string te pakken en daar de uint32 gewoon achter te plakken. Algoritme en protocol benamingen De gebruikte algoritmes en protocollen hebben ieder hun eigen naam. Een naam zal minstens 1 karakter hebben en niet langer zijn dan 64 karakters. Al deze karakters zullen printbare USASCII zijn, en de naam is case-sensitive, zodat zlib een andere naam is als ZLIB. Ook mogen ze geen komma bevatten. Alle mogelijke namen die bevat, zijn gereserveerd door de IETF. Alle mogelijke namen die bevatten, zijn te gebruiken door andere personen. Het formaat van deze namen is naam@dnsnaam, waabij dnsnaam eigendom is van de persoon die de naam gebruikt. Op deze manier kunnen er geen botsingen ontstaan doordat verschillende personen dezelfde naam hebben gekozen voor een algoritme dat anders werkt. Genereren van random data In de Transport layer worden er tijdelijke sleutels gegenereerd voor de verschillende algoritmes. De informatie die nodig is om die sleutels te maken, is voor een deel random data, die door elke partij zelf gegenereerd moet worden. Het is zeer belangrijk dat hiervoor goed random number generators (rng s) worden gebruikt. Het beste is om non-deterministische rng s te gebruiken, maar die zullen vaak niet aanwezig zijn. Met een voldoende grote entropie is het best mogelijk om deterministische rng s te gebruiken. Het is verleidelijk om de C library functie rand() te gebruiken, deze heeft een toestand van 2 32, dit is echter veel te weinig voor een fatsoenlijke initialisatie van je sleutels. Een afluisteraar kan gewoon elke toestand van de rng proberen en zien of de sleutels kloppen. Een Mersenne twister met een toestand van is al een veel betere keus. Zo n rng moet dan ook nog geinitialiseerd worden. De standaard truuk om de huidige tijd te pakken, werkt niet. Als de klok in secondes nauwkeurig werkt, dan hoeft een afluisteraar slechts 1800 mogelijke sleutels af te gaan, gegeven dat hij op een kwartier nauwkeurig de tijd van een van de beide partijen weet. Het initialiseren van een rng kan het beste met nondeterministische data, zoals bv. uit /dev/random onder linux. Het is misschien mogelijk dat een andere user op hetzelfde systeem ook 512 bits uit /dev/random haalt en daaruit jouw 512 bits berekent. Een andere mogelijkheid om random data te genereren is de eindgebruiker een aantal keer toetsen in te laten drukken. Je meet steeds de tijd tussen twee opeenvolgende aanslagen, als deze groter is dan de voorgaande, genereer je een bit 1, als deze kleiner is, dan genereer je een 0. Op deze manier heb je nondeterministische data gegenereerd. Het is echt belangrijk dat er goede random data wordt gegenereerd, want dit is de basis van het hele protocol. Als dit niet goed in elkaar zit, dan is de rest niet veilig, en kun je beter onbeveiligde TCP/IP connecties gebruiken, want dan ben je je er tenminste van bewust dat wat je doet niet beveiligd is. 6

7 De Transport layer De Transport layer is een beveiligd transport protocol. Op dit niveau wordt de vertrouwelijkheid geregeld door de data door encryptie algoritmes te versleutelen, de integriteit wordt gewaarborgd door een message authentication code (MAC) toe te voegen aan de data, en de server authenticiteit wordt gecontroleerd doordat de server in het begin zijn cryptografische handtekening over bepaalde data moet zetten. Concepten EncryptionAlgorithm Een EncryptionAlgorithm is een cryptografische symmetrische cipher; dit is een algoritme dat met een geheime sleutel data kan encrypten, en met dezelfde sleutel kan de versleutelde data decrypten, zodat de originele data weer bekend wordt. Een voorbeeld van een EncryptionAlgorithm is DES. PublicKeyAlgorithm Een PublicKeyAlgorithm is een cryptografisch algoritme dat gebruikt wordt voor het signen/verifyen (handtekening zetten/verifiëren) en/of encrypten/decrypten van data. Het heeft als eigenschap dat slechts één partij data kan signen en encrypten, en ieder ander kan het sign van de data verifiëren en decrypten. Dit wordt gebruikt door de server om zijn authenticiteit aan te tonen. Een PublicKeyAlgorithm kan data signen, encrypten, of beide. Een voorbeeld van een PublicKeyAlgorithm is DSA. Dit algoritme kan alleen signen. MACAlgorithm Een MACAlgorithm is een Message Authentication Code en wordt gebruikt om m.b.v. een sleutel die aan beide kanten van de connectie bekend is van data een soort checksum te maken. Deze checksum die MAC wordt genoemd, wordt achter de data geplakt voor het versturen zodat de andere kant van de connectie kan zien dat er niets aan de data is veranderd. Een voorbeeld van een MACAlgorithm is HMAC-SHA1. CompressionAlgorithm Een CompressionAlgorithm is een algoritme dat compressie toe past op data. Dit kan het dataverkeer over het netwerk verminderen, maar het gebruik kost wel rekenkracht van zowel de server als de client. KeyExchangeAlgorithm Een KeyExchangeAlgorithm is een algoritme dat gebruikt wordt om sleutels af te spreken. Dit algoritme heeft de eigenschap dat beide kanten van de connectie data oversturen, beide partijen kunnen uit die data de benodigde sleutels berekenen, maar een afluisteraar kan uit de overgestuurde data de sleutels niet bereken. Een KeyExchangeAlgorithm gebruikt eerder overgestuurde informatie, dit zijn de versies van de client en de server en de pakketten van de initialisatie van de Algoritme onderhandeling. Een KeyExchangeAlgorithm levert een Shared 7

8 Secret op, een Exchange Hash en een Hashfunctie. Met deze informatie worden later de sleutels berekend. Als de sleutels berekend zijn, worden deze voor de EncryptionAlgorithms en MACAlgorithms gebruikt. Een voorbeeld van een (onderdeel van een) KeyExchangeAlgorithm is Diffie-Hellman. Host key Een PublicKeyAlgorithm heeft een sleutel nodig. Als de server een bepaald PublicKeyAlgorithm wil gebruiken, dan moet hij daar al een sleutel bij gegenereerd hebben. Deze sleutel wordt de Host key genoemd. Tijdens het gebruik van het KeyExchangeAlgorithm wordt deze Host key gebruikt om de authenticiteit van de server aan te tonen. Als de client nog geen Host key van de server kent, of als er wel een Host key bekend is maar deze afwijkt van de gestuurde Host key, dan bestaat het gevaar dat je geen connectie hebt met de gewenste server, maar met iemand die zelf wel een connectie heeft met de server. Door zijn eigen key op te sturen, kan hij de connectie afluisteren en data veranderen. Dit is de man-in-the-middle attack. Het kan zijn dat je voor de eerste keer een connectie met de server opent, en nog geen Host key kent. Daarom wordt vaak de optie aangeboden om alleen de eerste keer de Host key te accepteren. Het is verstandig om via andere methodes (bv. de server eigenaar opbellen) te verifiëren dat de host key klopt, anders loop je alsnog het risico dat iemand een man-in-the-middle attack uit voert. Algemeen Ik zal eerst uitleggen hoe de Transport layer ongeveer in elkaar zit om daar een globaal idee van te krijgen. Daarna leg ik hetzelfde nog eens uit, maar dan komen alle details aan bod. Initialisatie Een client wil een SSH connectie maken met een server. De client opent eerst een TCP/IP connectie met de SSH server. De client en server sturen hun versies naar elkaar op. Vervolgens begint de client met de Algoritme onderhandeling: dit is het bepalen van de te gebruiken algoritmes en sleutels. Daarna zal de client een service aanvragen. De services worden in een ander hoofdstuk behandeld. Algoritme onderhandeling Zowel de client als de server sturen lijsten van algoritmes op die ze ondersteunen. De volgende lijsten worden opgestuurd: KexExchangeAlgorithms ServerHostKeyAlgorithms, dit is een lijst met PublicKeyAlgorithms die door de client ondersteund worden of waarvoor de server een Host key heeft. EncryptionAlgorithms, dit is een lijst met EncryptionAlgorithms die de client wil gebruiken of die door de server ondersteund worden. Hieruit wordt een EncryptionAlgorithm afgeleid die wordt gebruikt om de data te versleutelen die van de client naar de server wordt gestuurd. MACAlgorithms CompressionAlgorithms 8

9 Encryption, MAC en CompressionAlgorithms worden toegepast op het verkeer van server naar client en client naar server. Er kan voor de client naar server richting een ander algoritme worden gekozen dan voor de server naar client richting. Voor Encryption, MAC en CompressionAlgorithms geldt, dat het eerste protocol dat op de lijst van de Client staat, en die ook op de lijst van de Server staat, gebruikt wordt als protocol voor die desbetreffende functie. Als de Client bv. als EncryptionAlgorithms de lijst aes128-cbc,aes192-cbc,blowfish-cbc stuurt en de server stuurt aes192-cbc,twofish192-cbc, dan zal aes192-cbc als EncryptionAlgorithm gebruikt worden. Als KexExchangeAlgorithm en PublicKeyAlgorithm wordt een iets moeilijker algoritme toegepast, dat verderop behandeld wordt. In het geval dat er geen algoritme afgesproken kan worden, doordat de corresponderende lijst op de server en de client disjunct zijn, dan mislukt de Algoritme onderhandeling, en moeten de server en client de connectie verbreken. Na het succesvol bepalen van de te gebruiken algoritmes, wordt door middel van een KeyExchangeAlgorithm de sleutels voor de algoritmes bepaald, en wordt de authenticiteit van de server vastgesteld. Sleutel onderhandeling Het bepalen van de sleutels voor de algoritmes gebeurt tijdens de Sleutel onderhandelingsfase met een KeyExchangeAlgorithm. Een KeyExchangeAlgorithm levert het volgende op: een shared secret K, een exchange hash H en een hash algoritme Hash. Als session identifier voor de connectie wordt de H gebruikt van de eerste sleutel onderhandeling. Deze session identifier is een uniek gegeven voor de connectie en wordt later nog gebruikt. Uit de K, H en Session identifier wordt m.b.v. Hash de verschillende sleutels berekend. Er kunnen zes verschillende sleutels gemaakt worden: Initializatie Vector (IV) voor het EncryptionAlgorithm van client naar server, IV voor server naar client, key voor het EncryptionAlgorithm van client naar server, key voor server naar client, key voor het MACAlgorithm van client naar server en key voor het MACAlgorithm van server naar client. Het berekenen van de sleutels gebeurd door de session identifier, de K en de H op een bepaalde manier aan elkaar te plakken en daar de Hash functie op los te laten. In gebruik nemen van sleutels Na het bepalen van de sleutels stuurt elke kant een bericht De sleutels zijn in gebruik genomen en is de connectie helemaal gereed om data over te sturen. De client zal een service aanvragen, dit zal meestal de User Authentication service zijn, die op zijn beurt het Connection protocol start. Het is ook mogelijk om nieuwe sleutels af te spreken, zodat hackers het moeilijker krijgen om de connectie te kraken. Dit gebeurt door opnieuw met de Algoritme onderhandeling te beginnen. Het advies is om dit elk uur of na elke gigabyte aan verstuurde data, wat er ook eerder komt. 9

10 Details Initialisatie In het algemeen opent de client een TCP/IP connectie met de server, die op poort 22 staat te luisteren. Andere poorten kunnen natuurlijk ook worden gebruikt, er kan zelfs een ander soort connectie worden gebruikt. Dit moet wel een betrouwbare, connectie-georiënteerde verbinding zijn. Als de connectie eenmaal open staat, dan sturen client en server hun versie op in het volgende formaat: SSH-protoversion-softwareversion comments gevolgd door een CRLF, waarbij protoversion 2.0 is voor het in dit document besproken protocol, en softwareversion een implementatie-afhankelijke string is, die uit printbare ASCII karakters bestaat, behalve de spatie en het minteken. De totale lengte mag niet meer zijn dan 255 tekens. Het deel zonder de CRLF wordt later voor het KexExchangeAlgorithm gebruikt. De server mag nog extra informatie sturen voor de versie. Die regels mogen niet met SSH- beginnen, en worden afgesloten met een CRLF. Na het ontvangen van de versies, beginnen de server en client met de Algoritme onderhandeling. Binair protocol Vanaf het einde van het oversturen van de versies wordt er niet meer gebruik gemaakt van een ASCII protocol, maar van een binair protocol. Informatie wordt overgestuurd in pakketten, die er als volgt uit zien: uint32 packet_length De lengte van het pakket, zonder de mac of de packet_length zelf uint8 padding_length Lengte van de padding, zo dat 5 + n1 + n2 deelbaar is door het maximum van 8 en de blok grootte van het huide EncryptionAlgorithm. De padding_length is minimaal 4. uint8[n1] payload De informatie van het pakket uint8[n2] random Random data padding uint8[m] mac De message authentication code n1 = packet_length padding_length 1 n2 = padding_length m = lengte van de MAC. Als er geen MACAlgorithm is, dan m = 0. Een pakket is minimaal 16 bytes groot, en minimaal de blok grootte van het EncryptionAlgorithm plus de lengte van de MAC. De maximale grootte van een pakket is bytes, de maximale ongecomprimeerde grootte van de payload is bytes. Op plaatsen waar het nodig is, mag hiervan worden afgeweken, bv. als de server een groot aantal certificaten wil oversturen. Payload De payload is de (mogelijk gecomprimeerde) informatie van het pakket. Als je informatie wil versturen over de Transport layer, dan gebeurt dat als payload in een pakket. De eerste byte van de payload is het type van het pakket. De namen van de types beginnen in dit document met SSH_MSG_. Types 10

11 bestemd voor verschillende delen van het protocol zitten in verschillende waardebereiken: Transport layer: 1 19: Transport layer algemeen 20 29: Algoritme onderhandeling 30 49: Sleutel onderhandeling User Authentication protocol: 50 59: User Authentication algemeen 60 79: Methode specifieke codes Connection layer: 80 89: Connection layer algemeen : Channel berichten Overig: : Gereserveerd : Lokale extensies Compressie Als er een compressie algoritme actief is wordt de te versturen data gecomprimeerd. De uitvoer hiervan wordt als payload gebruikt. De compressiemethode wordt opnieuw geinitialiseerd na elke Algoritme onderhandeling. De context wordt van pakket tot pakket doorgegeven en voor het verkeer van client naar server en van server naar client worden aparte contexten bewaard. Na elk pakket wordt een partieële flush toegepast, dit betekent dat het huidige blok wordt beeindigd zodat alle data kan worden overgestuurd. Encryptie Als er een encryptie algoritme actief is, dan wordt het hele pakket zonder mac geencrypt. De lengte van het pakket is dus ook geencrypt, zodat bij het ontvangen van de eerste vier bytes van het pakket of de blokgrootte van het encryptie algoritme al begonnen moet worden met decrypten. De sleutels en initialisatie vectors worden bepaald na de KeyExchange. Alle pakketten (zonder mac) achter elkaar worden als één stroom data gezien, de algoritmes worden dus niet steeds opnieuw geinitialiseerd. De encryptie algoritmes voor client naar server en server naar client werken onafhankelijk van elkaar. MAC Als er een MAC algoritme actief is, dan wordt aan het pakket een MAC toegevoegd. Het MAC algoritme wordt geinitialiseerd na de KeyExchange. De MAC wordt berekend over (sequence_number ++ unencrypted_packet) waarbij sequence_number het nummer van het pakket is, gerepresenteerd als een uint32. Het sequence_number is nul voor het eerste pakket, wordt na elk pakket verhoogd, en wordt weer op nul gezet na Het unencrypted_packet is het pakket voordat het geencrypt wordt. Algoritme onderhandeling Na het uitwisselen van de versies, begint de Algoritme onderhandeling. Elke kant stuurt het volgende pakket: 11

12 uint8 SSH_MSG_KEXINIT uint8[16] random data namelist KeyExchangeAlgorithms namelist ServerHostKeyAlgorithms namelist EncryptionAlgorithmsClientToServer namelist EncryptionAlgorithmsServerToClient namelist MacAlgorithmsClientToServer namelist MacAlgorithmsServerToClient namelist CompressionAlgorithmsClientToServer namelist CompressionAlgorithmsServerToClient namelist LanguagesClientToServer namelist LanguagesServerToClient boolean FirstKexPacketFollows uint32 0 (reserved) Op de hieronder beschreven manieren worden de te gebruiken algoritmes bepaald. Als een algoritme niet gekozen kan worden, dan verbreken de client en server de connectie. KeyExchangeAlgorithms Beide kanten sturen een lijst met namen van KeyExchangeAlgorithms die ze ondersteunen. De client geeft met de volgorde de voorkeur weer. Op de volgende manier wordt het te gebruiken KeyExchangeAlgorithm bepaald: itereer over de algoritmes ondersteund door de client. Neem het eerste algoritme dat aan de volgende voorwaardes voldoet: De server ondersteund het algoritme Als het algoritme een PublicKeyAlgorithm nodig heeft dat kan encrypten, dan staat zo n algoritme op de lijst van ServerHostKeyAlgorithms van zowel de client als de server Als het algoritme een PublicKeyAlgorithm nodig heeft dat kan signen, dan staat zo n algoritme op de lijst van ServerHostKeyAlgorithms van zowel de client als de server ServerHostKeyAlgorithms De server stuurt een lijst met de namen van PublicKeyAlgorithms op waarvoor hij Host keys heeft. De client stuurt een lijst met PublicKeyAlgorithms op waarvoor hij Host keys wil accepteren. Als PublicKeyAlgorithm wordt het eerste algoritme op de lijst van de client gebruikt die ook door de server wordt ondersteund en die ook aan de voorwaarden voor de al gekozen KeyExchangeAlgorithm voldoet. EncryptionAlgorithmsClientToServer EncryptionAlgorithmsServerToClient Beide kanten sturen een lijst met de namen van EncryptionAlgoritms op. Het gekozen algoritme is het eerste algoritme op de lijst van de client die ook op de lijst van de server staat. Voor het verkeer van client naar server en voor het verkeer van server naar client kunnen dus verschillende algoritmes worden gebruikt. 12

13 MacAlgorithmsClientToServer MacAlgorithmsServerToClient Beide kanten sturen een lijst met de namen van MacAlgorithms op. Het gekozen algoritme is het eerste algoritme op de lijst van de client die ook op de lijst van de server staat. CompressionAlgorithmsClientToServer CompressionAlgorithmsServerToClient Beide kanten sturen een lijst met de namen van CompressionAlgorithms op. Het gekozen algoritme is het eerste algoritme op de lijst van de client die ook op de lijst van de server staat. LanguagesClientToServer LanguagesServerToClient Wordt hier niet behandeld. FirstKexPacketFollows Zowel de server als de client mogen gokken dat het eerste algoritme dat ze op sturen in KeyExchangeAlgorithms het te gebruiken algoritme wordt. Om de snelheid van het opbouwen van de Transport layer te verhogen, mogen ze alvast een pakket voor dat specifieke KeyExchangeAlgorithm sturen. Als ze dat doen, dan is het veld FirstKexPacketFollows gelijk aan true, anders false. Als bij het ontvangen van het Algoritme onderhandelingspakket van de andere kant blijkt dat de gok van de andere partij verkeerd was, dan moet het volgende pakket bestemd voor Key Exchange genegeerd worden. Als blijkt dat de eigen gok verkeerd was, dan kan er gewoon door worden gegaan met het echte KeyExchangeAlgorithm. Sleutel onderhandeling De KeyExchangeAlgorithms van beide kanten sturen een aantal voor dat algoritme specifieke pakketten over. Ze krijgen daar de volgende informatie voor: De versies die in het begin zijn overgestuurd, zonder CRLF, en de payload van de Algoritme onderhandelings pakketten. Een KeyExchangeAlgorithm levert het volgende op: Een Shared Secret K, een Exchange Hash H en een Hash functie Hash. De K en H worden als getallen gezien; als ze in een pakket worden gebruikt worden ze dus als mpint gecodeerd. Voor de Transport layer wordt een Session Identifier bijgehouden, die uniek is voor de connectie. Hogere protocollen kunnen van deze session identifier gebruik maken. Tijdens de eerste Sleutel onderhandeling wordt de Session Identifier gelijk gemaakt aan H. Deze verandert daarna niet meer. De sleutels worden als volgt gemaakt: IV client to server: Key = Hash(K ++ H ++ A ++ Session ID) IV server to client: Key = Hash(K ++ H ++ B ++ Session ID) Encryption client to server: Key = Hash(K ++ H ++ C ++ Session ID) Encryption server to client: Key = Hash(K ++ H ++ D ++ Session ID) Mac client to server: Key = Hash(K ++ H ++ E ++ Session ID) Mac server to client: Key = Hash(K ++ H ++ F ++ Sessied ID) De A, B, etc worden als byte gecodeerd, de K, H, en Session ID als mpint. Samen worden ze in een block gestopt, waarna Hash over dat block de hashwaarde berekent. 13

14 De algoritmes geven zelf aan hoe groot de sleutel moet zijn. Als de benodigde lengte kleiner is dan de verkregen sleutel, dan wordt de rest van de sleutel niet gebruikt. Als de benodigde lengte groter is, dan wordt de sleutel op de volgende manier langer gemaakt, dit proces wordt herhaald totdat de lengte groot genoeg. Key = Hash(K ++ H ++ Key) In gebruik nemen van sleutels Nadat de sleutels bekend zijn, kunnen ze worden gebruikt. Met de oude sleutels wordt het volgende pakket verstuurd: uint8 SSH_MSG_NEWKEYS Nadat dit pakket verstuurd is, worden de algoritmes en de bijbehorende sleutels voor het versturen van data in gebruik genomen. Nadat dit pakket ontvangen is, worden de algoritmes en de bijbehorende sleutels voor het ontvangen van data in gebruik genomen. De connectie is gereed Na de eerste Algoritme onderhandeling vraagt de client een service aan. Services aanvragen De client kan services aanvragen. Dat gebeurt door het volgende pakket te sturen: uint8 SSH_MSG_SERVICE_REQUEST string service name Als de server de service wil aanbieden, stuurt hij het volgende pakket en start hij de service: uint8 SSH_MSG_SERVICE_ACCEPT string service name Als de server de service de service niet wil aanbieden, dan verbreekt hij de verbinding. De verbinding verbreken Er zijn verschillende redenen waarom de server of client de verbinding wil verbreken. Een mac van een pakket is niet in orde, een service kan niet verleent worden, etc. Voordat de verbinding echt verbroken wordt, wordt het volgende pakket verstuurd: uint8 SSH_MSG_DISCONNECT uint32 reason code string description string language tag 14

15 Als reden worden de volgende waardes gebruikt: 1 De host mag niet connecten 2 Protocol fout 3 Key Exchange is mislukt 4 gereserveerd 5 Mac fout 6 Compressie fout 7 Service is niet beschikbaar 8 Protocol versie wordt niet ondersteund 9 Host key is niet te controleren 10 Connectie is kwijtgeraakt 11 Connectie is verbroken door de applicatie 12 Te veel connecties 13 Authenticatie is door de gebruiker afgebroken 14 Er zijn geen authenticatiemethodes meer 15 Illegale gebruikersnaam Negeer data Om eventuele hackers af te leiden, kan het volgende pakket gestuurd worden: uint8 SSH_MSG_IGNORE string data Beide partijen mogen dit pakket op elk moment sturen, beide partijen zullen de inhoud van data negeren. Debug berichten Voor het debuggen van programma s is het volgende pakket bestemd: uint8 SSH_MSG_DEBUG boolean always_display string message string language_tag Beide partijen mogen dit pakket op elk moment sturen, beide partijen mogen dit pakket negeren. Als always_display true is, dan is dat een sterke hint dat de implementatie het aan de eindgebruiker moet laten zien of in de logs moet opslaan. Onbekende pakketten Als een implementatie een pakket binnen krijgt waarvan het niet weet waar het voor bestemd is, dan moet hij het volgende pakket terug sturen: uint8 SSH_MSG_UNIMPLEMENTED uint32 sequence number van onbekende pakket Deze pakketten zullen gestuurd worden in de volgorde van de onbekende pakketten waarin ze binnen kwamen. Het nut van deze pakketten is dat toekomstige protocollen nieuwe pakketten kan definiëren. Als ze dan niet ondersteund worden, kan zo n implementatie dan verder af zien van verder gebruik van de nieuwe opties. 15

16 Bericht nummers De volgende bericht nummers zijn gebruikt in het protocol: SSH_MSG_DISCONNECT 1 SSH_MSG_IGNORE 2 SSH_MSG_UNIMPLEMENTED 3 SSH_MSG_DEBUG 4 SSH_MSG_SERVICE_REQUEST 5 SSH_MSG_SERVICE_ACCEPT 6 SSH_MSG_KEXINIT 20 SSH_MSG_NEWKEYS 21 Algoritmes Van elk algoritme is de titel gelijk aan de naam. Encryptie 3des-cbc Dit is DES in EDE3 modus (encrypt-decrypt-encrypt met 3 verschillende sleutels). Het wordt gebruikt in CBC (Cipher Block Chaining) modus. De sleutel, IV en blok grootte is 24 bytes. Een beschrijving van dit algoritme staat in [SCHNEIER] blowfish-cbc Dit is Blowfish in CBC modus, zoals beschreven in [SCHNEIER]. De sleutel en IV grootte is 16 bytes, de blok grootte is 8 bytes. twofish128-cbc Dit is Twofish in CBC modus, zoals beschreven in [TWOFISH]. De sleutel, IV en blok grootte is 16 bytes. twofish192-cbc Dit is Twofish in CBC modus, zoals beschreven in [TWOFISH]. De sleutel en IV grootte is 24 bytes, de blok grootte is 16 bytes. twofish256-cbc Dit is Twofish in CBC modus, zoals beschreven in [TWOFISH]. De sleutel en IV grootte is 32 bytes, de blok grootte is 16 bytes. aes128-cbc Dit is AES (Rijndael, sinds 2 october 200 de Advanced Encryption Standard) in CBC modus. De sleutel, IV en blok grootte is 16 bytes. aes192-cbc Dit is AES in CBC modus. De sleutel, IV en blok grootte is 24 bytes. aes256-cbc Dit is AES in CBC modus. De sleutel, IV en blok grootte is 32 bytes. serpent128-cbc Dit is Serpent (gemaakt door Ross Anderson, Eli Biham, Lars Knudsen) in CBC modus. De sleutel, IV en blok grootte is 16 bytes. serpent192-cbc Dit is Serpent in CBC modus. De sleutel, IV en blok grootte is 24 bytes serpent256-cbc Dit is Serpent in CBC modus. De sleutel, IV en blok grootte is 32 bytes. arcfour Dit is de Arcfour stream cipher, zoals beschreven in [SCHNEIER]. De sleutel grootte is 16 bytes, de IV grootte 0 bytes en de blok grootte is 1 byte. Er wordt 16

17 geloofd dat dit algoritme hetzelfde is als RC4, dat geregistreerd is al strademark van RSA Data Security, Inc. idea-cbc Dit is IDEA (International Data Encryption Algorithm) in CBC modus, zoals beschreven in [SCHNEIER]. De sleutel en IV grootte is 16 bytes, de blok grootte is 8 bytes. The IDEA(tm) block cipher is covered by a patent held by ETH and a Swiss company called Ascom-Tech AG. The Swiss patent number is PCT/CH91/ International patents are pending. IDEA(tm) is a trademark of Ascom-Tech AG. There is no license fee required for noncommercial use. Commercial users may obtain licensing details from Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel , Fax cast128-cbc Dit is CAST-128 in CBC modus, zoals beschreven in [RFC2144]. De sleutel, IV en blok grootte is 16 bytes. none Dit is het algoritme dat niets doet met de data. De sleutel en IV grootte is 0 bytes. De blok grootte is 1 byte. Dit algoritme wordt initieel gebruikt. Aangeraden wordt om dit algoritme niet te gebruiken. Integriteit hmac-sha1 Dit is HMAC, beschreven in [RFC2104] met als hash SHA-1, beschreven in [SCHNEIER]. De sleutel en digest grootte is 20 bytes hmac-sha1-96 Dit is HMAC met als hash SHA-1 waarvan alleen de eerste 96 bits worden gebruikt. De sleutel grootte is 20 bytes, de digest grootte is 12 bytes. hmac-md5 Dit is HMAC met als hash MD5, beschreven in [RFC1321]. De sleutel en digest grootte is 16 bytes. hmac-md5-96 Dit is HMAC met als hash MD5 waarvan alleen de eerste 96 bits worden gebruikt. De sleutel grootte is 16 bytes, de digest grootte is 12 bytes. none Dit is het algoritme dat geen mac oplevert. De sleutel en digest grootte is 0 bytes. Aangeraden wordt om dit algoritme niet te gebruiken. Compressie none Dit is het algoritme dat niets aan de data veranderd. zlib Dit is Zlib (Lempel-Ziv, [LZ77]) zoals beschreven in [RFC1950] en [RFC1951]. Key Exchange diffie-hellman-group1-sha1 Dit algoritme gebruikt Diffie-hellman met als priemgetal p =

18 en als generator voor een subgroep van GF(p), g = 2. De orde q is (p 1) / 2. De hashfunctie Hash is SHA-1. Het heeft een PublicKeyAlgorithm nodig dat kan signen. VC = versie van de client, VS = versie van de server, IC = Algoritme onderhandelings pakket van de client, IS = Algoritme onderhandelingspakket van de server, KS is de public Host key van de server voor het gebruikte PublicKeyAlgoritm. De client genereert een random getal x, 1 < x < q, en berekent e = g x mod p. De client stuurt het volgende pakket naar de server: uint8 SSH_MSG_KEXDH_INIT mpint e De server genereert een random getal y, 0 < y < q) en berekent f = g y mod p. De server ontvangt e van de client. Hij berekent K = e y mod p, H = Hash(VC ++ VS ++ IC ++ IS ++ KS ++ e ++ f ++ K), en hij berekent de signature s van H met het PublicKeyAlgorithm en zijn private Host key. H. VC, VS, IC, IS en KS worden als string gecodeerd, e, f en K worden als mpint gecodeerd. De server stuurt het volgende pakket naar de client: uint8 SSH_MSG_KEXDH_REPLY string KS mpint f string s De client verifieert dat KS de echte Host key van de server is. De client mag KS accepteren zonder te hebben gecontroleerd dat het echt de Host key is van de server. Dit brengt echter het gevaar van de man-in-the-middle-attack met zich mee. De client berekent K = f x mod p, H = Hash(VC ++ VS ++ IC ++ IS ++ KS ++ e ++ f ++ K) en verifieert met het PublicKeyAlgoritm en KS de signature s van De waardes K, H en de functie Hash worden geretourneert aan de Algoritme onderhandeling. De volgende bericht nummers zijn gebruikt in dit algoritme: SSH_MSG_KEXDH_INIT 30 SSH_MSG_KEXDH_REPLY 31 diffie-hellman-group-exchange-sha1 De veiligheid van Diffie-Hellman is gebaseerd op de moeilijkheid van het oplossen van het Discrete Logaritme Probleem (DLP). Waarschijnlijk wordt SSH nog vele jaren gebruikt, en het is mogelijk dat door efficiente algoritmes en veel voorbereidend rekenwerk diffie-hellman-group1-sha1 niet meer veilig is. Daarom is er een tweede KeyExchange gemaakt. De server genereert nu een veilig priemgetal en een generator van een grote subgroep. De hashfunctie is SHA-1. Het heeft een PublicKeyAlgorithm nodig dat kan signen. VC = versie van de client, VS = versie van de server, IC = Algoritme onderhandelings pakket van de client, IS = Algoritme onderhandelingspakket van de server, KS is de public Host key van de server voor het gebruikte PublicKeyAlgoritm. 18

19 De client stuurt het volgende pakket om de key exchange te beginnen: uint8 SSH_MSG_KEY_DH_GEX_REQUEST uint32 min uint32 n uint32 max min is de minimum grootte van een accepteerbare groep, n is de gewenste grootte en max is de maximum grootte. De aanbevolen grootte van min is 1024, voor max De server neemt een groep die het beste past bij de wensen van de client. P is een veilig priemgetal, dat wil zeggen dat (p 1) / 2 is priem. g is een generator van een grote subgroep van GF(p). en stuurt het volgende pakket: uint8 SSH_MSG_KEY_DH_GEX_GROUP mpint p mpint g De client genereert een random getal x, 1 < x < (p 1) / 2, berekent e = g x mod p, en stuurt het volgende pakket: uint8 SSH_MSG_KEY_DH_GEX_INIT mpint e De server genereert een random getal y, 0 < y < (p 1) / 2, berekent f = g y mod p, en ontvangt e. De server berekent K = e y mod p, H = Hash(VC ++ VS ++ IC ++ IS ++ KS ++ min ++ n ++ max ++ p ++ g ++ e ++ f ++ K), en signature s over H met de PublicKeyAlgorithm met als key KS. VC, VS, IC, IS en KS worden als string gecodeerd, min, n en max als uint32 en p, g, e, f en K worden als mpint gecodeerd. De server stuurt het volgende pakket op: uint8 SSH_MSG_KEY_DH_GEX_REPLY string KS mpint f string s De client verifieert dat KS de echte Host key van de server is. Ook hier mag de client een onbekende Host key accepteren. De client berekent vervolgens K = f x mod p, H = Hash(VC ++ VS ++ IC ++ IS ++ KS ++ min ++ n ++ max ++ p ++ g ++ e ++ f ++ K), en verifieert het signature s over H met het PublicKeyAlgorithm en de Host key HS. De waardes K, H en de functie Hash worden geretourneert aan de Algoritme onderhandeling. De volgende bericht nummers zijn gebruikt in dit algoritme: SSH_MSG_KEX_DH_GEX_REQUEST 34 SSH_MSG_KEX_DH_GEX_GROUP 31 SSH_MSG_KEX_DH_GEX_INIT 32 SSH_MSG_KEX_DH_GEX_REPLY 33 Public Key Algoritmes In het voorafgaande deel werd gesproken over Host key en Signature. Er werd niet verteld hoe deze in elkaar zitten. Wat de bovengaande tekst betreft, zijn dit allebei blocks, die verpakt in een string (uint32 lengte + inhoud van het block) behandeld worden. 19

20 ssh-dss Dit is de DSS (Digital Signature Standard, [FIPS-186]) DSA (Digital Signature Algorithm), zoals beschreven in [SCHNEIER]. Dit PublicKeyAlgorithm kan alleen signen. De Host key wordt als volgt gecodeerd in een block: string ssh-dss mpint p mpint q mpint g mpint y De Signature wordt als volgt gecodeerd in een block: string ssh-dss string dss_signature_blob dss_signature_blob is gecodeerd als een string die r en s bevat. r es s zijn beide 160 bits unsigned integers, zonder lengte, zonder padding en in bigendian gecodeerd. ssh-rsa Dit is het RSA (Rivest, Shamir, Adleman) algoritme, zoals beschreven in [SCHNEIER]. Dit algoritme kan alleen signen (wat het SSH protocol betreft). Het signen en verifien wordt gedaan zoals beschreven in [PKCS1] met de SHA-1 hash. De Host key wordt als volgt gecodeerd in een block: string ssh-rsa mpint e mpint n De Signature wordt als volgt gecodeerd in een block: string ssh-rsa string rsa_signature_blob rsa_signature_blob is gecodeerd als een string die s bevat. s is een unsigned integer, zonder lengte, zonder padding en in big-endian gecodeerd. 20