1. 개요

 

2월 11일 인터넷 포털 및 각종 사이트에서는 여기저기 우려의 목소리와 신음이 터져 나왔다. 나는 패치를 얼마 두지 않은 시점에다가 개발 과제가 산더미처럼 쌓여 있었기에 뒤늦게 해당 사실을 알게 되었다. 작년부터 SNI를 이용하여 차단 하겠다고 몇 번의 발표는 있었던 듯 하다. 하지만 뉴스를 접하고 내심 놀랐다.

 

'설마? 정말? SNI를 이용해서 차단 했다고?'

 

이런 심정이었다. 주변 동료들에게도 물었다. 서버 개발자, 서버 시스템을 담당하는 인프라 담당자들에게도 물어 보았더니 반응이 나와 비슷했다. 때 마침 죽지않는돌고래 편집장에게 메시지가 날아 왔다. 해서 개발자의 관점으로 써 볼까 마음을 먹었다.

 

많은 사람들이 마음의 안식처(?)를 잃어 버린 것에 가슴 아파하며 분노를 터트린다. 그 부분에 대해선 최대한 언급하지 않겠다. 성인물 및 여타 사이트의 합법적 고려는 내가 쉬이 말할 수 있는 분야가 아니다. 아무래도 사회학에 대한 방대한 지식이 필요할 것이며 별도의 통계 자료와 같은 사전 자료도 꽤나 필요할 것이다.

 

이 쟁점에 대해서 복합적인 안을 가지고 접근하는 것도 좋지만 일단 내가 개발자라 기술적인 관점과 현장의 관점에서 언급하는 것이 나에게 맞기에 이 점에 대해서만 기술해 보겠다.

 

 

 

2. HTTP와 HTTPS 그리고 SNI

 

어떤 방식으로 차단이 되었는지 알기 전에 기본적인 차이는 개념적으로 알 필요 있다. HTTP와 HTTPS 등의 개념은 '구글'에서 검색하면 한 트럭 분량 만큼 나온다. 자료도 꽤나 양질이다. 각 프로토콜 상세도까지 자세히 설명해 놓았다. (프로토콜이란 통신하기 위한 서로의 규칙이라고 생각하면 된다)

 

그러므로 여기서는 해당 프로토콜에 대한 자세한 설명은 생략한다. 해봐야 재미도 없고 전공자가 아니고서는 알아 보기도 쉽지 않다. 최대한 비유에 빗대어 설명하고자 한다. 많은 사람들이 알게 되면 좋게 말이다. 기술적인 부분도 현 사태와 관점에서 알기 쉬운 부분만을 설명하고자 한다.

 

 

- HTTP (HyperText Transfer Protocol) : 암호화 되지 않는 통신

 

당신은 사랑하는 미자씨에게 한 통의 연애 편지를 보내려고 한다. 그냥 예쁜 글씨로만 적어서 편지(Body)를 주소(URL)가 적힌 봉투(Header)에 씩씩하게 넣었다. 그리고는 어떤 우체국(DNS)에 갈 것인지를 고민하고 편지를 수거해가는 집배원(ISP)에게 건네 준다. (집배원이 집 앞으로 온다고 임시로 생각하자)

 

집배원이 우체국(DNS)으로 가서 "저 여기로 보낼 건데요?"하고 물어보면 우체국(DNS)에서 "거기 우편번호 123-456입니다." 하고 알려준다. 그 주소로 편지를 보내면 아주 간단히 미션 완료가 되고, 결국에는 차일 것이지만 헛된 희망을 가지게 된다. 이것이 기본적인 HTTP의 통신이다. 하지만 암호화 되지 않은 것에 대해서는 심각한 문제가 있는데 문제는 다음과 같다.

 

집배원이 우체국으로 가다 한 무리의 불량배를 만나게 되었는데 뒤져서 나오면 10원에 한 대씩 이라고 엄포를 놓는 바람에 편지 봉투를 보여 주고 말았다. 불량배가 봉투를 보니 '사랑하는 미자'씨에게 라고 적혀 있어 봉투를 뜯어 내용을 봤더니 '5월의 나비가 날고 훈풍에 실린 꽃 내음이 코 끝을 농락 할 때 나 그대 미자씨를 항상 생각 합니다...' 라는 연애 편지가 적혀 있었다. 불량배들은 낄낄 대고 웃으면서 당신의 편지를 전부 다 읽는다. 그리고 봉투의 미자씨 주소와 이름에 낙서를 하고 집배원이 한 눈을 판 사이에 편지마저 바꿔치기 해버렸다.

 

