이번엔 기술적으로 설명을 해 보고자 합니다(기술 중심의 얘기라서 일반인들에게는 어려울 수 있음). 이번 기사의 핵심 요지는 "와이파이 기반에서 SSL을 무력화시킨다" 정도가 되겠습니다. 여기에는 2가지의 관점에서 나누어 볼 필요가 있습니다.

첫째, Victim의 Packet을 어떻게 Attacker가 획득할 수 있느냐입니다.

일명 MITM(Man In The Middle)Attack이라는 용어를 많이 사용하죠. 방법들은 여러가지가 있습니다.

1. 스위치나 라우터, 혹은 그 상위단 네트워크 장비에서 Mirroring or Tapping을 통하여 Packet을 받는다.

2. ARP spoofing(ARP route poisoning)을 이용해서 같은 네트워크 대역의 다른 호스트(Victim)의 IP Packet을 반는다.

3. Victim으로 하여금 Rouge AP(Rogue hosted network)에 접속하게 하여 Victim의 Packet을 받는다.

4. 원격의 경우라면 해당 네트워크 대역의 라우터(혹은 스위치)의 권한을 얻어낸 다음 (GRE)Tunneling 을 할 수 있도록 routing table을 변경하여, 해당 네트워크 대역의 모든 External IP Packet을 Attacker에게 오게 한다.

이중에 1번은 passive 방식(packet을 볼 수만 있음)이라 하고, 2~4번은 active 방식(packet을 보기만 하는 것이 아니라 routing 변경, drop, data change까지 가능)이라고 합니다.

지금까지는 2번이 중요한 이슈가 되어 왔고(Ethernet 환경이 보편화되어 있기 때문에 아직까지도 Attack이 가능한 상황임), WiFi가 보급이 되면서 3번의 취약점이 부각되어 지고 있는 상황입니다. 4번은 간이 큰 해커가 아니라고 하면 엄두를 내지 못하는 취약점입니다(dynamips를 이용해서 Local 상에만 구현을 해 보았지, 실제 Field에서 4번 Attack을 감행한다면 들통 나기 쉽습니다).

둘째, 잡힌 Victim의 Packet을 가지고 무엇을 할 수 있느냐입니다.

예전에는 그냥 Monitoring을 통해서 Plain Text에서 중요한 정보(예: ID/Password)를 얻어 내는 것이 고작이었습니다. 하지만 암호화 프로토콜이 도입이 되면서 이러한 Attack은 점점 무용지물이 되어 지고 있죠. 그에 따라 많은 곳에서 어떻게 하면 암호화 프로토콜을 무력화할 수 있을까 하는 고민들이 시작되었습니다.

암호화 프로토콜은 여러가지가 존재하지만, 그중에 가장 많이 쓰이는 것이 바로 SSL입니다. 기법과 소스가 공개되어 있으면서도 가장 강력한 암호화가 가능하기 때문입니다(여기에서 얘기하는 "강력함"이라 함은 SSL 통신의 관리를 잘 해야 한다는 것을 가정합니다).

비단 SSL만 있는 것은 아닙니다. SSH도 있고, TCP뿐만 아니라 다양한 Transport Layer에서 돌아 갈 수 있도록 하는 TLS(SSL의 상위 버전)라는 것도 있고, VoIP 등에서 상대적으로 가벼운 암호화 프로토콜(AES, ARIA)등도 있습니다. 제가 얘기하는 것은 전부 표준 프로토콜만을 말씀드린 것이며, 게임이나 다른 분야에서는 자체적인 암호화 프로토콜이 사용되어 지기도 합니다.

이번 기사에서 유독 SSL이 강조되어 지는 것은 SSL 자체가 가장 유명하고 많이 쓰이기 때문입니다.

자, 그럼 대응 방안은 어떻게 해야 할까요?

A. WiFi의 보안을 강화한다.

