Nyheder er netop kommet frem, at Apple, Cloudflare, Fastly og Mozilla har samarbejdet om at forbedre krypteringen af servernavnsidentifikationsmekanismen for HTTPS ved IETF 102 Hackathon som angivet af en tweet fra Cloudflares Nick Sullivan. Tweeten lykønskede mix-teamet fra de fire tech-giganter ved at sige 'Awesome work' og delte der under links til de fungerende servere på esni.examp1e.net og cloudflare-esni.com .
Fantastisk arbejde på IETF 102 hackathon af det krypterede SNI-team bestående af folk fra @Cloudflare @ hurtigt @mozilla og @æble . Der er nu implementeringer i BoringSSL, NSS og picotls.
Arbejdende servere er live på https://t.co/sLI9xLRjlK og https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15. juli 2018
IETF Hackathon er en platform, der inviterer unge udviklere og tech-entusiaster til at deltage i hovedet i udarbejdelsen af løsninger til teknologirelaterede problemer, som den almindelige bruger står over for i dag. Arrangementerne er gratis at deltage, åbne for alle, og de tilskynder til teamwork i modsætning til konkurrence. Årets IETF Hackathon blev afholdt i Montreal den 14thog 15thjuli. Det ser ud til, at den mest fremtrædende bedrift, der kommer ud af det, er krypteringen af Transport Layer Security (TLS) Server Name Indication (SNI), et problem, der har plaget udviklere i det sidste årti, et som medlemmer af Apple, Cloudflare, hurtigt og Mozilla har nu foreslået en løsning på.
IETF Hackathon begivenhed. IETF
Der har været et klart globalt skifte fra Hyper Text Transfer Protocol (HTTP) til Transport Layer Security Server Indikation Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) i det sidste halvandet årti. Det problem der steg ud af optimering af TLS SNI HTTPS-systemet var hackers evne til at bruge SNI mod dets formål at matche dataoverførsel til dekryptering senere.
Før udviklingen af SNI var det vanskeligt at etablere sikre forbindelser til flere virtuelle servere ved hjælp af det samme første klienthåndtryk. Når en IP-adresse interagerede med en server, udvekslede de to 'helvede', serveren sendte sine certifikater, computeren sendte sin klientnøgle, de to udvekslede 'ChangeCipherSpec' -kommandoer, og derefter blev interaktionen afsluttet, da en forbindelse blev oprettet. Dette lyder måske let, som det lige er blevet sagt, men processen involverede flere udvekslinger og svar, som let formåede at blive ret problematiske, da antallet af servere, der kommunikeres med, steg. Hvis alle webstederne brugte de samme certifikater, var dette ikke meget af et problem, men desværre var det sjældent tilfældet. Når flere sider sendte forskellige certifikater frem og tilbage, var det vanskeligt for serveren at bestemme, hvilket certifikat computeren ledte efter, og i det komplekse udvekslingsnet blev det vanskeligt at identificere, hvem der sendte hvad og hvornår og derved afslutte hele aktiviteten med en advarselsmeddelelse helt.
TLS SNI blev derefter introduceret i juni 2003 gennem et IETF-topmøde, og formålet med det på en måde var at oprette navneskilte til de computere og tjenester, der var involveret i udvekslingsnettet. Dette gjorde server-klient-hej-udvekslingsprocessen meget mere ligetil, da serveren var i stand til at levere de nøjagtige certifikater, der var nødvendige, og de to blev gjort i stand til at have deres egen samtaleudveksling uden at blive forvirret over, hvem der sagde hvad. Det er lidt som at have kontaktnavne til chats og ikke blive forvirret over, hvor meddelelserne kommer fra, og også være i stand til at svare på hver forespørgsel korrekt og levere de rigtige dokumenter til den computer, der har brug for det. Denne SNI-definition er præcis det, der fik det største problem med denne metode til optimering af udvekslingsprocessen.
Kampen, som mange firmaer stod over for ved at skifte til HTTPS, var tilpasningen af mange certifikater til SNI-formatet med individuelle IP-adresser for at udføre anmodninger om hvert certifikat. Hvad TLS gjorde for dem var at gøre det nemmere at generere certifikater til at svare på sådanne anmodninger, og hvad SNI gjorde endnu mere var at fjerne behovet for individualiserede dedikerede certifikat-IP-adresser ved at smide et helt identifikationssystem på tværs af hele internetnetværket. Hvad der fulgte med århundredets opgradering var, at det tillod hackere at bruge de etablerede 'kontaktnavne' til at overvåge og skygge dataoverførsel og udtrække de oplysninger, de har brug for til at dekryptere på et senere tidspunkt.
Selvom TLS tillod, at data sendes frem og tilbage i en krypteret kanal, med SNI, der sikrer, at de når den korrekte destination, tilvejebragte sidstnævnte også midler til hackere til at overvåge onlineaktivitet og matche den til dens kilde ved at følge DNS-anmodninger, IP-adresser og datastrømme. Selvom strengere SNI-kodningspolitikker er blevet implementeret ved at videregive DNS-information gennem TLS-kanalen, er der stadig et lille vindue for hackere, der kan bruge dette som et identifikationsmiddel til at følge det stykke information, de gerne vil udtrække og isolere det til dekryptering. Komplekse servere, der beskæftiger sig med større trafik af TLS-krypterede data, bruger SNI i almindelig tekst til at sende kommunikationen rundt på deres servere, og det er det, der gør det lettere for hackere at identificere de kanaler og strømme af information, som de ønsker at følge. Når en hacker er i stand til at udtrække SNI-informationen af de relevante data, er han / hun i stand til at oprette en faux-replay af kommandoen i en separat TLS-forbindelse med serveren, sende SNI-oplysninger stjålet og hente de oplysninger, der var forbundet med det. Der har været adskillige forsøg på at løse dette SNI-problem tidligere, men de fleste har været imod det enkelhedsprincip, som SNI arbejder på for at gøre det til en bekvem identifikationsmetode for servere.
Tilbage til topmødet, der først arbejdede for at etablere denne metode, er deltagere fra fire tech-giganter vendt tilbage til konferencen i Montreal for at udvikle en kryptering til TLS SNI, for på trods af den større effektivitet i det multi HTTPS tilstødende system er sikkerhed stadig et problem så meget som det gjorde før.
For at skjule SNI i TLS skal en 'skjult tjeneste' holdes under showet af en 'Fronting Service', som hackeren kan se. Uden at være i stand til direkte at observere den skjulte tjeneste vil hacker blive vildledt af den forklædning, som den skjuler under, i almindelig tekst uden at være i stand til at identificere de underliggende hemmelige serviceparametre, der bruges til at videregive de krypterede data. Når observatøren følger sporet af frontingtjenesten, fjernes dataene fra den observerede kanal, da de omdirigeres til den tilsigtede skjulte tjeneste, på hvilket tidspunkt hackeren har mistet sin spor. Da serveren også vil blive eksponeret for fronting-tjenesten, når dataene finder vej der, vil et andet parallelt SNI-signal blive sendt til fronting-tjenesten for at omdirigere dataene mod den skjulte service og i denne retningsændringsproces vil hackeren gå tabt på serveren. Denne mekanisme med dobbeltbilletter udvikles yderligere til en kombineret billet under samme SNI. Da et stykke data sendes til serveren, frembringer dataene en samarbejdende SNI-re-direktør, og de to arbejder sammen for at få TLS-krypterede data til, hvor de skal hen. Uden at være i stand til at knække den randomiserede frontingtjeneste, der dækker begge SNI-spor, vil hacker ikke være i stand til at følge sporet af data, men serveren vil stadig være i stand til at forbinde de to og dekryptere den skjulte tjeneste som datas ultimative placering. Dette gør det muligt for servere at fortsætte med at bruge SNI til at optimere deres dataoverførsel i TLS-kryptering, samtidig med at det sikres, at hackere ikke er i stand til at udnytte SNI-mekanismen.
