Windows XP 기술 지원 종료 이슈보다 더 크게 다가올 수 있는 인터넷 보안 통신 구멍이 될 가능성이 높은 OpenSSL 버그(HeartBleed 버그)

음.. OpenSSL TLS HeartBeat Read Overrun 버그가 발견되었다고 한다. 이 내용에 대해서는 먼저 [여기]서 내용을 확인했고 정리를 했다. 내용을 간단히 정리하면 TLS HeartBeat Extension(확장모듈)이 입력값에 대한 제한(경계, Boundary)이 없어서 서버로부터 64kb씩 메모리 내용을 계속 읽어올 수 있다는 것이다. 즉, 서버의 메모리 내용을 읽어올 수 있다는 얘기인데 이게 왜 문제가 되는가 하면 서버의 메모리를 계속 읽다 보면 서버에 저장된 암/복호화 키도 같이 노출될 수 있다는데 그 문제가 있다는 얘기다. 

그런데 이게 왜 문제가 될까? 왜 MS의 Windows XP 기술 지원 종료 이슈보다 더 문제가 될 수 있다고 했을까?

국내의 경우에는 인터넷 뱅킹이나 온라인 쇼핑몰을 통해서 결제를 진행하거나 송금을 하는 등의 인터넷 금융 행위를 할 때에는 공인인증서를 이용한 암호화 통신 방식(요즘 아주 핫이슈다. ActiveX 문제와 이리저리 뒤죽박죽 섞여서 말이지 -.-)을 이용하지만 해외의 경우에는 대부분 SSL을 이용한 HTTPS 방식으로 결제나 구매를 진행하곤 한다. HTTPS는 인터넷 통신에서 사용하는 HTTP 프로토콜의 보안 적용 버전이다. 서비스를 하는 서버와 사용자에게 화면을 보여주는 웹브라우저간에 통신을 하는데 HTTP의 경우 통신하는 내용들이 그냥 평문으로 전달된다. 하지만 개인정보나 금융정보 등 민감하고 중요한 정보를 누구나 다 볼 수 있는 평문으로 보낸다는 것은 무척이나 위험한 일이다. 그래서 보안통신을 사용하게 되는데 그때 사용하는 보안통신이 HTTPS다. 국내에는 HTTPS 대신에 공인인증서를 이용한 보안통신을 많이 사용한다(하지만 형식은 HTTPS와 거의 동일하다고 보면 된다).

그런데 OpenSSL에서 나타난 TLS HeartBeat Read Overrun 버그는 이 보안통신에 구멍을 만들 수 있는 가능성이 있다. 내용을 이해하기 위해서는 먼저 HTTPS의 방식에 대해서 살펴봐야 하는데 간단히 설명을 하면 다음과 같다. 앞서 얘기했던 대로 HTTPS는 암호화 통신 방식이다. 암호화를 하기 위해서는 암호화 알고리즘과 암호화에 사용되는 키(Key)가 필요하다. 암호화 알고리즘은 보통 공개키 암호화 알고리즘과 대칭키 암호화 알고리즘으로 나뉘어 존재하며 공개키 알고리즘은 보안성이 매우 높고 안전하지만 시스템의 하드웨어 자원을 많이 사용하고 속도가 느리며 암호화 할 수 있는 용량에 제한이 있다. 대칭키 알고리즘의 경우에는 공개키 알고리즘에 비해서 상대적으로 속도가 빠르다. 공개키 알고리즘의 경우에는 공개키(Public Key)와 개인키(Private Key, 비밀키라고 불리기도 한다)가 존재하는데 이 2가지 키는 쌍으로 존재한다. 즉, 공개키 암호화 알고리즘은 공개키로 암호화를 하고 개인키로 복호화를 하는 방식이다. 공개키 알고리즘의 장점이자 특징은 암호화 할 때 사용하는 키와 복호화 할 때 사용하는 키가 다르다는 점이며 암호화 때 사용하는 공개키는 보통 노출이 되어도 되지만 복호화때 사용하는 개인키는 노출이 되면 안된다는 점이다. 그래서 암호화 통신을 할 때 공개키와 개인키를 생성하고 상대에게 공개키만 던져주고 그 키로 암호화해서 보내라고 하면 자신은 갖고 있는 개인키로 복호화해서 사용하면 된다. 그래서 보안성이 높다고 얘기하는 것이다. 노출된 공개키만 갖고는 내용을 복호화 할 수 없기 때문에 말이다. 하지만 앞서 얘기했던 것처럼 속도가 느리고 시스템 자원을 많이 잡아먹기 때문에 속도를 우선시하는 통신에서는 사용하기가 부담스러운 것이 사실이다. 그래서 보통은 공개키 알고리즘을 이용하여 대칭키 알고리즘에서 사용할 키를 서로 교환하고 그 다음부터는 대칭키 알고리즘을 이용하여 내용을 암호화해서 통신을 한다. 간단히 얘기하자면 이런 방식으로 HTTPS 통신은 이뤄진다.