우여 곡절 끝에 편지가 전송되었지만 편지는 미자씨에게로 간 것이 아니라 철수에게로 갔고 내용은 '5월의 나비가...'의 내용이 아니고 '이 편지는 영국으로부터...' 따위로 변해 있었다.

 

즉 암호화 되지 않아 내용물이 공개되고 해킹 당한 것이다.

 

 

- HTTPS (Hypertext Transfer Protocol Secure) TLS/SSL : 암호화 된 통신

 

미자에게 신나게 차여버린 당신은 좌절에 빠졌고 대신 옆 동네 순자씨와 다시 잘해보고 싶었던 찰나에 우정국의 광고가 나온 것을 보게 되었다.

 

'마법의 암호화를 사용 하십시오. 당신과 당신의 연인 이외에는 절대로 읽을 수 없는 신비를 체험 하십시오! 당신이 암호화 한 것은 당신의 연인만 풀 수 있습니다. 아닐 시는 전액 환불!!!'

 

그렇게 해서 두 통의 편지를 쓴다. 한 통은 순자씨가 어떤 암호 해독집(암호 해독집은 순자씨만 가지고 있어서 안전하다)을 써야 하는지 적혀 있는 일반 편지다. 그리고 한 통은 암호화를 해서 편지(Body)를 쓰고 주소(URL)가 적힌 봉투(Header)에 넣어 들고 둘 다 집배원에게 건넸다.

 

역시나 중간에 불량배들을 만나 편지를 빼앗겼지만 불량배들은 봉투에 적힌 주소 조차 읽을 수가 없었다. 알 수 없는 문자로 쓰여 있었고 화가 난 불량배가 편지의 내용을 들여다 보았지만 내용 역시 전혀 이해 할 수 없었다. 그래서 집배원은 웃는 얼굴로 우체국으로 가서 순자에게 편지를 보내는 것에 성공했다. 그리고 순자씨는 먼저 온 편지에 적힌 암호집으로 암호를 풀어 '5월의 나비가...'하는 내용을 읽고 과감히 거절하기로 결정 했다.

 

하지만 여기서도 문제가 하나 있다. 바로 집배원이 두 번째 편지를 순자씨에게로 배달 할 수가 없다는 것이다. 왜냐하면 봉투의 목적지도 암호화 되었기 때문에 집배원이 읽을 수 없다. 그래서 봉투의 안쪽에다가 아주 조그만 하게 어디로 갈 편지인지 내용을 암호화 하지 않고 '순자네 집'이라고 기록해 놓기로 했다. 그러면 집배원이 그 내용을 보고 순자씨에게 정상적으로 배달을 하게 된다.

 

바로 이 봉투 안의 작은 주소 메모('순자네 집')가 SNI(Server Name Indication)다. 그리고 이 SNI의 실질적인 주요 기능은 '순자네 집' 메모 하나로 순자씨, 순자 아버지, 순자 할머니, 순자 할아버지, 순자 오빠, 순자 이모 등 모두 순자 식구라면 추가적인 암호화 및 IP 비용을 들이지 않고 편지를 주고 받을 수 있게 하는 것이다.

 

 

3. 차단의 방식

 

일전의 차단 방식은 DNS에서 차단한 방식이었다. 즉 우체국에서 편지를 보내기 전에 봉투에 적힌 수신 주소를 보고 우체국에서 차단 해버리는 것이다. 그래서 HTTP로 접속을 하게 되면 차단되어 warning 화면으로 목적지가 바꿔 치기 되는 것이다. 하지만 HTTPS를 사용하면 봉투의 목적지도 암호화 되기 때문에 우체국은 차단에 실패하게 된다.

 

이번에 큰 논란이 되고 있는 차단의 방식이 SNI를 이용한 차단 방식이다. 즉, 봉투(Header)를 까서 암호화 되어 있지 않는 SNI를 읽어 들인 다음 이를 이용해 차단 했다. 그리고 차단 주체도 집배원이 현장에서 바로 까서 차단을 하게 되는 방식이다. 이는 편지의 내용물은 절대 볼 수 없다. 하지만 어디로 갈 편지인지 확인 한 다음에 차단한다.

 

그렇다면 논란도 벌어졌겠다, 이것이 정말 검열 혹은 사찰인가, 한번 살펴 볼 필요가 있다.

 

 

 

4. 이 방식은 문제 될 것이 없는가?

 

