그림으로 쉽게 보는 HTTPS, SSL, TLS
SSL과 TLS는 무슨 차이일까
지난 포스팅에서 웹 브라우저와 웹 서버 간에 데이터를 주고받기 위해 사용하는 인터넷 프로토콜인 HTTP에 대해 알아봤습니다.
1996년에 탄생한 이후부터 지금까지 HTTP는 웹 통신에 있어 필수 요소로 굳건히 자리하고 있는데요. 그러나 사용하는 사람이 많아지고 웹 기술이 고도화되며 다양한 해킹 방법이 등장했고, 그에 따라 더욱 안전하게 데이터를 전달할 수 있는 보안 체계가 필요해졌습니다.
이번 포스팅에서는 이처럼 HTTP의 보안을 위해 탄생한 프로토콜인 HTTPS에 대해 알아보고, 함께 언급되는 개념인 SSL, TLS에 대해 살펴보겠습니다.
보안을 책임지는 HTTPS
HTTPS(Hypertext Transfer Protocol Secure)는 HTTP의 뒤에 S 한 글자가 추가되었는데요. 이름에서 알 수 있듯 HTTP에서 보안(secure)이 강화된 프로토콜입니다.
HTTPS는 누구나 볼 수 있었던 메시지를 통신하는 당사자들만 볼 수 있도록 암호화해 HTTP의 보안 문제를 해결했다는 점이 가장 큰 특징입니다. 마치 전쟁에서 적군이 못 알아보게끔 우리만의 체계로 명령을 암호화해서 전달한 것처럼 말이에요.
또한 특정 서비스가 HTTPS를 사용하고 있는지는 브라우저 상단의 주소창에서 쉽게 파악할 수 있습니다. 우리가 웹을 이용할 때 주소창을 보면 URL이 https:// 로 시작하고, 앞에 자물쇠 기호가 달린 모습을 종종 목격할 수 있는데요. 이를 통해 해당 사이트가 https 프로토콜을 사용하고 있음을 알 수 있습니다.
그렇다면 실제로 얼마나 많은 웹 서비스가 HTTPS를 사용하고 있을까요?
구글의 보고서에 의하면 2022년 기준 인터넷 상위 100개 사이트 중 97개가 HTTPS를 사용하고 있으며 네이버, 다음 등 우리나라에서 많이 사용하는 플랫폼 또한 HTTPS를 사용하고 있습니다. 구글 크롬 브라우저는 아예 2018년부터 HTTP 페이지에 접근하면 ‘주의 요함’이라는 보안 경고를 표시하는 등 안전한 웹 서비스 사용을 위해 주의를 기울이고 있습니다.
국토교통부(http://www.molit.go.kr/portal.do) 홈페이지SSL과 TLS는 무엇이 다를까
그런데 우리가 앞서 언급했던 HTTP의 보안은 사실 HTTPS가 아닌 다른 곳에서 담당하고 있었는데요. 바로 SSL(Secure Sockets Layer)입니다.
SSL은 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있도록 돕는 보안 계층입니다.
HTTPS를 사용하면 HTTP 메시지에 포함되는 콘텐츠 정보에 보안 요소가 추가되기 때문에 데이터를 안전하게 주고받을 수 있는 거였죠. OSI 계층 구조로 보자면 HTTPS는 아래 그림과 같이 HTTP 계층 아래에 SSL이라는 보안 계층이 추가된 모습입니다.
OSI의 각 계층은 서로 독립되어 있기 때문에 SSL 또한 HTTPS뿐만 아니라 다른 프로토콜과 조합해서도 사용할 수 있습니다. 가령 파일 전송을 위한 FTP, 이메일 전송에 사용되는 SMTP처럼 HTTP와 같은 계층의 프로토콜과 말이죠.
그리고 SSL을 검색해보면 TLS(Transport Layer Security)이라는 단어가 함께 따라다니는 것을 종종 볼 수 있는데요. 사실 이 둘은 약간의 차이는 있지만 같은 보안 프로토콜에서 시작했답니다. 그럼 SSL과 TLS는 어쩌다 다른 이름으로 불려지게 된 것일까요?
원인은 SSL이 갓 알려지기 시작한 1990년대 후반으로 거슬러 올라가 찾아볼 수 있습니다. 당시 공개된 SSL 2.0에 몇 가지 취약점이 발견되어 이를 해결하기 위해 아예 구조를 재설계해 SSL 3.0을 배포했는데요. 그 이후 기존 버전과 구분하기 위해 3.0 다음부터 등장한 SSL의 이름을 TLS로 변경했습니다. 다만 사람들이 SSL이란 이름에 더 익숙하다 보니, 대다수의 보안 프로토콜이 TLS로 교체되어 더 이상 SSL을 사용하고 있지 않은 지금까지도 계속 SSL이라고 부르고 있는 거죠.
대칭키, 공개키로 안전하게 암호화하기
그럼 SSL은 어떤 방식으로 동작하고 있을까요? 과정을 본격적으로 알아보기 전에, SSL은 꽤 복잡한 방식으로 동작하다 보니 쉬운 이해를 위해 미리 두 가지 핵심 개념을 짚고 넘어가고자 합니다.
앞서 군대에서 기밀 정보를 암호화해서 주고받았다는 내용 기억하시나요? 가령 2차 세계대전에서는 각 나라 별로 암호 체계가 있었는데, 이처럼 컴퓨터 세상에서도 데이터를 암호화하는 다양한 방법이 있습니다.
컴퓨터 세상에서는 암호를 만드는 행위, 즉 암호화를 하기 위해 비밀번호 같은 개념인 키(key)가 필요합니다. 이 키가 있어야 암호화를 하고, 반대로 암호를 푸는 복호화도 할 수 있죠. 그중 SSL은 공개키 기법과 대칭키 기법이라는 두 암호화 기법을 함께 사용하고 있습니다. 그럼 하나씩 알아볼까요?
대칭키 기법은 하나의 키로 암호화와 복호화를 둘 다 할 수 있는 암호화 기법입니다. 예를 들면 보물 상자에 하나의 열쇠 구멍이 있고, 거기에 맞는 열쇠 하나로 보물 상자를 열고 잠글 수 있는 것과 같습니다. 웹 통신으로 생각해보면 클라이언트와 서버가 각각 '1234'라는 키를 갖고 있다가 데이터가 왔을 때 이 키로 복호화를 하고, 데이터를 보낼 땐 같은 키를 가지고 암호화를 해 전송하는 식인거죠.
이런 대칭키 기법은 뒤에 설명할 공개키 방식에 비해 암호화나 복호화에 속도가 빠르다는 장점이 있지만, 키를 안전하게 서로 교환하기 어렵다는 단점이 있습니다. 왜냐하면 클라이언트와 서버가 같은 키를 갖고 있어야 하므로 서로 키를 통신해야 하는데, 그럼 중간에 누가 키를 가로챌 위험이 있기 때문입니다.
이러한 대칭키 기법의 문제를 해결하기 위해 탄생한 암호화 방식이 바로 공개키 기법입니다. 공개키 기법은 서로 다른 키 두 개로 암호화, 복호화를 한다는 특징이 있는데요. 이때 사용하는 키 두 개를 각각 공개키, 개인키라고 부릅니다. 공개키는 누구나 가질 수 있는 키지만 개인키는 소유자 한 명만 가질 수 있는 키로 이 두 키는 늘 한 쌍으로 동작하죠. 이 때문에 공개키 암호화 기법을 위해서는 반드시 공개키와 개인키가 함께 필요합니다.
그럼 두 개의 키로 어떻게 암호화가 가능할까요?
이해를 돕기 위해 앞서 설명했던 보물 상자를 다시 가져와 보겠습니다. 공개키의 보물 상자가 대칭키와 다른 점이 있다면 각기 다른 형태인 열쇠 두 개가 한 쌍으로 이루어져 있다는 점입니다. 이해하기 쉽게 각각 빨간 열쇠와 파란 열쇠라고 부르겠습니다. 이때 만약 보물 상자를 빨간 열쇠로 잠갔다면 남아있는 파란 열쇠로만 상자를 열 수 있습니다. 반대로 파란 열쇠로 상자를 잠갔다면 남은 빨간 열쇠로만 열 수 있죠.
공개키 기법도 이와 마찬가지입니다. 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있고, 반대로 개인키로 암호화한 데이터는 공개키로만 복호화할 수 있습니다.
그래서 만약 서버가 개인키를 갖고, 클라이언트에게 공개키를 전달해 서로 데이터를 암호화해서 주고받는다면 중간에 누군가 공개키를 가로챘다고 하더라도 개인키를 모르기 때문에 데이터를 온전히 복호화할 수 없겠죠.
따라서 대칭키보다 더 안전하게 데이터를 주고받을 수 있다는 점에서 장점이 있지만, 암호화 과정이 복잡하므로 속도가 느리다는 단점이 있습니다.
이처럼 공개키 기법과 대칭기 기법은 언뜻 비슷해 보이지만 각자 뚜렷한 특징을 갖고 있는데요. SSL에서는 이 두 기법을 함께 사용하며 서로의 단점을 보완할 수 있게 했습니다. 그럼 필요한 개념도 익혔으니 본격적으로 SSL의 동작 과정을 알아볼까요?
SSL 동작 과정
SSL은 크게 핸드 셰이크, 세션, 세션 종료 세 단계로 이루어집니다.
핸드 셰이크는 TCP 포스팅에서 3방향 핸드 셰이크(3 way handshake)를 설명할 때 나온 용어인데요. TCP와 유사하게 SSL도 클라이언트와 서버가 통신할 때 준비가 되었는지 확인하는 과정인 핸드 셰이크를 거칩니다.
한 번 단계별로 알아볼까요?
1단계: 클라이언트는 서버에게 인사를 건넵니다. 과정 이름도 Client Hello인데요. 이때 랜덤한 데이터와 현재 지원할 수 있는 암호화 방식을 서버에게 전달합니다. 암호화 방식을 전달하는 이유는 같은 대칭키, 공개키 기법이라도 다양한 암호화 방식이 있으므로 서로 어떤 암호화 방식을 사용할지 협의하는 과정이 필요하기 때문입니다.
2단계: 클라이언트의 인사를 받은 서버는 똑같이 클라이언트에게 인사를 합니다. 이때 서버는 세 가지 내용을 전달하는데요. 앞서 클라이언트가 전달한 내용과 동일한 랜덤 데이터와 지원 가능한 암호화 방식, 그리고 새롭게 등장하는 개념인 인증서를 전달합니다.
인증서란 서버가 공식으로 인증된 기관인 CA(Certificate Authority)에서 발급받은 문서로, 서버가 신뢰할 수 있는지 보장하는 역할입니다. 제품으로 따지면 품질보증서 같은 존재인 거죠.
3단계: 인증서를 받은 클라이언트는 이 인증서가 제대로 된 문서인지 검증하기 위해, CA가 발급한 인증서 목록 중에서 서버가 전달한 인증서가 있는지 확인합니다. 그리고 인증서가 목록에 있다면 한 번 더 철저히 확인하기 위해 CA에서 공유하는 공개키를 가지고 인증서를 복호화합니다. 만약 복호화에 성공한다면 이 인증서는 서버가 자신의 비밀키로 암호화를 했다는 것이 검증되니 드디어 서버를 신뢰할 수 있는 거죠.
4단계: 본격적으로 키를 주고받기 위해 클라이언트는 실제 데이터 통신에서 사용할 대칭키를 임시로 만듭니다. 이때 앞서 클라이언트와 서버가 서로 주고받은 랜덤한 데이터를 조합해 임시 키(pre master secret)를 생성하는데요. 임시 키는 대칭키이기 때문에 절대 중간에 제삼자에게 노출되어선 안 되므로 앞서 갖고 있던 공개키로 암호화해 서버에게 전달합니다.
5단계: 키를 받은 서버는 자신이 갖고 있던 비밀키로 암호를 해독해 임시 키를 전달받게 됩니다. 비로소 클라이언트와 서버가 같은 키를 갖게 된 거죠.
6단계: 클라이언트와 서버의 임시 키는 일련의 과정을 거쳐 세션 키로 바뀌고, 이 세션 키를 이용해 본격적으로 클라이언트와 서버가 통신을 할 수 있게 됩니다.
그 이후 단계인 세션 단계에서는 앞서 생성한 세션 키를 이용해 대칭키 기법으로 데이터를 암호화해서 통신하고, 데이터 전송이 끝나면 세션을 종료해 통신을 마칩니다. 이때 통신에서 사용한 세션 키도 함께 삭제하죠.
생각보다 과정이 복잡하죠? 그래도 이렇게 SSL이 까다로운 절차를 거쳐 신뢰할 수 있는 데이터 통신 환경을 만들어주기 때문에 우리가 HTTPS로 안전하게 데이터를 주고받을 수 있는 거랍니다.
마무리
이번 포스팅에서는 HTTPS에 대해 이야기로 시작해 암호화 기법을 지나 SSL의 동작 과정까지 꽤 많은 개념을 다루어 보았습니다. 저 또한 생소했던 개념이 많았던지라 이해하고 정리하는데 상당한 시간이 걸린 글이었는데요. 여기까지 읽어주신 분들께 다시 한번 감사의 인사를 드리며 이번 포스팅은 여기서 마치겠습니다.
