들어가기 전에, 용어 정리
네트워크에는 평문 전송과 암호화 전송이라는 말이 있습니다.
평문 전송은, 암호화 하지 않은 데이터 전송이라는 뜻으로... 네트워크 장비에서 모든 데이터를 다 까볼 수 있다는 뜻입니다.
앞으로의 글에서, 네트워크 데이터 전송은 암호화 전송이라는 말이 없는 이상 모두 평문 전송입니다.
0. Government is watching you
모든 클라이언트와 서버는 이런 식으로 연결되어 있습니다(실제로는 장비를 최소 대여섯개는 더 거치겠지만요).
자동차가 출발지에서 목적지까지 수많은 교차로를 거쳐가며 이동하듯이, 네트워크 데이터도 수많은 라우터를 거쳐가며 이동하는거죠.
정부는 저 네트워크 장비들마다 자기네들의 감청 시스템을 달아서, 자기들 입맛에 맞지 않는 데이터는 조작해 버립니다.
1. 태초에 HTTP Host가 있었으니...
클리앙 인이라면 HTTP, HTTPS라는 단어 한번쯤은 들어보셨을 겁니다.
HTTP/HTTPS는 인터넷에서 서버와 클라이언트가 통신하는 하나의 방식입니다. 더 이상 설명하면 너무 길어지니 이정도만 알아 두시고...
예를 들어, 한 클량인이 파이어폭스한테 " 'www.clien.net'으로 접속해줘!" 라고 요청을 했다고 합시다. 이를 그림으로 나타내면...
대략 이런 모양이 됩니다.
i. 먼저, 브라우저는 유저가 입력한 도메인(www.clien.net)을 IP로 변환해야 합니다. 이를 위해 네임 서버라는 서버에 먼저 접촉을 합니다. 네임 서버는 도메인에 대응하는 IP들이 저장된 공간입니다.
ii. 네임 서버에 접촉해 IP를 얻고 나면, 이 IP에 /(루트) 페이지를 달라고 요청을 합니다. 해당 IP에는 클리앙 서버가 살고 있으므로, 클리앙의 메인 페이지를 리턴해 주겠네요.
ii번 과정을 자세히 보면,
브라우저는 모공을 화면에 띄우기 위해 클리앙 서버에 다음과 같은 글자를 보냅니다.
중간에 "Host: www.clien.net"이 보이시죠? 이 부분은 모든 HTTP 연결을 할 때 등장합니다. 다시 말해, HTTP 연결을 할때는 사이트의 도메인이 꼭 들어간다는 얘기죠.
그림으로 그리면 이렇게 생겼습니다.
정부의 네트워크 장비는 이 점을 노립니다.
ISP(인터넷 제공자, kt, SKB, U+ 등등)의 장비에 기생하면서 ISP의 네트워크 장비에서 오가는 모든 데이터를 감시하다가, HTTP 연결과 비슷한 형태의 데이터가 사행성/음란물 사이트 등의 도메인을 포함하면...
그 순간, 네트워크 장비는 본인이 유저가 접속한 서버인 마냥 위장하고, 가짜 데이터를 유저에게 되돌려 보냅니다.
그림으로 그리면 이렇게 되겠네요.
당연히 유저는 이 데이터가 진짜 서버에서 온건지, 아니면 감시장비에서 위장한건지 알 턱이 없습니다.
2. 구세주 HTTPS의 등장
그리고, HTTPS가 등장합니다.
HTTPS를 통한 연결에서는,
i. 먼저, 브라우저는 유저가 입력한 도메인(www.clien.net)을 IP로 변환해야 합니다. 이를 위해 네임 서버라는 서버에 먼저 접촉을 합니다. 네임 서버는 도메인에 대응하는 IP들이 저장된 공간입니다.
ii. 네임 서버에 접촉해 IP를 얻고 나면, 클리앙 서버에 바로 데이터를 보내는 대신, 데이터 암호화 키를 달라고 합니다.
iii. 브라우저는, 전달받은 암호화 키를 이용해 데이터를 암호화 해서 보냅니다. 마찬가지로 서버도 데이터를 암호화 해서 브라우저에게 전달합니다. 서버와 클라이언트는 서로 무슨 말을 했는지 다 알수 있지만, 네트워크 장비는 얘들이 무슨 말을 하는지 해독할 수 없죠.
이래서 기존 차단 방식이 무용지물이 된 것입니다.
3. DNS의 차단
HTTPS로 인해 자신들의 노력이 허무하게 날라간 정부는, 부들부들대면서 DNS에 손을 대기로 합니다.
HTTP나 HTTPS나, 네임 서버에 접촉하는 과정에서는 네트워크 장비에서 유저가 어떤 도메인의 IP를 요청하는지 다 볼 수 있었죠?
이를 이용해서, 네트워크 장비들은 불건전한 도메인의 IP를 요청하려고 하면 마찬가지로 중간에 가로채서 warning.or.kr 사이트의 IP를 전달해 줍니다.이는 1번에서 말한 HTTP 차단 방식과 비슷합니다.
그림으로 그리면 이렇습니다(NS는 네임 서버의 약자입니다).
4. DNS over HTTPS
최근 모공에서 나름 핫한 기술입니다.
DNS over HTTPS(이하 DoH)는, 엄밀히 말해서 DNS 프로토콜을 이용한 기술이 아닙니다.
(without DoH)
(with DoH)
먼저, 컴퓨터에 네임서버를 설치합니다. 근데 이 네임서버(로컬 네임서버)는 조금 특수한 아이입니다.
보통의 네임서버는 도메인에 대한 정보가 들어있고, 유저의 요청 시 그 정보를 전달해 주지만 이 로컬 네임서버는 정보를 저장하지 않습니다.
그 대신, 유저로부터 도메인에 대한 요청을 받으면, 도메인에 대한 정보가 담긴 서버(이 서버는 네임 서버가 아닙니다)에 HTTPS를 이용해서 IP주소를 달라고 요청합니다.
HTTPS로 데이터를 전달했으니, 네트워크 망에 빈대붙어있는 감시자는 우리가 무슨 도메인에 대한 IP 정보를 요청했는지 모르겠죠?
이렇게 해서 데이터를 받아온 로컬 네임서버는, 보통의 네임서버가 동작하듯이 IP 정보를 브라우저에게 전달해 줍니다.
이렇게 해서, 우리는 두번째 차단까지도 피해가는데 성공합니다.
3. SNI 차단
이 방법은 아직 상용화되지 않은 방법입니다만, 높은 확률로 상용화가 될 것입니다.
2번 HTTPS 부분에서, 인증서를 요구하는 부분에서는 실제로는 인증서만 요구하지는 않습니다. 이 부분을 TLS Handshake라고 하는데, 여기서는
i. 클라이언트가 서버와 TLS/SSL 인증 버전을 서로 맞추고,
ii. 서로 이런저런 정보 교환을 하며,
iii. 서버와 클라이언트가 각각의 인증서를 서로 맞교환합니다.
HTTPS가 기본적으로 암호화 전송이지만, 이 구간만은 평문 전송을 통해 데이터를 전송합니다.
암호화와 복호화(암호화된 문장을 평문으로 바꿈)를 하는데는 암/복호화 키가 필요하지만, 이를 받지도 않은 상태에서 문장을 암/복호화 하는 것은 불가능이니까요.
그리고 문제는, 위에서 말한 Handshake 과정중 ii 번에 도메인 정보가 들어있다는 것입니다.
맨 밑을 보면, 클라이언트가 서버에게 SNI 라는 이름으로 도메인 명을 제공하고 있죠?
정부는 이 부분을 캐치해서 연결을 차단할 것으로 보입니다. 차단 방법은 HTTP/DNS 차단과 비슷할 듯 하네요.
다만 vpn은 비용이 들고 속도 등의 문제가 있기에 각종 우회 방법을 찾아보는거죠.
클리앙킷
완벽하게 이해가 됐어요!!ㅎㅎ...정말이에요!!ㅎㅎ.........
정보 감사합니다!
이런 글 너무 감사합니다
1. 이름을 부르면 옆에서 듣고 샤샤샥 달려와서 끼어들고 악수 받는 손을 바꿔치기하는 어깨 형님들이 있다 칩시다.
2. HTTPS는 암호화되어 이름이 옆에서 안 들립니다. 어깨 형님들은 지켜보지만 제가 누구랑 악수하는지 모릅니다.
3. 그러나 상대방 집주소(서버)가 같은 곳은 가상호스트(집으로 치면 같은동에 호수만 다름)가 필요합니다.
4. 가상호스트는 평문으로 크게 소리지릅니다. Xx ip에 있는 여러 사이트 중에 클리앙 나와라!
5. 지금은 HTTPS를 건들지 않지만 그 암호화 직전의 클리앙 나와라 소리를 듣고 달려올 준비가 진행중입니다.
6. 지금의 DNS 차단 기법은 이 단계 전에 "클리앙은 서울시 어디에 있냐?"에 "서울이 아니라 경찰청 뒷마당이야"라고 어깨 형님들이 대답하는 형태로 위와 다릅니다.
지금은 아마존 등 클라우드 서버에 여러 사이트가 입주하는게 대세라 SNI는 피할 수 없는 상황입니다.
뒤늦게 이 이름 부르기도 암호화하는 기술이 개발중이지만 표준화가 안 된 걸로 압니다.
그렇다면 일반 브라우저에 도입은 훨씬 더 먼 일이 되겠죠.
하지만 TLS가 SNI 암호화를 넣는다고하니 지금의 정책은 결국엔 다 막힐 정책들이죠.
편지 내용이야 열어볼 수 없다지만, 수신자 주소가 적히지 않은 편지는 없으니까요.
해당 IP에서 돌아가는 다른 서비스도 함께 막히겠지만, 정부가 그런거 신경쓰진 않겠죠.
새벽에 설렁설렁 쓰다 SNI 파트 쓸때쯤엔 너무 졸려서 걍 대충 써버리고 잤습니다. 죄송합니다. 꾸벅...