통신의 구조

현대의 HTTP 인터넷 통신(좀 더 정확히 말하자면, 브라우저가 통상적으로 수행하는 HTTP 인터넷 통신과 이를 위한 일련의 과정)은 클라이언트의 입장에서 단순히 보면 아래의 네 개의 구성 요소로 이루어졌다고 할 수 있습니다.

 

  • 클라이언트(고객)
  • 서버(사이트)
  • 통신망(통신망 사업자)
  • DNS 서버

 

http://www.clien.net/service/board/rule/10707404 에 HTTP 통신으로 접속한다고 가정해 보면, 다음과 같은 과정이 일어납니다. 모든 통신 과정에는 통신망이 관여를 하지만, 이하 특별한 사정이 없는 한 통신망은 생략합니다.

 

클라이언트 : www.clien.net의 /service/board/rule/10707404 라는 정보에 접근하고 싶어. www.clien.net은 어디에 있지? DNS 서버 1.1.1.1에 물어보자. DNS 서버 1.1.1.1, "www.clien.net이 어디에 있지?"

DNS 서버 : www.clien.net? 친구들에게 물어보자. www.clien.net은 어디에 있니? 아, www.clien.net은 183.111.27.116에 있구나! 클라이언트, "www.clien.net은 183.111.27.116에 있어."

클라이언트 : 183.111.27.116 말이지? 서버 183.111.27.116, "/service/board/rule/10707404를 www.clien.net에서 꺼내서 보내줘."

서버 : www.clien.net에 있는 /service/board/rule/10707404라고? "모두의공원 게시판 이용규칙" 이구나. 클라이언트, "모두의공원 게시판 이용규칙"이야.

클라이언트 : www.clien.net의 /service/board/rule/10707404는 "모두의공원 게시판 이용규칙" 이구나!

 

Q. www.clien.net이 어디에 있는지 클라이언트는 왜 모르고 있나요? 그냥 www.clien.net으로 보내는게 아닌가요?

A. 모든 "인터넷 연결"은 각각의 컴퓨터를 가리키는 IP 주소를 통해 이루어집니다. IP 주소는 10진수로 이루어진 IPv4 체계와, 16진수로 이루어진 IPv6 체계가 있는데, IPv4 체계의 주소인 183.111.27.116이나 IPv6 체계의 주소인 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 같은 것은 실제 사용에 있어서 상당히 불편합니다. 따라서 간편하게 일상생활에서 사용하는 문자로 "별명"을 만들어 쓸 수 있도록 한 것이 www.clien.net과 같은 "도메인 이름"인 것입니다.

이 도메인 이름과 IP 주소의 짝을 맞춰 클라이언트가 어떤 도메인 이름에 대응하는 IP 주소를 요청하면 IP 주소를 돌려주는 서버가 DNS 서버입니다. 따라서 도메인 이름을 이용한 인터넷 연결은 모두 DNS 서버를 거치게 됩니다.

 

이상의 모든 연결은 암호화 등 정보보호를 위한 아무런 조치도 되지 않은 평문으로 전달됩니다. 정부는 통신망 사업자에 간섭해서 이렇게 평문으로 전달되는 정보를 취득하거나 연결을 끊는 등 다양한 방법으로 검열을 시행할 수 있습니다. 이제 이 평문의 통신을 방해하기 위해 한국에서 사용하는 검열 방법을 살펴보겠습니다.

 

현행 검열 방법

1. IP 주소 차단

정부는 통신망 사업자에 간섭해서 특정한 IP 주소로 가는 통신을 차단할 수 있습니다. 다음과 같습니다.

 

클라이언트 : DNS 서버에 물어봐서 "www.pornocheonsa.com"을 제공하는 IP 주소 218.16.168.16을 알아냈어. 서버 218.16.168.16, "/view_video.php?viewkey=illegalporno18을 www.pornocheonsa.com에서 꺼내서 보내줘."

통신망 : 서버 218.16.168.16은 유해 사이트 데이터베이스에 포함되어 있습니다. 통신을 전달하지 않습니다.

클라이언트 : 어라... 반응이 없네? 할 수 없지. 들어가는건 포기해야겠다.

 

