[마소 394호] 알아두면 쓸데없는 신비한 TLS 1.3

입력 2018.10.25 10:30

소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. TLS 1.3, 오픈스택, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

TLS 1.3이 2018년 8월 10일에 RFC 8446(tools.ietf.org/html/rfc8446)이란 이름으로 등장했다. 우리가 이용하는 수많은 서비스의 보안을 담당하는 TLS(Transport Layer Security Protocol)의 새로운 버전에 대해서 알아보자.

우리가 개발하는 서비스 중에서 인터넷에 연결이 필요 없는 서비스는 거의 없다고 봐야 한다. 이런 서비스는 우리가 만든 앱 혹은 웹을 통해서 데이터를 받아 서버에 저장한다. 오프라인 모드로 즐기는 게임마저도 장애 로그 또는 통계 데이터를 인터넷 연결로 받는 사례가 늘고있다. 다만 이 데이터에는 굉장히 민감한 정보가 포함돼 있다는 것이 요점이다. 카드 번호나 주소는 기본이고, 심지어 우리 집 거실에 있는 공유기의 맥 주소까지도 데이터화 돼 전송된다. 그래서 중간에 데이터가 조작되거나 변조되지 않도록 암호화해 데이터를 보내야 한다.

우리는 이런 민감한 정보를 보낼 때 HTTP보다는 HTTPS(‘Secure’를 의미하는 ‘S’)를 사용하라고 배웠다. HTTPS의 안전성은 TLS라는 프로토콜을 통해 보장된다. TLS는 과거 우리가 SSL이라 부르던 프로토콜에서 시작했다. SSL은 1990년대에 브라우저를 개발했던 넷스케이프(Netscape)에서 보안성이 높은 HTTP 통신을 지원하기 위해 만든 프로토콜이다. 넷스케이프가 SSL을 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)에게 양도하면서 바뀐 이름이 TLS 1.0이다. (TLS 1.0은 단순히 이름만 바뀐 것이기 때문에, SSL 3.0과 같은 프로토콜로 본다)

TLS의 전신인 SSL은 1990년대에 등장한 프로토콜이다. 초기 SSL을 디자인할 당시에는 설계상 허점으로 인해 구현체가 실제 구현 결과와 다른 부분(Heuristic)이 있었다. 또한 보안 프로토콜에서 발생하는 문제가 어떤 방식인지 자료나 학습이 부족했다. 허점이 발견된(Heuristric) 부분이나 문제가 되는 부분은 구현체가 만들어지는 과정에서 많이 고쳐지면서 현재의 TLS 1.2가 탄생했다. 하지만 TLS의 설계적인 허점과는 별개로 TLS와 관련된 직간접적인 보안 이슈가 많이 발생했다.

하트블리드. / 마이크로소프트웨어 394호 발췌
가장 먼저 떠오르는 보안 관련 이슈로 하트블리드(Heartbleed, CVE-2014-0160)가 있다. 하트블리드는 많은 언어, 프레임워크, 서버 프로그램에서 TLS연결을 위해 사용하던 오픈소스 라이브러리인 OpenSSL에서 발생한 버퍼 오버플로우(BOF) 버그다. 엄밀하게는 TLS 구현체 자체에서 해결해야 하는 문제점이므로 TLS와는 상관없다고 할 수 있다. (OpenSSL은 ‘BERserk’, ‘goto fail;’ 등 구현체 수준의 다른 문제도 제기됐다.)

TLS 1.3 표준은 IETF의 RFC 8446에서 맡고 있다. 더 빠르고 안전한 인터넷을 만들기 위해 4년간 논의하고 28회의 초안을 거쳤다. 문제점이 제기된 암호화 방식을 버리고, 핸드셰이크 과정을 최소화해 암호화 통신하는 방법을 추가했다.