"내용을 직접적으로 보지 않기 때문에 이는 별로 문제 될 것이 없다"라는 견해에 동의 하는가? 하고 물어 본다면 현재로선 '네'라고 대답 할 수 없다. 나 뿐만 아니라 주변 개발자들도 마찬가지며 특정 사이트를 차단했기 때문에 감성적으로 그러하다, 라는 것이 아니다. 이러한 견해는 감성적, 철학적, 정치적 사유가 아닌 기술적인 측면에서 보았을 때 쉬이 동의 할 수 없다. 그 이유는 다음과 같다.

 

A) HTTPS Header(봉투)를 굳이 뒤지는 것 자체를 문제로 볼 수 있다

 

HTTPS는 보안이 가장 중요한 측면이라고 해도 과언이 아니다. 그런 통신 규약에서 굳이 내용이 아니라 어디로 행하는지 적혀 있는 요소를 분석한다는 행위 자체가 문제시 되는 것이다. 비약적으로 본다면 오히려 이를 행함으로 통신에 대한 보안요소를 공격하는 '중간자 공격' 역할을 한다고도 볼 수 있다.

 

즉, 보안이 최우선시 되어야 하는 통신의 보안 요소를 굳이 파헤쳤다는 것. 이 자체를 문제로 볼 수 있다. (중간자 공격 : 중간자 공격(man in the middle attack, MITM)은 네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법이다. 중간자 공격은 통신을 연결하는 두 사람 사이에 중간자가 침입하여, 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사람은 중간자에게 연결되어 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달한다. 링크)

 

B) Wikipedia

 

방송통신위원회는 '검열과 무관하다'라는 표현을 썼다. 정말 무관 할까?

 

우선 나는 해당 자료를 보기 위해 Wikipedia를 뒤졌다. HTTPS TLS/SSL, SNI는 해외가 원천 기술이자 표준 규격이므로 영어를 못하지만 멋있어 보이기 위해 영어 버전으로 뒤져보았다. (링크)

 

중간 항목에 보안 관련 사항(Security implications)이 있는데 그 중 첫 문장을 그대로 나열 해보면 다음과 같다. (그리고 우리는 영어를 왕 잘하므로 번역기로 돌린 것을 해석으로 아래에 적는다)

 

"The desired hostname is not encrypted, so an eavesdropper can see which site is being requested. This has been used to implement censorship."

(원하는 호스트 이름은 암호화되지 않으므로 도청자는 요청중인 사이트를 볼 수 있습니다. 이것은 검열에 사용되었습니다.)

 

검열(censorship) 이라는 단어를 명시적으로 사용했다. 겨우 Wikipedia를 보고 너무 오버 하는 것 아니냐, 라고 할 수 있다. 그리고 Wikipedia는 다양한 사람이 편집을 하므로 공신력이 없는 것 아닌가, 하고 의문을 가질 수도 있다.

 

자. 그렇다면 C 항목을 보도록 하자.

 

 

C) IETF

 

IETF가 무엇을 하는 곳이냐 하면 다음과 같다.

 

'국제 인터넷 표준화 기구(Internet Engineering Task Force, IETF)'

 

이름도 엄청 멋있다. 태스크 포스다. 여기는 인터넷에 대한 표준화를 만들어 내는 작업 기구다. 개별적인 연구원부터 시작하여 망 사업자까지 다양한 분야의 사람과 조직이 참여하고 있는 글로벌 연구 공동체다. 매년 기술 회의가 개최되는데 회의 참석 연구원 수가 1000명 수준을 넘고 있다.

 

