Generelt

SSL (og dens etterfølger, TLS ) er en protokoll som fungerer direkte på toppen av TCP (selv om det også finnes implementeringer for datagrambaserte protokoller som UDP). På denne måten kan protokoller på høyere lag (som HTTP) være uendret mens s til du gir en sikker forbindelse. Under SSL-laget er HTTP identisk med HTTPS.

Når du bruker SSL / TLS riktig, kan alt en angriper se på kabelen hvilken IP og port du er koblet til, omtrent hvor mye data du sender , og hvilken kryptering og komprimering som brukes. Han kan også avslutte forbindelsen, men begge sider vil vite at forbindelsen er avbrutt av en tredjepart.

I vanlig bruk vil angriperen også kunne finne ut hvilket vertsnavn du kobler til (men ikke resten av URL-en): Selv om HTTPS i seg selv ikke avslører vertsnavnet, må nettleseren din vanligvis sende en DNS-forespørsel først for å finne ut hvilken IP-adresse du vil sende forespørselen til.

Høy -nivåbeskrivelse av protokollen

Etter å ha bygget en TCP-forbindelse, startes SSL-håndtrykket av klienten. Klienten (som kan være en nettleser, i tillegg til et hvilket som helst annet program som Windows Update eller PuTTY) sender en rekke spesifikasjoner:

• hvilken versjon av SSL / TLS den kjører,
• hva krypteringer den vil bruke, og
• hva komprimeringsmetoder den vil bruke.

Serveren identifiserer den høyeste SSL / TLS-versjonen som støttes av både den og klienten, velger en krypteringssuite fra et av klientens alternativer (hvis den støtter en), og velger en komprimeringsmetode.

Etter dette er det grunnleggende oppsettet gjort, serveren sender sitt sertifikat. Dette sertifikatet må være klarert av enten klienten selv eller en part som klienten stoler på. For eksempel, hvis klienten stoler på GeoTrust, kan klienten stole på sertifikatet fra Google.com fordi GeoTrust kryptografisk signert Googles sertifikat.

Etter å ha bekreftet sertifikatet og være sikker på at denne serveren virkelig er den han hevder å være (og ikke en mann i midten), byttes en nøkkel ut. Dette kan være en offentlig nøkkel, en » PreMasterSecret » eller rett og slett ingenting, avhengig av valgt chifferuite. Både serveren og klienten kan nå beregne nøkkelen for symmetrisk kryptering ^{whynot PKE?} . Klienten forteller serveren at fra nå av blir all kommunikasjon kryptert, og sender en kryptert og autentisert melding til serveren.

Serveren verifiserer at MAC (brukt til autentisering) er riktig, og at meldingen kan dekrypteres riktig. Den returnerer deretter en melding som klienten bekrefter som vel.

Håndtrykket er nå ferdig, og de to vertene kan kommunisere sikkert. For mer info, se technet.microsoft.com/en-us/library/cc785811 og en.wikipedia .org / wiki / Secure_Sockets_Layer .

For å lukke tilkoblingen, brukes et varsel om «close_notify». Hvis en angriper prøver å avslutte forbindelsen ved å fullføre TCP-forbindelsen (injisere en FIN-pakke), vil begge sider vite at forbindelsen ble feilaktig avsluttet. Forbindelsen kan imidlertid ikke kompromitteres av dette, men bare avbrutt.

Noen flere detaljer

Hvorfor kan du stole på Google.com ved å stole på GeoTrust?

Et nettsted vil kommunisere sikkert med deg. For å bevise identiteten og sørge for at den ikke er en angriper, må du ha serveren «s offentlig nøkkel . Du kan imidlertid knapt lagre alle nøkler fra alle nettsteder på jorden ville databasen være enorm og oppdateringer måtte kjøres hver time!

Løsningen på dette er Certificate Authorities, eller kort sagt CA.Når du installerte operativsystemet eller nettleseren, fulgte sannsynligvis en liste med pålitelige CA-er. Denne listen kan endres etter ønske; Du kan fjerne hvem du ikke stoler på, legge til andre eller til og med lage din egen CA (selv om du vil være den eneste som stoler på denne CA, så det er ikke mye å bruke for det offentlige nettstedet). I denne CA-listen lagres også CAs offentlige nøkkel.

Når Googles server sender deg sertifikatet, nevner den også at den er signert av GeoTrust. Hvis du stoler på GeoTrust, kan du bekrefte (ved hjelp av GeoTrusts offentlige nøkkel) at GeoTrust virkelig signerte serverens sertifikat. For å signere et sertifikat selv trenger du den private nøkkelen, som bare er kjent av GeoTrust. På denne måten kan en angriper ikke signere et sertifikat selv og feilaktig hevde å være Google.com. Når sertifikatet er endret med en bit, vil tegnet være feil, og klienten vil avvise det.

Så hvis jeg kjenner den offentlige nøkkelen, kan serveren bevise identiteten?

