TLS 1.3 기반 도메인 프론팅

소개

Cisco, BlueCoat, FireEye와 같은 유명 제조업체의 최신 기업 콘텐츠 필터링 시스템은 국가 차원에서 활발히 도입되고 있는 더욱 강력한 DPI 시스템과 많은 공통점을 가지고 있습니다. 두 시스템의 핵심 기능은 인터넷 트래픽의 송수신을 차단하고, 블랙리스트/화이트리스트를 기반으로 인터넷 연결을 차단하는 것입니다. 두 시스템 모두 작동 원리가 유사하기 때문에, 이를 우회하는 방법 또한 많은 공통점을 가지고 있습니다.

DPI와 기업 시스템을 모두 효과적으로 우회할 수 있는 기술 중 하나는 도메인 프론팅(domain fronting) 기술입니다. 이 기술의 핵심은 평판이 좋은 다른 공개 도메인 뒤에 숨어 차단된 리소스로 접근하는 것입니다. 이 도메인은 어떤 시스템에서도 차단되지 않을 것입니다. 예를 들어 google.com과 같은 도메인이 있습니다.

이 기술에 대한 기사는 이미 꽤 많이 작성되었고, 많은 사례가 제시되었습니다. 하지만 최근 주목받고 논의되는 DNS-over-HTTPS 및 암호화된 SNI 기술과 새로운 버전의 TLS 1.3 프로토콜을 통해 도메인 프론팅의 또 다른 버전을 고려할 수 있게 되었습니다.

기술 이해

먼저, 모두가 누가 누구인지, 그리고 왜 이 모든 것이 필요한지 이해할 수 있도록 몇 가지 기본 개념을 정의해 보겠습니다. 앞서 eSNI 메커니즘에 대해 언급했는데, 이 메커니즘의 작동 방식은 나중에 자세히 살펴보겠습니다. eSNI(암호화된 서버 이름 표시) 메커니즘은 SNI의 보안 버전으로, TLS 1.3 프로토콜에서만 사용할 수 있습니다. 핵심은 요청이 전송되는 도메인 정보를 암호화하는 것입니다.

이제 eSNI 메커니즘이 실제로 어떻게 작동하는지 살펴보겠습니다.

최신 DPI 솔루션(예: 유명한 토렌트 추적 프로그램인 rutracker.nl)에 의해 차단된 인터넷 리소스가 있다고 가정해 보겠습니다. 토렌트 추적 프로그램 웹사이트에 접속하려고 하면 해당 리소스가 차단되었다는 표준 제공업체의 스텁이 표시됩니다.

RKN 웹사이트에서는 이 도메인이 실제로 중지 목록에 등재되어 있습니다.

whois를 쿼리하면 도메인 자체가 클라우드 제공업체 Cloudflare 뒤에 "숨겨져" 있다는 것을 알 수 있습니다.

하지만 RKN의 "전문가"들과는 달리, 기술적으로 더 능숙한 Beeline의 직원들(혹은 유명한 규제 기관의 쓰라린 경험을 통해 교훈을 얻은 직원들)은 단순히 IP 주소로 사이트를 차단하는 데 그치지 않고, 해당 사이트를 차단 목록에 추가했습니다. 도메인 이름이 도메인 뒤에 숨겨진 다른 도메인들을 살펴보면 이를 쉽게 확인할 수 있습니다. IP 주소그중 한 곳을 방문하여 접속이 차단되지 않았는지 확인하십시오.

어떻게 이런 일이 일어나는 걸까요? 모든 통신이 https 프로토콜을 통해 이루어지고 Beeline의 https 인증서가 아직 대체된 것을 발견하지 못했는데, 제공업체의 DPI는 어떻게 내 브라우저가 어떤 도메인에 접속하는지 알 수 있을까요? 그는 투시력이 있는 걸까요, 아니면 저를 감시하고 있는 걸까요?

Wireshark를 통해 트래픽을 살펴보면서 이 질문에 답해 보겠습니다.