그런데 왜 문제가 될까? 보통은 접속하는 사용자마다 처음 접속할 때 공개키와 개인키를 만들어서 통신을 시작하는 것이 정석이다. 그런데 동시에 수천명에서 수만명, 심하면 수백만명이 붙는 웹서비스의 경우에는 매번 접속할 때마다(보통 인터넷 연결 세션을 맺는다고 한다) 공개키와 개인키를 만들어서 통신하는 것이 어렵다. 그래서 보통은 서비스 서버는 공통으로 사용할 공개키와 개인키를 만들어두고 사용자가 접속할 때마다 저장되어있는 공개키를 전달해서 키 교환을 한다(물론 대칭키 알고리즘에서 사용할 키는 사용자가 접속할 때마다 바꾼다). 물론 한번 만들고 계속 사용하는 것은 아니다. 주기적으로 공개키와 개인키를 바꾸게 되는데 하루 단위, 혹은 반나절 정도의 주기를 갖고 바꾸는 것이 일반적이다(이 설정은 관리자에 의해서, 혹은 내부 서비스 정책에 의해서 결정이 될 것이다). 그렇다고 하더라도 바꾸는 주기 안에서는 계속 공개키와 개인키는 고정인 상태다. 그리고 공개키에 대한 개인키는 어떤 사용자가 접속하더라도 동일하게 된다.

그런데 위에서 얘기했듯 저 버그를 이용하여 서버의 메모리를 야금야금 읽어들이다보면 서버의 메모리에 저장되어 있는 개인키가 노출이 될 수 있다는 얘기다. 개인키가 노출된다는 얘기는 초기에 사용자가 연결을 맺을 때 교환하는 암호화 키(대칭키에서 사용할)를 제 3자(해커일 가능성이 높다)가 가로채서 사용할 수 있다는 얘기다. 적어도 공개키, 개인키가 다시 바뀌는 주기가 되기 전에는 탈취된 개인키를 이용하여 암호화 키를 가져올 수 있을테니까 말이다. 그렇다면 해커는 대칭키에서 사용할 키를 획득하게 되고 아무리 보안통신을 한다고 해도 해커 입장에서는 그냥 평문으로 왔다갔다 하는 일반통신과 마찬가지로 내용을 볼 수 있다는 얘기다. 그런데 그 서비스가 인터넷 뱅킹이나 온라인 쇼핑몰이 될 경우에는 개인정보 및 금융정보와 같은 민감정보들이 노출될 수 있으며 서비스 접속 암호도 그냥 노출이 될 수가 있다. 얼마든지 악용할 소지가 높다는 얘기다. 이른바 보안통신에 구멍(Hole)이 생긴다는 얘기다.