이건 아닙니다. WiFi의 태생 자체가 무선 단말기(스마트폰, 노트북 등)의 인터넷 접속을 쉽고 용이하게 하기 위해 나온 기술입니다. ISP 입장에서는 상업적인 목적을 위해 보안보다는 접속의 용이성을 높이기 위해 암호를 걸지 않는 경우가 있죠. 제가 보기에는 이번 기사를 통해서 이러한 서비스들로 하여금 무조건 암호를 걸도록 정부의 방침이 바뀌는 것이 아닐까 하는 걱정이 들기도 합니다. 결국 WiFi 본연의 장점을 이런 보도로 인해서 활용 정도가 위축되는 결과는 없었으면 합니다.

B. 암호화 프로토콜에 대한 취약점을 보완한다.

네, 제가 보기에 이 방법이 가장 무난할 것 같습니다. 지금까지 공개되어 져 온 SSL 기반의 취약점을 나열해 보자면 다음과 같습니다(개인의 상용 SSL VPN의 사용도 권장합니다).

1. MD5 hash value collision의 가능성을 이용한 Rogue CA 알아 내기 : 손도장 알고리즘이 SHA1으로 바뀌어 가고 있습니다.

2. SSL Sniff : 기사에서 얘기되어 진 기법입니다. 엄밀히 말하면 SSL에 사용되는 Key 탈취가 아니라 , SSL proxy가 중간에 위치하여 전혀 다른 별도의 SSL Session을 맺는 기법입니다. 이는 Client Authentication / Server Authentication 방식을 더욱 엄격히 해서 점차 해결할 수가 있습니다. 예를 들자면, HTTP over SSL의 경우 웹브라우저에서 인증서 경고창을 더욱 무시무시하게 보여 주도록 웹브라우저가 업그레이드되어야 할 것입니다.

3. SSL Strip : 몇년전 BlackHat에서 본격적으로 이슈화가 되고 나서 요즘 많이 거론이 되어 지고 있죠. 이를 해결할 수 있는 방안도 많이 있습니다. Ajax를 통하여 로그인 과정을 조금 꼬아 놓는 방법, STS(Strict Transport Security)를 도입하는 방법 등 많은 경우의 수가 존재합니다. 이를 위해서 많은 웹사이트 관리자들에게 STS의 기능 및 그 구현 과정을 지속적으로 홍보를 해야 할 것입니다.

4. 무분별한 인증서 발급 관리 : 얼마전에 Rogue CA에 몰래 들어가 자신이 원하는 common name으로 인증서가 무단 발급된 사건이 있었죠. 이 또한 관리 차원의 사고였습니다.

이번 기사가 언론을 통해서 그 취약점의 경각심을 부각한 것은 바람직하나, 사실 본 취약점에 대해서 일반인들이 할 수 있는 것은 별로 없습니다. 괜한 국민적 불안감만 조성할 뿐이죠. 이번 기사를 제공한 교수는 "취약점에 대한 경각심을 부각시켜서 보안의 발전을 기해야 한다"라는 취지를 가지시고 계시는 것 같은데, 글쎄요, 별 효용 없는(일반인들에게 알려서 보안의 향상이 별로 안되는) 결과로 결론날 것 같고, 마치 보안에 입문하여 취약점을 처음 알아낸 사람의 순수한 해커의 발상(왜 내 얘기를 알아 주지 않는거야? 이게 얼마나 위험한 건데?) 정도로 밖에 보이지가 않습니다.

내가 언론에 A라고 얘기를 하면 언론은 B라고 얘기를 하고 일반인은 C라고 알아 듣습니다. 이게 엄연한 보안 방면을 대하는 언론의 성격입니다. 제대로 된 정보의 전달을 위해서는 기자를 통해서 취재 형식으로 일을 진행하기 보다는, 칼럼을 통해서 직접 기고를 했었으면 어땠을까 하는 생각을 해 봅니다.