HTTPS 에 대하여

드엔트론프·2023년 7월 25일

http https ssl 개인키 공개키 대칭키 비대칭키

들어가며

HTTP 와 HTTPS의 차이에 대해 공부하려했다. 하다보니, HTTP에서 왜 HTTPS가 나오게 됐고, 어떻게 HTTPS가 동작하는지를 보는 방향으로 글을 쓰면 흐름이 깨지지않고 이해될 수 있을 것 같았다.
이러한 흐름 속 알아두어야 이해가 더 쉬워지는 개념들 (대칭키, 비대칭키, 개인키, 공개키, SSL/TLS)을 가볍게 짚으며 HTTPS를 설명해보려한다.

HTTP

HTTP는 우리가 가장 많이쓰는 기본적인 프로토콜이다. GET, POST, PUT과 같은 메서드를 통해 백엔드와 통신할 때 주로 사용하곤한다.

HTTP의 단점

이러한 HTTP는 암호화되지 않은 평문 데이터를 전송한다. 이는 다른 사람이 중간에 탈취하게 되면 데이터를 모두 볼 수 있다는 치명적인 문제로 작용한다.
이를 방지하기 위해 HTTPS가 나오게 됐다.

HTTPS

HTTPS는 HTTP에 S(Secure)인 보안이 추가된 프로토콜이다.
HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합한다.
기존 HTTP 레이어에 SSL(Socket Secure Layer)를 얹어 평문 데이터를 암호화한다.

HTTP, HTTPS 예시

간단한 예시를 보자면, 앞서 설명했듯 HTTP는 누군가 중간에 탈취하면 그 안에 있는 정보(사진의 예에선 password)를 그대로 볼 수 있지만, HTTPS는 알아보기 힘든 암호화된 내용이 적혀 있어 HTTP보다 더 안전하다는 점이다.
이러한 HTTPS, 어떤 방식으로 동작하길래 암호화된 데이터를 보내줄 수 있는 것일까? 바로 대칭키, 비대칭키 두 방법을 모두 활용하여 암호화를 하기 때문이다. 이 대칭키, 비대칭키에 대해 알아보자.

대칭키, 비대칭키

대칭키

간단히 생각하자. 대칭키는 내가 암호화하고, 누군가 암호를 해독할 때 필요한 키가 동일한 경우이다. 이 동일한 키를 나도, 상대방도 갖고 있어야하기 때문에 키를 전달해야 할 경우 안전하게 전달하는 것이 중요하다.

비대칭키

비대칭키는 반대다. 내가 암호화하는 키와 암호를 해독하는 키가 다르다.
이렇게 2가지의 키가 필요한건데, 이 두 가지의 키는 공개키와 개인키로 나뉜다.
참고로, 공개키로 암호화된건 개인키로만 해독할 수 있고, 개인키로 암호화된건 공개키로만 해독할 수 있다. 공개-공개 개인-개인 안됨

공개키: 누구든지 확인하고 사용할 수 있도록 대중에게 공개된 키
개인키: 자기만 갖고있는 키

그래서 공개키로, 또는 개인키로 암호화하는 2가지의 방식이 있다.

자꾸 키 얘기하는데 키가 여러가지 튀어나와 헷갈릴 수 있겠다. 잠깐 정리하자면

크게 대칭키와 비대칭키의 방식으로 나뉜다.

비대칭키를 이용한 방식에는 다시 공개키와 개인키로 암호화하는 방식으로 나뉜다.

비대칭키 - 공개키로 암호화

공개키로 암호화하기

간단한 예시로 이해해보자.
철수는 영희의 공개키로 상자(정보)를 암호화한다. 영희의 공개키는 대중에게 공개된 키이기에 할 수 있다.
이게 영희에게 가면, 영희는 자신의 개인키로 상자를 복호화(해독)한다.
앞서 대칭키처럼 동일한 키가 아니니 대칭키의 방식보다는 훨씬 안전하다.

비대칭키 - 개인키로 암호화

개인키로 암호화하기

예시의 방식이 크게 다르지않다.
철수는 자신의 개인키로 상자를 암호화한다.
철수의 공개키는 이미 공개되어 있기에, 영희는 철수의 공개키로 복호화한다.

여기서 의문은, 철수의 공개키로 암호를 해독하는건, 누구나 할 수 있는거 아닌가? 라는 의문이다. 맞다. 그러면 이런 보안도 안되는 방법을 왜 쓸까? 바로, 상자 안의 내용보다 누가 보냈냐를 아는 확실한 방법이기 때문이다. 철수의 공개키로 해독한다는건 이건 철수가 보냈다는 확실한 말이기 때문이며, 이러한 방법은 실제로 전자서명과 같은 공인인증체계의 기본이 된다고 한다.

