IP-baserade program

Det här kapitlet behandlar några klassiska TCP/IP-baserade program. Främsta fokus är HTTP men även lite enklare applikationer som telnet och FTP behandlas. Kapitlet är tänkt att kunna läsas fristående men fungerar bäst om du vet hur TCP/IP fungerar.

Så har vi kommit fram till programmen. Själva vitsen med TCP/IP är ju att alla typer av program ska kunna kommunicera med varandra oavsett hur kanalen eller länken ser ut. Vi har tidigare konstaterat att vi förväntar oss att visst stöd och vissa program ska ingå i internetprotokollen. Ofta har program och protokoll blivit synonymer.

Det finns ett par program som i princip inte dokumenterats. Hit hör traceroute och ping, hur de fungerar behandlas bland annat i kapitlet Felsökning i TCP/IP-miljö. Traceroute används av tusentals användare i hundratals länder. Trots det finns det väldigt lite skrivet om hur programmet kan och borde fungera, och de beskrivningar som finns tillkom efteråt. Programmen och kommandona är så gamla så det kommer från en tid då man i Unix hade den informella principen att ”all dokumentation finns i källkoden”. Ett program blev de facto standard och tillslut ett eget protokoll.

Telnet

Att kunna logga in på en annan dator via en fjärranslutning är en gammal idé, det var bland det första man ville göra med Arpanet. I en grafisk miljö brukar man prata om remote desktop, i textbaserade system om remote login. Telnet hanterar textbaserade system.

Principen kan verka enkel: det som skrivs på den ena datorns tangentbord ska utgöra input på andra sidan. Det som utgör output på en sida ska visas på en textbaserad konsol på andra sidan. Men det är svårt och behandlas i en mängd RFC:er som 854, 859–861 och många fler (och tyvärr behandlar varje RFC bara delar av protokollet). Svårigheterna har med en mängd optioner att göra, att applikationen ligger nära operativsystemet och hårdvaran (en miljö kanske använder knappt 50 tangenter och en annan runt 75) men även med principen och att göra om enstaka tangentnedtryckningar till paket på ett effektivt sätt.

Fortfarande är textbaserade system vanliga, de kan göras väldigt inmatningseffektiva, den datamodell som de arbetar med är väl beprövad och de är lätta att nå: i stort sett vilken dator som helst med TCP/IP kan vara en telnet-terminal. I Linux är tangent och konsol fortfarande standard input respektive output. I Windows finns stöd för telnet i konsolläge och i programmet Hyperterminal.

Liksom många andra applikationer bygger telnet och FTP på TCP.

Telnet bygger på TCP, vi vill ju att dataöverföringen ska vara tillförlitlig och visa samma data i bägge ändar. Telnet använder ofta push-funktionen i TCP för att ge en snabbare användarupplevelse.

För att förhandla fram optioner och inställningar som 7- eller 8-bitars ASCII, hur man ska hantera kombinationer av Carriage Return samt Line Feed etc så används ett begrepp vid namn NVT, Network Virtual Terminal. Både klient och server tar omvägen över NVT, det gör att man enklare kan anpassa ett telnet-program för varje maskins egenheter.

Testa själv

Till telnet finns en mängd optioner. Både klient- och serversidan kan meddela att de avser att använda en option och den andra ändan får bekräfta eller stoppa. Några exempel på optioner är ECHO (tilllåta lokalt eko) och end-of-record. NVT ser till att bägge ändar kan kommunicera överhuvudtaget.

Telnet kan användas på andra portar än nummer 23. Detta är praktiskt vid felsökning med mera.