즉, 전세계의 인터넷 기술 덕후들이 서로 모여서 우리가 쓰는 인터넷 기술 표준을 확립하고 기술적인 쟁점 등을 해결하기 위한 조직이라고 생각하면 된다. 우리가 쓰고 있는 HTTPS TLS 또한 여기서 표준 확립이 되었고 이에 따른 기술 문서가 있다. (IETF : https://www.ietf.org/)

 

해당기구의 홈페이지에 방문하면 도출된 표준화 및 기술 문서를 누구든 열람을 할 수 있다. 가서 찾아 보았더니 다음과 같은 문서가 있었다.

 

링크 > Issues and Requirements for SNI Encryption in TLS

PDF > 링크

 

문서의 제목은 다음과 같다.

 

'Issues and Requirements for SNI Encryption in TLS'

(TLS의 SNI 암호화 문제 및 요구 사항)

 

내용은 현재 논란이 되고 있는 SNI에 대한 암호화에 대한 기술 초안 문서다. 이 문서 중간에 공개된 SNI의 잘못된 사용 사례에 대해 몇 가지 나열했다. 그 부분은 아래와 같다. 5가지의 사례가 나오는데 3가지만 옮기고 대충의 번역을 아래에 달아 놓았다. (문서 섹션 2.1 Unanticipated usage of SNI information : 예상치 못한 SNI 정보 사용)

 

o Censorship of specific sites by "national firewalls",

- "국가 방화벽"에 의한 특정 사이트 검열

 

o Content filtering by ISP blocking specific web sites in order to implement "parental controls", or to prevent access to fraudulent web sites, such as used for phishing,

- "유해 컨텐츠 차단"을 구현하거나 피싱에 사용되는 것과 같은 사기성 웹 사이트에 대한 액세스를 차단하기 위해 ISP가 특정 웹 사이트를 차단하는 콘텐츠 필터링

 

o ISP assigning different QOS profiles to target services,

- 인터넷 공급자(ISP: SKT,KT,LGU 등)는 타겟 서비스에 다른 QOS를 할당(QOS의 의미는 Quality Of Service. 쉽게 생각해서 인터넷 공급자가 특정 서비스에 통신 품질을 임의대로 제한을 할 수 있다고 생각하면 된다.)

 

위에서 나열된 사례들이 우리와 딱 맞아 떨어진다. IETF에서는 이 방식을 개인 사생활에 대한 침해라고 보고 문제임을 제기 했다. (여기에 나열하지 않은 사례 중 한 가지 사례에 '개인 사생활 침해'라는 표현이 등장한다.)

 

그리고 섹션 2.3에서는 다음과 같이 기술 한다.

 

Deploying SNI encryption will help thwarting most of the "unanticipated" SNI usages described in Section 2.1, including censorship and pervasive surveillance.

- SNI를 암호화 해서 배포 하는 것은 검열과 만연한 감시를 포함한 섹션 2.1에서 소개된 예상치 못한 SNI의 사용을 막는데 도움이 될 것이다.

 

한 줄 요약 하자면 IETF에는 SNI자체를 임의 조작 및 감시 하는 것을 문제로 인식하고 있고 이를 방지 하기 위한 기술 문서가 등록 되었다.

 

방송통신심의위원회가 내어 놓은 '검열과 무관합니다'와 다르게 IETF는 검열이라고 보고 있다.

 

 

D) 어차피 Header(봉투)는 까서 보는 것인데 좀 보는 것은 괜찮지 않나?

 

이렇게 생각 할 수도 있다. 어차피 그 Header라는 것은 결국 분석되는 것일 텐데 그거 미리 깐다고 해서 뭐 달라질 것은 없잖아?

 

대답부터 말하자면 그렇게 해서는 안 된다. 이유는 다음과 같다.

 

우리가 사용하는 네트워크 통신들은 상당히 복잡한 단계의 'Layer(층 혹은 단계)'를 거친다. 쉽게 상상이 안 될 것이므로 비유 하자면 '징병 검사' 혹은 '큰 병원에서 건강 검진'을 상상해 보자. 이런 곳은 각 검진과가 쭉 배열이 되어 있고 각 과에는 의사나 측정 간호사가 앉아서 측정을 해 주고 이상이 있는지 봐주고 있다.

 

당신은 문진표를 들고 첫 번째 과부터 순차적으로 들러야 한다. 첫 번째 과에서는 키와 몸무게를 재고 기록한 다음 내과로 넘어가서 혈압을 재고 채혈한다. 그 다음 안과로 넘어가서 시력을 측정하고 방사선과로 넘어가서 흉부 X-Ray를 찍고 마지막에 치과에서 이빨 상태를 본다.

 

이렇게 지나 오면서 당신의 문진표에는 검진 결과가 차례대로 기록이 되고 마지막을 지나오면 당신은 건강한 사람인지 건강하지 않은 사람인지 판명된다. 혈압만 재고 중간 단계를 다 뛰어 넘어 마지막으로 올 수 없다. 온다 하더라도 다시 돌려 보내지게 된다. 여기서 당신을 통신 패킷으로 대입하고 각 과를 Layer라고 대입하면 된다. 그리고 문진표를 Header로 대입해 보라.

 

각 병원의 과처럼 각 Layer에서 검사하고 확인하는 것들이 전부 다르다. 이 모든 Layer들을 정상적으로 통과 했을 때 우리는 당신, 즉 패킷이 건강해서 열람해도 되는지를 알 수 있다. 암호화 되어 있지 않다고 이를 중간에 먼저 까보는 것은 다음과 같다.

 

