TLS 1.3 기반 도메인 프론팅

소개

Cisco, BlueCoat, FireEye와 같은 유명한 제조업체의 최신 기업 콘텐츠 필터링 시스템은 국가 차원에서 적극적으로 구현되고 있는 보다 강력한 시스템인 DPI 시스템과 많은 공통점을 가지고 있습니다. 두 작업의 핵심은 들어오고 나가는 인터넷 트래픽을 검사하고 블랙/화이트 목록을 기반으로 인터넷 연결 금지 결정을 내리는 것입니다. 그리고 둘 다 작업의 기본에서 유사한 원칙을 사용하기 때문에 이를 우회하는 방법도 공통점이 많습니다.

DPI와 기업 시스템을 모두 효과적으로 우회할 수 있는 기술 중 하나는 도메인 프론팅 기술입니다. 그 본질은 우리가 차단된 리소스로 이동하여 평판이 좋은 다른 공개 도메인 뒤에 숨어 있다는 것입니다. 이는 분명히 google.com과 같은 어떤 시스템에서도 차단되지 않습니다.

이 기술에 관해 이미 많은 기사가 작성되었으며 많은 사례가 제시되었습니다. 그러나 인기 있고 최근 논의된 DNS-over-HTTPS 및 암호화된 SNI 기술과 TLS 1.3 프로토콜의 새 버전을 통해 도메인 프론팅에 대한 또 다른 옵션을 고려할 수 있습니다.

기술의 이해

먼저, 모든 사람이 누가 누구이며 왜 이 모든 것이 필요한지 이해할 수 있도록 약간의 기본 개념을 정의합시다. 우리는 eSNI 메커니즘에 대해 언급했으며 그 작동에 대해서는 더 자세히 논의할 것입니다. eSNI(암호화된 서버 이름 표시) 메커니즘은 TLS 1.3 프로토콜에서만 사용할 수 있는 SNI의 보안 버전입니다. 주요 아이디어는 무엇보다도 요청이 전송되는 도메인에 대한 정보를 암호화하는 것입니다.

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

최신 DPI 솔루션에 의해 차단된 인터넷 리소스가 있다고 가정해 보겠습니다(예를 들어 유명한 토렌트 추적기 rutracker.nl을 예로 들어 보겠습니다). 토렌트 추적기의 웹사이트에 액세스하려고 하면 리소스가 차단되었음을 나타내는 공급자의 표준 스텁이 표시됩니다.

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

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

그러나 RKN의 "전문가"와는 달리 Beeline의 기술적으로 더 능숙한 직원(또는 유명한 규제 기관의 쓰라린 경험을 통해 배운)은 IP 주소로 사이트를 어리석게 금지하지 않고 도메인 이름을 중지 목록에 추가했습니다. 동일한 IP 주소 뒤에 숨겨진 다른 도메인이 무엇인지 살펴보고 그 중 하나를 방문하여 액세스가 차단되지 않았는지 확인하면 쉽게 확인할 수 있습니다.

어떻게 이런 일이 발생하나요? 모든 통신이 https 프로토콜을 통해 이루어지고 아직 Beeline의 https 인증서 대체를 확인하지 못했기 때문에 공급자의 DPI는 내 브라우저가 어느 도메인에 있는지 어떻게 알 수 있습니까? 그 사람은 투시력이 있는 걸까, 아니면 내가 미행되고 있는 걸까?

Wireshark를 통한 트래픽을 살펴봄으로써 이 질문에 답해 보겠습니다.

스크린샷은 먼저 브라우저가 DNS를 통해 서버의 IP 주소를 얻은 다음 대상 서버와 표준 TCP 핸드셰이크가 발생한 다음 브라우저가 서버와 SSL 연결을 설정하려고 시도하는 것을 보여줍니다. 이를 위해 원본 도메인 이름이 일반 텍스트로 포함된 SSL 클라이언트 Hello 패킷을 보냅니다. 이 필드는 연결을 올바르게 라우팅하기 위해 cloudflare 프런트엔드 서버에 필요합니다. 여기서 공급자 DPI가 우리를 잡아서 연결을 끊습니다. 동시에 공급자로부터 스텁을 받지 못하며 사이트가 비활성화되었거나 단순히 작동하지 않는 것처럼 표준 브라우저 오류가 표시됩니다.

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

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

그런 다음 cloudflare 웹사이트에서 설정이 올바르게 작동하는지 확인하겠습니다. 링크 토렌트 추적기로 다시 트릭을 시도해 보겠습니다.

짜잔. 우리가 가장 좋아하는 트래커는 VPN이나 ​​프록시 서버 없이 열렸습니다. 이제 Wireshark의 트래픽 덤프를 살펴보고 무슨 일이 일어났는지 살펴보겠습니다.

이번에는 SSL 클라이언트 hello 패키지에 대상 도메인이 명시적으로 포함되어 있지 않지만 대신 패키지에 새 필드(crypted_server_name)가 나타났습니다. 여기에 rutracker.nl 값이 포함되어 있으며 cloudflare 프런트엔드 서버만 이를 해독할 수 있습니다. 필드. 그렇다면 공급자 DPI는 손을 씻고 그러한 트래픽을 허용할 수밖에 없습니다. 암호화에는 다른 옵션이 없습니다.

그래서 우리는 브라우저에서 기술이 어떻게 작동하는지 살펴보았습니다. 이제 좀 더 구체적이고 흥미로운 것에 적용해 보도록 하겠습니다. 먼저 동일한 컬에 eSNI를 사용하여 TLS 1.3과 함께 작동하도록 가르치고 동시에 eSNI 기반 도메인 프론팅 자체가 어떻게 작동하는지 살펴보겠습니다.

eSNI를 사용한 도메인 프론팅

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

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

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

$ make
$ cd esnistuff
$ make

다음으로, 컬을 사용하여 저장소를 복제하고 컴파일된 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 파일을 사용하여 컬을 구성하고 실행합니다. 편의상 컬을 사용하여 디렉터리에 복사해 보겠습니다.

cp /opt/openssl/esnistuff/curl-esni 

Wireshark에 DNS 및 TLS 패킷을 동시에 기록하는 동시에 cloudflare 서버에 테스트 https 요청을 보냅니다.

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

서버 응답에서는 openssl 및 cur의 많은 디버깅 정보 외에도 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가 확인한 내용입니다.

컬은 먼저 cloudflare 서버의 공개 eSNI 키(_esni.cloudflare.com(패키지 번호 13)에 대한 TXT DNS 요청)를 위해 DNS 서버로 전환된 것을 볼 수 있습니다. 그런 다음, openssl 라이브러리를 사용하여 컬은 SNI 필드가 이전 단계에서 얻은 공개 키(패킷 #1.3)로 암호화된 cloudflare 서버에 TLS 22 요청을 보냈습니다. 그러나 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 요청을 보내 중간자 공격으로부터 보호할 수 있는 프로토콜입니다.

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

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

요청 트래픽 덤프는 아래 스크린샷에 표시됩니다.

컬은 먼저 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 서버로 전환하고(여기에는 오타가 없습니다. 이제 유명한 회사는 자체적인 XNUMX차 도메인을 보유하고 있습니다) 엄밀히 말하면 다른 도메인으로 우리 자신을 덮었습니다. 모든 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