ESNI로 공개 웹사이트를 보호하는 방법

안녕하세요 Habr. 제 이름은 Ilya입니다. 저는 Exness의 플랫폼 팀에서 일하고 있습니다. 우리는 제품 개발 팀이 사용하는 핵심 인프라 구성 요소를 개발하고 구현합니다.

이 글에서는 공개 웹사이트 인프라에 암호화된 SNI(ESNI) 기술을 구현한 경험을 공유하고 싶습니다.

이 기술을 사용하면 공개 웹사이트 작업 시 보안 수준이 향상되고 회사가 채택한 내부 보안 표준을 준수하게 됩니다.

우선 해당 기술이 표준화되지 않아 아직 초안 단계에 있지만 CloudFlare와 Mozilla에서는 이미 지원하고 있다는 점을 지적하고 싶습니다. 초안01). 이것이 우리에게 그러한 실험을 하게 된 계기가 되었습니다.

약간의 이론

에스니 TLS 핸드셰이크 "클라이언트 Hello" 메시지에서 SNI 암호화를 허용하는 TLS 1.3 프로토콜의 확장입니다. ESNI를 지원하는 Client Hello는 다음과 같습니다(일반적인 SNI 대신 ESNI로 표시됨).

 ESNI를 사용하려면 세 가지 구성 요소가 필요합니다.

• DNS; 
• 클라이언트 지원;
• 서버 측 지원.

DNS

두 개의 DNS 레코드를 추가해야 합니다. A과 TXT (TXT 레코드에는 클라이언트가 SNI를 암호화할 수 있는 공개 키가 포함되어 있습니다.) - 아래를 참조하세요. 게다가 지원이 있어야지 DoH (HTTPS를 통한 DNS) 사용 가능한 클라이언트(아래 참조)가 DoH 없이는 ESNI 지원을 활성화하지 않기 때문입니다. ESNI는 우리가 액세스하는 리소스 이름의 암호화를 의미하므로 이는 논리적입니다. 즉, UDP를 통해 DNS에 액세스하는 것은 의미가 없습니다. 게다가 용도는 DNSSEC 이 시나리오에서 캐시 중독 공격으로부터 보호할 수 있습니다.

지금 사용 가능 여러 DoH 제공업체, 그중 :

• CloudFlare
• 오픈 DNS
• 구글

CloudFlare 선언하다 (내 브라우저 확인 → 암호화된 SNI → 자세히 알아보기) 해당 서버가 이미 ESNI를 지원하는지, 즉 DNS의 CloudFlare 서버에 대해 A와 TXT라는 두 개 이상의 레코드가 있는지 확인하세요. 아래 예에서는 HTTPS를 통해 Google DNS를 쿼리합니다. 

А 기록 :

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 기록, 요청은 템플릿에 따라 생성됩니다. _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."
}

따라서 DNS 관점에서 DoH(바람직하게는 DNSSEC와 함께)를 사용하고 두 개의 항목을 추가해야 합니다. 

고객 지원

브라우저에 관해 이야기하고 있다면 현재로서는 지원은 FireFox에서만 구현됩니다.. 여기에 FireFox에서 ESNI 및 DoH 지원을 활성화하는 방법에 대한 지침은 다음과 같습니다. 브라우저가 구성되면 다음과 같은 내용이 표시됩니다.

링크 브라우저를 확인합니다.

물론 ESNI는 TLS 1.3의 확장이므로 ESNI를 지원하려면 TLS 1.3을 사용해야 합니다.

ESNI 지원으로 백엔드를 테스트하기 위해 우리는 클라이언트를 다음 위치에 구현했습니다. go, 그러나 나중에 더 자세히 설명합니다.

서버 측 지원

현재 ESNI는 nginx/apache 등과 같은 웹 서버에서 지원되지 않습니다. 왜냐하면 공식적으로 ESNI를 지원하지 않는 OpenSSL/BoringSSL을 통해 TLS와 작동하기 때문입니다.