혈압만 재어야 하는 내과 의사가 갑자기 당신의 입을 강제로 열어 봐서 치과 검사를 한 다음 '오 이사람 충치가 없구먼. 특전사 보내!'라고 하는 것과 유사하다.

 

그렇다면 이렇게 중요한 단계들을 안전하게 거쳐야 하는 것인데 왜 이렇게 암호화 하지 않고 허술하게 해 놓았나 하고 반문할 것이다. 그러니 E 항목을 보자.

 

E) 보안 취약점

 

서버 개발자나 인프라 담당자들에게 벌어지는 일 중 가장 우선 순위가 높은 업무 중 하나가 보안 취약점 개선이다. 사내에서 일어나는 간단한 보안적 이슈도 있지만 중대한 경우 세계적으로 공표되고 가이드가 되는 사항도 있다. 이는 보안이 취약한 점을 통하여 부작용이나 공격의 가능성이 있기 때문에 가이드가 배포되면 최대한 빠른 시일 내로 조치 한다.

 

전 세계에 퍼져 있는 연구원들이 연구를 하다가 "어? 이거 이상하다!. 저기 님들. 이거 이상하니까 빨리 업그레이드하고 구 버전은 버리세요. 그리고 이 부분은 이렇게 고치세요. 안 그러면 이 구멍으로 공격 당합니다~" 라고 공표한다. (HTTPS에 대해서는 대표적으로 'Poodle' 취약점이 있었다. SSL 3.0에서 발생한 보안 이슈로 이 보안 이슈를 회피하기 위해 이에 대한 조치 가이드가 공표 되었고 수정을 권고했다. 개인정보들을 다루는 중요한 서버들은 해당 권고를 지키지 않는 접속들을 차단하는 극단적 조치도 행했다.)

 

암호화 되지 않는 SNI를 보안 취약 부분이라고 보기 시작했다. (SNI 공개로 인한 부작용은 미처 고려하지 못하였다고 문서에 기재되어 있다) 그래서 C항목에서처럼 IETF에서는 암호화 해야 한다고 기술 문서가 등록 되었고 실제로 이것이 구현된 기술인 ESNI(암호화된 SNI)가 2018년 중반에 시범적으로 서비스 되기 시작했다. 그리고 현재 우리가 사용하고 있는 HTTPS TLS의 1.3 버전에서는 본격적으로 논의도 이루어졌다.

 

참 아이러니 하게도 2월 11일 SNI를 이용한 차단이 이루어지기 훨씬 전, 이미 다른 국가나 단체에서는 이 자체를 취약점으로 보고 있고 이를 방지하기 위한 기술 개발을 해 나가고 있고 논의 해가고 있다. 즉 D의 마지막에 말한 내과의사가 치과를 기습적으로 검진하는 사태를 막아 나가고 있는 것이다.

 

지금 ESNI(암호화된 SNI) 서비스를 이행하고 있는 'ClOUDFLARE'에서는 당신의 인터넷 브라우저가 ESNI를 지원 하는지 체크 서비스까지 지원하고 있다. 궁금 하신 분들은 아래의 링크에서 체크 해보시면 된다.

 

검사 URL : https://www.cloudflare.com/ssl/encrypted-sni/

 

위에서 나열한 모든 것을 내려 놓고 이렇게 생각하는 사람이 있을 것이다. '내가 접속하고자 하는 사이트를 국가가 보는 것 정도는 괜찮지 않겠어?'. 이는 간단한 문제가 아니고 훨씬 심각한 문제를 야기 할 수 있다. 우리는 정보의 흐름과 정보의 수집이라는 것에 대해 큰 그림을 보아야 한다.

 

 

 

5. 정보의 흐름과 수집의 결과

 

만약에 접속 기록이 저장되기 시작한다면 다음과 같은 일이 일어날 수 있다. 굳이 데이터베이스에 저장하지 않고 로그만 남아도 마찬가지다. (시스템이 로그를 남기는 것은 기본 중의 기본이다.)

 

지금의 네트워크 세상은 단순히 시간 때우기나 놀거리의 세상이 아니다. 인터넷은 그냥 여가용이 아니다. 과거 인터넷이 없던 시절에 오프라인으로 하던 작업들이 우리가 인식하지 못하던 사이에 네트워크의 세상으로 대거 옮겨져 왔다. 즉, 지금의 네트워크 세상은 삶을 살아가는 또 다른 공간이다.

 