Telnet ställer inga krav på att det verkligen är ett tangentbord eller en konsol som skickar eller tar emot data. Detta gör att telnet kan användas för att testa förbindelser och protokoll. Det vi skickar från ena sidan kommer fram till den andra. Genom att använda telnet på andra portar än port 23 kan telnet användas vid felsökning. Vi kan till exempel telnetta till en webbserver på port 80 med kommandot ”telnet www.firma.se 80”.
Sedan skickar vi en slumpartad textsträng och trycker Enter två gånger. Webbserver kommer då svara med att vårt HTTP-anrop var fel. Men då ser vi att webbservern svarar. Om vi kan syntaxen för HTTP kan vi dessutom skicka korrekta kommandon till servern och se hur den svarar. Samma sak gäller bland annat protokollen SMTP, POP3 och FTP.

Telnet har dålig säkerhet. Kommunikationen sker i klartext vilket gör att användaridentitet och lösenord kan avlyssnas enkelt. Detta gör att användningen av telnet bör begränsas. En följd av detta är också at flera Unix-varianter idag inte tillåter att man loggar in sig med root-behörighet via telnet.

Felmeddelanden och intern kommunikation i klartext gör felsökning enkel men är en säkerhetsrisk.

Att all kommunikation sker i klartext, även felhantering och intern förhandling mellan klient och server, är säkerhetsmässigt en nackdel. Men för felsökning är det en fördel. Man kan enkelt koppla in en analysator och se var problemen uppstår. Detta är en egenskap som flera TCP/IP-baserade program delar och ett skäl till att internetprotokollen blivit populära.
Felhanteringen är dessutom relativt utförlig, vid förhandlingar om optioner inom applikationer sker mycket i klartext och inte bit-orienterat (via flaggor). Om den ena sidan inte förstår skickar de ofta meddelanden med text ”the client sent a message the server can’t understand” eller något liknande.

Secure Shell – SSH

Säkerheten i telnet är låg och inloggningssekvenser skickas i klartext. Eftersom det finns ett behov av fjärrterminaler har konceptet utvecklats vidare till bland annat SSH, Secure SHell. SSH har även blivit populärt genom en lättanvänd shareware vid namn PuTTY.

SSH ger möjlighet till autentisering via PKI-teknik. Med hjälp av serverns publika nyckel och ett fingeravtryck kan klienten autentisera servern. Den publika nyckeln kan sedan användas för att upprätta krypterad kommunikation mellan klient och server. På samma sätt som det går till i HTTPS förhandlar sedan klient och server fram ett symmetriskt krypto och en sessionsnyckel för att spara CPU-belastning.

En funktion till som gjort SSH populärt är en funktion för port forwarding. SSH kan konfigureras så att en godtycklig applikation och port kan använda SSH, och SSH kan således skapa en krypterad tunnel mellan två noder.

File Transfer Protocol – FTP

Program för att överföra filer tillhör också de äldsta tillämpningarna. De äldsta RFC:erna är från tiden innan TCP/IP. Klassisk FTP fungerar fortfarande på ett sätt som inte passar när brandväggar ska konfigureras, se nedan. Och precis som för Telnet är säkerheten svag, såväl kontrollinformation som inloggningar skickas i klartext.

FTP använder två portnummer. På port 21 skickas kontrollinformation för inloggning med mera. När sedan data ska överföras (vilket även omfattar en listning av vilka filer som finns att hämta) så startas dotterprocesser på servern och de använder port 20.

Klassisk FTP använder två portnummer och dataöverföring sker via en session som startas från servern.

Det som är lite udda i klassisk FTP är att dataöverföringen dels startar från servern sessionsmässigt (ett problem då brandväggar brukar acceptera inkommande SYN+ACK-paket men inte SYN-paket), dels att det då är servern som har ett känt portnummer som initierar sessionen. Med FTP i passivt läge, även kallat PASV, så löser man detta problem och PASV är numer oftast förvalt flera klienter. Ett klassiskt undantag har varit FTP i MS Windows kommandoläge. FTP och speciellt passivt läge behandlas även i kapitlet om adressöversättning.

