사업체, 공공기관은 작은 규모라도 자사를 드러내고 소개할 수 있는 웹사이트를 모두 보유하고 있다. 홈페이지를 통해 내 사업체의 정보를 미리 안내하고 유령회사가 아니라는 신뢰를 줄 수 있기 때문일 것이다.

지금 인터넷 창을 열고 생각나는 웹사이트 아무 곳이나 접속해보자. 작은 규모의 웹사이트일 수록 좋다. 혹시 주소창 왼쪽에 자물쇠가 표시되어 있는가? 아니면 다른 표시가 나타나 있는가? 사실 새로 창을 열지 않아도 된다. 지금 보고 있는 이 블로그 주소창을 보자. 자물쇠 아이콘이 표시되어 있다.

​

자물쇠가 없는 웹사이트에서는 자물쇠 대신 ‘주의요함’이 표시되어 있을 것이다. 클릭하면 ‘이 사이트에서 입력하는 비밀번호, 신용카드 번호 등이 공격자에 의해 도용될 수 있다’는 경고 메시지가 노출된다. 들어갔다가 사단이 날 것 같은 느낌이 든다.

​

​

주소창의 자물쇠 표시는 ‘이 웹사이트는 공격자로부터 안전하게 보호되고 있다’는 의미이다. 해당 표시가 뜨는 곳은 SSL/TLS 로 암호처리된 웹사이트이다. 암호화로 한 번 덮어씌운, 보안이 되는 사이트이기 때문에 누가 내 정보를 중간에 탈취할 위험이 없어 안심된다. 온전히 클라이언트 PC를 사용하는 나와 웹서버를 사용하는 웹사이트 둘 만이 가진 개인키와 공개키로 내용을 암호화하고 복호화하면서 정보를 읽어 들이기 때문에 제3자는 내가 무엇을 하는지 알 수 없다.

​

​

* SSL/TLS의 위치 : 이렇게 싹 암호로 덮어씌워서 나간다.

​

​

SSL/TLS를 제공하는 웹서비스가 최근 몇 년 사이에 급증하긴 했지만 SSL/TLS는 이미 90년대 초반에 만들어진 기술이다. 넷스케이프사에서 통신 보안을 위해 내부적으로 개발한 규약인데 SSL(Secure Sockets Layer: 보안 소켓 레이어)이라고 불렸다. 1.0은 보안결함이 심각했기에 외부에 공개되지는 않았다. 95년 2월에 공개된 2.0부터 공개적으로 사용되기 시작했다.

​

SSL 통신규약은 3.0 버전이 마지막이며, 1999년 TLS(Transport Layer Security) 1.0이 릴리즈 되면서 정식 명식은 TLS로 명명되었다. SSL이 아니라 TLS로 불리는 것이 더 정확한 표현이나 SSL이라는 용어가 더 익숙하여 SSL/TLS로 혼용하여 사용되고 있다.

​

현재 나와있는 프로토콜 중 2018년에 릴리즈된 ‘TLS 1.3’이 가장 최신 버전이다.

​

​

만남이 있다면 사전에 통성명을 주고받고 시작하는 것이 인지상정이다. 다짜고짜 용건만 냅다 던지면 대화가 묵살될 수 있다. SSL/TLS에서도 핸드셰이크가 수반되어야 한다. 암호화기반이기 때문에 서로 암호키를 교환하여 전송에 필요한 절차를 만들어야 하기 때문이다.

​

SSL/TLS 핸드셰이크는 크게 4단계로 나눌 수 있다.

​

1. 보안기능설정: 프로토콜 버전, 세션ID, 암호조합, 압축방법 등을 공유한다. 상대가 어떤 언어를 어떻게 사용하는지 (한국어/영어/독일어 중 무슨 언어를 쓰는지 서로 대화가 가능한 언어가 무엇인지) 확인하는 단계이다.

​

​

2. 서버인증과 키 교환: ​서버가 필요하다고 생각될 경우 인증서/키교환을 보낸 후 클라이언트 PC에게 인증서를 요청한다. 위장한 제3자가 난입하는 경우를 막기 위해서다. 상황에 따라 수행하지 않는 경우도 있다.