모든 통신은 IP 주소를 통해 이루어지므로 효과적인 차단 방법일 것 같습니다. 과연 그럴까요? 다른 사례를 봅시다.

 

클라이언트 : DNS 서버에 물어봐서 "www.jungleshopping.com"을 제공하는 IP 주소 218.16.168.16을 알아냈어. 서버 218.16.168.16, "/item?id=5731781319을 www.jungleshopping.com에서 꺼내서 보내줘."

통신망 : 서버 218.16.168.16은 유해 사이트 데이터베이스에 포함되어 있습니다. 통신을 전달하지 않습니다.

클라이언트 : 어? 이 사이트가 왜 안 들어가지지? 서버가 터졌나...?

 

사실 하나의 도메인 이름은 하나의 IP 주소를 점유하지 않습니다. 하나의 IP 주소가 여러가지 도메인 이름에 대응될 수도 있습니다. 서버는 받아낸 도메인 이름에 따라 다른 정보를 전달할 수 있죠. 예를 들어 클라우드플레어의 CDN 서비스를 적용한 사이트는 접속시에 클라우드플레어의 서버를 거치기 때문에 여러 사이트와 클라우드플레어의 IP 주소를 공유하게 됩니다. 이렇게 IP 주소 차단 방식은 보편적으로 쓰고자 하면 억울하게 차단되는 경우가 발생하기 때문에, 현재는 거의 사용되지 않고 있습니다. 사용한다면 북한에 할당된 IP 주소 영역 정도일까요.

 

2. DNS 서버 응답 변경

통신망에 특별한 설정 없이 접속하면 통신망 사업자의 DNS 서버를 사용하게 됩니다. 정부는 통신망 사업자의 DNS 서버에 간섭해서 특정한 도메인 이름이 가리키는 IP 주소를 허위로 알려 접속을 차단할 수 있습니다. 다음과 같습니다.

 

클라이언트 : www.pornocheonsa.com의 /view_video.php?viewkey=illegalporno18 라는 정보에 접근하고 싶어. www.pornocheonsa.com은 어디에 있지? DNS 서버 168.126.63.1, "www.pornocheonsa.com은 어디에 있지?"

DNS 서버 : www.pornocheonsa.com은 유해 사이트 목록에 포함되어 있네. 유해 사이트 접근 안내 사이트의 서버 IP 주소를 보내자. 클라이언트, "www.pornocheonsa.com은 121.189.57.82에 있어."

클라이언트 : 121.189.57.82 말이지? 서버 121.189.57.82, "/view_video.php?viewkey=illegalporno18를 www.pornocheonsa.com에서 꺼내서 보내줘."

서버 : 클라이언트, "불법·유해 정보(사이트)에 대한 차단 안내"야.

클라이언트 : 어라, 차단이 됐다고? 사이버경찰청? 뭐... 이러면 어쩔 수 없지...

 

DNS 서버는 도메인 이름을 통한 인터넷 연결에 필수적이기 때문에 차단은 확실할 것 같은데요, 아닙니다. 통신망 사업자가 제공하지 않는 DNS 서버에 요청하는 것으로 바꾸면 그만입니다. 구글이나, 클라우드플레어 등이 제공하는 DNS를 이용하면 어떤 사이트도 차단되지 않고 제공됩니다.

 

3. HTTP 통신 내용을 분석하여 차단

2007년 3월, 정보통신부는 위 두 가지 차단 방법의 한계를 인식하고 새로운 유해 사이트 차단 계획을 발표합니다.(디지털데일리, 2007. 03. 26, "음란물 새 차단 방법 ‘URL 차단’ 관심") HTTP 통신의 내용을 분석해서 URL(네트워크 상에서 자원의 위치를 나타내는 규약 및 이를 이용해 표현한 자원의 주소) 부분을 추출해서 차단한다는 계획입니다. HTTP 통신의 내용이란 간단히 말하자면 위 대화 내역들에서 큰따옴표로 감싼 부분과 같은 것입니다. HTTP 통신에서 클라이언트가 서버에 정보의 접근을 위해 보내는 내용은 대략적으로 다음과 같습니다.

 