Ja. Vanligvis krypteres den offentlige nøkkelen og den private nøkkelen. Krypter en melding med serverens offentlige nøkkel, send den, og hvis serveren kan gjenta den opprinnelige meldingen, beviste den bare at den fikk den private nøkkelen uten å avsløre nøkkelen.

Dette er grunnen til at den er så viktig for å kunne stole på den offentlige nøkkelen: hvem som helst kan generere et privat / offentlig nøkkelpar, også en angriper. Du vil ikke ende opp med å bruke den offentlige nøkkelen til en angriper!

Hvis en av CA-ene du stoler på er kompromittert, kan en angriper bruke den stjålne private nøkkelen til å signere et sertifikat for et hvilket som helst nettsted de liker. Når angriperen kan sende et smidd sertifikat til klienten din, signert av ham selv med den private nøkkelen fra en CA som du stoler på, vet ikke klienten at den offentlige nøkkelen er en forfalsket, signert med en stjålet privat nøkkel.

Men en CA kan få meg til å stole på hvilken som helst server de vil ha!

Ja, og det er her tilliten kommer i. Du må stole på at CA ikke lager sertifikater som de vil. Når organisasjoner som Microsoft, Apple og Mozilla stoler på en CA, må CA imidlertid ha revisjoner. En annen organisasjon sjekker dem med jevne mellomrom for å sikre at alt fremdeles kjører i henhold til til reglene.

Utstedelse av et sertifikat gjøres hvis, og bare hvis, registranten kan bevise at de eier domenet som sertifikatet er utstedt for.

Hva er denne MAC for autentisering av meldinger?

Hver melding er signert med en såkalt Autentiseringskode for melding , eller MAC for kort. Hvis vi blir enige om en nøkkel og hashing-kryptering, kan du bekrefte at meldingen min kommer fra meg, og jeg kan bekrefte at meldingen kommer fra deg.

For eksempel med nøkkelen » riktig hestebatteriestift » og meldingen » eksempel «, Jeg kan beregne MAC » 58393 «. Når jeg sender denne meldingen med MAC til deg (du kjenner allerede nøkkelen), kan du utføre den samme beregningen og matche den beregnede MAC-en med MAC-en som jeg sendte.

En angriper kan endre meldingen men kjenner ikke nøkkelen. Han kan ikke beregne riktig MAC, og du vil vite at meldingen ikke er autentisk.

Ved å inkludere et sekvensnummer når du beregner MAC, kan du eliminere reprise angrep . SSL gjør dette.

Du sa at klienten sender en nøkkel, som deretter brukes til å konfigurere symmetrisk kryptering. Hva hindrer en angriper i å bruke den?

Serverens offentlige nøkkel gjør. Siden vi har bekreftet at den offentlige nøkkelen virkelig tilhører serveren og ingen andre, kan kryptere nøkkelen ved hjelp av den offentlige nøkkelen. Når serveren mottar denne, kan han dekryptere den med den private nøkkelen. Når noen andre mottar den, kan de ikke dekryptere den.

Dette er også grunnen til at nøkkelstørrelse er viktig: Jo større offentlig og privat nøkkel, desto vanskeligere er det å knekke nøkkelen som klienten sender til serveren.

Hvordan knekke SSL

Oppsummert :

• Prøv om brukeren ignorerer sertifikatadvarsler;
• Applikasjonen kan laste inn data fra en ukryptert kanal (f.eks. HTTP), som kan tukles med;
• En ubeskyttet påloggingsside som sendes til HTTPS, kan endres slik at den sendes til HTTP;
• Ikke-oppdaterte applikasjoner kan være sårbar for utnyttelser som BEAST og CRIME;
• Tyr til andre metoder suc h som et fysisk angrep;
• Utnytt sidekanaler som meldingslengde og tid tatt for å danne meldingen;
• Vent på kvanteangrep .

Se også: En ordning med mange angrepsvektorer mot SSL av Ivan Ristic ^(png)

I detalj:

Det er ingen enkel og rett frem vei; SSL er sikkert når det gjøres riktig. En angriper kan prøve om brukeren ignorerer sertifikatadvarsler , noe som vil ødelegge sikkerheten umiddelbart. Når en bruker gjør dette, trenger angriperen ikke en privat nøkkel fra en CA for å forfalske et sertifikat, han må bare sende et eget sertifikat.

En annen måte ville være ved en feil i applikasjon (server- eller klientsiden). Et enkelt eksempel er på nettsteder: Hvis en av ressursene som brukes av nettstedet (for eksempel et bilde eller et skript) er lastet over HTTP, kan ikke konfidensialiteten lenger garanteres. ikke send HTTP Referer-overskriften når du ber om usikre ressurser fra en sikker side ( kilde ), det er fremdeles mulig for noen som lytter til trafikken å gjette hvor du «re besøk fra; for eksempel, hvis de vet at bilder X, Y og Z brukes på en side, kan de gjette at du besøker den siden når de ser at nettleseren din ber om disse tre bildene samtidig. I tillegg, når du laster Javascript, kan hele siden bli kompromittert. En angriper kan utføre hvilket som helst skript på siden, og endre for eksempel hvem banktransaksjonen vil gå til.