FTP använder en delmängd av protokollet telnet för att skicka kommandon och textsträngar. Även NVM används på ett sätt liknande telnet, men jämfört med telnet används bara ett fåtal optioner. På samma sätt som med telnet påverkar detta säkerheten negativt men det underlättar för felhantering.

Det finns varianter på filöverföring med högre säkerhet, där till exempel Kerberos används för inloggning eller SSL (Secure Socket Layer) används för att skydda såväl inloggning som överföring. En annan konsekvens av FTP:s svaga säkerhet är att FTP ofta används för anonym FTP. En användare loggar in med användarid ”anonymous” eller ”ftp” och anger sedan sin e-postadress som lösenord (av artighetsskäl så att servern kan logga hur servern används). Till stor del har webbservrar tagit över denna funktion men en del leverantörer väljer fortfarande att visa olika information på webb- respektive FTP-servrar.

TFTP använder UDP och är ett väldigt enkelt protokoll för att överföra (huvudsakligen små) filer.

En förenklad variant av FTP har utvecklats i form av Trivial FTP, TFTP. TFTP blev snabbt en succé och används flitigt då till exempel konfigurationsfiler ska överföras eller då system ska boota upp. TFTP utmärks av:

  • ingen inloggning eller autentisering
  • ingen möjlighet till kryptering
  • UDP används som nivå 4-protokoll. Detta sparar både minne och kod. För att kontrollera att data kom fram används ett enkelt stop-and-wait protokoll där servern väntar på kvittenser innan nästa paket skickas. Både klient och servern har timers så att de kan sända om vid behov.
  • Protokollet kan användas för att ta emot och sända filer (kallas READ respektive WRITE inom protokollet).

HyperText Transfer Protocol – HTTP

HTTP har flera egenskaper gemensamma med telnet och FTP. TCP används. Inloggning, kommunikation och felhantering sker i klartext. Detta gör felsökning enkel men det medför också säkerhetsproblem.

HTTP har utvecklats från att vara ett ganska enkelt protokoll för att överföra webbsidor (HTML och de objekt som hör till dem) till en generell och ganska komplex metod med flera varianter. HTTP används inte bara för att skicka webbsidor utan även i modern systemutveckling via regelverk som Web Services och SOAP. I detta kapitel går vi igenom dem översiktligt.

För att göra överföringen tillförlitlig använder HTTP protokollet TCP. För att avgöra vad som ska överföras används URL:er. Uniform Resource Locators är en specifik form av den mer generella formen URI, Uniform Resource Identifiers. Populärt kallar vi dem ofta ”länkar” och de har formen ”protokoll://domännamn [:portnummer] /sökväg [:parametrar] [?fråga]. Variabler inom hakparentes är optioner så en enklare form för endast HTTP blir endast ”http://domännamn/sökväg”. För att översätta domännamn används DNS. Sökvägen anger vilket dokument eller objekt som vi vill hämta. Normalt är det klienten (webbläsaren) som hämtar objekt från webbservern men metoden i sig är tvåvägs och servern kan hämta objekt från klienten.

I princip kan vi alltså få olika felmeddelanden beroende på om det är sökvägen som inte finns eller om det är namnuppslagningen som inte lyckas. Eller om namnuppslagningen lyckas men aktuell IP-adress inte svarar på port 80.

HTTP har ett par egenskaper som är värda att notera:

HTTP är tillståndslöst. Detta gör det enkelt att bygga servers, de behöver inte hålla reda på vad klienten gjort förr. Klienten frågar efter ett objekt (anger en sökväg) och får ett svar. I princip är överföringen sedan klar och sessionen stängs. Detta är HTTP:s grundfunktion, men ibland vill vi ha kontroll på vad som skett tidigare, det vill säga servern svarar olika beroende på vad klienten har gjort tidigare. Flera tillägg har utvecklats för detta. Ett sätt är att använda cookies (se sidan 79) ett annat sätt är att skicka status via själva URL:en. Följaktligen blir då URL:erna bärare av information och i princip för komplexa för människor. Följande är kanske inte en länk man tipsar sin kompis om: http://www.bolag.se/jtrac/flow?_flowExeKey=cC5728581-2A39-B914-6D50-8A7981D8CA5F-k71AAD132-2501ABE5-D231-94460E3C4B6C&_eventId=back.

