mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-12-03 14:21:21

SNI


1. 개요2. 암호화
2.1. ESNI2.2. ECH
3. 인터넷 검열
3.1. 2019년 인터넷 검열 사건3.2. 공인 IP 접속대수 감시
4. 도메인 프런팅5. 관련 문서

1. 개요

Server Name Indication

TLS의 확장 표준 중 하나로, 접속 도메인 이름을 지정하는 기능이다.

이 기술이 개발된 주된 이유는 하나의 웹서버가 여러 웹사이트를 서비스하면서 인증서 인증에 문제가 생겼기 때문이다. 기존에는 대상 서버의 IP 주소와 도메인이 1:1 대응 관계라 서버의 인증서 제공에 문제가 없었지만, 여러 도메인을 하나의 IP 주소로 연결하는 서비스가 널리 쓰이면서 보낼 인증서를 특정하지 못하게 되었다. 이 때문에 클라이언트가 사이트에 접속하면서 도메인 정보를 보내도록 바꾼 것이다.

SNI를 사용하면 하나의 웹 서버에서 여러 도메인의 웹사이트를 서비스하는 경우에도 인증서를 사용한 HTTPS를 활성화할 수 있다.

2. 암호화

TLS 표준에는 SNI 암호화가 없어서, SNI 부분이 평문 형태로 전송된다. 이로 인해 제 3자에게 쉽게 노출이 되어 보안 문제가 생기기 때문에, TLS에 SNI의 암호화 규격을 추가하는 문제는 오랜 기간 논의되어 왔다.

2.1. ESNI

ESNI는 후술할 ECH에 대체되었으므로 ECH항목을 참조하라 [1]

2018년 7월 2일 Apple, Cloudflare, Fastly, Mozilla에 의해 작성된, TLS 1.3을 전제로 한 확장 규격으로서의 SNI 암호화 규격의 초안 문서가 IETF에 등재됐다. Encrypted Server Name Indication, 줄여서 ESNI 라고 한다.

2018년 9월 24일에 Cloudflare가 위 초안 규격에 의한 ESNI 시범 서비스를 개시했다.

2018년 12월 12일부터 Firefox의 최신 안정화 버전에서 ESNI 지원이 시작되었다. 반면 2019년 2월 기준 엣지, 크롬 등 다른 브라우저에서는 지원되지 않는다.

이 ESNI 구현은 클라이언트 브라우저에 서버의 공개키가 전달되는 시점을 DNS 통신 단계로 앞당겨서, 서버와 연결하는 시점에 해당 공개키로 도메인이 암호화될 수 있도록 하는 것이다. 파이어폭스는 ESNI 구현이 DNS 통신의 암호화가 이루어지지 않는 상황에서는 별 의미가 없다는 점을 들어, ESNI가 작동하려면 DoH(DNS over HTTPS)가 활성화되어 있을 것을 요구하고 있다. 차후 운영체제 기능에 DNS 통신 암호화가 구현되거나 플래그 등이 만들어져서 암호화 통신인지 아닌지를 구분할 수 있게 된다면 운영체제 기능으로도 ESNI를 쓸 수 있도록 제약이 풀릴 듯.
파이어폭스(버전 64~84)에서의 활성화 방법
  1. 파이어폭스 주소창에 about:config 를 쳐서 고급 설정창에 접속한다. 경고 메시지가 뜨면, 「위험을 감수하겠습니다!」 버튼을 눌러 진행한다.
  2. 화면 상단의 검색창에 trr이라고 입력한다. 자동으로 검색이 이루어진다.
  3. network.trr.mode라는 설정값의 숫자를 2로 바꾼다.[2]
  4. 만약에 network.trr.uri가 비어있다면 https://mozilla.cloudflare-dns.com/dns-query로 바꾼다. 최신 버전을 신규 설치하였을 경우 이 부분에 이미 해당 주소값이 입력되어 있으므로, 건드릴 필요 없다.
  5. 화면 상단의 검색창에서 trr을 지운 다음 esni라고 입력하여 검색한다.
  6. network.security.esni.enabled를 true로 바꾼다.
  7. 고급 설정창을 닫는다.