물론 OpenSSL은 이에 대한 패치를 공개했다. OpenSSL을 이용해서 HTTPS를 구현한 서비스는 해당 패치를 적용하면 된다. 그런데 패치를 적용한다는 얘기는 서비스를 중지해야 한다는 얘기고 패치를 적용하는 시간이 필요하다는 얘기다. 서비스 다운타임이 생긴다는 얘기며 이는 사용자에게 불편함을 끼치게 된다. 더욱이 하나의 시스템에서 HTTPS로 서로 연결되어서 통신하는 기간망 시스템의 경우에는 연결되어 있는 모든 서비스에 대해서 패치가 진행되어야 하며 또 패치로 인한 사이드이펙트(파생효과 정도?)에 대해서는 아직까지 검증이 안된 상태인지라 어떤 다른 위험요소가 있을지 모르는 상황이다. 그리고 연결되어 있는 시스템이 단일 시스템이고 개수가 적으면 그나마 괜찮겠지만 요즘은 내부 시스템도 HTTPS를 이용하여 통신하는 상황인지라 시스템이 크면 클수록 패치에 대한 부담은 더욱 커진다. 이러니 문제라는 얘기다.

MS의 Windows XP 기술 지원 종료도 보안에 대한 문제가 생기겠지만 어느정도 시간이 걸릴 일이다. 하지만 OpenSSL의 TLS HeartBeat Read Overrun 문제의 경우에는 당장에 문제가 일어날 수 있는 일인지라 체감되는 문제는 이쪽이 더 클 수가 있다. 내 개인정보와 금융정보, 접속정보가 해커에 의해 탈취될 수 있다는 얘기며 그것은 곧 내 금전적인 피해로 돌아올 수 있기 때문이다. 보안하는 입장에서 보면 아주 중요하며 무서운 일이라고 생각할 수 있다.

그런데 흥미로운 점은 국내에는 과연 이 이슈가 얼마나 크게 부각될까 하는 점이다. 해외에서는 이 문제가 꽤 심각하게 받아들여질 가능성이 높은데 국내의 경우에는 앞서서 얘기했던 것처럼 SSL을 이용한 HTTPS를 사용하기 보다는 공인인증서를 이용한 보안통신을 이용하는 경우가 더 많다. 물론 앞서 얘기했듯 공인인증서를 이용한 보안통신도 내부의 구성은 HTTPS와 비슷하다. 사용하는 포트 역시 동일하게 443번 포트를 이용한다. 통신하는 방식도 위에서 설명한 HTTPS와 비슷하다고 보면 된다. 국내 공인인증서 핸들링 모듈은 대부분 OpenSSL의 라이브러를 이용해서 만들곤 한다. 그렇다면 어떻게 보면 내부적으로 OpenSSL이 갖고 있는 버그를 잠재적으로 갖고 있다고 해도 아주 틀린 말은 아닐 것이다. 지금 문제가 되는 TLS HeartBeat Read Overrun에 대한 문제점을 공인인증서를 이용한 보안통신도 갖고 있을지가 관건이 된다. 만약 이 문제가 없다면 지금 열심히 공격 받고 있는 공인인증서 옹호 진영에서는 반격의 카드로 쏠쏠히 사용할 수 있을 듯 싶다. 오픈넷 등에서 주장하고 있는 SSL + OTP 방식은 이 버그에 대해서 자유롭지 못하기 때문이다. 하기사 공인인증서의 문제점은 ActiveX 방식과 내부 시스템적인 문제가 더 크기는 하지만 말이지(-.-).

ps) OpenSSL의 이 버그를 Heartbleed 버그라고 부른다고 한다. 그만큼 치명적인 버그라는 얘기가 아닐까 싶다. 이 버그에 대해서 더 자세히 알고 싶다면 [여기]를 방문해보길 바란다.

이 글은 페이스북 페이지의 노트에 적었던 것을 에버노트에 옮겨서 내용을 보충하고 편집해서 저장한 후 블로그에서 에버노트를 이용한 블로깅 방식으로 읽어와서 작업한 것이다. 그런데 에버노트에서 읽어올 때 쓸데없는 태그들이 붙어서 그거 따로 작업하는 것이 더 귀찮은 듯 싶다. 하지만 태블릿PC 등을 이용하여 블로깅을 할 때는 꽤나 요긴하게 사용할 수 있을 듯 싶다.