스크린샷은 브라우저가 먼저 DNS를 통해 서버의 IP 주소를 얻은 다음, 대상 서버와 표준 TCP 핸드셰이크를 수행하고, 마지막으로 서버와의 SSL 연결을 시도하는 과정을 보여줍니다. 이 과정에서 브라우저는 패킷을 전송합니다. SSL 클라이언트의 "Hello" 메시지에는 소스 도메인 이름이 평문으로 포함되어 있습니다. 이 필드는 Cloudflare 프런트엔드 서버에서 연결을 올바르게 라우팅하는 데 필요합니다. 바로 이 부분에서 ISP의 DPI(심화 패킷 검사)가 저희 연결을 차단합니다. 하지만 저희는 ISP로부터 아무런 스텁 메시지도 받지 못하고, 마치 사이트가 다운되었거나 작동하지 않는 것처럼 일반적인 브라우저 오류 메시지만 표시됩니다.

이제 브라우저에서 eSNI 메커니즘을 활성화해 보겠습니다. 파이어 폭스 :
이를 위해 Firefox 구성 페이지를 엽니다. 정보 : 설정 다음 설정을 활성화하세요.

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

그 후, 클라우드플레어 웹사이트의 설정이 정상적으로 동작하는지 확인해 보겠습니다. 링크 이제 토렌트 추적기를 이용해 다시 한번 시도해 보겠습니다.

짜잔! VPN이나 ​​프록시 서버 없이도 우리가 가장 좋아하는 추적 프로그램이 실행되었습니다. 이제 와이어샤크에서 트래픽 덤프를 확인해 볼까요? 무슨 일이 일어났는지.

이번에는 SSL 클라이언트 Hello 패킷에 대상 도메인이 명시적으로 포함되어 있지 않고, 대신 패킷에 새로운 필드인 encrypted_server_name이 추가되었습니다. 이 필드에 rutracker.nl 값이 포함되어 있으며, Cloudflare 프런트엔드 서버만 이 필드를 복호화할 수 있습니다. 만약 복호화가 가능하다면, 제공업체 DPI는 이러한 트래픽을 허용할 수밖에 없습니다. 암호화에는 다른 방법이 없습니다.

브라우저에서 이 기술이 어떻게 작동하는지 살펴보았습니다. 이제 이 기술을 더 구체적이고 흥미로운 분야에 적용해 보겠습니다. 먼저, 동일한 curl을 사용하여 TLS 1.3에서 eSNI를 사용하는 방법을 배우고, 동시에 eSNI 기반 도메인 프론팅이 어떻게 작동하는지 살펴보겠습니다.

eSNI를 사용한 도메인 프런팅

curl은 https를 통해 연결하기 위해 표준 openssl 라이브러리를 사용하므로, 먼저 해당 라이브러리에서 eSNI 지원을 제공해야 합니다. openssl 마스터 브랜치에는 아직 eSNI 지원이 없으므로, 별도의 openssl 브랜치를 다운로드하여 컴파일하고 설치해야 합니다.

GitHub에서 저장소를 복제하고 평소처럼 컴파일합니다.

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

다음으로, curl을 사용하여 저장소를 복제하고 내장된 openssl 라이브러리를 사용하여 컴파일을 구성합니다.

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

여기서 openssl이 있는 모든 디렉토리(이 경우 /opt/openssl/)를 올바르게 지정하고 구성 프로세스가 오류 없이 진행되는지 확인하는 것이 중요합니다.

구성이 성공하면 다음 줄이 표시됩니다.

경고: esni ESNI가 활성화되어 있지만 실험용으로 표시되어 있습니다. 주의해서 사용하세요!

$ make

패키지를 성공적으로 빌드한 후 openssl의 특수 bash 파일을 사용하여 curl을 설정하고 실행합니다. 편의를 위해 이 파일을 curl 디렉터리에 복사해 보겠습니다.

cp /opt/openssl/esnistuff/curl-esni 

그리고 Cloudflare 서버에 대한 테스트 https 요청을 수행하고 Wireshark에서 DNS 및 TLS 패킷을 동시에 기록합니다.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

서버 응답에는 openssl과 curl에서 온 많은 디버깅 정보와 더불어 Cloudflare에서 301 코드가 포함된 HTTP 응답이 수신됩니다.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

이는 요청이 대상 서버에 성공적으로 전달되어 처리되었음을 나타냅니다.

이제 Wireshark에서 트래픽 덤프를 살펴보겠습니다. 즉, 이 경우 공급자 DPI가 확인한 내용입니다.