Når dette skjer (en ressurs lastes over HTTP), gir nettleseren en advarsel om blandet innhold: Chrome , Firefox , Internet Explorer 9

Et annet triks for HTTP er når påloggingssiden ikke er sikret, og den sendes til en https-side. » Flott, » utvikleren trodde sannsynligvis, » nå lagrer jeg serverbelastning og passordet sendes fortsatt kryptert! » Problemet er sslstrip , et verktøy som endrer den usikre påloggingssiden slik at den sender inn et sted slik at angriperen kan lese det.

Det har også vært forskjellige angrep de siste årene, for eksempel TLS reforhandlingssårbarhet , sslsniff , BEAST , og nylig, KRIM . Alle vanlige nettlesere er imidlertid beskyttet mot alle disse angrepene, så disse sårbarhetene er ingen risiko hvis du kjører en oppdatert nettleser.

Sist, men ikke minst, kan du ty til andre metoder for å skaffe deg informasjonen som SSL nekter deg å innhente. Hvis du allerede kan se og tukle med brukerens tilkobling, er det kanskje ikke så vanskelig å erstatte en av hans / hennes .exe-nedlastinger med en keylogger, eller bare å fysisk angripe den personen. Kryptografi kan være ganske sikker, men mennesker og menneskelige feil er fremdeles en svak faktor. Ifølge denne artikkelen av Verizon , involverte 10% av datainnbruddene fysiske angrep (se side 3), så det » s absolutt noe å huske på.

Kommentarer

• Jeg vil være interessert i litt mer forklaring på » en nøkkel byttes » mot den symmetriske nøkkelen. Hvordan skjer dette at noen med en pakkesniper ikke får tilgang.
• @Yehosef Godt spørsmål! Jeg glemte å forklare det i svaret mitt. Når du ser deg rundt, viser det seg at det faktisk er et spørsmål dedikert til dette: security.stackexchange.com/q/6290/10863
• @ Iwazaru Alle CAer gjør dette siden første dag. Poenget med et sertifikat er å gi den offentlige nøkkelen til et gitt domene, og poenget med å signere det for å bevise at det virkelig er den rette nøkkelen for domenet. La ‘ s Encrypt gjør akkurat hva det skal gjøre: verifisere at du eier domenet, og signere sertifikatet ditt (med nøkkelen) hvis du kan bevise det. Nå vil alle som stoler på Let ‘ s Encrypt, som er praktisk talt alle nettlesere, stole på sertifikatet.
• Er, nei. TLS er faktisk bare implementert på toppen av TCP.
• Fant denne grafisk SSL-håndtrykkprosess , veldig tydelig.

Siden det generelle konseptet med SSL allerede har blitt dekket i noen andre spørsmål (f.eks. denne og den ene ), denne gangen vil jeg gå for detaljer. Detaljer er viktige. Dette svaret kommer til å være noe ordentlig.

Historie

SSL er en protokoll med lang historie og flere versjoner.Første prototyper kom fra Netscape da de utviklet de første versjonene av flaggskip-nettleseren deres, Netscape Navigator (denne nettleseren drepte Mosaic i de tidlige tidene av Browser Wars, som fortsatt raser, om enn med nye konkurrenter). Versjon 1 har aldri blitt offentliggjort, så vi vet ikke hvordan det så ut. SSL-versjon 2 er beskrevet i et utkast som kan leses der ; den har en rekke svakheter, noen av dem er ganske alvorlige, så den er utfaset og nyere SSL / TLS-implementeringer støtter ikke den (mens eldre er deaktivert som standard). Jeg vil ikke snakke om SSL-versjon 2 lenger, bortsett fra som en og annen referanse.

SSL-versjon 3 (som jeg vil kalle «SSLv3») var en forbedret protokoll som fremdeles fungerer i dag og støttes bredt. Selv om det fremdeles er en eiendom som tilhører Netscape Communications (eller den som eier det i dag), har protokollen blitt publisert som en «historisk RFC» ( RFC 6101 ). I mellomtiden har protokollen blitt standardisert, med et nytt navn for å unngå juridiske problemer; det nye navnet er TLS .

Tre versjoner av TLS har blitt produsert så langt, hver med sin dedikert RFC: TLS 1.0 , TLS 1.1 og TLS 1.2 . De er internt veldig like hverandre, og med SSLv3, til det punktet at en implementering lett kan støtte SSLv3 og alle de tre TLS-versjonene, med minst 95% av koden som vanlig. Fortsatt, internt, er alle versjoner betegnet med et versjonsnummer med formatet major.minor ; SSLv3 er da 3.0, mens TLS-versjonene er henholdsvis 3.1, 3.2 og 3.3. Dermed er det ikke rart at TLS 1.0 noen ganger kalles SSL 3.1 (og det er heller ikke feil). SSL 3.0 og TLS 1.0 skiller seg bare ut med noen få detaljer. TLS 1.1 og 1.2 støttes foreløpig ikke, selv om det er en drivkraft for det på grunn av mulige svakheter (se nedenfor for «BEAST-angrepet»). SSLv3 og TLS 1.0 støttes «overalt» (selv IE 6.0 kjenner dem).