GET /service/board/rule/10707404 HTTP/1.1

Host: www.clien.net

Cookie: SESSION=142151-12512-135-5-1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

 

(별로 안 중요한 부분 : 'GET'은 고정된 자원을 요청한다는 뜻이고, Cookie는 매 접속시마다 서버에게 알리고자 하는 고정된 정보를 나타내는 것으로 로그인된 회원을 식별하는 정보 등이 주로 보내지며 User-Agent는 사용자가 사용하는 클라이언트 프로그램(브라우저 등)이 어떤 프로그램인지를 서버에 알려서 알맞게 대응하게 하려는 목적으로 보내지는 것입니다. 그림파일을 업로드 한다든지, 비밀번호를 입력한다든지 하는 일회성 요청을 할 때는 GET이 아닌 POST를 쓰고 User-Agent의 밑부분에 두 줄 띈 상태로 보내고자 하는 데이터를 입력하여 보내게 됩니다.)

 

서버는 이 내용을 보고 어떤 정보를 전달할지 정한 다음 그 내용을 클라이언트에 보내게 됩니다.

 

정부가 통신망 사업자에게 요구하여 설치된 차단장비는 이제 위 부분을 읽어서 그 중 "/service/board/rule/10707404"와 "www.clien.net" 부분을 적절히 추출해서 유해 사이트 데이터베이스와 비교한 다음 연결의 허가 여부를 결정하게 됩니다. 연결을 허가할 수 없다면, 차단장비는 위 내용을 서버에 전달하지 않고 끊어버린 다음, 서버를 모방하여 클라이언트에 사이트가 이동되었다는 정보를 허위로 전달하여 유해 사이트 차단 안내 사이트로 이동하게 만듭니다. 대화 형식으로 나타내 보겠습니다.

 

클라이언트 : DNS 서버에 물어봐서 "www.pornocheonsa.com"을 제공하는 IP 주소 218.16.168.16을 알아냈어. 서버 218.16.168.16, "/view_video.php?viewkey=illegalporno18을 www.pornocheonsa.com에서 꺼내서 보내줘."

통신망 : 서버 218.16.168.16에 전달이 요청된 정보에서 도메인 이름과 자원 위치(pathname)를 추출합니다. "www.pornocheonsa.com"과 "/view_video.php?viewkey=illegalporno18"을 발견했습니다. 데이터베이스 조회 결과 "www.pornocheonsa.com"의 "/view_video.php?viewkey=illegalporno18"은 차단 대상입니다. 연결을 끊고 클라이언트에 "이 사이트는 warning.or.kr로 이동되었습니다."를 전달합니다.

클라이언트 : 사이트가 바뀌었어? 그럼 warning.or.kr로 이동해야겠다.

(과정 생략)

클라이언트 : "불법·유해 정보(사이트)에 대한 차단 안내"라니... 어쩔 수 없네. 포기하자.

 

이 방법은 순수한 HTTP 통신인 경우 이론상 회피가 불가능하므로(차단장비의 취약점을 이용한 "닷지크롬"이라는 개조 크롬 브라우저가 유포된 적이 있습니다.) 정부의 입장에서 썩 괜찮게 차단이 되었고, 현재까지 주된 차단방법으로 이용되고 있습니다.

 

무력화

현재 한국의 통신검열 시스템은 위의 세 가지 방식으로 이루어져 있습니다. 하지만 통신규약 개발자들은 보안되지 않은 통신 시스템이 정부 또는 해킹집단의 타깃이 될 것을 우려하여 통신비밀을 확보하기 위한 여러가지 시도를 하였고, 그 중 하나가 HTTPS입니다.

 

HTTPS는, HTTP 통신이 TLS 보안 통신 위에서 이루어지게 만든 것으로, HTTP 통신의 전체가 암호화되기 때문에 위에서 예를 든 "자원 위치"라든지, "로그인된 사용자를 식별하는 정보"라든지 하는 것이 노출되지 않습니다. 이것은 사실 2000년에 표준화가 된 것인데, 암호화 통신이 과거 컴퓨터 성능을 상당히 잡아먹었고 DDoS 공격에도 상대적으로 취약하다는 점 때문에 사이트 전체에 대해서 사용하게 된 것은 비교적 최근이 됩니다. HTTPS 통신일 경우의 통신 과정을 살펴봅시다.

 