​

​

3. 클라이언트인증과 키 교환: 서버가 요청한 클라이언트 PC 사용자의 인증서를 전달하는 단계다. 이때 인증서를 보내 위변조 등 부정행위가 없음을 확인시켜준다.

​

​

4. 종료: 서로 암호조합을 교환한다. 내가 보내는 패킷을 해독할 수 있도록 공개키를 보낸다. 세팅이 끝났다. 지금부터 암호화된 통신이 시작된다.

​

악수하며 정보를 교환하고 서로를 파악하면 그 때부터 앉아서 편하게 대화를 진행할 수 있게 된다. 사용언어도 합의 하에 설정했겠다, 제3자는 그들이 무슨 말을 해도 알아들을 수 없다.

​

​

​

글로벌 기업들은 2015년 전후로 SSL/TLS 기반 웹서비스를 제공했다.

​

구글의 경우 지메일, 구글닥스 등 정보의 보안이 필요한 서비스에 SSL/TLS를 먼저 적용하기도 했다. (현재는 모든 서비스를 SSL/TLS에서 제공한다.) 국내는 2016년 이후부터 전환이 시작되었다. 조금 늦은 편이다. 본래 국내에서는 은행 등 일부 기관에서만 한정적으로 사용했던 것인데 해킹기법이 지능화됨에 따라 이를 상쇄하기 위해 도입을 시작한 것이다. 국내 웹서비스 중에서는 네이버, 다음카카오가 암호화웹 기반으로 맨 처음 전환했다. 이 이후로 점차 공공기관, 국내 클라우드 서비스, 쇼핑몰 등도 암호화웹 규약을 채택하기 시작했고 현재는 90%이상의 웹사이트는 대부분 암호화웹을 사용하고 있다.

​

보안솔루션 개발사들은 100% SSL/TLS기반 웹사이트를 운영하고 있다. 만약 HTTP 기반 웹사이트를 보유하면서 정보보호를 외치고 있다면 몸이 좋지 않은 헬스트레이너가 회원들에게 “체중감량 하시려면 절식하시고 운동 열심히 하셔야 합니다!”라고 말하는 것과 비슷한 맥락이 될 것이다.

​

​

HTTP웹에 SSL/TLS이 적용되면 아래 요소들이 암호화되어 안전하게 오고 갈 수 있게 된다.

​

– URL (내가 어 느 페이지에 접속했는지 숨겨줌)

– 문서내용 (내가 무슨 내용을 보고 있는지 안알랴줌)

– 브라우저 양식 내용 (취약점이 있는 브라우저를 이용하더라도 브라우저를 모르니 해킹이 어려워짐)

– 쿠키 (티끌을 모아 유추하려 해도 알 수가 없게 됨)

– HTTP 헤더내용 (내가 발송한 정보를 어디사는 누구에게 보내더라도 행선지는 물론이고 내가 무엇을 보냈는지도 알 수 없음)

​

복호화 키가 없으면 내용을 볼 수가 없다. 패킷을 탈취하더라도 난수로 구성된 패킷일 뿐이다. 그 덕분에 우리는 해킹 불안에서 벗어나 안전한 웹환경을 보장받고 즐겁게 웹서핑을 할 수 있게 되었다.

​

SSL/TLS는 우리에게 아래와 같은 안전성을 보장한다.

​

1. HTTP 보다 뛰어난 보안성을 제공한다.

2. 패킷이 암호화되어 오고 가기 때문에 누군가가 패킷을 가로채도 해커는 내용을 알아낼 수 없다.

3. 핸드셰이크 절차를 통해 서로를 인증하고 인증확인이 되어야 통신이 구현되기 때문에 나를 사칭하는 일도 발생하지 않는다.

안전성을 보장받은 기술임은 확실하다. 하지만 완벽한 보안은 아직까지 없는 것 같다.

이토록 안전성을 보장받은 기술임에도 불구, 허점이 있기 마련이다.

