[Web] HTTPS, 대칭키 및 비대칭키(공개키) 암호화

1. HTTPS 프로토콜

HTTP(HyperText Transfer Protocol)란 인터넷 상에서 통신을 할 때 데이터를 주고받는 형식(프로토콜)들 중 하나를 의미한다. 각각의 HTTP 요청과 HTTP 응답은 정해진 형식이 존재한다. 클라이언트가 HTTP 요청의 형식으로 서버에게 요청을 보내면 서버가 그 요청을 HTTP 요청의 형식에 맞게 해독을 하고, 이에 대한 응답을 HTTP 응답의 형식으로 클라이언트에게 보내면 클라이언트가 그 응답을 HTTP 응답의 형식에 맞게 해독을 하는 것이다.

 

HTTPS의 S는 Secure의 약자로, HTTP의 보안 기능을 한층 더 강화한 프로토콜을 의미한다. 요즘 대부분의 신뢰할 만한 사이트들은 HTTPS 프로토콜을 사용하고 있다. HTTPS가 제공하는 대표적인 보안 기능 두 가지는 다음과 같다.

 

• 서버에 보내는 정보를 누군가 훔쳐보지 못하게 한다. 즉, 해당 서버만 알아볼 수 있도록 데이터를 암호화하여 보낸다.
• 접속한 사이트가 신뢰할 만한지 판별해준다. 공인 기관으로부터 검증된 사이트만 주소에 HTTPS를 사용할 수 있다.

 

2. 대칭키 및 비대칭키(공개키) 암호화

2-1. 대칭키 암호화

동일한 키를 사용하여 암호화와 복호화를 하는 방식으로, 서버와 클라이언트 양쪽이 동일한 키(= 대칭키)를 가지도록 한다. 암호화를 할 때는 데이터와 키를 특정 알고리즘에 넣어서 돌리면 되고, 복호화를 할 때는 데이터와 키를 그 알고리즘에 넣어서 거꾸로 돌리면 된다. 즉 대칭키를 서버와 클라이언트만 가지고 있다면 전송 과정의 데이터를 누군가 훔쳐보더라도 그 내용을 알아볼 수 없게 된다. 그러나 이러한 대칭키를 서버와 클라이언트가 서로 공유하기 위해서는 최소 한 번은 그 대칭키를 전송하는 과정이 필요하다는 문제가 있다. 만약 이 과정에서 그 대칭키가 탈취당한다면 암호화가 아무 의미 없어지는 것이다. 이를 보완하기 위해 등장한 방식이 바로 비대칭키(공개키) 암호화 방식이다.

 

2-2. 비대칭키(공개키) 암호화

암호화와 복호화를 할 때 서로 다른 키를 사용하는 방식으로, 서버는 자신만의 개인키를 가지고 있고 이에 대응되는 공개키는 누구나 가지고 있을 수 있도록 공개한다. 개인키로 암호화된 데이터는 이에 대응되는 공개키로만 복호화가 가능하며, 공개키로 암호화된 데이터는 이에 대응되는 개인키로만 복호화가 가능하다. 따라서 서버에게 데이터를 전송할 때 해당 서버의 공개키로 암호화를 하면 누군가 훔쳐보더라도 해당 서버의 개인키를 가지고 있지 않아서 그 내용을 알아볼 수 없게 된다.

 

3. CA (Certificate Authority), 사이트의 안전성 판별

그렇다면 우리가 HTTPS로 네이버를 접속할 때 그 사이트가 진짜 네이버인지는 어떻게 판별할 수 있을까? 이를 이해하기 위해서는 먼저 CA(Certificate Authority)와 관련된 내용을 짚고 넘어가야 한다. 그리고 나면 이를 앞서 소개한 비대칭키(공개키) 암호화 방식과 연결 지어 사이트의 안전성을 판별하는 방법을 이해할 수 있게 될 것이다.

 

3-1. CA (Certificate Authority)