조금 더 설정하고 싶은 사람들을 위한 설명
network.trr.mode 0은 기본값(현재는 해당 기능을 사용하지 않음), 1은 DNS와 DoH[3] 중 빠른 쪽을 택해서 접속, 2는 DoH 접속을 먼저 시도한 다음 실패하면 DNS로 접속, 3은 DoH만 이용, 5는 이 기능을 완전히 꺼버림.
network.trr.uri DoH를 이용할 주소. DoH의 정의상 반드시 https://로 시작하는 주소라야 한다. 현재 사용가능한 주소는 https://mozilla.cloudflare-dns.com/dns-query https://dns.google.com/experimental, https://dns.quad9.net/dns-query 그리고 https://dns.adguard.com/dns-query등이 있다.
network.trr.bootstrapAddress network.trr.uri에 기재된 DoH 서버의 IP 주소. DoH 서버에 접속하는 초기단계에 서버명을 IP주소로 변환해야 하는데, 보통 이는 기본 DNS를 이용하여 이뤄지지만 기본 DNS가 DoH 서버를 막는 경우나 또는 기본 DNS를 전혀 쓰지 않는 경우 (즉 network.trr.mode를 3으로 설정한 경우) DoH 서버명을 수동으로 변환한 결과를 여기에 입력한다. https://dns.google.com/등의 DNS도구로 DoH 서버명을 변환하여 나온 결과를 적어주면 된다. mozilla.cloudflare-dns.com → 104.16.248.249, dns.google.com → 8.8.8.8 이런 식이다.
network.trr.wait-for-portal 와이파이 접속시 처음에 광고 페이지 등이 강제로 뜨는지 확인할지의 여부. 그런 광고 페이지에서는 보통 DoH를 이용할 수 없기 때문에 존재하는 옵션이다. 되도록이면 기본값인 true로 놔두고 건드리지 말자.
network.trr.confirmationNS 위 wait-for-portal을 확인하기 위해서 쓰는 사이트 주소. 기본값은 http://example.com이다. 건드릴 필요 없다.

Firefox 브라우저를 재시작[4]한 후 클라우드플레어 ESNI Checker 사이트에서 정상적용 여부를 확인할 수 있다. 단, DNS가 클라우드플레어가 아닌 경우 Secure DNS 항목은 불확실할 수 있다.

자잘한 팁으로, 가끔 ESNI 작동이 풀릴 경우 network.trr.mode 및 network.security.esni.enabled 설정을 바꿨다가 복원하면 기능이 돌아온다.

클라우드플레어를 이용하는 개별 웹사이트에서 암호화 여부를 알고 싶다면, 도메인 뒤에 /cdn-cgi/trace를 붙여 접속하면 된다. 나무위키라면 https://namu.wiki/cdn-cgi/trace로, 파이어폭스에서 위 설정을 마친 뒤 접속하면 tls=TLSv1.3, sni=encrypted라는 값이 나올 것이다.

2018년 10월 24일, 미국 오리건 상원의원 Ron Wyden이 미국 국토안보부에 국내 기업들에 대한 DNS 암호화 및 ESNI의 적용을 지원할 수 있도록 움직여달라고 요청하였다. #

중국은 이 기술이 표준화되지도 않은 2020년 7월에 ESNI로는 어떤 연결도 허용하지 않도록 차단을 해버렸다. #

2021년 1월 26일에 출시되는 Firefox 85부터는 후술할 ECH로 대체되어 지원이 삭제되며 ESR 버전도 2021년 11월 2일에 91로 상향되며 지원 종료, ESR 버전의 포크인 Waterfox조차도 동년 11월 5일에 G4로 상향되며 지원을 종료했다. 따라서 기존 ESNI를 사용할 수 있는 브라우저는 더 이상 없다.