TLS 1.3 특징으로는 ▲핸드셰이크에 ‘0-RTT’ 모드 추가 ▲정적인 RSA와 디피-헬먼 암호화 스위트(Diffie-Hellman Cipher Suite) 제거 ▲핸드셰이크를 가능한 최대한 암호화 ▲타원 곡선 알고리즘을 기본으로 지원 ▲키 교환과 암호화 방식을 암호화 스위트(Cipher Suite)방식이 아니라, 개별적으로 결정 등이 있다.

TLS같이 인터넷 연결 과정에서 중추가 되는 프로토콜은 많은 장비가 관여하고 있어서 함부로 버전을 올리기에는 부담이 클 수 있다. TLS 1.3에서는 이런 부분을 고려해 완벽하게 하위 호환될 수 있도록 제작했다. TLS 1.3은 드래프트(Draft) 과정을 거치면서 많은 테스트 과정을 거쳤고, 점유율이 가장 높은 크롬 브라우저가 이를 지원하고 있다. CDN/DNS 제공 업체인 클라우드플레어(Cloudflare) 외 페이스북(Facebook)과 인스타그램(Instagram)도 TLS 1.3을 지원하고 있다.

TLS 1.3은 이전 버전에서 가지고 있던 많은 레거시(Legacy)를 없애면서 더 안전하고 빠른 프로토콜이 됐다. TLS 1.2에서 노출된 취약점과 위협요소가 언제 우리를 위협할지 알 수 없다. TLS 1.3을 조금이라도 빨리 적용해서, 발생할 수 있는 보안사고를 미리 예방하는 게 좋지 않을까?

강성일 필자의 ‘알아두면 쓸데없는 신비한 TLS 1.3’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


키워드

관련기사를 더 보시려면,

[마소 394호] RxJava로 생각하기 오세용 기자
[마소 394호] 플라스크 효과적으로 사용하기 오세용 기자
[마소 394호] 스토리체인이 사이드체인을 선택하기까지 오세용 기자
[마소 394호] 모바일 앱 테스트 자동화용 디바이스팜 구축 오세용 기자
[마소 394호] 되돌아 보는 1만 개의 클라이언트 문제 오세용 기자
[마소 394호] 클릭만으로 도커 개발 환경을 완성시켜주는 애저 PaaS 오세용 기자
[마소 394호] DDD와 MSA로 쇼핑몰 구축하기 오세용 기자
[마소 394호] 이스티오 서비스 메시를 이용한 MSA 구축 오세용 기자
[마소 394호] 제대로 구성하는 마이크로서비스 아키텍처 오세용 기자
[마소 394호] 아마존 API 게이트웨이와 AWS 람다로 구성하는 다운로드 서버 오세용 기자
[마소 394호] AWS EC2와 트래비스CI를 활용한 무중단 배포 서비스 오세용 기자
[마소 394호] 스타트업의 좌충우돌 CI/CD 구성 오세용 기자
[마소 394호] AWS 이메일 서비스 써보니 오세용 기자
[마소 394호] 클라우드의 성능 품질 이야기 오세용 기자
[마소 394호] 클라우드 시대 토종 호스팅 업체의 변신 오세용 기자
[마소 394호] 데이터베이스의 게임 체인저, 오라클 클라우드 오세용 기자
[마소 394호] 다시 보는 PaaS, 어디서 와서 어디로 가는가 오세용 기자
[마소 394호] 코드로 관리하는 인프라스트럭처, 테라폼 오세용 기자
[마소 394호] 더 웨더 컴퍼니의 데브옵스 오세용 기자
[마소 394호] 사설 클라우드의 끝판왕 오픈스택 오세용 기자
[마소 394호] 개발운영 퀀텀 점프를 위한 도커 오세용 기자
[마소 394호] IT 서비스와 모니터링 역사 오세용 기자
[마소 394호] 오픈스택 커뮤니티 동고동락 오세용 기자
[마소 394호] 데브옵스를 꿈꾸는 개발자를 위한 안내서 오세용 기자