예를 들어보자. 내가 어릴 적에는 기차표를 사기 위해서는 반드시 역에 가야 했다. 야구를 보기 위해서는 야구장에서 줄 서서 티켓을 끊어야 했으며 인기 영화를 보기 위해서는 극장 앞에서 한 시간이고 두 시간이고 줄을 서야 했다. 좋아하는 장난감이 입고 되었는지 확인하기 위해서는 귀찮아도 매일 같이 매장을 가서 두 눈으로 확인 해야 했다. 그리고 학교 등록금이나 공과금을 내기 위해서는 은행이나 서무과를 필히 가야 했다.

 

지금은 어떤가? 위의 행위 중 두 발로 가서 하는 것이 있는가? 심지어 지금은 온라인 마켓의 성장으로 오프라인 마트 조차 점점 가지 않고 인터넷으로 장을 본다. 그것도 PC가 아닌 각자 개인의 스마트 폰으로 말이다.

 

자, 그러면 이렇게 생각할 수도 있다.

 

'이런 저런 사이트 접속 한 것 가지고 뭘 할 수 있겠어?'

 

지금 시대는 이런 저런 사이트에 접속 한 당신을 분석 할 수 있다. 아니, 분석당할 수 있다. AI는 우리의 삶에서 패턴을 읽어 내고 당신이 어떤 사람이라는 것을 유추해 낸다.

 

너무 먼 이야기 같은가? 그렇다면 간단히 지금의 온라인 마켓들이 당신을 어떻게 파악 해내는지 그 방법을 간단히 설명해 보고자 한다. 아마 많은 사람들이 온라인 마켓을 사용해서 물건을 구매 할 것이다. 온라인 마켓들은 불법적으로 개인정보를 모으지 않는다. 합법적으로 유추해 낸다. (여러가지 기술이 있지만 이런 식으로 패턴을 익히는 것이 존재한다, 라고 참조만 해주시라.) 

 

1. 어떤 물건을 배송 시켰다 > 배송지 정보를 토대로 당신이 주거하는 곳 혹은 직장 위치, 혹은 직장의 정보가 쌓인다.

2. 면도 거품과 면도기를 시킨 적이 있다 > 당신의 ID 사용자는 남성이라는 것이 집계된다.

3. 매니큐어를 주문한 적이 있다 > 당신의 ID를 사용 하는 구성원 중 여자 구성원이 있다는 것이 유추된다.

4. 미술 전시회 티켓을 몇 번 구매 한 적이 있다 > 당신이 예술을 좋아한다는 것이 집계되었다.

5. 남아용 기저귀를 주기적으로 시킨다 > 이제 결혼한 유부남 혹은 유부녀임이 유추가 되고 당신의 자녀는 남아인지 여아인지 집계된다. 기저귀의 단계에서 자녀가 몇 살인지 유추 가능해졌고 앞으로 나이가 추측 가능해진다. 그리고 당신의 가족 구성원이 현재로는 최소 3명이라는 것이 유추 되었다.

6. 강아지 사료를 샀다 > 가족 구성원 3명에 강아지를 키우는 사람으로 집계가 되었다.

7. 매달 2번씩 생수와 생필품을 구매한다 > 생필품 떨어지는 시기가 집계 되었고 물은 어떤 브랜드를 이용해 마시고 어떤 샴푸, 비누, 칫솔 브랜드를 좋아하는 가족인지 파악이 가능해졌다.

8. 차량용 방향제를 몇 번인가 샀다 > 당신의 가족은 승용차를 소유하고 있으며 구성원 누군가 중에는 운전 가능자가 있다는 것이 파악되었다.

 

이제 시스템은 스스로 당신을 다음과 같이 파악했다.

 

서울 XX에 살며 가족 구성원은 최소 3명 이상이며 자녀는 X세 남아이다. 예술 전시회에 관심이 있으며 반려동물도 최소 한 마리 이상이 있다. 그리고 승용차가 있는 가정이다.

 

이제 해당 마켓에서 당신이 이탈리아 비행기 티켓을 검색 했다고 하면 시스템은 자동으로 다음과 같은 제품을 추천해서 늘어 놓는 것이 가능하다.

 

'3인 이상 머무를 수 있는 숙소, 가족단위 여행 보험 상품, 3인 이상 탈 수 있는 렌트카, 한국의 반려견 호텔 이용권, 남성 여성 혼합 여행용 생필품, 주변 예술 전시장 입장권,'

 

온라인 마켓에서 이 정도로 파악이 되는데 접속하고자 하는 정보는 자칫하다 사찰 수준으로 정보가 쌓일 수 있고 패턴화 될 수 있다.

 

 