HTTP är tvåvägs. (En egenskap som delas med de flesta program.) Normalt efterfrågar klienten objekt eller egenskaper hos servern men motsatsen finns också. Dessutom finns kommandona PUT och POST för att klienten ska kunna överföra information till servern.

HTTP är byggt för caching och mellanhänder (proxies).

HTTP version 1.1 använder persistenta förbindelser. När klienten hämtat ett objekt (varav själva HTML-texten kan vara ett) så behålls TCP-förbindelsen öppen tills ena parten begär att den ska stängas. Detta ger flera fördelar för komplexa (moderna) webbsidor. En modern webbsida består av många objekt och flera av dessa kan överföras via samma session. HTTP version 1.0 öppnade en session per objekt. HTTP version 1.0 och dess teknik ökar handskakningen via TCP och dessutom tar det tid för TCP med slow start att uppnå bästa prestanda. HTTP version 1.1 ger en klar förbättring speciellt över länkar med lång fördröjning.

Testa själv

För att testa HTTP kan du enkelt använda telnet och fråga efter en webbsida.

C:> telnet www.twoviews.se 80 GET /index.html HTTP/1.1

Slå sedan Enter två gånger och din terminal ska få en mängd HTML-kod. En webbläsare ser sedan vilka objekt som ingår och fortsätter fråga efter dem.

HTTP har utvecklats från att i grunden vara ett enkelt protokoll till en komplex samling tekniker och optioner. En webbsida kan bestå av 30–40 objekt och behöva hundratals paket. Det vi uppfattar som en webbsida kan egentligen bestå av flera webbsidor som hämtas på olika servrar. För att förbättra prestanda används dessutom mellanlagring på klienten men även på internet.

Det är också värt att notera att många webbplatser lagras på många ställen. Om vi surfar till exempelvis microsoft.com, www.fbi.gov eller www.whitehouse.gov så hamnar vi oftast på en av många kopior av webbplatsen. Detta gör att prestanda förbättras eftersom kopian är lokaliserad nära oss, men det gör både namnuppslagning och HTTP mer komplicerad. Vidare kan klient och server förhandla om språkstöd etc så klienten hämtar olika objekt beroende på våra lokala inställningar.

Webben var från början tillståndslös, en sak som kan lösas med cookies. En cookie är i huvudsakligen en liten sträng som läggs på en bestämd plats på din dator. Varje webbplats skapar en egen sträng. En cookie är mer tillförlitlig än en IP-adress eftersom bland annat adressöversättning gör att fler användare kan uppträda som en IP-adress. Den här lilla strängen gör att en server kan komma ihåg att när du går till kassan så har du tidigare klickat på köp av två böcker. All denna logik bygger på vad servern gör och lagrar om din unika cookie.

På ett liknande sätt kan servern lagra vilka sökningar du brukar göra och sortera svaren efter vad du valt. Givetvis kan servern på detta sätt även styra vilken reklam den vill visa. Cookies är alltså inte en speciellt avancerad funktion och röjer inte så många hemligheter i sig. Men genom att granska vilka cookies en användare har på datorn kan man se vilka webbplatser han besökt. Webbläsare har historiskt också haft problem så att servrar har kunnat läsa varandras cookies, vilket inte är meningen och en oetisk användning.

Cookies fick därför snabbt oförtjänt dåligt rykte. I alla moderna webbläsare kan man blockera cookies, men vissa webbplatser fungerar inte utan cookies så de får då användas tillfälligt.