어떤 사람들은 강점을 역으로 이용해서 공격을 수행한다.

​

​

SSL/TLS의 보안성을 악용해 다음과 같은 공격을 수행하기도 한다.

​

1. 정보유출 경로로 악용

​

SSL 개발 목적은 통신과정의 ‘도청, 패킷탈취, 위변조를 막기 위해서’ 였다. 기존 통신규약에 암호화 한번 덧 입히면 쉽게 해킹할 수 없을 거라는 생각으로 개발했었다. 하지만 이로 인하여 되려 클라이언트PC와 서버 사이에서 어떤 정보가 오고 가는지 알 수 없게 만들어버렸다. 한번 암호화되어 덧입혀져 나가기 때문에 내가 주민번호를 1만건 유출해도, 종합부동산세 납부대상자 명단을 모두 끌고 와도 기존 보안 솔루션으로는 파악할 수 없다. 복호화키는 클라이언트PC와 서버 단 둘만 알고 있기 때문에 제3자인 보안 솔루션은 무엇이 언제, 누구에게, 몇 건이 밖으로 유출되었는지 알 수 없다.

​

해커들 못 보게 하려고 만든 기술이 기존 보안솔루션에게도 적용된 것이다.

과거에는 인증이 필요한 페이지에서만 부분적으로 사용됐었지만 현재는 클라우드, 메일, 메신저 등도 대부분 SSL/TLS를 사용하고 있다. 정보유출 가능성이 있는 통로에 SSL/TLS가 덧입혀진 것이다. 해커의 탈취행위는 막을 수 있게 되었지만 내부자의 유출행위는 막을 수 없게 되었다.

SSL/TLS 기반 웹트래픽은 꾸준히 증가하고 있다. 줄어들지 않을 것이다.

​

2. 악성코드 유입 통로로 악용

​

악성코드/랜섬웨어는 PDF, 워드, 한글파일로 위장한 실행파일을 클릭함으로써 감염된다. 이 외에도 의심스러운 URL을 클릭해서 감염되기도 한다. 해당 링크에 접속하는 순간, 드라이브바이다운로드(Drive By Download) 공격으로 인해 악성코드/랜섬웨어 파일을 자동으로 다운로드 받게 되는데 이 파일은 당신의 PC와 사내 네트워크를 아작낼 수도 있다. 정보유출은 물론이고 데이터가 위변조되거나 디도스 공격의 장기말로 이용될 수도 있다.

​

기존에는 유해사이트 차단 솔루션이 URL을 확인하고 접속 전에 해당 URL을 통제/차단해낼 수 있었지만, 위에서 이야기한 것과 같은 맥락으로 SSL/TLS 암호화웹을 쓰면 URL도 암호화된다. 그래서 내가 어떤 페이지에 접속했는지 보안 솔루션이 파악할 수가 없게 된다.

이미 20만대 이상의 C&C서버들은 SSL/TLS를 활용하고 있다. 기업을 타깃으로 한 네트워크 공격의 50% 이상은 SSL/TLS을 이용해 발생했다. 크립토락커, 스팸봇, VMZeus 등 유명 랜섬웨어/봇넷/루트킷등은 SSL/TLS를 사용해 이미 악성행위를 벌이고 있다.

​

2008년 인도 뭄바이에서 발생한 테러사건을 배경으로 한 영화 <호텔 뭄바이>에서 테러리스트들은 혼란스러운 틈을 타 겁에 질린 행인들 사이에 섞여 호텔문을 두드리고, 호텔 문이 열리는 순간 호텔 잠입에 성공한다. 악성코드 감염도 이와 비슷하다. 평범한 패킷인 척 숨어들어오면 알 수가 없다.

​

DLP솔루션과 악성코드 차단 솔루션에 국한된 내용이 아니다.

보안을 수행하고 있는 대부분의 솔루션으로는 대응이 쉽지 않다.

