HTTPS와 HTTP의 차이는 암호화 프로토콜이 적용되있느냐의 유무다.
HTTPS의 경우, 과거 SSL이 적용되고 있었으나, SSL의 취약점으로 인해 SSL 3.0 부터는 TLS가 SSL을 계승하여 사용된다.
SSL과 TLS는 다른 방식이며, TLS가 더 진화한 방식이지만 용어 자체는 혼용되어 사용된다.
TLS의 개념 정리를 위해서는 선행되는 개념들도 함께 정리가 필요하다.
비대칭키와 대칭키 암호화
암호화에 사용되는 키와, 복호화에 사용되는 키가 같다면 대칭키 암호화,
다르다면 비대칭키 암호화라고 부른다.
대칭키 암호화의 문제점
키가 탈취되면 암호화/복호화가 둘 다 되서 보안 리스크
비대칭키 암호화
비대칭키 암호화에선 2개의 키가 존재한다.
2개의 키를 A, B라고 칭할 때,
- A로 암호화된 데이터는 B로 복호화된다.
- B로 암호화된 데이터는 A로 복호화된다.
RSA 알고리즘
- 비대칭 키 암호화 방식에서, 2개의 키 중 1개를 개인 키, 나머지 1개를 공개 키로 정한다.
- 공개 키는 통신할 모든 사람들에게 뿌린다.
- 통신 전, 개인키를 통해 전송할 데이터를 암호화한다.
- 받는 쪽에서, 공개키를 통해 전송받은 데이터를 복호화한다.
해당 방식을 사용하면, 암호화는 전송자측에서만 할 수 있기에 source를 신뢰할 수 있게 된다.
하지만 CPU 리소스를 크게 소모한다.
TLS의 암호화 방식
TLS는 대칭키와 비대칭키의 RSA방식을 모두 차용한다.
맨 처음에, 대칭 키를 서로 공유하는 과정을 RSA 비대칭키 방식으로 이용하고,
실제 통신을 할 때는 CPU 리소스가 적게 소모되는 대칭키 방식으로 데이터를 주고 받는다.
(이때 사용되는 대칭키는 세션키라고 지칭하여, 통신이 끝나면 폐기된다.)
또한 TLS에서는 공개 키를 주고받는 과정에서 인증서(CRT)를 사용하게 되는데, 인증서가 무결한지 검증하는 과정 또한 수행하게 된다.
TLS의 통신 과정
서버의 인증서 발급 과정
- 서버에서 개인 키를 생성한다.
- 서버에서 CSR(certificate signing request)를 인증기관(CA)에 전달하며 인증서(CRT) 발급을 요청한다.
- 해당 인증기관에서는 CSR을 토대로 사이트를 검증하고, 사이트의 정보와 공개키가 담긴 인증서를 인증기관의 비공개키로 암호화하여 발급한다.
오픈소스 라이브러리 Openssl을 사용하여 셀프 인증서를 발급할 수 있다.
$ openssl req \ -x509 \ -newkey rsa:4096 \ -nodes \ -keyout ${PATH}/XXX.key \ -out ${PATH}/XXX.crt
클라이언트 ~ 서버의 통신 과정
- 서버측의 인증서가 클라이언트에게 전송된다. (인증서에는 공개키가 포함되어있다.)
- 클라이언트는 인증서의 공개키를 사용해 대칭키로 사용할 세션키를 암호화하여 서버에 전송한다.
- 서버는 개인키로 전달받은 대칭키 해시값을 복호화한다.
- 대칭키를 통해 통신한다.
위 기재된 통신 과정은 대략적인 과정이며, TLS handshake의 인증서 검증 과정 등은 생략되어있다.
TLS handshake 참고 URL: https://brunch.co.kr/@sangjinkang/38
HTTPS(TLS)의 위험요소
HTTPS는 가장 기본적인 단계라 모든 상황에서도 안전하지는 않다.
- 만약 해커가 웹서버의 루트 권한을 탈취했다면
- 전달 구간 중간에 해커가 중간자 공격을 할 수 있는 취약점이 있다면
Https는 유지되지만 전달하는 내용은 고스란히 노출된다.
그에 따라 민감한 데이터 전달에서는 HTTPS와 함께 E2E 암호화 기술을 함께 적용하여 HTTPS가 무력화되도 데이터가 복호화되지 않도록 대비해야 한다.
