Nyheter har just dykt upp att Apple, Cloudflare, Fastly och Mozilla har samarbetat för att förbättra krypteringen av HTTPS-mekanismen för servernamn vid IETF 102 Hackathon, vilket indikeras av en tweet från Cloudflares Nick Sullivan. Tweeten gratulerade mixteamet från de fyra tekniska giganterna genom att säga 'Fantastiskt arbete' och dela där under länkar till de fungerande servrarna på esni.examp1e.net och cloudflare-esni.com .
Fantastiskt arbete vid IETF 102 hackathon av det krypterade SNI-teamet som består av folk från @Cloudflare @snabbt @mozilla och @äpple . Det finns nu implementeringar i BoringSSL, NSS och picotls.
Arbetsservrar är live på https://t.co/sLI9xLRjlK och https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 juli 2018
IETF Hackathon är en plattform som inbjuder unga utvecklare och teknikentusiaster att gå med i huvuden för att utarbeta lösningar för tekniska frågor som den vanliga användaren står inför idag. Händelserna är gratis att gå med, öppna för alla, och de uppmuntrar lagarbete i motsats till konkurrens. Årets IETF Hackathon hölls i Montreal den 14thoch 15thi juli. Det verkar som om den mest framträdande prestationen att komma ut ur den är krypteringen av Transport Layer Security (TLS) Server Name Indication (SNI), ett problem som har plågat utvecklare under det senaste decenniet, ett som medlemmar av Apple, Cloudflare, snabbt , och Mozilla har nu föreslagit en lösning på.
IETF Hackathon-händelse. IETF
Det har skett ett tydligt globalt skifte från Hyper Text Transfer Protocol (HTTP) till Transport Layer Security Server Namnindikation Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) under det senaste decenniet. De problem som steg ut ur att optimera TLS SNI HTTPS-systemet var hackarens förmåga att använda SNI mot dess syfte att matcha dataöverföring för dekryptering senare.
Innan SNI utvecklades var det svårt att upprätta säkra anslutningar till flera virtuella servrar med samma första klienthandskakning. När en IP-adress interagerade med en server utbytte de två 'helvete', servern skickade sina certifikat, datorn skickade sin klientnyckel, de två utbytte 'ChangeCipherSpec' -kommandon och sedan avslutades interaktionen när en anslutning upprättades. Det här låter kanske lätt som det just har sagts men processen involverade flera utbyten och svar som lätt lyckades bli ganska problematiska eftersom antalet servrar som kommuniceras med ökade. Om alla sajter använde samma certifikat var det inte så mycket problem, men tyvärr var det sällan fallet. När flera webbplatser skickade olika certifikat fram och tillbaka var det svårt för servern att avgöra vilket certifikat datorn letade efter och i det komplexa nätet av utbyten blev det svårt att identifiera vem som skickade vad och när och därmed avslutade hela aktiviteten med ett varningsmeddelande helt och hållet.
TLS SNI introducerades sedan i juni 2003 genom ett IETF-toppmöte och syftet med det på sätt och vis var att skapa namnskyltar för datorerna och tjänsterna som var inblandade i utbytesnätet. Detta gjorde server-klientens hejutbytesprocess mycket mer rakt fram eftersom servern kunde tillhandahålla exakta certifikat som behövdes och de två kunde ha ett eget konversationsutbyte utan att bli förvirrade över vem som sa vad. Det är lite som att ha kontaktnamn för chattar och inte bli förvirrad över var meddelandena kommer från, och att kunna svara på varje fråga på lämpligt sätt och tillhandahålla rätt dokument till vilken dator som helst som behöver det. Denna SNI-definition är exakt vad som orsakade det största problemet med denna metod för att optimera utbytesprocessen.
Kampen som många företag mötte när de bytte till HTTPS var anpassningen av många certifikat till SNI-formatet med enskilda IP-adresser för att utföra förfrågningar för varje certifikat. Det TLS gjorde för dem var att göra det enklare att generera certifikat för att svara på sådana förfrågningar och vad SNI gjorde ännu mer var att ta bort behovet av individualiserade dedikerade certifikat IP-adresser genom att kasta in ett helt identifieringssystem över hela nätverket av internet. Det som kom med århundradets uppgradering var det faktum att det tillät hackare att använda de etablerade ”kontaktnamnen” för att övervaka och skugga dataöverföring och extrahera den information de behöver för att dekryptera i ett senare skede.
Även om TLS tillät data att skickas fram och tillbaka i en krypterad kanal, med SNI som säkerställer att den når rätt destination, tillhandahöll den senare också medel för hackare att övervaka onlineaktivitet och matcha den till sin källa genom att följa DNS-förfrågningar, IP-adresser och dataströmmar. Även om strängare SNI-kodningspolicyer har implementerats genom att även DNS-information skickas genom TLS-kanalen, är det ett litet fönster kvar för hackare att kunna använda detta som ett identifieringsmedel för att följa den information de vill extrahera och isolera den för dekryptering. Komplexa servrar som hanterar större trafik av TLS-krypterad data använder SNI för klartext för att skicka kommunikationen runt på sina servrar och det är det som gör det lättare för hackare att identifiera de kanaler och strömmar av information som de vill följa. När en hackare kan extrahera SNI-informationen av intressanta data, kan han / hon skapa en faux-uppspelning av kommandot i en separat TLS-anslutning till servern, skicka in SNI-information som stulits och hämta informationen som var associerad med det. Det har gjorts flera försök att lösa detta SNI-problem tidigare men de flesta har gått emot enkelhetsprincipen som SNI arbetar för att göra det till en bekväm identifieringsmetod för servrar.
Tillbaka till toppmötet som först arbetade för att upprätta denna metod har deltagare från fyra tekniska giganter återvänt till konferensen i Montreal för att utveckla en kryptering för TLS SNI, för trots den större effektiviteten i det flera HTTPS-angränsande systemet är säkerheten fortfarande ett problem bara lika mycket som det gjorde tidigare.
För att dölja SNI i TLS måste en 'Hidden Service' förvaras under showen av en 'Fronting Service' som hackaren kan se. Utan att kunna observera den dolda tjänsten direkt kommer hackaren att vilseledas av den främre förklädnad som den gömmer sig i i vanlig text utan att kunna identifiera de underliggande hemliga tjänsteparametrarna som används för att vidarebefordra den krypterade data. När observatören följer spåren för fronttjänsten kommer data att tas bort från den observerade kanalen när den omdirigeras till den avsedda dolda tjänsten vid vilken tidpunkt hackaren förlorar sitt spår. Eftersom servern också kommer att exponeras för fronting-tjänsten, när data tar sig dit, kommer en andra parallell SNI-signal att skickas till fronting-tjänsten för att omdirigera data mot den dolda tjänsten och i denna riktningsförändringsprocess kommer hackaren att gå förlorade på servern. Denna mekanism för dubbelbiljetter utvecklas vidare till en kombinerad biljett under samma SNI. När en bit data skickas till servern, producerar data en samarbetsvillig SNI-regissör och de två arbetar tillsammans för att få TLS-krypterad data dit den behöver. Utan att kunna knäcka den randomiserade frontingtjänsten som täcker båda SNI-spåren kommer hackaren inte att kunna följa spåren av data men servern kommer fortfarande att kunna ansluta de två och dekryptera den dolda tjänsten som dataens ultimata plats. Detta gör det möjligt för servrar att fortsätta använda SNI för att optimera sin dataöverföring i TLS-kryptering och samtidigt se till att hackare inte kan dra nytta av SNI-mekanismen.