인터넷 상에 존재하는 수많은 사이트들은 CA(Certificate Authority)라고 불리는 공인 민간 기업들로부터 신뢰할 만한 사이트임을 인증할 수 있는 인증서를 발급받는다. CA로부터 발급되는 인증서는 인증받는 서버의 공개키 정보를 포함하고 있으며, 해당 CA의 개인키로 암호화가 되어 있다. 그러면 이제 클라이언트가 네이버에 접속하는 상황을 가정해 보자.

 

3-2. Handshake (사이트의 안전성 판별)

처음에는 클라이언트가 서버를 완전히 신뢰할 수 없기 때문에 그 사이트의 안전성을 판별하기 위한 Handshake(악수)의 과정을 밟는다. 클라이언트는 특정 랜덤 데이터를 생성해서 서버에게 보내고, 그것을 받은 서버는 또 다른 랜덤 데이터를 생성하여 자신이 CA로부터 발급받은 인증서와 함께 클라이언트에게 보내는 것이다. 그러면 클라이언트는 브라우저에 내장되어 있는 CA들의 정보를 통해 해당 인증서가 정말 CA로부터 발급받은 인증서인지 확인한다. 모든 브라우저는 각 CA의 공개키를 이미 알고 있고 CA로부터 발급받는 인증서는 해당 CA의 개인키로 암호화가 되어 있기 때문에, 정말로 CA로부터 발급받은 인증서가 맞다면 복호화가 가능할 것이다. 만약 브라우저가 알고 있는 CA의 개인키로 복호화가 불가능하다면 안전하지 않음(Not Secure) 표시가 뜰 것이다.

 

4. 대칭키 + 비대칭키(공개키) 암호화

위에서 설명한 Handshake의 과정이 성공적으로 끝나고 나면, 복호화된 서버의 인증서로부터 해당 서버의 공개키를 얻게 된다. 그러면 이제 그 공개키를 이용해서 해당 서버와 비대칭키 암호화 방식으로 데이터를 주고받으면 되는 것일까? 그렇지 않다! 실제로는 대칭키 암호화 방식과 비대칭키 암호화 방식을 혼합하여 데이터를 주고받게 된다. 이게 무슨 의미일까?

 

비대칭키(공개키) 암호화 방식은 대칭키 암호화 방식에 비해 알고리즘이 복잡하여 컴퓨터에 많은 부담을 준다고 알려져 있다. 따라서 수많은 데이터들을 주고받을 때마다 매번 비대칭키 방식을 사용하는 것은 좋지 못하다. 따라서 데이터를 주고받을 때는 대칭키 암호화 방식을 사용하게 된다. 그런데 이러면 대칭키를 공유하는 과정에서 위험하다고 하지 않았는가? 이를 해결하기 위해, 최초에 대칭키를 공유할 때만 비대칭키(공개키) 암호화 방식을 사용하게 된다. 

 

이전의 Handshake 과정이 끝나고 나면 클라이언트에는 두 종류의 랜덤 데이터가 존재한다는 것을 알 수 있다. 하나는 클라이언트에서 생성했던 랜덤 데이터이고, 나머지 하나는 서버가 만들어서 보내준 랜덤 데이터이다. 클라이언트는 이 둘을 섞어서 특정 임시키를 생성하고, 이 임시키를 서버의 공개키로 암호화하여 서버로 전송하며, 서버는 그 임시키를 자신의 개인키로 복호화한다. 이제 클라이언트와 서버가 동일한 어떤 방식으로 그 임시키를 조작하면 동일한 대칭키가 생성이 된다. 결국, 둘의 통신을 위한 대칭키는 오직 둘만 가지고 있게 되기 때문에 안전한 데이터 통신이 가능해진다.

 

 

 

 

 

 

본 글은 아래 링크의 내용을 참고하여 학습한 내용을 나름대로 정리한 글임을 밝힙니다.

https://youtu.be/H6lpFRpyl14