정치 성향, 어느 곳에서 생필품을 사는지, 언제 은행 업무를 보는지, 기차를 타려고 하는지, 고속 버스를 타려고 하는지, 어떤 야구팀을 좋아하는지, 어떤 축구팀을 좋아하는지, 어떤 대학교를 다니는지, 직장이 어딘지, 여가 시간에는 유투브를 보는지, 어떤 포털 사이트를 보는지, 어떤 카페에서 활동하는지, 어떤 SNS를 하는지, 음악은 어디에서 듣는지, 그리고 주말에는 어떤 커피숖 IP에서 어떤 스마트 폰을 통해 어디로 접속하려고 하는지 등.

 

이 모든 것이 패턴화 되면 당신의 이름은 모르지만 이름을 제외한 나머지 정체성이 다 읽혀 버리는 수준이 될 수 있다.

 

그러면 또 이렇게 반문 할 수 있다.

 

"저는 이제 PC보다 스마트폰에서 APP을 더 많이 쓰니 괜찮지 않나요? 웹 사이트로 접속을 하는 게 아니잖아요."

 

이에 대해서는 실제 APP을 통해 설명 해보고자 한다. 아래 스크린 샷은 '코레일' APP의 관광 상품 메뉴 화면이다.

 

 

<코레일 APP의 관광 상품 '여행패키지' 메뉴>

 

위의 화면에 보면 스키장 운영이 2월 28일 까지란다. 2월 28일이 지나면 상품이 교체 되어야 하며 이미지도 교체 되어야 한다. 이런 것이 변경 될 때 마다 매번 APP을 업데이트 할 수는 없다. 그렇기에 서버에 저장되어 있는 이미지를 네트워크 통신을 사용하여 Load해 출력한다. 이 때 웹 서버에서 이미지를 불러 올 경우 HTTP나 HTTPS 통신을 사용한다. 이는 어떤 이미지를 보았는지 조차 기록에 남게 되는 것을 의미 한다.

 

이미지 뿐만 아니다. APP 내부에서도 별도의 웹 페이지를 호출해서 보여주는 기능도 있고 범용적으로 많이 사용되기 때문에 스마트폰 APP이라 할지라도 HTTP, HTTPS통신 사용은 빈번히 발생한다.

 

 

6. 해명과 우려

 

2019년 2월 13일 뉴스 기사로 나온 정부 해명을 보았다. (뉴스 : 링크)

 

해당 기사에서 정부의 우려 불식에 대한 기사를 부분적으로 옮겨 보면 다음과 같다.

 

"시민들의 우려는 오해일 뿐이며, 정부는 전혀 개입하지 않고 있다고 설명했다. 정부에 따르면 유해 사이트는 민간 독립기구인 방송통신심의위원회의 심의를 거쳐 지정된 것이며 사이트를 접속 차단한 건 정부가 아닌 KT와 같은 민간 통신 사업자다."

 

일단 정부의 해명을 100% 믿기로 하였다. 그렇다면 문제는 없는가? 아니다, 그렇지 않다. 오히려 우려는 더 커진다. 위의 해명은 문구 그대로 해석하면 결국 다음과 같다.

 

"민간 독립기구와 민간 기업 둘이서 차단했다"

 

우리는 바로 이런 질문을 던져야 한다.

 

"민간 기구와 기업이 정보를 통제 하였는데 정부의 역할은 없어도 되는 것인가? 그렇다면 이 민간 기구는 어디에서 정보통제에 대한 권한을 위임 받았는가? 정부의 정보 독점도 문제가 되는 것이지만 국민들의 정보가 민간 기구에 의해 통제되는 것은 정상인가?"

 

그리고 다른 기사에서는 차단만 할 뿐 정보는 저장되지 않는다고 해명하였다. 하지만 우리는 섹션 5에서 저장이 된다는 가정을 했다. 그 가정의 가능성 이유는 다음과 같다.

 

개인적인 견해지만 민간 통신 업자(SKT, KT, LGU 등)의 경우, 아마 이 시스템을 두 팔 벌려 환영했을 것이다. 사용자의 정보를 데이터화 할 수 있는 절호의 기회라 절대 마다하지 않았을 것이다. 이는 추후 사업 확장에 굉장한 자산이 된다.

 

이미 SNI를 분석하고 차단하는 기능까지 되었다면 데이터 베이스에 축적하거나 로그로 기록을 남기는 것은 어려운 일이 아니다. 반면 통신 사업자가 정말 저장하지 않는지 혹은 로그를 남기지 않는지 감독 할 수 있는 제 3의 기구가 지금 있는가? 만약에 있다 하더라도 시간이 지남에 따라 이 3의 감독 기구가 훼손되어 유착이 발생하지 않으리라는 보장이 있는가?

 