Cookies används även för att räkna antal unika besökare på en webbplats. Flera webbplatser lever på annonser och man behöver skaffa sig en uppfattning om antal unika besökare.

Hur påverkas program av IPv6?

Att byta ut ett nätnivå-protokoll som IP har visat sig vara svårt. Men det ställer även till det för applikationerna. Vi kan se detta på hur det triviala programmet ping fungerar nu när IPv6-stöd är på väg att införas. I Windows Vista skriver du alltid ”ping nodnamn” oavsett om du ska pinga en IPv4 eller en IPv6-adress. Windows Vista ställer DNS-frågor efter både IPv4- och IPv6-adresser. Om den får träff på en IPv6-adress prioriterar den IPv6. (Du kan tvinga ping att använda version 4 eller 6 med växlar till kommandot.)

Samma kommando i dagens Linuxvarianter fungerar ibland inte alls med IPv6, man måste skriva ”ping -6” eller använda programmet och kommandot ping6. Och även om man gjort det kanske det inte fungerar, då ligger skillnaden kanske i huruvida den DNS som innehåller rätt information pratar IPv4, IPv6 eller både och.

Ping är ett enkelt program. För mer komplexa program är läget inte bättre. Vissa program fungerar inte alls med IPv6, även om de principiellt bara borde få rätt information från DNS. Många program blir direkt motsträviga om man försöker få dem att fungera med IPv6 och förklarar glatt att adresser som 2001:234:5678:999:204:76ff:fec2:c193 inte är ett ”giltigt namn!” eller en giltig sökväg. Program som innehåller IPv4-adresser i kod eller konfigurationer får självklart stora problem. För att underlätta övergången till IPv6 finns verktyg för utvecklare som går igenom kod och varnar för potentiella svårigheter och problem.

Säkerhet på applikationsnivå

De program vi gått igenom i det här kapitlet har alla i någon mening säkerhetsproblem. De flesta äldre program skickar även intern kommunikation och inloggningssekvenser i klartext. Detta gör debuggning och felsökning enkel men det gör trafiken känslig för avlyssning.

De flesta program finns i förbättrade varianter med bättre säkerhet inklusive autentisering och kryptering. För HTTP finns en förbättring kallad HTTPS, som bygger på SSL, Secure Socket Layer.

SSL, Secure Socket Layer

När du använder en internetbaserad banktjänst eller köper något via ett kreditkort på internet finns ingen delad hemlighet eller lösenord som du och banken eller kortinlösaren kommit överens om. Den pinkod som används (fyra till sex siffror) är alldeles för svag för att skydda informationen, en dator testar sig igenom sex siffror på bråkdelen av en sekund. Men ändå är allt som skickas mellan din dator och webbplatsen skyddat, och det är det lilla hänglåset som syns i webbläsaren som ger en fingervisning om hur det går till.

Secure Socket Layer, SSL, är ett bra exempel på en modern metod för att kryptera information som ska överföras. Den är beprövad, den är väldigt spridd, den finns i ett par varianter och den använder både symmetrisk och asymmetrisk kryptering. Och som flera andra metoder har den haft problem i de första implementeringarna som kom.

Idag använder vi SSL version 3 eller 3.1. Historiska problem med SSL är inte alls så illa som det låter utan kanske till och med en styrka. Moderna metoder för säkerhet bygger sällan på att någon enstaka person sitter inlåst på en kammare och uppfinner en metod.

Det är istället en grupp som utvecklar en metod, i fallet SSL var det företaget Netscape som utvecklade en metod för säker informationsöverföring mellan webbläsare och webbserver. Uppfinnarna lanserar sedan metoden och vips kommer ett antal andra arbetsgrupper att försöka hitta brister. Netscape fick kritik för brister i sina första releaser och kom i mitten av 1990-talet med tre releaser i tät följd (SSL version 1 till 3). Resultatet har blivit en metod som är testad och beprövad, och inte mycket har behövt ändras sedan dess. IETF tog några år senare fram en variant på SSL, där man redde ut ett par oklarheter, som kallas för TLS (Transport Layer Security).