이제 대칭키, 비대칭키에 대해 간략하게 알아보았으니 연결과정에 대해 살펴보자.

HTTPS 연결 과정

HTTPS 연결과정

연결과정은 위와 같다.

브라우저가 서버에게 최초 연결을 시도하면 서버는 인증서를 브라우저에게 보낸다.
브라우저는 인증서의 유효성을 확인하여 서버의 공개키를 얻고, 세션키를 발급한다.
이후 서버의 공개키로 이 세션키를 암호화 후, 이를 서버에게 전달한다.
서버는 자신의 개인키로 공개키를 복호화, 안의 세션키를 얻게 된다.
서버와 클라이언트는 동일한 세션키를 공유하게 되며 이제 데이터 전달 시 세션키로 암호화/복호화를 한다.

앞서 말했듯 HTTPS는 대칭키, 비대칭키 방식 둘 다 사용한다고 했다. 대칭키는 바로 세션키를 위해 사용된다. 비대칭키의 방식은 암호화/복호화와 같은 과정이 있기에 대칭키 방식보다 시간이 오래 걸린다. 그렇기에 세션키는 대칭키로 만드는 것이다.
대신 보안을 위해 세션키의 전달은 비대칭키 방식을 통해 전달한다.

HTTPS 연결과정 -인증서

그런데, 여기 이 인증서는 뭐길래 뚝딱 보내고, 이 안에 서버 공개키가 있고, 인증서 유효성 어떻게 확인하고 할까? HTTPS 통신은 제3자인 인증된 기관에서 발급해준 SSL/TLS 인증서가 필요하다. 마지막으로 인증서를 발급받는 과정까지 살펴보자.

SSL/TLS 인증서는 시스템에서 ID를 확인하고 이후에 Secure Sockets Layer/전송 계층 보안(SSL/TLS) 프로토콜을 사용하여 다른 시스템에 대한 암호화된 네트워크 연결을 설정할 수 있도록 하는 디지털 객체

HTTPS 인증서 발급과정

HTTPS 발급과정

인증서를 발급해주는 인증된 기관은 돈을 받고 (혹은 무료로) 인증서를 발급해준다.
이 인증서는 CA 기업의 개인키로 암호화하여 인증서 발급을 요청한 기업에게 전달해준다.
발급 과정에서 재미있는 점은 브라우저(크롬, 파이어폭스 이런 친구들)가 이미 CA의 공개키를 갖고 있다는 점이다. 그렇기에 서버에서 인증서를 보내줬을 때 공개키로 복호화할 수 있는 것이다.

벨로그 인증서 -1

벨로그 인증서 -2

참고로 벨로그도 주소창 옆 자물쇠를 눌러보면 인증서를 발급받았음을 확인할 수 있다.

마지막으로 흐름을 정리해보자.

A 기업은 CA(인증된 업체)에서 CA의 개인키로 암호화된 인증서를 발급받는다. (인증서 안에는 A기업의 공개키가 들어있다.)

브라우저는 A 기업 서버에게 최초 연결을 시도한다.

A 기업은 인증서를 브라우저에게 전달한다.

브라우저는 이미 갖고있는 CA의 공개키를 통해 인증서의 유효성을 검사한다.

유효한 인증서였고, 확인해보니 안에 있는건 A기업의 공개키다.

브라우저는 대칭키 방식으로 세션키를 생성하고, A기업의 공개키를 활용하여 세션키를 암호화한다.

A기업의 공개키를 활용하여 세션키를 암호화한 정보를 A기업 서버에 전달하면, 서버는 자신이 갖고 있는 개인키를 활용하여 암호를 해독한다.

안에는 세션키가 들어있다.

브라우저도, 서버도 동일한 세션키를 갖게 되고, 이제 데이터를 전송할 때 세션키를 통해 암호화/복호화를 한다.

마치며

많은 부분을 간단하게 정리하려고 하다보니, 몇몇 부분을 빼먹은것도 있지 않나 싶다. 그래도 이렇게 HTTPS의 인증서 발급과정과 연결과정을 알아보았다.
남에게 설명하려 공부하고 찾다보면 더 재밌고 도움된다. 스터디 발표 후 이렇게 블로그에 작성하면 더 오래 기억에 남기도 하니 여러모로 좋은 방법인 듯 하다.
글을 작성하며 당연하게도 많은 블로그와 유튜브를 찾아보았다. 걔중 SSL/TLS에 관련하여 글을 너무나도 잘 쓰신 블로그 글이 있어 링크를 남겨둔다. (나도 보려고) 개발자 소들이 - TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키)