SNI
Server Name Indication
TLS의 확장 표준 중 하나로, 인증서에서 사용하는 방식이다.
이 기술이 나오게 된 큰 이유는 하나의 웹서버가 여러 웹사이트를 서비스하면서 인증서 인증에 문제가 생겼기 때문이다. 기존까지는 대상 서버의 IP 주소와 도메인이 1:1 대응 관계라서 서버의 인증서 제공에 문제가 없었지만, 여러 도메인을 하나의 IP 주소로 연결하는 서비스가 대중화되면서 보낼 인증서를 특정하지 못하게 되었다. 이 때문에 클라이언트가 사이트에 접속하면서 도메인 정보를 보내도록 변경한 것이다.
이 SNI를 사용하게 되면 하나의 웹 서버에서 여러 도메인의 웹사이트를 서비스하는 경우에도 인증서를 사용한 HTTPS를 활성화시킬 수 있다.
TLS 표준에는 SNI 암호화가 없어서, SNI 부분이 평문 형태로 전송된다. 이로 인해 제 3자에게 쉽게 노출이 되어 보안 문제가 생기기 때문에, TLS에 SNI의 암호화 규격을 추가하는 문제는 오랜 기간 논의되어 왔다.
DNS 암호화랑 달리 초안, 즉 비표준이다. 그런 이유로 '''Firefox는 실험적으로 지원하고, 나머지 브라우저들은 지원하지 않는다.''' 나무위키도 파이어폭스로 접속하면 SSL_ERROR_MISSING_ESNI_EXTENSION이라는 오류가 뜰 때가 많다.
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월 기준 엣지, 크롬 등 다른 브라우저에서는 지원되지 않는다. IE는 지원될 가능성이 '''절대''' 없으니 제발 갖다 버리자.
이 ESNI 구현은 클라이언트 브라우저에 서버의 공개키가 전달되는 시점을 DNS 통신 단계로 앞당겨서, 서버와 연결하는 시점에 해당 공개키로 도메인이 암호화될 수 있도록 하는 것이다. 파이어폭스는 ESNI 구현이 DNS 통신의 암호화가 이루어지지 않는 상황에서는 별 의미가 없다는 점을 들어, ESNI가 작동하려면 DoH(DNS over HTTPS)가 활성화되어 있을 것을 요구하고 있다. 차후 운영체제 기능에 DNS 통신 암호화가 구현되거나 플래그 등이 만들어져서 암호화 통신인지 아닌지를 구분할 수 있게 된다면 운영체제 기능으로도 ESNI를 쓸 수 있도록 제약이 풀릴 듯.
Firefox 브라우저를 재시작[3]한 후 클라우드플레어 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의 적용을 지원할 수 있도록 움직여달라고 요청하였다. #
'''2021년 1월 26일에 출시되는 Firefox 85부터는 후술할 ECH로 대체되어 지원이 삭제된다. 기존 ESNI를 사용해야 한다면 장기지원용 ESR 버전을 사용해야 한다.'''
2020년 6월 1일, '''Encrypted ClientHello''', 줄여서 '''ECH''' 라는 명칭을 가진 새 암호화 규격이 공개되었다. SNI 암호화 기술이 확대되어 TLS의 ClientHello 전부를 암호화하도록 변경되었다. 평문 SNI인 ClientHelloOuter와 암호화된 SNI인 ClientHelloInner로 이루어저 있으며, 서버가 암호화를 지원하면 ClientHelloInner를, 지원하지 않으면 ClientHelloOuter를 사용하는 방식이다. 그러나 이렇게 될 경우 상황에 따라서 ClientHelloOuter의 평문 SNI를 탈취해서 다시 검열이 가능해 질 거라는 우려의 목소리도 있다.[4] 본격적으로 서비스가 시작되어야 사실 여부를 알 수 있으니 너무 절망하지는 말자.
2021년 1월 26일, Firefox 85가 출시되면서 기존의 ESNI 지원이 삭제되고, ECH로 대체되었다. 그러나 클라우드플레어 등에서 ECH를 아직 지원하지 않기 때문에 현재 ESNI 기술이 상당수의 웹사이트에서 제대로 동작하지 않고 있다. 그렇지만 클라우드플레어 역시 ESNI에서 ECH로의 움직임을 보이고 있기 때문에 아직까지 그림의 떡으로 단정짓기엔 이르다.
about:config에서
현재 HTTPS는 암호화를 위해 TLS를 이용하는데, 이 경우 인증 후의 사용자와 웹서버 사이의 통신은 암호화되지만, 인증 과정에서 발생하는 통신은 암호화되지 않고 진행된다. 이 인증 과정에서 SNI 패킷을 주고 받아야 하고, 이 SNI 패킷에 기록된 도메인을 보고 특정 웹사이트를 차단하는 식으로 이용이 가능하다. 후술할 해외 사이트 차단이 바로 이 방법을 이용한 것이다.
위에 나와 있듯이 웹사이트가 TLS 1.3을 지원하고 SNI 암호화가 구현된 서버 프로그램을 사용하면 SNI 패킷에 기록된 도메인 또한 암호화되므로 차단을 회피할 수 있으나, 아직 정식 표준으로 채택되지 않은 초안 단계이기 때문에 적용되는 곳이 많지 않다. 예를 들어 클라우드플레어를 사용하는 사이트는 TLS 1.3와 SNI 암호화가 지원되기 때문에 차단되어도 들어갈 수 있다. 하지만 클라우드플레어를 이용하지 않는 사이트도 상당히 많고, 그런 사이트들은 직접 보안 업데이트를 준비해야 해서 TLS 1.3 버전의 도입도 늦어지므로 표준화되지 않은 SNI 암호화의 도입은 상당히 먼 일이 된다. 웹 브라우저 또한 아직 모질라 파이어폭스만 지원하며, 그마저도 직접 활성화해야 한다. 대표적인 TLS 통신 소프트웨어인 OpenSSL은 SNI 암호화에 대해 표준 등재 이후에 지원할 것이라 언급하기도 했다. nginx 같은 웹서버도 기본적으로 OpenSSL을 활용하고 있기 때문에 OpenSSL의 SNI 암호화 구현 이후에야 지원 가능할 것이라고 한다. #
클라우드 서비스를 사용하는 사이트에 이 SNI 영역을 허위의 도메인 정보로 속여서 연결하는 기법을 도메인 프런팅(Domain fronting)이라고 한다. 이 기법은 인터넷 검열에 대항하기 위해 상당히 쓰인 바 있고, 우회기술을 사용한 중국인 중 35%가 이 기법을 사용하는 것으로 나타나기도 했다. 하지만, 이 기법은 동시에 해킹 등으로 악용되기도 하였기 때문에(텔레그램의 도메인 프런팅 행위에 대한 러시아 정부의 압박이라는 설도 있다), 구글과 아마존은 약관에 근거하여 도메인 프런팅 행위를 막았고, 이에 영향을 받은 Signal Private Messenger 측은 두 회사를 비판하는 성명을 게시하기도 하였다.
1. 개요
TLS의 확장 표준 중 하나로, 인증서에서 사용하는 방식이다.
이 기술이 나오게 된 큰 이유는 하나의 웹서버가 여러 웹사이트를 서비스하면서 인증서 인증에 문제가 생겼기 때문이다. 기존까지는 대상 서버의 IP 주소와 도메인이 1:1 대응 관계라서 서버의 인증서 제공에 문제가 없었지만, 여러 도메인을 하나의 IP 주소로 연결하는 서비스가 대중화되면서 보낼 인증서를 특정하지 못하게 되었다. 이 때문에 클라이언트가 사이트에 접속하면서 도메인 정보를 보내도록 변경한 것이다.
이 SNI를 사용하게 되면 하나의 웹 서버에서 여러 도메인의 웹사이트를 서비스하는 경우에도 인증서를 사용한 HTTPS를 활성화시킬 수 있다.
2. 암호화
TLS 표준에는 SNI 암호화가 없어서, SNI 부분이 평문 형태로 전송된다. 이로 인해 제 3자에게 쉽게 노출이 되어 보안 문제가 생기기 때문에, TLS에 SNI의 암호화 규격을 추가하는 문제는 오랜 기간 논의되어 왔다.
DNS 암호화랑 달리 초안, 즉 비표준이다. 그런 이유로 '''Firefox는 실험적으로 지원하고, 나머지 브라우저들은 지원하지 않는다.''' 나무위키도 파이어폭스로 접속하면 SSL_ERROR_MISSING_ESNI_EXTENSION이라는 오류가 뜰 때가 많다.
2.1. ESNI
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월 기준 엣지, 크롬 등 다른 브라우저에서는 지원되지 않는다. IE는 지원될 가능성이 '''절대''' 없으니 제발 갖다 버리자.
이 ESNI 구현은 클라이언트 브라우저에 서버의 공개키가 전달되는 시점을 DNS 통신 단계로 앞당겨서, 서버와 연결하는 시점에 해당 공개키로 도메인이 암호화될 수 있도록 하는 것이다. 파이어폭스는 ESNI 구현이 DNS 통신의 암호화가 이루어지지 않는 상황에서는 별 의미가 없다는 점을 들어, ESNI가 작동하려면 DoH(DNS over HTTPS)가 활성화되어 있을 것을 요구하고 있다. 차후 운영체제 기능에 DNS 통신 암호화가 구현되거나 플래그 등이 만들어져서 암호화 통신인지 아닌지를 구분할 수 있게 된다면 운영체제 기능으로도 ESNI를 쓸 수 있도록 제약이 풀릴 듯.
Firefox 브라우저를 재시작[3]한 후 클라우드플레어 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의 적용을 지원할 수 있도록 움직여달라고 요청하였다. #
'''2021년 1월 26일에 출시되는 Firefox 85부터는 후술할 ECH로 대체되어 지원이 삭제된다. 기존 ESNI를 사용해야 한다면 장기지원용 ESR 버전을 사용해야 한다.'''
2.2. ECH
2020년 6월 1일, '''Encrypted ClientHello''', 줄여서 '''ECH''' 라는 명칭을 가진 새 암호화 규격이 공개되었다. SNI 암호화 기술이 확대되어 TLS의 ClientHello 전부를 암호화하도록 변경되었다. 평문 SNI인 ClientHelloOuter와 암호화된 SNI인 ClientHelloInner로 이루어저 있으며, 서버가 암호화를 지원하면 ClientHelloInner를, 지원하지 않으면 ClientHelloOuter를 사용하는 방식이다. 그러나 이렇게 될 경우 상황에 따라서 ClientHelloOuter의 평문 SNI를 탈취해서 다시 검열이 가능해 질 거라는 우려의 목소리도 있다.[4] 본격적으로 서비스가 시작되어야 사실 여부를 알 수 있으니 너무 절망하지는 말자.
2021년 1월 26일, Firefox 85가 출시되면서 기존의 ESNI 지원이 삭제되고, ECH로 대체되었다. 그러나 클라우드플레어 등에서 ECH를 아직 지원하지 않기 때문에 현재 ESNI 기술이 상당수의 웹사이트에서 제대로 동작하지 않고 있다. 그렇지만 클라우드플레어 역시 ESNI에서 ECH로의 움직임을 보이고 있기 때문에 아직까지 그림의 떡으로 단정짓기엔 이르다.
about:config에서
network.dns.echconfig.enablednetwork.dns.use_https_rr_as_altsvctrue3. 인터넷 검열
현재 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년 2월 11일 해외 사이트 차단
4. 도메인 프런팅
클라우드 서비스를 사용하는 사이트에 이 SNI 영역을 허위의 도메인 정보로 속여서 연결하는 기법을 도메인 프런팅(Domain fronting)이라고 한다. 이 기법은 인터넷 검열에 대항하기 위해 상당히 쓰인 바 있고, 우회기술을 사용한 중국인 중 35%가 이 기법을 사용하는 것으로 나타나기도 했다. 하지만, 이 기법은 동시에 해킹 등으로 악용되기도 하였기 때문에(텔레그램의 도메인 프런팅 행위에 대한 러시아 정부의 압박이라는 설도 있다), 구글과 아마존은 약관에 근거하여 도메인 프런팅 행위를 막았고, 이에 영향을 받은 Signal Private Messenger 측은 두 회사를 비판하는 성명을 게시하기도 하였다.
5. 관련 문서
[1] TRR관련 설정은 브라우저 설정창의 네트워크 설정에서도 접근 가능하고, 여기서 편집하는것을 권장한다.[2] DNS over HTTPS[3] 최신 Nightly 버전의 경우 재시작할 필요 없이 곧바로 설정이 적용되지만, 잘 안 되는 경우도 있기 때문에 가급적 한번 완전히 껐다 켜주는 것이 확실하다.[4] ECH 미지원 사이트는 검열의 영향을 받는 것으로 볼 때, 실제로 미지원 사이트에서의 탈취는 가능한 것으로 보인다.