Kontekst

SSL tar sikte på å gi en sikker toveis tunnel for vilkårlige data. Tenk på TCP , den velkjente protokollen for sending av data over Internett. TCP fungerer over IP «pakkene» og gir en toveis tunnel for byte; den fungerer for hver byteverdi og sender dem i to strømmer som kan fungere samtidig. TCP håndterer det harde arbeidet med å splitte dataene i pakker, anerkjenne dem, sette dem sammen igjen i riktig rekkefølge, mens du fjerner duplikater og sender ut tapte pakker. Fra synspunktet til applikasjonen som bruker TCP, er det bare to strømmer, og pakkene er usynlige; spesielt er ikke streamene delt inn i «meldinger» (det er opp til applikasjonen å ta sine egne kodingsregler hvis den ønsker å ha meldinger, og det er nøyaktig hva HTTP gjør).

TCP er pålitelig i nærvær av «ulykker», dvs. overføringsfeil på grunn av flassende maskinvare, nettverksbelastning, personer med smarttelefoner som går utenfor rekkevidden til en gitt basestasjon , og andre ikke-ondsinnede hendelser. Imidlertid kunne en uforsettlig person («angriperen») med noe tilgang til transportmediet lese alle de overførte dataene og / eller endre det med vilje, og TCP beskytter ikke mot det. SSL.

SSL antar at det fungerer over en TCP-lignende protokoll, som gir en pålitelig strøm; SSL implementerer ikke gjenoppretting av tapte pakker og sånt. Angriperen er ment å ha makt for å forstyrre kommunikasjonen helt på en uunngåelig måte (for eksempel kan han kutte kablene) så SSLs jobb er å:

• oppdag endringer (angriperen må ikke kunne endre dataene stille );
• sikre data konfidensialitet ( angriperen må ikke få kunnskap om de utvekslede dataene.

SSL oppfyller disse målene i stor grad (men ikke absolutt).

Registrerer

SSL er lagdelt og det nederste laget er protokoll . Uansett hvilken data som sendes i en SSL-tunnel, er den delt inn i poster . Over ledningen (den underliggende TCP-kontakten eller TCP-lignende medium) ser en post ut slik:

HH V1:V2 L1:L2 data

hvor:

• HH er en enkelt byte som indikerer datatypen i posten.Fire typer er definert: change_cipher_spec (20), alert (21), handshake (22) og application_data ( 23).
• V1: V2 er protokollversjonen, over to byte. For alle versjoner som for øyeblikket er definert, har V1 verdien 0x03, mens V2 har verdien 0x00 for SSLv3, 0x01 for TLS 1.0, 0x02 for TLS 1.1 og 0x03 for TLS 1.2.
• L1: L2 er lengden på data, i byte (stor endian-konvensjon er brukt: lengden er 256 * L1 + L2). Den totale lengden på data kan ikke overstige 18432 byte, men i praksis kan den ikke engang nå den verdien.

Så en post har fem- byteoverskrift, etterfulgt av maksimalt 18 kB data. data er der symmetrisk kryptering og integritetskontroll brukes. Når en post sendes ut, skal både avsender og mottaker være enige om hvilke kryptografiske algoritmer som for øyeblikket brukes, og med hvilke nøkler; denne avtalen oppnås gjennom håndtrykkprotokollen, beskrevet i neste avsnitt. Komprimering, hvis noen, blir også brukt på det tidspunktet.

I full detalj fungerer bygningen av en plate slik:

• Opprinnelig er det noen byte å overføre ; Dette er applikasjonsdata eller annen type byte. Denne nyttelasten består av maksimalt 16384 byte, men muligens mindre (en nyttelast med lengde 0 er lovlig, men det viser seg at Internet Explorer 6.0 ikke liker det i det hele tatt ) .
• Nyttelasten komprimeres deretter med den komprimeringsalgoritmen som for øyeblikket er avtalt. Komprimering er stateful og kan derfor avhenge av innholdet i tidligere poster. I praksis er komprimering enten «null» (ingen komprimering i det hele tatt) eller «Deflate» ( RFC 3749 ), sistnevnte er for øyeblikket høflig, men tydelig vist utgangen dør i nettkontekst på grunn av det nylige CRIME-angrepet . Kompresjon tar sikte på å forkorte data, men den må nødvendigvis utvide dem litt i noen ugunstige situasjoner (på grunn av pigeonhole-prinsippet ). SSL tillater en utvidelse på maksimalt 1024 byte. Selvfølgelig utvides nullkompresjon aldri (men forkorter heller ikke); Deflate vil utvides med maksimalt 10 byte hvis implementeringen er god.
• Den komprimerte nyttelasten blir deretter beskyttet mot endringer og kryptert. Hvis de nåværende krypterings- og integritetsalgoritmene er «null», er dette trinnet en ikke-operasjon. Ellers er en MAC lagt til, deretter litt polstring (avhengig av krypteringsalgoritmen), og resultatet blir kryptert. Disse trinnene induserer igjen noe utvidelse, som SSL-standarden begrenser til 1024 ekstra byte (kombinert med maksimal utvidelse fra kompresjonstrinnet, dette bringer oss til 18432 byte, som vi må legge til 5-byte-overskriften).

MAC er vanligvis HMAC med en av de vanlige hashfunksjonene (for det meste MD5, SHA-1 eller SHA-256) (med SSLv3 er dette ikke den «sanne» HMAC, men noe veldig likt og, så langt vi vet, like sikkert som HMAC). Kryptering vil enten bruke en blokkryptering i CBC-modus , eller RC4 strømkryptering. Merk at i teorien kan andre typer moduser eller algoritmer brukes, for eksempel en av disse smarte modusene som kombinerer kryptering og integritetskontroller; det er til og med noe RFC for det . I praksis vet imidlertid ikke implementerte implementeringer om disse ennå, så de gjør HMAC og CBC. Avgjørende er at MAC først blir beregnet og lagt til dataene, og resultatet blir kryptert. Dette er MAC-then-encrypt, og det er faktisk ikke . MAC beregnes over sammenkoblingen av (komprimert) nyttelast og et sekvensnummer, slik at en flittig angriper ikke kan bytte poster.

Håndtrykk

håndtrykk er en protokoll som spilles av i protokollen. Målet er å etablere algoritmene og nøklene som skal brukes til postene. Den består av meldinger . Hver håndtrykksmelding begynner med en fire-byte-overskrift, en byte som beskriver meldingstypen, deretter tre byte for lengden på meldingen (stor endian-konvensjon). De påfølgende håndtrykksmeldingene sendes deretter med poster merket med typen «håndtrykk» (den første byten i overskriften til hver post har verdien 22).

Legg merke til lagene: håndtrykkmeldingene, komplett med fire byte-overskrift, blir deretter sendt som poster, og hver post også har sin egen overskrift. Videre kan flere håndtrykkingsmeldinger sendes innenfor samme post, og en gitt håndtrykkingsmelding kan deles over flere poster.Fra synspunktet til modulen som bygger håndtrykkingsmeldingene, er «postene» bare en strøm som byte kan sendes på; den er ikke klar over den faktiske splittelsen av den strømmen i poster.

Fullt håndtrykk

I utgangspunktet er «klient og server» enige om «nullkryptering uten MAC og nullkomprimering. Dette betyr at posten de først vil sende vil bli sendt som klar tekst og ubeskyttet.

Den første meldingen til et håndtrykk er en ClientHello. Det er meldingen klienten sier at den har til hensikt å gjøre noe SSL. Merk at «klient» er en symbolsk rolle; det betyr «partiet som snakker først». Det skjer slik at i HTTPS-konteksten, som er HTTP-innenfor-SSL-i-TCP, har alle tre lagene en forestilling om «klient» og «server», og de er alle enige (TCP-klienten er også SSL-klienten og HTTP-klienten), men det er en slags tilfeldighet.

Meldingen ClientHello inneholder:

• maksimal protokoll versjon som klienten ønsker å støtte;
• «klienten tilfeldig» (32 byte, hvorav 28 skal være generert med en kryptografisk sterk tallgenerator);
• » økt-ID «(i tilfelle klienten ønsker å gjenoppta en økt i et forkortet håndtrykk, se nedenfor).
• listen over» krypteringsserier «som klienten kjenner til, sortert etter klientpreferanse;
• listen over komprimeringsalgoritmer som klienten kjenner til, ordnet etter klientpreferanse;
• noen valgfrie utvidelser.

A cipher suite er en 16-biters symbolsk identifikator for et sett med kryptografi c algoritmer. For eksempel har TLS_RSA_WITH_AES_128_CBC_SHA krypteringssuiten verdien 0x002F, og betyr «poster bruker HMAC / SHA-1 og AES-kryptering med en 128-bit nøkkel, og nøkkelutvekslingen gjøres ved å kryptere en tilfeldig nøkkel med serverens «RSA offentlige nøkkel».

Serveren svarer på ClientHello med en ServerHello som inneholder:

• protokollversjonen som klienten og serveren vil bruke;
• «server random» (32 byte, med 28 tilfeldige byte);
• økt-ID for denne forbindelsen;
• krypteringssuiten som skal brukes;
• komprimeringsalgoritmen som skal brukes;
• valgfritt, noen utvidelser.

Hele håndtrykket ser slik ut:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Dette skjemaet har blitt skamløst kopiert fra RFC.)