클라이언트 : DNS 서버에 물어봐서 "www.pornocheonsa.com"을 제공하는 IP 주소 218.16.168.16을 알아냈어. 서버 218.16.168.16, "www.pornocheonsa.com에 보안 연결을 할 거야. 인증서를 줘."

서버 : www.pornocheonsa.com의 인증서? 클라이언트, "www.pornocheonsa.com에 대한 DigiCert, Inc.의 인증서. (공개키)"야.

클라이언트 : 올바른 인증서네. 공개키로 통신에 사용할 대칭키인 (대칭키)를 암호화해서 보내자. 서버, "(공개키로 암호화된 대칭키)"야.

서버 : (공개키로 암호화한 대칭키)가 왔네. 개인키로 복호화하자. 대칭키는 (대칭키)구나. 클라이언트, "준비 완료됐어."

클라이언트 : 준비가 완료됐으니 "/view_video.php?viewkey=illegalporno18을 www.pornocheonsa.com에서 꺼내서 보내줘."를 (대칭키)로 암호화해서 보내자. 서버, "(암호화된 HTTP 통신 내용)"

서버 : 클라이언트, "(암호화된 HTTP 통신 내용)"

(위 절차는 TLS 1.2에서의 Handshake 절차를 간략화한 것이며, TLS 1.3부터는 방식이 좀 달라집니다.)

 

Q. 대칭키, 공개키, 개인키가 뭔가요?

A. 대칭키는 암호화와 복호화에 쓰이는 비밀번호가 동일한 경우의 그 비밀번호를 말합니다. 공개키와 개인키는, 한 쪽으로 데이터를 암호화하면 다른 한 쪽으로 복호화할 수 있는 키쌍이고, 일반에 공개하는 것을 공개키, 공개하지 않는 것을 개인키라 합니다. 이 특성을 이용하면 공개키로 암호화한 것은 개인키 소지자만이 복호화할 수 있어 중간자 공격이 불가능하고, 개인키로 암호화한 것은 공개키로 복호화할 수 있어 개인키 소지자의 의사표현임이 증명됩니다.(공개키 서명) 자세한 수학적 원리를 알고 싶다면 구글에 "RSA 암호화"나, "공개키 암호화"를 검색해보세요.

Q. 대칭키를 왜 교환하나요?

A. 공개키/개인키 암호화는 컴퓨터 자원을 너무 많이 쓰기 때문에 비교적 자원을 덜 쓰는 대칭키 암호화를 쓰기 위해 대칭키를 교환하여 통신하는 것입니다.

Q. 인증서가 뭔가요?

A. 위에 언급한 공개키 서명 기법을 응용해 클라이언트가 서버와의 TLS 통신을 신뢰할 수 있는지 판단할 수 있도록 제공되는 정보의 묶음입니다. 생활코딩의 관련 페이지를 참고해주세요.

Q. 통신중에 www.pornocheonsa.com인게 평문으로 다 노출되어 있는데 왜 차단을 못 하나요?

A. 차단장비는 아직까지는 사람도 인공지능도 아니기 때문에, 위와 같이 형식이 완전히 달라진 연결을 업데이트 없이 차단할 수 없습니다.

Q. 클라이언트와 서버는 도메인 이름이 www.pornocheonsa.com이라는걸 왜 (평문으로) 보내나요?