SSL bygger på att vi krypterar informationen mellan nivå fyra och fem enligt OSI:s referensmodell. Det gör att flera protokoll som ligger ovanpå TCP eller UDP ganska enkelt kan anpassas och då förekomma i en krypterad variant. HTTP finns i varianten HTTPS. NNTP (Network News Transfer Protocol) finns i varianten NNTPS. POP3, FTP och Telnet finns i varianter som bygger på SSL. Eftersom vi krypterar på en högre nivå än nivå tre kommer felmeddelanden (ICMP) inte krypteras, inte heller DNS- eller routinginformation. Men vi skyddar data som överförs mellan program och ofta är det just det vi är ute efter.

För att förstå SSL behöver vi kunna skilja på symmetrisk och asymmetrisk kryptering. Fram till 1970-talet fanns bara symmetrisk kryptering. Symmetrisk kryptering bygger på att sändare och mottagare använder samma nyckel vid kryptering och dekryptering. För att förstå principen kan vi tänka oss att nyckeln består av 40 bitar, det vill säga tio hexadecimala siffror. Ett exempel skulle kunna vara strängen 1846B3CF71. Om ett meddelande är digitaliserat kan vi uppfatta även det som siffror (eller ett väldigt stort tal) och nu bestämmer vi att vår metod för kryptering består av att vi multiplicerar vår klartext med nyckeln. Den metod som vår mottagare använder är att dividera med nyckeln.

Det finns ett par problem med den här modellen. Dels är metoden sårbar. Om sändare och mottagare kommer överens om en dålig nyckel som till exempel 1111111111 så kommer kryptot bli enkelt att knäcka och även det krypterade meddelandet kommer röja delar av klartexten. Dels kanske den som vill knäcka metoden kan få avsändaren att skicka ett meddelande bestående av klartexten 1 och då visas nyckeln rakt av. Men huvudproblemet med all symmetrisk kryptering handlar om hur avsändare och mottagare ska byta nycklar. Det sker i och för sig utanför modellen men är ändå ett stort problem. Speciellt med långa nycklar så skriver vi ner dem eller sparar dem på ett lagringmedium och då kan obehöriga komma åt dem. Trots denna brist är symmetriska krypton baserade på en delad hemlighet (shared key) väldigt vanliga. Några exempel på symmetriska krypton är DES, 3DES, IDEA, Blowfish, AES.

Asymmetriska metoder använder en nyckel för kryptering och en annan nyckel för dekryptering. De har den förvånansvärda egenskapen att vi kan börja med att kryptera med den ena nyckeln (den publika, kallas även offentlig nyckel) och sedan dekryptera med den andra (den privata) och på så sätt få tillbaka klartexten. Men vi kunde lika gärna börjat med att kryptera med den privata nyckeln och sedan dekrypterat med den publika. Det kan verka lite som magi och matematiken som ligger bakom är avancerad och kräver datorer. Metoderna uppfanns på 1970-talet, och den mest spridda kallas RSA efter uppfinnarnas initialer.

Albin och Beda med sina privata och publika nycklar. Den privata nyckeln håller man för sig själv. Den publika nyckeln kan man kopiera och sprida. På bilden visas den publika nyckeln symboliskt med ett hänglås. I verkligheten är både den privata och publika nyckeln långa teckensträngar.

Varje användare i ett system för asymmetrisk kryptering har alltså två nycklar, den privata som man ska hålla för sig själv och den publika som kan spridas fritt. Vill man kryptera ett meddelande till en mottagare så hämtar man mottagarens publika nyckel och krypterar med den, då blir det bara mottagaren som kan dekryptera meddelandet.

