🥇Hur man skyddar sin offentliga webbplats med ESNI

Hej Habr, jag heter Ilya och jag arbetar i plattformsteamet på företaget Exness. Vi utvecklar och implementerar grundläggande infrastrukturella komponenter som våra produktutvecklingsteam använder.

I den här artikeln skulle jag vilja dela med mig av erfarenheten av att implementera teknologin encrypted SNI (ESNI) i infrastrukturen för publika webbplatser.

Användningen av denna teknologi kommer att öka säkerhetsnivån vid arbete med publika webbplatser och uppfylla interna säkerhetsstandarder som antagits av företaget.

Först och främst vill jag påpeka att teknologin inte är standardiserad och fortfarande är i utkast, men CloudFlare och Mozilla stöder den redan (i draft01). Det är vad som motiverade oss till detta experiment.

Lite teori

ESNI är en utvidgning av TLS 1.3-protokollet som möjliggör kryptering av SNI i meddelandet 'Client Hello' under TLS-handshake. Så här ser 'Client Hello' ut med ESNI-stöd (istället för det vanliga SNI ser vi ESNI):

För att använda ESNI behövs tre komponenter:

DNS;
Klientstöd;
Serverstöd.

DNS

Två DNS-poster måste läggas till – A, och TXT (TXT-posten innehåller den offentliga nyckeln som klienten kan använda för att kryptera SNI) – se nedan. Dessutom måste stöd för DoH (DNS over HTTPS) finnas, eftersom tillgängliga klienter (se nedan) inte aktiverar ESNI-stöd utan DoH. Detta är logiskt, eftersom ESNI innebär kryptering av resursnamnet vi anropar, det vill säga det är meningslöst att anropa DNS via UDP. Dessutom möjliggör användningen av DNSSEC att skydda sig mot 'cache poisoning'-attacker i detta scenario.

För närvarande finns det flera DoH-leverantörer, bland dem:

CloudFlare uttalar (Check My Browser → Encrypted SNI → Learn More), att deras servrar redan nu stöder ESNI, det vill säga för CloudFlare-servrar har vi minst två poster i DNS – A och TXT. I exemplet nedan anropar vi Google DNS (över HTTPS):

A post:

curl 'https://dns.google.com/resolve?name=www.cloudflare.com&type=A' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "www.cloudflare.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.210.9"
    },
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.209.9"
    }
  ]
}

TXT post, begäran formuleras enligt mallen _esni.FQDN:

curl 'https://dns.google.com/resolve?name=_esni.www.cloudflare.com&type=TXT' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16
    }
  ],
  "Answer": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16,
    "TTL": 1799,
    "data": ""/wEUgUKlACQAHQAg9SiAYQ9aUseUZr47HYHvF5jkt3aZ5802eAMJPhRz1QgAAhMBAQQAAAAAXtUmAAAAAABe3Q8AAAA=""
    }
  ],
  "Comment": "Response from 2400:cb00:2049:1::a29f:209."
}

Så ur ett DNS-perspektiv bör vi använda DoH (helst med DNSSEC) och lägga till två poster.

Support från kunden

Om vi talar om webbläsare, så är det för närvarande stöd implementerat endast i FireFox. Här här är en instruktion för hur man aktiverar stöd för ESNI och DoH i FireFox. När webbläsaren är konfigurerad, bör vi se något i stil med:

Länk för att kontrollera webbläsaren.

Självklart måste TLS 1.3 användas för att stödja ESNI, eftersom ESNI är en tillägg till TLS 1.3.

För teständamål av backend med stöd för ESNI har vi implementerat en klient på go, men mer om det senare.

Support från servern

För närvarande stöds inte ESNI av webbservrar som nginx/apache m.fl., eftersom de arbetar med TLS via OpenSSL/BoringSSL, där ESNI inte officiellt stöds.