그리고 정권이란 건 영원히 유지되지 않는다. 정권은 계속 바뀐다. 그렇다면 이 시스템이 안착된 후에 정권이 바뀌어 저장 할 수 있도록 시정 된다고 하면 그때 가서 어떻게 하겠는가? 그리고 또 하나, 장기적으로 보았을 때 과거 KT가 그러했듯이 보안 취약점에 대한 공격으로 개인정보 유출이 재차 발생해서 이 저장된 데이터들이 국외에 넘어 갔을 경우, 파급 효과가 상상이나 되는가?

 

 

'나중에 문제가 생기면 제외하는 법안을 마련하고 그 토대를 만들어 놓으면 된다.' 라고 생각 할 수도 있다. 이 문제는 단 하나만 보면 된다.

 

'지금 대한민국에서 Active X가 사라졌는가?'

 

한 번 정착된 친 기업적인 시스템은 없애는 것은 정말 쉽지 않다. 이런 위험 속에서 "저장하지 않습니다"라는 하나의 해명만 가지고 '괜찮네, 이상 없겠어' 하고 넘어 갈 수 있는 문제인지는 심각하게 고민해 보아야 한다.

 

위의 C항목에 보면 QOS 조정, 즉, 특정 서비스 품질을 인터넷 공급자가 할당 가능한 부작용이 있다고 기술되었다. 이는 정치적 악용 가능성을 보여준다. 선거 기간에 특정 정당의 공약 홈페이지 접속 제한이나 품질제어를 할 수도 있고 선거 당일 선거 공보 및 장소 안내 사이트의 품질 저하 쯤은 쉽게 상상 가능한 일이다.

 

우려가 아닌 의문 사항도 있다. '방심위'에서 왜 하필 이 시점에 SNI를 조작하여 차단 하였는지가 궁금하다. 위에서도 나열 했지만 이는 이미 보안 취약점으로 판단되어 이를 막기 위한 논의와 개발이 진행 되었다. 그런데 이 상태에서 굳이 보안 취약점을 파헤쳐 중간 공격자처럼 막았는지 말이다.

 

이는 분명 앞으로 실효성이 없음(이미 차단한 날, 우회 법이 인터넷에서는 공유되기 시작했다)이 자명해질 텐데 왜 굳이 이렇게 하는가 하는 의문이 있다. '방심위'에는 이쪽으로 진지하게 고민하거나 전문가가 없는 것일까? 아니면 누군가가 힘으로 찍어 눌러 진행시킨 것일까?

 

마무리 해서 개발자적인 시선으로 이 문제의 감상을 말하자면 다음과 같다.

 

'원점으로 돌려 다시 생각하고 고민해야 할 만큼 중대한 문제라고 생각한다. 기술적인 부분에서도 취약점이며 향후 예상 가능한 문제도 많다. 표준화된 기술은 보안 취약점 제거를 위해 계속해서 패치 중이다. 이미 보안 취약점으로 보여진 부분이라 향후 운영 경비 측면으로 보아도 문제가 될 여지도 크다.

 

실제 데이터 내용을 보지 않는다 하여 감청이 아니다 하고 넘어 갈 문제도 아니다.

 

처리된 결과로 보자면 고장난 자동차의 범퍼를 제대로 고친 것이 아니라 청테이프로 그냥 대충 붙여 놓은 것을 보는 기분이다. 그 방법적인 측면을 본다면 타이어 펑크가 난 자동차의 타이어 펑크를 때우는 것이 아니라 타이어 펑크를 이유로 폐차 시키는 것처럼 문제 접근 방식과 처리가 완전히 1차원적으로 느껴진다.'

 

순전히 개발자적인 입장에서만 접근했다. 그리고 기술적인 검토에는 정치적, 철학적 견해 등은 최대한 배제하고 국제 표준에 맞추어야 한다고 생각한다. 이유는 해당 기술이 우리가 만들어 내고 우리가 정립한 표준이 아니기 때문이다. 변형을 가해 예외 상황을 만들거나 표준에서 이탈 했을 시 발생하는 '예외 상황'은 예측할 수 없고 감당 할 수 없을 가능성이 크다. 실제로 SW개발 및 출시된 제품에서 발생하는 많은 문제들이 '예측하지 못한 예외 상황' 때문에 생긴다.

 

너무 기술면에서만 본 것이 아닌가 하시는 분들에게 위와 같은 이유 때문이니 양해를 구하며 마무리 한다.