2.2. ECH

2020년 6월 1일, Encrypted Client Hello, 줄여서 ECH 라는 명칭을 가진 새 암호화 규격이 공개되었다. SNI 암호화 기술이 확대되어 TLS의 ClientHello 전부를 암호화하도록 변경되었다. 평문 핸드셰이크인 ClientHelloOuter와 암호화된 핸드셰이크인 ClientHelloInner로 이루어저 있으며, 서버가 암호화를 지원하면 ClientHelloInner를, 지원하지 않으면 ClientHelloOuter를 사용하는 방식이다.[5]

ECH는 다음과 같이 구현된다. 먼저, 서버는 '백엔드 서버'와 '클라이언트가 대면하는 서버'(이하 대면서버)로 나뉘는데, 이 서버가 같은 IP 주소를 부여받을 수도, 다른 IP 주소를 부여받을 수도 있다. 클라이언트는 '백엔드 서버'로 접속하기 전에 DNS를 통해 암호화를 위한 공개키와 함께 대면서버의 도메인 이름을 받아온다. 이 도메인 이름을 ClientHelloOuter를 구성하는 데에 SNI 값으로서 이용하고[6], '백엔드 서버'의 도메인 이름을 ClientHelloInner를 구성하는 데에 SNI 값으로서 이용한다. 대면서버는 요청이 올바른 ECH 핸드셰이크인 경우 '백엔드 서버'로 요청을 전달해 최종적으로 '백엔드 서버'와 클라이언트 간에 연결이 구성된다.

각 브라우져별 지원 상황을 살펴보자.

Firefox의 경우에는 2021년 1월 26일, Firefox 85가 출시되면서 기존의 ESNI 지원이 삭제되고, ECH로 대체되었다. Firefox 118부터는 기본적으로 ECH 설정이 켜져있다.

크로뮴, 크롬 엣지의 경우 버전 105부터 플래그 설정을 통해 ECH 기능을 쓸 수 있다. 117부터는 기본적으로 켜져있다.

ECH를 사용하려면 보안 DNS 기능이 켜져 있어야 한다. 운영체제 설정을 해주면 브라우저는 자동 설정되지만, 되도록이면 둘 다 해주는 것이 좋다. 제대로 설정되었는지는 Cloudflare 보안 검사 사이트를 확인해보면 된다.

서버에서도 이를 지원하여야 하므로 이를 알아보면, 2021년 10월 12일, Cloudflare에서 드디어 일부 무료 영역의 네트워크에 ech를 사용할 수 있도록 하겠다고 한다. #

2024년 9월 23일, ECH의 표준화 working group이 RFC 문서의 publication을 요청했다. #

3. 인터넷 검열

현재 HTTPS는 암호화를 위해 TLS를 이용하는데, 이 경우 인증 후의 사용자와 웹서버 사이의 통신은 암호화되지만, 인증 과정에서 발생하는 통신은 암호화되지 않고 진행된다. 이 인증 과정에서 SNI 패킷을 주고 받아야 하고, 이 SNI 패킷에 기록된 도메인을 보고 특정 웹사이트를 차단하는 식으로 이용이 가능하다. 후술할 해외 사이트 차단이 바로 이 방법을 이용한 것이다.