Därför har vi beslutat att skapa vår egen front-end-komponent (ESNI reverse proxy) som skulle stödja TLS 1.3-terminering med ESNI och proxy HTTP(S)-trafik till en upstream som inte stöder ESNI. Detta möjliggör användning av teknologin i en redan etablerad infrastruktur, utan att förändra grundkomponenterna – det vill säga att använda nuvarande webbservrar som inte stöder ESNI.

För tydlighetens skull, här är ett diagram:

Jag vill påpeka att proxyn designades för att kunna terminera TLS-anslutningar utan ESNI, för att stödja klienter som inte har ESNI. Dessutom kan protokollet för kommunikation med upstream vara både HTTP och HTTPS med en TLS-version under 1.3 (om upstream inte stöder 1.3). Detta schema ger maximal flexibilitet.

Implementeringen av ESNI-support på go har vi lånat från CloudFlare. Jag vill genast påpeka att själva implementeringen är ganska icke-trivialiskt, eftersom den kräver ändringar i standardbiblioteket crypto/tls och därför kräver "patchning" GOROOT innan byggnation.

För att generera ESNI-nycklar använde vi esnitool (också ett projekt från CloudFlare). Dessa nycklar används för kryptering/avkryptering av SNI.
Vi testade bygget med go 1.13 på Linux (Debian, Alpine) och MacOS.

Några ord om driftsäkerhetsaspekter

ESNI reverse proxy erbjuder metrics i Prometheus-format, såsom rps, upstream latens & responskoder, misslyckade/lyckade TLS-handshakes & TLS-handshake varaktighet. Vid första anblick såg detta tillräckligt ut för att bedöma hur proxy klarar av trafiken.

Innan vi använde den genomförde vi även belastningstestning. Resultaten nedan:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Kör 6m test @ https://esni-rev-proxy.npw:443
 50 trådar och 1000 anslutningar
 Trådstatistik   Genomsnitt   Stdev     Max   +/− Stdev
  Latens      1.77s     1.21s    7.20s    65.43%
  Begärningar/Sek    13.78      8.84   140.00     83.70%
  206357 begärningar på 6.00m, 6.08GB lästa
Begärningar/s:    573.07
Överföring/s:     17.28MB

Vi genomförde belastningstestningen av rent kvalitativa skäl, för att jämföra scheman med och utan ESNI reverse proxy. Vi "matade" trafiken lokalt för att utesluta "störningar" i mellanliggande komponenter.

Så, med stöd för ESNI och proxytjänst till upstream med HTTP, fick vi cirka ~ 550 rps från en instans, medan den genomsnittliga CPU/RAM-användningen för ESNI reverse proxy:

80% CPU-användning (4 vCPU, 4 GB RAM-värdar, Linux)
130 MB Mem RSS

I jämförelse, RPS för samma upstream nginx utan TLS-terminering (HTTP-protokoll) ~ 1100:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Kör 6m test @ http://lb.npw:80
 50 trådar och 1000 anslutningar
 Trådstatistik   Genomsnitt   Stdev     Max   +/− Stdev
  Latens      1.11s     2.30s   15.00s    90.94%
  Begärningar/Sek    23.25      13.55   282.00     79.25%
  393093 begärningar på 6.00m, 11.35GB lästa
  Socket-fel: anslut 0, läs 0, skriv 0, timeout 9555
  Icke-2xx eller 3xx svar: 8111
Begärningar/s:   1091.62
Överföring/s:     32.27MB

Närvaron av timeouts tyder på att det finns brist på resurser (vi använde 4 vCPU, 4 GB RAM-värdar, Linux), och faktiska potentiella RPS är högre (vi fick siffror upp till 2700 RPS på kraftfullare resurser).

Avslutningsvis vill jag nämna att teknologin ESNI ser ganska lovande ut. Det finns fortfarande många öppna frågor, såsom lagring av den offentliga ESNI-nyckeln i DNS och rotation av ESNI-nycklar – dessa frågor diskuteras aktivt, och den senaste versionen av utkastet (vid tidpunkten för skrivandet) ESNI redan 7.

Källa: habr.com