따라서 우리는 ESNI를 사용하여 TLS 1.3 종료를 지원하고 ESNI를 지원하지 않는 업스트림에 대한 프록시 HTTP(S) 트래픽을 지원하는 자체 프런트 엔드 구성 요소(ESNI 역방향 프록시)를 만들기로 결정했습니다. 이를 통해 주요 구성 요소를 변경하지 않고, 즉 ESNI를 지원하지 않는 현재 웹 서버를 사용하지 않고도 이미 존재하는 인프라에서 기술을 사용할 수 있습니다. 

명확성을 위해 다음 다이어그램을 참조하세요.

프록시는 ESNI 없이 TLS 연결을 종료하고 ESNI가 없는 클라이언트를 지원하는 기능으로 설계되었습니다. 또한 업스트림의 통신 프로토콜은 TLS 버전이 1.3보다 낮은 HTTP 또는 HTTPS일 수 있습니다(업스트림이 1.3을 지원하지 않는 경우). 이 구성표는 최대의 유연성을 제공합니다.

ESNI 지원 구현 go 우리는 빌렸다 CloudFlare. 표준 라이브러리의 변경이 포함되므로 구현 자체가 매우 중요하다는 점을 즉시 지적하고 싶습니다. 암호화/TLS 따라서 "패치"가 필요합니다. 구 루트 조립 전.

ESNI 키를 생성하기 위해 우리는 사용했습니다. 에스니툴 (CloudFlare의 아이디어이기도 함) 이 키는 SNI 암호화/암호 해독에 사용됩니다.
Linux(Debian, Alpine) 및 MacOS에서 go 1.13을 사용하여 빌드를 테스트했습니다. 

운영 기능에 대한 몇 마디

ESNI 역방향 프록시는 rps, 업스트림 대기 시간 및 응답 코드, 실패/성공 TLS 핸드셰이크 및 TLS 핸드셰이크 기간과 같은 Prometheus 형식의 메트릭을 제공합니다. 언뜻 보기에 이는 프록시가 트래픽을 처리하는 방법을 평가하기에 충분한 것처럼 보였습니다. 

사용 전 부하 테스트도 수행했습니다. 아래 결과:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Running 6m test @ https://esni-rev-proxy.npw:443
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.77s     1.21s    7.20s    65.43%
    Req/Sec    13.78      8.84   140.00     83.70%
  206357 requests in 6.00m, 6.08GB read
Requests/sec:    573.07
Transfer/sec:     17.28MB 

우리는 ESNI 역방향 프록시를 사용하는 방식과 사용하지 않는 방식을 비교하기 위해 순수하게 정성적인 로드 테스트를 수행했습니다. 중간 구성 요소의 "간섭"을 제거하기 위해 로컬로 트래픽을 "쏟았습니다".

따라서 ESNI 지원 및 HTTP에서 업스트림으로의 프록시를 통해 ESNI 역방향 프록시의 평균 CPU/RAM 소비와 함께 한 인스턴스에서 약 550rps를 얻었습니다.

• 80% CPU 사용량(vCPU 4개, 4GB RAM 호스트, Linux)
• 130MB 메모리 RSS

비교를 위해 TLS(HTTP 프로토콜) 종료가 없는 동일한 nginx 업스트림에 대한 RPS는 ~ 1100입니다.

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Running 6m test @ http://lb.npw:80
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11s     2.30s   15.00s    90.94%
    Req/Sec    23.25     13.55   282.00     79.25%
  393093 requests in 6.00m, 11.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 9555
  Non-2xx or 3xx responses: 8111
Requests/sec:   1091.62
Transfer/sec:     32.27MB 

시간 초과가 있다는 것은 리소스가 부족하다는 것을 의미하며(vCPU 4개, RAM 호스트 4GB, Linux 사용) 실제로 잠재적인 RPS는 더 높습니다(보다 강력한 리소스에서 최대 2700RPS라는 수치를 받았습니다).

결론부터 말씀드리자면 ESNI 기술은 매우 유망해 보입니다. 예를 들어 공개 ESNI 키를 DNS에 저장하고 ESNI 키를 순환하는 문제와 같은 미해결 질문이 여전히 많이 있습니다. 이러한 문제는 활발히 논의되고 있으며 (작성 당시) ESNI 초안의 최신 버전이 이미 작성되었습니다. 7.

출처 : habr.com