curl이 먼저 Cloudflare 서버의 공개 eSNI 키를 얻기 위해 DNS 서버에 접속한 것을 확인할 수 있습니다. _esni.cloudflare.com으로 전송된 TXT DNS 요청(패킷 #13)입니다. 그런 다음 openssl 라이브러리를 사용하여 SNI 필드가 이전 단계에서 얻은 공개 키(패킷 #1.3)로 암호화된 TLS 22 요청을 Cloudflare 서버로 전송했습니다. 그러나 eSNI 필드 외에도 SSL-hello 패킷에는 일반적인 개방형 SNI가 포함된 필드도 포함되어 있으며, 이는 어떤 순서로든 지정할 수 있습니다(이 경우, www.hello-rkn.ru).

이 공개 SNI 필드는 Cloudflare 서버에서 처리될 때 전혀 고려되지 않았으며, 제공업체의 DPI를 마스킹하는 용도로만 사용되었습니다. Cloudflare 서버는 ssl-hello 패킷을 수신하여 eSNI를 복호화하고, 원본 SNI를 추출하여 마치 아무 일도 없었던 것처럼 처리했습니다(eSNI 개발 당시 계획했던 대로 모든 작업을 정확히 수행했습니다).

이 경우 DPI 관점에서 포착할 수 있는 유일한 것은 _esni.cloudflare.com에 대한 기본 DNS 요청입니다. 하지만 저희는 이 메커니즘이 내부에서 어떻게 작동하는지 보여주기 위해 DNS 요청을 공개했습니다.

DPI를 완전히 무력화하기 위해, 앞서 언급한 DNS-over-HTTPS 메커니즘을 사용합니다. 간단히 설명하자면, DOH는 HTTPS 프로토콜을 통해 DNS 요청을 전송하여 "중간자 공격(man in the middle attack)"으로부터 자신을 보호할 수 있는 프로토콜입니다.

요청을 다시 실행해 보겠습니다. 하지만 이번에는 DNS가 아닌 https 프로토콜을 통해 공개 eSNI 키를 받게 됩니다.

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

요청 트래픽 덤프는 아래 스크린샷에 나와 있습니다.

curl이 먼저 DoH 프로토콜(서버 104.16.249.249에 대한 https 연결)을 통해 mozilla.cloudflare-dns.com 서버에 접속하여 SNI 암호화를 위한 공개 키 값을 얻은 다음 도메인 뒤에 숨어 대상 서버로 전송한다는 것이 분명합니다. www.hello-rkn.ru.

위의 DoH 리졸버 mozilla.cloudflare-dns.com 외에도, 예를 들어 유명한 악의적인 기업이 제공하는 다른 인기 있는 DoH 서비스를 사용할 수도 있습니다.
다음 쿼리를 실행해 보겠습니다.

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

그리고 우리는 답을 얻습니다:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

이 경우, DoH 리졸버인 dns.google(오타가 아닙니다. 이 유명 기업은 자체 최상위 도메인을 가지고 있습니다)을 사용하여 차단된 rutracker.nl 서버에 접속하고, 모든 DPI에 대해 사형을 감수하고라도 차단이 엄격히 금지된 다른 도메인으로 대체했습니다. 응답을 통해 요청이 성공적으로 처리되었음을 알 수 있습니다.

제공자의 DPI가 우리가 커버로 전달하는 공개 SNI에 응답하는지 확인하기 위한 추가 확인으로, 예를 들어 다른 "좋은" 토런트 추적기와 같이 금지된 리소스를 가장하여 rutracker.nl에 요청을 수행할 수 있습니다.

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

DPI 시스템이 우리의 요청을 차단했기 때문에, 우리는 서버로부터 응답을 받지 못할 것입니다.

첫 번째 부분에 대한 간략한 결론

따라서 openssl과 curl을 사용하여 eSNI의 기능을 시연하고 eSNI 기반 도메인 프론팅 작동을 검증했습니다. 마찬가지로 openssl 라이브러리를 사용하여 선호하는 도구를 다른 도메인의 "커버 아래"에서 작동하도록 조정할 수 있습니다. 이에 대한 자세한 내용은 다음 글에서 다루겠습니다.

출처 : habr.com