En avsändare kan även kryptera ett meddelande med sin egen privata nyckel innan det skickas iväg. Mottagaren kan bara dekryptera meddelandet genom att hämta avsändarens publika nycket och kan därmed vara säker på att det verkligen kommer från rätt avsändare. Vi får på det här sättet en metod för digitala signaturer.

Observera att Albin inte behöver träffa Beda för att få tag på hennes publika nyckel. Albin kan lika gärna fråga exempelvis David om han har tillgång till Bedas publika nyckel. Och om Albin litar på David, och David är ärlig, så fungerar modellen. En annan möjlighet är att gå till en server som hanterar nycklar eller något som skulle kunna likna en myndighet som tillhandahåller medborgarnas publika nycklar. Men om det nu finns en illasinnad användare vid namn Crydolf så kan ju han ha bytt ut Bedas nycklar för att komma åt den information som bara är avsedd för Bedas ögon.

För att systemet med publika nycklar ska fungera behövs därför en infrastruktur vi kan lita på, den beteckning som vanligen används är Public Key Infrastructure eller PKI. PKI bygger på att vi litar på en eller flera så kallade rot-CA (Certificate Authority eller certifikatutfärdare). Dessa har till uppgift att garantera att en publik nyckel hör ihop med en viss användaridentitet eller en viss webbplats, och att ingen Crydolf har bytt ut dem.

Ett certifikat är ett elektroniskt dokument som består av en publik nyckel, giltighetsdatum etc. samt en utfärdare. Litar vi på certifikatutfärdaren ska vi kunna låta denne signera att vi fått rätt information i vårt elektroniska dokument.

Dags att återvända till SSL. I likhet med många andra moderna säkerhetsmetoder kombinerar SSL det bästa av två världar. Vi använder symmetrisk kryptering under den största delen av sessionen. Symmetrisk kryptering går fort och belastar inte datorns processor så mycket. Men vi använder asymmetrisk kryptering och serverns publika nyckel för att kunna byta nyckel på ett säkert sätt.

Handskakningen i SLL mellan klient och server.

Klienten börjar handskakningen. I huvudsak meddelar den vilka versioner av SSL den har stöd för, vilka krypteringsmetoder den stöder samt ett slumptal som ska användas när krypteringen startar. Servern svarar med i princip samma information förutom slumptalet. Servern skickar sedan över sitt certifikat och övriga certifikat hela sökvägen upp till en rot-CA. Det är sedan klientens ansvar att verifiera certifikatets giltighet. I nästa skede överför servern sin publika nyckel och meddelar att den är klar. Klienten skickar sedan över den gemensamma nyckel som ska användas för symmetrisk kryptering under sessionen, och denna nyckel krypteras med serverns publika nyckel. Bara servern kan därmed dekryptera och komma åt sessionsnyckeln. Klienten skickar sedan över vilken metod som ska användas för den symmetriska krypteringen, till exempel DES och SHA-1.

Servern avslutar med att kvittera metoden. Genom SSL får vi kontroll på att vi pratar med rätt server (serverautentisering) och vi får ett sätt att skydda informationsöverföringen. Vill vi kontrollera klienten eller användaren kan det göras via ett certifikat det också (det finns ett tillägg till SSL med klientautentisering). Men det vanligaste är att använda lösenord eller dosor för att generera engångslösenord. Till skillnad från HTTP där lösenord överförs helt oskyddat kan lösenord överföras på ett säkert sätt via HTTPS tack vare sessionsnyckeln.

Referenser

RFC 959 - FTP
RFC 1630 och 1738 - Behandlar URL
RFC 2854 - HTML
RFC 1945 - HTTP 1.0
RFC 2616 - Behandlar HTTP version 1.1
www consortium - www.w3c.org
HTTP Essential - Stephen Thomas, 2001 (Enklare att läsa än RFC 2616)
TCP/IP Handboken - Gunnar Gunnarsson, 1999 Trots namnet handlar boken mest om applikationer.