A. 서버가 인증서에 도메인 이름을 넣어 보내는 이유는, 클라이언트가 인증서의 도메인 이름을 확인하여 본래 접속하고자 하는 도메인 이름이 아니면 부정한 통신으로 간주하기 때문입니다. 제3자가 간섭했을 가능성이 있다는 것이죠. 클라이언트가 도메인 이름을 보내는 이유는, 본래 접속하고자 하는 도메인 이름이 적힌 인증서가 아니면 접속을 차단하게 되는데 클라이언트가 도메인 이름을 보내지 않으면 클라우드플레어와 같이 여러 개의 서비스를 동시에 제공하는 서버가 무슨 인증서를 보내야 할지 알 수 없게 되기 때문입니다. 또한 클라이언트는 이 부분을 평문으로 보내지 않으면 서버가 복호화를 할 수 없기 때문에 통신이 성립하지 않게 되므로 평문으로 보낼 수밖에 없습니다. 서버의 인증서 암호화는, TLS 1.3에서 도입되었습니다.

 

HTTPS를 이용한 차단 무력화는 구글과 모질라 등 브라우저 업체가 HTTPS 전면화 정책을 펼친 영향으로 더욱 활성화되었고, 현재는 상당히 많은 "유해 사이트"가 HTTPS를 이용하여 차단을 무력화하고 있습니다.

 

새로운 방법

2018년 5월, 문화체육관광부와 방송통신위원회는 HTTPS를 이용한 차단 무력화로 수많은 저작권 피해가 발생하고 있는데 현재의 차단 방식은 실효성이 없다며, DNS 서버를 이용한 차단 기술을 다시 사용하고, SNI 영역을 이용한 차단 기술을 개발하겠다고 발표했습니다.(문화체육관광부 보도자료, 2018. 05. 02, "웹툰 등 불법유통 해외사이트 집중 단속 및 정품 이용 캠페인 연계 실시") 여기서 말하는 SNI 영역이라는 것이 바로 위에서 언급한 "HTTPS 통신에서 클라이언트가 보내는 도메인 이름"입니다.

 

SNI 영역을 이용한 사이트 차단은 국내에서는 새롭지만, 국외에서는 이미 통신 검열의 방법으로 어느 정도 쓰이고 있는 것입니다.

통신망 사업자 속이기

SNI 영역을 이용하는 이유는, 서버의 인증서를 클라이언트가 확인해야 하기 때문입니다. 그 말인즉슨, 클라이언트가 서버의 인증서를 확인하지 않을 것이라면 SNI 영역을 허위로 보내도 된다는 것입니다. 실제 통신하고자 하는 도메인 이름은 HTTP 통신 시에 기재하면 통신할 수 있습니다. 이 꼼수를 이용해 검열을 회피하는 기법을 "도메인 프런팅(domain fronting)"이라 합니다. 텔레그램이나, 시그널 메신저가 이런 방법을 이용해서 각국 정부의 검열을 회피했습니다.

 

이 꼼수에는 결국 제동이 걸립니다. 2018년 구글과 아마존은 각각 도메인 프런팅 행위를 "지원한 적도 없으며, 약관 위반이다"라며 금지하였고, SNI 영역을 이용한 검열은 유효해집니다. 일각에서는 이것이 "러시아 정부의 텔레그램에 대한 압박의 일환"이라 해석하기도 했습니다.

 

보안 업그레이드

SNI 영역이 평문으로 노출되는 문제는, 통신규약 개발자들이 인지하고 있던 TLS의 최대 문제였고, 이를 암호화하는 방법이 오랫동안 논의가 되어왔습니다. 본래 TLS 1.3 버전의 개발 과정에서 이 문제를 해결하고자 상당 기간 논의가 되었으나, 결국 TLS 1.3 최종 버전에서 SNI의 암호화는 빠졌습니다. 다만, 이와 별개로 TLS 1.3을 전제하여 SNI를 암호화하는 규약(Encrypted SNI, ESNI)의 제안이 2018년 7월 3일 IETF에 등록되었고, 이를 기반으로 9월 말, 클라우드플레어와 모질라가 자사의 서비스/프로그램에 SNI 암호화를 적용하게 됩니다.

 

위에서 저는 "클라이언트가 SNI를 평문으로 보내지 않으면 서버가 복호화할 수 없다"고 했는데, 그렇다면 ESNI 규약에서는 어떻게 SNI를 암호화하죠? ESNI 개발진은 이 질문의 해답으로 DNS 서버를 사용하자고 제안합니다. 서버가 DNS 서버에 미리 공개키를 보내놓으면, 클라이언트가 DNS 서버에 접속해서 공개키를 받아와 SNI를 암호화해서 서버에 전달하고 서버가 개인키로 이를 복호화할 수 있다는 것이죠.

 

