Nyheter har nettopp dukket opp at Apple, Cloudflare, Fastly og Mozilla har samarbeidet om å forbedre krypteringen av servernavnidentifikasjonsmekanismen til HTTPS ved IETF 102 Hackathon, som indikert av en tweet fra Cloudflares Nick Sullivan. Tweeten gratulerte blandeteamet fra de fire teknologiske gigantene med å si 'Fantastisk arbeid' og delte det under lenker til de fungerende serverne på esni.examp1e.net og cloudflare-esni.com .
Fantastisk arbeid på IETF 102 hackathon av det krypterte SNI-teamet som består av folk fra @Cloudflare @ raskt @mozilla og @eple . Det er nå implementeringer i BoringSSL, NSS og picotls.
Arbeidsservere er live på https://t.co/sLI9xLRjlK og https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15. juli 2018
IETF Hackathon er en plattform som inviterer unge utviklere og teknologientusiaster til å delta i hodet i utarbeidelse av løsninger for teknologirelaterte problemer som den vanlige brukeren står overfor i dag. Arrangementene er gratis å delta, åpne for alle, og de oppfordrer teamarbeid i motsetning til konkurranse. Årets IETF Hackathon ble arrangert i Montreal den 14thog 15thjuli. Det ser ut til at den mest fremtredende prestasjonen som kommer ut av det, er krypteringen av Transport Layer Security (TLS) Server Name Indication (SNI), et problem som har plaget utviklere det siste tiåret, et som medlemmer av Apple, Cloudflare, raskt , og Mozilla har nå foreslått en løsning på.
IETF Hackathon-begivenhet. IETF
Det har vært en klar global endring fra Hyper Text Transfer Protocol (HTTP) til Transport Layer Security Server Name Indication Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) i løpet av det siste halvannet tiåret. De problem som steg ut av å optimalisere TLS SNI HTTPS-systemet, var hackers evne til å bruke SNI mot formålet med å matche dataoverføring for dekryptering senere.
Før utviklingen av SNI var det vanskelig å etablere sikre forbindelser til flere virtuelle servere med samme første klienthåndtrykk. Når en IP-adresse interagerte med en server, byttet de to 'helvete', serveren sendte sertifikatene, datamaskinen sendte klientnøkkelen, de to byttet ut 'ChangeCipherSpec' -kommandoer, og deretter ble interaksjonen avsluttet da en forbindelse ble opprettet. Dette kan høres enkelt ut som det nettopp er blitt sagt, men prosessen involverte flere utvekslinger og svar som lett klarte å bli ganske problematiske ettersom antall servere som kommuniseres med økte. Hvis alle nettstedene brukte de samme sertifikatene, var dette ikke mye av et problem, men dessverre var det sjelden tilfelle. Når flere nettsteder sendte forskjellige sertifikater frem og tilbake, var det vanskelig for serveren å avgjøre hvilket sertifikat datamaskinen lette etter, og i det komplekse nettet av utvekslinger ble det vanskelig å identifisere hvem som sendte hva og når, og dermed avsluttet hele aktiviteten med en advarsel helt.
TLS SNI ble deretter introdusert i juni 2003 gjennom et IETF-toppmøte, og formålet det tjente på sett og vis var å lage navnelapper for datamaskiner og tjenester involvert i utvekslingsnettet. Dette gjorde server-klienten hei utvekslingsprosess mye mer rett frem da serveren var i stand til å gi de nøyaktige sertifikatene som trengs, og de to ble gjort i stand til å ha sin egen samtaleutveksling uten å bli forvirret om hvem som sa hva. Det er litt som å ha kontaktnavn for chatter og ikke bli forvirret om hvor meldingene kommer fra, og å også kunne svare på hvert spørsmål på riktig måte og levere de riktige dokumentene til hvilken datamaskin som trenger det. Denne SNI-definisjonen er akkurat det som førte til det største problemet med denne metoden for å optimalisere utvekslingsprosessen.
Kampen mange firmaer møtte med å bytte til HTTPS var tilpasningen av mange sertifikater til SNI-formatet med individuelle IP-adresser for å utføre forespørsler om hvert sertifikat. Det TLS gjorde for dem, var å gjøre det enklere å generere sertifikater for å svare på slike forespørsler, og det SNI gjorde enda lenger, var å fjerne behovet for individualiserte dedikerte sertifikat-IP-adresser ved å kaste inn et helt identifikasjonssystem over hele internettnettverket. Det som fulgte med oppgraderingen av århundret var det faktum at det tillot hackere å bruke de etablerte 'kontaktnavnene' til å overvåke og skygge dataoverføring og trekke ut informasjonen de trenger for å dekryptere på et senere tidspunkt.
Selv om TLS tillot at data sendes frem og tilbake i en kryptert kanal, med SNI som sørger for at den når riktig destinasjon, ga sistnevnte også midler for hackere til å overvåke online aktivitet og matche den til kilden ved å følge DNS-forespørsler, IP-adresser og datastrømmer. Selv om strengere SNI-kodingsregler er implementert ved å føre DNS-informasjon gjennom TLS-kanalen, gjenstår det et lite vindu for hackere for å kunne bruke dette som et identifikasjonsmiddel for å følge informasjonen de ønsker å hente ut og isolere den for dekryptering. Komplekse servere som håndterer større trafikk av TLS-krypterte data, bruker ren tekst SNI til å sende kommunikasjonen rundt på serverne sine, og det er det som gjør det lettere for hackere å identifisere kanalene og informasjonsstrømmene de vil følge. Når en hacker er i stand til å trekke ut SNI-informasjonen om dataene av interesse, er han / hun i stand til å sette opp en falsk reprise av kommandoen i en separat TLS-forbindelse med serveren, sende inn stjålet SNI-informasjon og hente informasjonen som var assosiert med det. Det har vært flere forsøk på å løse dette SNI-problemet tidligere, men de fleste har gått imot enkelhetsprinsippet som SNI arbeider for å gjøre det til en praktisk identifikasjonsmetode for servere.
Tilbake til toppmøtet som først jobbet med å etablere denne metoden, har deltakere fra fire teknologiske giganter returnert til konferansen i Montreal for å utvikle en kryptering for TLS SNI, for til tross for større effektivitet i det multi HTTPS tilstøtende systemet, er sikkerhet fortsatt en bekymring bare så mye som det gjorde før.
For å skjule SNI i TLS, må en 'skjult tjeneste' holdes under visningen av en 'Fronting Service' som hackeren kan se. Uten å være i stand til å observere den skjulte tjenesten direkte, vil hackeren bli villedet av den forkledde forkledning som den gjemmer seg under i ren tekst uten å kunne identifisere de underliggende hemmelige tjenesteparametrene som brukes til å videreformidle de krypterte dataene. Når observatøren følger stien til fronttjenesten, vil dataene bli fjernet fra den observerte kanalen når de blir omdirigert til den tiltenkte skjulte tjenesten, på hvilket tidspunkt hackeren vil ha mistet stien. Siden serveren også vil bli eksponert for fronting-tjenesten, når dataene tar veien dit, vil et andre parallelt SNI-signal bli sendt til fronting-tjenesten for å omdirigere dataene mot den skjulte tjenesten og i denne retningsendringsprosessen vil hackeren gå tapt på nettet til serveren. Denne mekanismen med dobbeltbilletter er videreutviklet til en kombinert billett under samme SNI. Når ett stykke data sendes til serveren, produserer dataene en samarbeidende SNI-regissør, og de to arbeider sammen for å få TLS-krypterte data dit de skal. Uten å være i stand til å knekke den randomiserte fronttjenesten som dekker begge SNI-sporene, vil ikke hackeren kunne følge sporene til dataene, men serveren vil fremdeles være i stand til å koble de to og dekryptere den skjulte tjenesten som dataens ultimate plassering. Dette gjør det mulig for servere å fortsette å bruke SNI for å optimalisere dataoverføringen i TLS-kryptering, samtidig som de sikrer at hackere ikke er i stand til å dra nytte av SNI-mekanismen.
