시작하며
막상 실무를 하다보면 SSL 적용… , HTTPS 로 통신이 되니….., 인증서…. 등등 보안 통신 관련해서 많은 일들을 접할수 있다. HTTPS 라는 말은 간단하지만, 실제로 내부 동작 원리를 살펴보면 대칭키, 공개키, 인증서, 전자서명 SSL, 해시 등 많은 개념들이 어우러져 있는 종합선물세트 같은 느낌이 든다. 1편에서는 HTTPS 안에 있는 기본 개념들을 살펴보고 2편에서는 HTTPS 의 동작 원리를 살펴보도록 한다.
HTTP 와 HTTPS
HTTPS의 정의를 위키에서 찾아보면 아래와 같다.
HTTPS(HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure)는 월드 와이드 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다.
즉 간단하게 생각하자면, HTTPS는 기존 HTTP 레이어에서 SSL(TLS) 프로토콜을 얹어 평문 데이터를 암호화하는 프로토콜이다,
SSL 과 TLS
간단하게 설명하면 SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의
과거 명칭이라 봐도 무방하다. 단어의 등장시기나 역사는 조금 다르지만, TLS는 SSL 3.0을 기초로 해서
IETF가 만든 프로토콜로 이는 SSL3 .0을 보다 안전하게 하고 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다.
즉, TLS 안에 SSL 있다.
하지만 TLS 보다는 SSL 이라는 이름이 훨씬 더 많이 사용하고 있다.
대칭키 와 공개키
대칭키 암호화 방식은 집 열쇠와 같다고 생각하면 되겠다. 대칭키를 가지고 데이터를 암호화 하고, 또한 대칭키로 데이터를 복호화 한다. 예를들어 hello 라는 키로 데이터를 암호화 했다면, 데이터를 복호화 하기 위해서는 반드시 hello 키가 필요하다.
다만 이런 방식은 치명적인 단점이 있다. 암호를 주고 받은 사이에서 대칭키를 전달하는 것이 어려우며, 만약 중간에 대칭키가 탈취/유출 되면 그 키로 암호화 됬던 데이터들은 모두 유출 되는 셈이다.
이러한 단점을 극복하고자 나온 방식이 공개키 방식(PKI,Public Key Infrastructure)이다. 공개키는 두개의 키를 갖게 되며, A키로 암호화 하면 B키로 복호화가 가능하며, 반대로 B키로 암호화 하면 A키로 복호화가 가능하다. 여기서 두개의 키중 하나는 공개키(public key)가 되며, 하나는 비공개키(private key)가 된다. 두개의 키가 동작되는 원리를 간단히 살펴보면, 비공개키는 소유자 즉 굉장히 private한 사용자가 가지고 있게 되며, 공개키는 소유자외 타인에게 공개되는 키이다.
타인은 공개키를 이용하여 데이터를 암호화 해서 소유자에게 전달하면, 소유자는 비공개키로 복호화 하여 그 데이터를 얻을수 있게 되는 간단한 원리이다.
전자서명
비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 정보와 공개키를 획득한 사람은 공개키를 이용해서 암호화된 정보를 복호화 한다. 이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해서 데이터가 복호화 될 위험이 있다. 이런 위험에도 불구하고 비공개키를 이용해서 암호화를 하는 이유는 무엇일까? 그것은 이것이 데이터를 보호하는 것이 목적이 아니기 때문이다. 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다. 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자 서명이라고 부른다.
SSL 인증서와 CA
SSL 인증서는 아래에 대해 제공된다.
- 클라이언트가 접속한 서버가 신뢰가 있는 서버임을 증명
- SSL 통신에 사용될 공개키를 클라이언트에 제공
CA(Certificate authority) SSL 인증서를 제공하는 기업이며, 꽤 높은 보안 허들을 뚫고 공인된 기업들이다. 위키피디아 CA 리스트에 가보면 CA 들에 대한 정의와 목록들을 볼수 있다.
SSL 인증서에는 아래 정보가 포함되어 있다.
- 서비스 정보(인증서 발급 CA, 도메인 등)
- 서버 공개키(공개키 암호화 방법)
위의 서비스 정보는 클라이언트가 접속한 서버가 클라이언트가 목적한 서버가 맞나 확인 되는 내용이 있고, 위 서버 공개키는 서버와 클라이언트가 통신할때 사용될 공개키와 공개키 암호화 방법들의 정보가 있다. 위 인증서 및 내용은 CA에 의해서 암호화 된다. 이때 CA는 자산의 비공개키로 서버가 제출한 인증서를 암호화한다. 알다시피 CA의 비공개키는 절대로 유출되서는 안되며, 실제로 디지노타 라는 회사에서 CA의 비공캐가 유출된 사례가 있어 CA 자체가 파산된 경우도 있었다.
브라우저와 CA
브라우저는 내부적으로 CA의 리스트를 미리 알고 있다. 즉 브라우저 소스안에 CA 리스트가 존재한다는 말이다, CA 리스트 뿐만 아니라, 각 CA의 공개키도 이미 브라우저안에 내장되어 있다.
브라우저가 서버에 접속할때 서버는 클라이언트에게 인증서를 제공한다. 브라우저는 서버에서 받은 인증서가 자신이 가지고 있는 CA 리스트에 있나 확인을 한다. 비교후 정상적인 인증서이면, 해당 CA의 공개키(브라우저 안에 있는)를 이용하여, 인증서를 복호화한다. 여기서 중요한 포인트는 복호화가 됬다면, 그 인증서는 CA의 비공개키로 암호화 된 것을 의미하게 된다. 즉 해당 CA에 의해 정상적으로 발급된 인증서라는 의미가 되며, 그것은 클라이언트가 접속한 서버에서 제공한 인증서가 해당 CA에 의해 정상적으로 발급됬다는 의미이다. 간단히 정리하면 [클라이언트가 접속한 서버에서 받은 인증서가 CA에서 정상적으로 발급된 인증서다!] 라는 결론을 내릴수 있다.
마치며
2편에서는 본격적으로 HTTPS가 어떻게 동작하는지 살펴보도록 하겠다.
참고 사이트
- https://opentutorials.org/course/228/4894
- https://wayhome25.github.io/cs/2018/03/11/ssl-https/