한국 정부가 검열에 사용하지는 않았지만, 평문으로 전송되는 DNS 정보는 정부의 영향을 받는 통신망 사업자나 해킹집단 등에게 쉽게 노려질 수 있고, 따라서 ESNI의 사용 이전에 DNS 서버와의 보안 통신 역시 중요한 요소입니다. 사실, 현재로서는 DNS over HTTPS 연결이 아닌 경우 DNS 서버로부터 공개키가 오지 않으며 Firefox의 ESNI 구현에서는 DNS over HTTPS 연결이 의무적입니다.

 

또한, 해당 서버가 DNSSEC 유효성 검사라는 것을 하고 있는지도 중요합니다. DNSSEC란 DNS가 보안을 고려하지 않고 설계되었다는 점을 보완하기 위해 DNS 체계에 공개키 서명 체계(공개키 암호화를 응용하여 개인키로 암호화된 정보를 공개키로 복호화하여 정보의 무결성을 확인하는 체계)를 도입하여 정보의 무결성을 검증할 수 있도록 한 규약입니다. DNS 서버는 수많은 DNS 서버와의 통신으로 도메인 이름에 해당하는 IP 주소를 알아내는데, 이 절차를 클라이언트가 요청할 때마다 매번 수행할 수는 없으니 IP 주소를 알아내면 이를 캐싱하게 됩니다. 해커는 이 점을 노려 DNS 서버에 다른 DNS 서버의 응답을 가장하여 허위 정보를 보내고, DNS 서버가 이를 진실로 받아들인다면 DNS 서버에 허위의 정보가 캐싱되어 그 DNS 서버에 IP 주소를 요청한 수많은 클라이언트에 피해가 가게 됩니다. DNSSEC 유효성 검사는 이러한 상황을 방지하기 위한 것입니다.

 

종장

하지만, DNS over HTTPS+DNSSEC+TLS 1.3+ESNI가 모두 동원되더라도 중국처럼 국가와 통신망 사업자가 인터넷 검열에 "사활을 건다면" 완벽한 우회 수단은 될 수 없을 것입니다. DNS over HTTPS가 지원되는 DNS 서버를 모두 차단해버린다거나 하는 방식으로 말이죠.

 

"권리 위에 잠자는 자는 보호받지 못한다"는 말처럼, 인터넷 검열에 대해서 우리는 "회피"만을 택하지 않고 "저항"해야 궁극적 해결을 볼 수 있을 것입니다.

 

 

 

 

https://www.clien.net/service/board/lecture/12724781?od=T31&po=51&category=&groupCd=








TitleNickname
59외국계 기업 장단점TT7370
58맥도날드 칼로리초코보44050
57[펌] 욕실 거울을 늘 깨끗하게 유지하는 법.배드6620
56[펌] 만화 애니메이션 대학 입시 - 학원에 대해배드6670
55[펌] 매콤하고 부드러운 마파두부 만들기배드6630
54[펌] 노래 잘 부르는 방법3배드6480
53[펌] 노래 잘 부르는 방법2배드7530
52[펌] 노래 잘 부르는 방법1배드6360
51HDR 동영상을 컴퓨터로 감상하기 (팟플레이어)배드12440
50PPT 이미지 때문에 용량 커질때 쉽게 줄이는 팁배드7730
49[펌] HTTP 인터넷 통신의 구조와 검열배드6580
48유튜버 시작 팁배드6410
47간헐적 단식 방법배드6750
46(안드로이드) 휴대폰 간 카카오톡 백업 & 복구 (대화, 사진, 미디어 포함)배드7150
45심심해서 적어보는 넷플릭스 이용 팁배드6570
44[펌] 초파리 트랩배드8710
43변비해소에 도움되는 음식TT6720
42증권사 선택 요령둥글둥글7640
41쓸만한 노트북 사양TT7780
40시미켄의 보양식배드8570
39윈도우에서 특수문자 입력방법TT7190