최근에는 SSL/TLS 가시성확보 장비를 도입하여 패킷을 확인하고 통제여부를 결정하고 있으나 가시성확보 장비가 충분히 확보되지 않은 상태라면 매초 발생하는 트래픽을 감당하지 못해 성능장애가 발생할 수 있다.

결론은 장비가 충분히 증설되어야 한다는 뜻인데 비용부담이 만만치 않다. 비용부담으로 인해 어떤 회사는 업무효율성과 보안성 두 가지 선택지에서 고민하다가 업무효율을 더 중시하기로 결정하게 된다. 당장 감당이 되지 않으니 SSL/TLS 트래픽이 발생하면 일단 통과시키기로 결정하게 된다.

​

소만사의 SSL/TLS 가시성 확보 및 복호화 솔루션 ‘T-Proxy’는 가시성을 확보하여 DLP, 유해사이트차단, IPS, IDS, APT 솔루션 등과 연동하여 내외부에서 발생하는 보안위협을 해소해준다. 이를 통해 위협을 인지하고 분석, 차단, 로깅하여 보안위협에 대응할 수 있다. 인라인 및 미러링 장비 연동이 가능하므로 원하는 보안제품에서 SSL/TLS 가시성을 확보, 보안할 수 있다.

​

소만사 ‘T-Proxy’는 ICAP연동 영향을 받지 않는 솔루션이다. 외산대비 30%이상 향상된 패킷처리 성능을 보유하고 있다. 이는 보안인프라 전반에 걸쳐 효율성을 증대화 시킨다.

​

소만사는 개인정보보호법, 신용정보법, 전자금융거래법 등 정보보호관련 컴플라이언스를 준수하는 솔루션을 개발하는 기업이다. ‘T-Proxy’ 역시 기술적 보호조치 100% 이행을 목적으로 개발되었다. ‘T-Proxy’를 도입한 기업과 기관들은 이를 통해 집단소송/법적처벌 가능성을 최소화할 수 있다. ‘T-Proxy’는 현재 100곳 이상에 적용되어 있다. 이 곳에서 ‘T-Proxy’는 각 기업/기관의 개인정보보호와 안전한 웹환경을 보장하고 있다.

​

​

SSL/TLS는 사람들에게 안전한 웹환경을 보장해주었다. 하지만 다른 시각에서 보면 보안전문가들에게 또 다른 과제를 안겨주기도 했다. 위장(camouflage)에 관한 보안허점을 수면 위로 올리기도 했으니 말이다.

​

패킷탈취 없이 안전하게 전송하려고 암호화한 것을 다시 복호화해서 열어보고 확인한 후에 보낸다니 일을 번거롭게 두 번하는 것처럼 보일 수도 있다. 보안솔루션은 업무효율성을 방해하지 않기 위해 최선의 노력을 하고는 있으나 아직까지는 상충하고 있다. 비효율적으로 보일 수 있다.

​

하지만 모든 웹서비스가 SSL/TLS로 바뀌었고 바뀌고 있는 상황에서, 기존 솔루션으로는 전혀 차단할 수 없는 상황에서, 위와 같은 ‘번거로운 일’을 하지 못해 개인정보가 유출되고 언론에 공개되고 집단소송과 형사처벌에 직면하게 된다면 비효율적인 행동은 ‘암호화 패킷을 복호화하지 않고 그냥 흘려보내고 들여보낸 행위’가 될 것이다.

​

보안위협에서 나와 우리회사와 국가의 네트워크 인프라를 보호하기 위해서는

SSL/TLS 가시성 확보 및 복호화는 선택이 아닌 필수이다.

​

​

참고:

​

소만사 웹키퍼 https://www.somansa.com/solution/safe-browsing/ssl-tls-solution-webkeeper/

​

소만사 메일아이 https://www.somansa.com/solution/outflow-control/ssl-tls-network-dlp-solution/

​

영문 위키피디아 https://en.wikipedia.org/wiki/Transport_Layer_Security

​

국문 위키백과 https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88

​

도서 네트워크 보안에센셜, 윌리엄 스탈링스 저

​

도서 정보보안 가이드북, 이상진 저

​

​