Vi ser ClientHello og ServerHello. Deretter sender serveren noen få andre meldinger, som avhenger av krypteringssuiten og noen andre parametere rs:

• Sertifikat: serverens sertifikat, som inneholder den offentlige nøkkelen. Mer om det nedenfor. Denne meldingen sendes nesten alltid, bortsett fra hvis krypteringspakken pålegger et håndtrykk uten sertifikat.
• ServerKeyExchange: noen ekstra verdier for nøkkelutvekslingen, hvis det som er i sertifikatet ikke er tilstrekkelig. Spesielt bruker «DHE» -kodingssuitene en kortvarig Diffie-Hellman nøkkelutveksling, som krever den meldingen.
• CertificateRequest: en melding som ber om at klienten også identifiserer seg med et eget sertifikat. Denne meldingen inneholder listen over navn på tillitsankre (også kalt «rotsertifikater») som serveren vil bruke til å validere klientsertifikatet.
• ServerHelloDone: en markørmelding (med lengde null) som sier at serveren er ferdig, og klienten skal nå snakke.

Klienten må da svare med:

• Sertifikat: klientsertifikatet, if serveren ba om en. Det er subtile variasjoner mellom versjoner (med SSLv3 må klienten utelate denne meldingen hvis den ikke har et sertifikat; med TLS 1.0+ må den i samme situasjon sende en Certificate melding med en tom liste med sertifikater).
• ClientKeyExchange: klientdelen av selve nøkkelutvekslingen (f.eks. noen tilfeldig verdi kryptert med serverens RSA-nøkkel).
• CertificateVerify: a digital signatur beregnet av klienten over alle tidligere håndtrykksmeldinger. Denne meldingen sendes når serveren ba om et klientsertifikat, og klienten fulgte. Slik viser klienten til serveren at den virkelig «eier» den offentlige nøkkelen som er kodet i sertifikatet den sendte.

Deretter sender klienten en ChangeCipherSpec melding, som ikke er en håndtrykksmelding: den har sin egen posttype, så den vil bli sendt i en egen post.Innholdet er rent symbolsk (en enkelt byte med verdi 1). Denne meldingen markerer hvor klienten bytter til den nylig forhandlede krypteringssuiten og nøklene. De påfølgende postene fra klienten blir deretter kryptert.

Ferdig -meldingen er en kryptografisk kontrollsum beregnet over alle tidligere håndtrykksmeldinger (fra både klienten og serveren). Siden den sendes ut etter ChangeCipherSpec, dekkes den også av integritetskontrollen og krypteringen. Når serveren mottar meldingen og verifiserer innholdet, får den et bevis på at den faktisk har snakket med samme klient hele tiden. Denne meldingen beskytter håndtrykket mot endringer (angriperen kan ikke endre håndtrykksmeldingene og fremdeles få Finished -meldingen riktig).

Serveren svarer til slutt med sin egen ChangeCipherSpec deretter Finished. På det tidspunktet er håndtrykket ferdig, og klienten og serveren kan utveksle applikasjonsdata (i krypterte poster merket som sådan).

Husk: klienten foreslår men serveren velger . Krypteringssuiten er i hendene på serveren. Høflige servere skal følge kundens preferanser (hvis mulig), men de kan gjøre noe annet, og noen gjør det faktisk (f.eks. Som en del av beskyttelsen mot BEAST).

Forkortet håndtrykk

I det fulle håndtrykket sender serveren en «økt-ID» (dvs. en haug med opptil 32 byte) til klienten. Senere kan klienten komme tilbake og sende samme økt-ID som en del av ClientHello. Dette betyr at klienten fremdeles husker krypteringspakken og nøklene fra forrige håndtrykk og ønsker å bruke disse parametrene på nytt. Hvis serveren også husker krypteringsserien og nøklene, kopierer den den spesifikke økt-ID-en i ServerHello, og følger deretter forkortet håndtrykk :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Det forkortede håndtrykket er kortere: færre meldinger, nei asymmetrisk kryptografivirksomhet, og, viktigst av alt, redusert ventetid . Nettlesere og servere gjør det mye. En typisk nettleser åpner en SSL-tilkobling med et fullstendig håndtrykk, og gjør deretter forkortede håndtrykk for alle andre tilkoblinger til samme server: de andre tilkoblingene den åpnes parallelt, og også de påfølgende tilkoblingene til samme server. Typiske webservere vil faktisk lukke forbindelser etter 15 sekunders inaktivitet, men de vil huske økter (krypteringssuiten og nøklene) mye lenger (muligens i flere timer eller til og med dager).

Nøkkelutveksling

Det er flere nøkkelutvekslingsalgoritmer som SSL kan bruke. Dette er spesifisert av krypteringssuiten; hver nøkkelutvekslingsalgoritme fungerer med noen typer servernøkkel. De vanligste nøkkelutvekslingsalgoritmene er:

• RSA: serverens nøkkel er av typen RSA. Klienten genererer en tilfeldig verdi (» pre-master hemmelighet «på 48 byte, hvorav 46 er tilfeldige) og krypterer den med serverens offentlige nøkkel. Det er ingen ServerKeyExchange.
• DHE_RSA: serverens nøkkel er av typen RSA, men brukes bare til Den faktiske nøkkelutvekslingen bruker Diffie-Hellman. Serveren sender en ServerKeyExchange -melding som inneholder DH-parametrene (modul, generator) og en nylig generert DH-nøkkel. Dessuten serveren signerer denne meldingen. Klienten vil svare med en ClientKeyExchange -melding som også inneholder en nylig generert DH-offentlig nøkkel. DH gir «pre-master secret» «.
• DHE_DSS: som DHE_RSA, men serveren har en DSS-nøkkel (» DSS «er også kjent som «DSA» ). DSS er en eneste signaturalgoritme.

Mindre vanlige nøkkelutvekslingsalgoritmer inkluderer:

• DH: serverens nøkkel er av typen Diffie-Hellman (vi snakker om et sertifikat som inneholder et DH-tast). Dette pleide å være «populært» på en administrativ måte (den amerikanske føderale regjeringen ga mandat for bruken) da RSA-patentet fremdeles var aktivt (dette var i forrige århundre). Til tross for det byråkratiske presset, ble det aldri så bredt distribuert som RSA.
• DH_anon: som DHE suitene, men uten signatur fra serveren. Dette er en sertifikatfri krypteringspakke. Ved bygging er den sårbar for Man-in-the-Middle angrep , og er derfor svært sjelden aktivert i det hele tatt.
• PSK: forhåndsdelt nøkkel krypteringssuiter. Den eneste symmetriske nøkkelutvekslingen, som bygger på en forhåndsinnstilt delt hemmelighet.
• SRP: anvendelsen av SRP-protokollen som er en Passordgodkjent nøkkelutveksling -protokoll. Klient og server autentiserer hverandre med hensyn til en delt hemmelighet, som kan være et passord med lav entropi (mens PSK krever en delt hemmelighet med høy entropi). Veldig kjekk. Støttes ikke allment ennå.
• En kortvarig RSA-nøkkel: som DHE men med et nylig generert RSA-nøkkelpar. Siden generering av RSA-nøkler er dyrt, er dette ikke et populært alternativ, og ble bare spesifisert som en del av «eksport» -krypteringssuiter som overholdt de amerikanske eksportbestemmelsene om kryptografi før 2000 (dvs. RSA-nøkler på maksimalt 512 bits). Ingen gjør det i dag.
• Varianter av DH* algoritmer med elliptiske kurver . Veldig fasjonabelt. Skal bli vanlig i fremtiden.

Sertifikater og autentisering

Digitale sertifikater er fartøy for asymmetriske nøkler. De er ment å løse nøkkelfordeling. Klienten ønsker nemlig å bruke serveren « offentlig nøkkel . Angriperen vil prøve å få klienten til å bruke angriperens» offentlige nøkkel. Så klienten må ha en måte å sikre seg at den bruker riktig nøkkel.

SSL skal bruke X.509 . Dette er en standard for sertifikater. Hvert sertifikat er signert av en sertifiseringsmyndighet . Tanken er at klienten iboende kjenner de offentlige nøklene til en håndfull CA (dette er «tillitsankre» eller «rotsertifikater»). Med disse nøklene kan klienten verifisere signaturen beregnet av en CA over et sertifikat som er utstedt til serveren. Denne prosessen kan utvides rekursivt: en CA kan utstede et sertifikat for en annen CA (dvs. signere sertifikatstrukturen som inneholder det andre CA-navnet og nøkkelen). En kjede av sertifikater som begynner med en rot-CA og slutter med serverens sertifikat, med mellomliggende CA-sertifikater i mellom, og hvert sertifikat blir signert relativt til den offentlige nøkkelen som er kodet i forrige sertifikat, kalles fantasiløst en sertifikatkjede .

Så klienten skal gjøre følgende:

• Få en sertifikatkjede som slutter med serverens sertifikat. Certificate -meldingen fra serveren skal inneholde nettopp en slik kjede.
• Valider kjeden, dvs. bekreft alle signaturer og navn og de forskjellige X.509 bitene. Kunden bør også sjekke tilbakekallingsstatus for alle sertifikatene i kjeden, som er kompleks og tung (nettlesere gjør det nå, mer eller mindre, men det er en nylig utvikling).
• Bekreft at det tiltenkte servernavnet faktisk er skrevet i serverens sertifikat. Fordi klienten ikke bare vil bruke en validert offentlig nøkkel, den vil også bruke den offentlige nøkkelen til en bestemt server . Se RFC 2818 for detaljer om hvordan dette gjøres i en HTTPS-kontekst .