위에 나와 있듯이 웹사이트가 TLS 1.3을 지원하고 SNI 암호화가 구현된 서버 프로그램을 사용하면 SNI 패킷에 기록된 도메인 또한 암호화되므로 차단을 회피할 수 있으나, 아직 정식 표준으로 채택되지 않은 초안 단계이기 때문에 적용되는 곳이 많지 않다. 예를 들어 클라우드플레어를 사용하는 사이트는 TLS 1.3와 SNI 암호화가 지원되기 때문에 차단되어도 들어갈 수 있다. 하지만 클라우드플레어를 이용하지 않는 사이트도 상당히 많고, 그런 사이트들은 직접 보안 업데이트를 준비해야 해서 TLS 1.3 버전의 도입도 늦어지므로 표준화되지 않은 SNI 암호화의 도입은 상당히 먼 일이 된다. 웹 브라우저 또한 아직 모질라 파이어폭스만 지원하며, 그마저도 직접 활성화해야 한다. 대표적인 TLS 통신 소프트웨어인 OpenSSL은 SNI 암호화에 대해 표준 등재 이후에 지원할 것이라 언급하기도 했다. NGINX 같은 웹서버도 기본적으로 OpenSSL을 활용하고 있기 때문에 OpenSSL의 SNI 암호화 구현 이후에야 지원 가능할 것이라고 한다. #

3.1. 2019년 인터넷 검열 사건

파일:상세 내용 아이콘.svg   자세한 내용은 2019년 인터넷 검열 사건 문서
번 문단을
부분을
참고하십시오.

3.2. 공인 IP 접속대수 감시

과거에는 통신사가 HTTP 패킷만을 감청하여 기업 회선을 제외한 모든 회선에 할당된 공인 IP를 대상으로 접속대수를 판별했다. 그리고 약관상에 명시된 최대 접속 가능 대수를 초과한 것으로 나올 경우에는 자동으로 회선 추가 안내 페이지가 뜨도록 만들었다. 그러나 이제는 대다수의 사이트들이 HTTPS로 전환하면서 이러한 중간자 공격은 더이상 안먹힐 것으로 보였다.

그러나 2019년 인터넷 검열 사건 이후로 방송통신심의위원회에서 정한 가이드라인에 맞춘 접속 차단 기술이 허용되면서 각 통신사들은 유해사이트 필터링 기능뿐만 아니라 접속대수 모니터링 기능까지 업그레이드했다. HTTPS 패킷 내에 있는 SNI 필드가 암호화가 되지 않은 평문이라는 점을 노린 것이다. KT의 회선을 쓸 경우 HTTPS 사이트로 접속하더라도 DNS 주소나 DNS 암호화 여부와는 상관 없이 접속대수 초과 페이지가 뜨는 경우가 발생한다. 이러한 상황을 해결하려면 웹 사이트 서버에 ECH 기능이 도입되어야 한다.

4. 도메인 프런팅

클라우드 서비스를 사용하는 사이트에 이 SNI 영역을 허위의 도메인 정보로 속여서 연결하는 기법을 도메인 프런팅(Domain fronting)이라고 한다. 이 기법은 인터넷 검열에 대항하기 위해 상당히 쓰인 바 있고, 우회기술을 사용한 중국인 중 35%가 이 기법을 사용하는 것으로 나타나기도 했다. 하지만, 이 기법은 동시에 해킹 등으로 악용되기도 하였기 때문에( 텔레그램의 도메인 프런팅 행위에 대한 러시아 정부의 압박이라는 설도 있다), 구글과 아마존은 약관에 근거하여 도메인 프런팅 행위를 막았고, 이에 영향을 받은 Signal 측은 두 회사를 비판하는 성명을 게시하기도 하였다.

5. 관련 문서


[1] 국제 인터넷 표준화 기구 IETF의 ECH 표준화 기술 명세 [2] TRR관련 설정은 브라우저 설정창의 네트워크 설정에서도 접근 가능하고, 여기서 편집하는것을 권장한다. [3] DNS over HTTPS [4] 최신 Nightly 버전의 경우 재시작할 필요 없이 곧바로 설정이 적용되지만, 잘 안 되는 경우도 있기 때문에 가급적 한번 완전히 껐다 켜주는 것이 확실하다. [5] 국제 인터넷 표준화 기구 IETF의 ECH 표준화 기술 명세 [6] 예시로, DNS 서버에 crypto.cloudflare.com을 RR Type ID 65(HTTPS)로 요청하면 대면서버의 도메인 이름으로 'cloudflare-ech.com'을 보내온다.