Sertifiseringsmodellen med X.509-sertifikater har ofte blitt kritisert, ikke egentlig av tekniske grunner, men heller av politisk-økonomiske årsaker. Den konsentrerer valideringsmakt i hendene på noen få aktører , som ikke nødvendigvis er velmenende, eller i det minste ikke alltid kompetente . Nå og igjen publiseres forslag til andre systemer (f.eks. Konvergens eller

Etter den lange presentasjonen av SSL i forrige svar , la oss gå med de morsomme tingene, nemlig:

Angrep på SSL

Det har vært mange angrep på SSL, noen bygger på implementeringsfeil, andre på sanne protokollsvakheter.

Man må huske at mens SSL er en av de mest angrepne protokollene (siden det er veldig høyt profilert: en vellykket applikasjon til SSL ser veldig fin ut i sammendraget av en forskningsartikkel), SSL er også en av de mest reparerte protokollene.Det er å anse for å være robust nettopp fordi alle kjente måter å angripe transportprotokoller er prøvd på SSL, og SSL har blitt lappet der det er hensiktsmessig.

Versjon tilbakeføring

I de første dagene av SSLv3 ble SSLv2 fortsatt mye brukt, og derfor sendte klienter ofte SSLv2-kompatible ClientHello meldinger, som bare antydet at SSLv3 også ble støttet; serveren vil da ta hintet og svare i SSLv3 + dialekt (se vedlegg E til RFC 2246 for detaljer). Siden SSLv2 hadde svakheter, var det i den beste interesse for angriperen å sørge for at en klient og server, begge kjenner SSLv3, likevel snakket med hverandre ved hjelp av SSLv2. Dette kalles et versjonsangrep angrep . Konseptet strekker seg formelt også til senere versjoner.

Kludges er lagt til for å oppdage tilbakeføringsforsøk. For tilbakeslag til SSLv2-tilbakeslag, bør en klient som kjenner SSLv3 + bruke en spesiell polstring for RSA-krypteringstrinnet (SSLv2 støttet bare RSA-basert nøkkelutveksling): i PKCS # 1 , skal dataene som skal krypteres være polstret med et antall tilfeldige byte; en SSLv3-klar klient skal da sette hver av de siste åtte polstringsbyte til den faste verdien 0x03. Serveren sjekker deretter disse byte; hvis de åtte 0x03 blir funnet, er det sannsynlig at en tilbakestilling blir forsøkt, og serveren avviser forsøket (en SSLv2-eneste klient har sannsynlighet bare 255 ^-8 for å bruke slike polstringsbyte på grunn av mangel på flaks, så falske positive oppstår med en ubetydelig hastighet).

For tilbakefall til en gammel versjon av SSL / TLS, men ikke eldre enn SSLv3, ble det lagt til en annen kludge: i pre-master-hemmeligheten av 48 byte som klienten krypterer med serverens RSA-nøkkel, er de to første byte ikke tilfeldige, men skal være lik den «maksimale støttede protokollversjonen» som klienten skrev først i sin ClientHello -melding. Dessverre fikk noen klienter feil, og denne kludgen fungerer bare med en RSA-basert nøkkelutveksling, så beskyttelsen mot tilbakeføring er veldig begrenset der. Heldigvis har SSLv3 + en annen, mye kraftigere beskyttelse mot tilbakestillinger, det vil si at meldinger om håndtrykk blir hashet sammen når Finished -meldingene er bygget. Denne pro tekter mot tilbakeslag med mindre den «gamle versjonen» ville være så grundig svak at angriperen totalt kunne bryte hele krypteringen før selve håndtrykket var over. Dette har ikke skjedd ennå (SSLv3 er fortsatt rimelig robust).

Svake krypteringssuiter

Noen av de standard krypteringssuitene er med vilje svake på en eller annen måte. Det er:

• noen krypteringssuiter uten kryptering i det hele tatt, bare integritetskontroll, f.eks. TLS_RSA_WITH_NULL_SHA;
• noen krypteringsserier med 40-biters kryptering, for eksempel TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (krypteringsserier ment å overholde de strenge amerikanske eksportreglene fra forrige århundre – disse reglene er for det meste opphevet på slutten av Bill Clinton-epoken);
• noen krypteringssuiter med 56-biters kryptering, for eksempel TLS_RSA_WITH_DES_CBC_SHA. 56-bit DES kan brytes med eksisterende teknologi , men det er fremdeles litt vanskelig for en amatør (til og med en kjedelig student med tilgang til noen få hundre universitetsmaskiner ), så jeg pleier å kvalifisere 56-bit DES som «medium styrke».

Dette åpner veien for en variant av tilbakeføringsangrep, der angriperen tvinger klient og server til å bli enige på en svak krypteringssuite, idet ideen er at angriperen endrer listen over krypteringssuiter som kunden har kunngjort. Dette kan fungere for angriperen hvis den valgte krypteringssuiten er så svak at han kan bryte den for å beregne en tilsynelatende korrekt div id = «82a2dff0c6»>