[간단 정리] HTTPS의 암호화 방식

https 통신은 http 통신과는 달리 데이터를 암호화해서 주고 받는다. 그래서 http 프로토콜을 사용하는 것보다 훨씬 안전하게 데이터를 주고받을 수 있다.

사실 여기까지는 개발자를 꿈꾸는 사람들이라면 누구나 아는 사실이다. 내가 궁금했던 것은 'https방식으로 데이터를 암호화해서 주고받는다고 하더라도 중간에 제삼자가 암호화된 데이터를 가로챈 후 데이터를 복호화하면 결국 데이터를 암호화한 의미가 없게 되는 것 아닐까?'였다. 클라이언트에서는 데이터를 복호화할 수 있기 때문에, 결국 암호화된 데이터에는 복호화하는 방법이 있는 것이다. 그러면 브루트포스 공격 등에는 취약한 게 아닌가?

결과부터 말하자면 그렇지 않다는 것이다. 나는 지금까지 https는 데이터를 암호화해서 주고받는다는 사실만 알고 있었지, 암호화가 어떻게 이루어지는지는 몰랐다. 그런데 이번에 찾아보고 나니 https 통신은 생각보다 안전하다는 것을 깨달을 수 있었다.

우선 데이터 암호화 방식에는 대칭키 암호화 방식과 비대칭키 암호화 방식이 있다.

대칭키 암호화: 데이터의 암호화와 복호화 모두 같은 키(key)를 사용한다.

• 같은 키를 사용하므로 데이터 복호화에 걸리는 시간이 빠르다.
• 그러나 키를 서버에서 클라이언트로 한 번은 공유해야 하는데, 이 과정에서 키가 유출된다면 암호화하는 의미가 없어진다.

비대칭키 암호화: 데이터의 암호화와 복호화에 서로 다른 키를 사용한다.

• 개인키와 공개키가 있는데, 개인키로 암호화했을 경우 복호화는 공개키를 통해서만, 공개키로 암호화했을 경우 복호화는 개인키를 통해서만 가능하다.
• 공개키는 이미 모두에게 공개되어 있기 때문에 서버는 자신의 개인키로 데이터를 암호화한 후 클라이언트에게 전달하면 클라이언트는 공개키로 복호화하는 방식으로 데이터를 주고받을 수 있다.
• 하나의 키로 암호화 및 복호화밖에 할 수 없으므로 키가 하나 유출된다고 하더라도 상대적으로 안전하다.
• 그러나 암호화와 복호화 때 사용하는 키가 서로 다르므로 복호화 시 시간이 상대적으로 더 소요된다.

 

그런데 공개키가 모두에게 공개되어 있으면, 결국 해커가 자신의 공개키를 사용하여 서버의 개인키로 암호화된 데이터를 복호화할 수 있는 것 아닌가?

그럴 수도 있다. 그래서 https에서는 SSL 인증서 방식을 추가적으로 사용한다.
SSL 인증서 방식이란, AWS와 같이 거대한 제삼자 기업들이 '이 공개키는 서버에서 사용할 수 있는 안전한 키입니다.' 하고 인증해주는 방식이다. 이 때 이러한 기업들을 Certification Authority(CA)라고 부르며, CA에 의해 인증된 공개키를 통해 해커의 복호화 시도를 차단할 수 있다.

그런데 https 통신은 여기서 끝이 아니다. https는 비대칭키 암호화 방식 뿐 아니라 대칭키 암호화 방식을 함께 사용하고 있다. 비대칭키 암호화 방식은 보안은 좋지만 시간이 오래 걸리기 때문이다. 통신 과정을 간단하게 작성해 보면 아래와 같다.

1. 서버와 클라이언트 간 3-way handshaking 과정에서 서버는 CA의 인증을 받은 암호화된 공개키를 클라이언트에게 전달한다.
   이 때 암호화된 공개키는 브라우저에서 복호화해준다(CA의 인증으로 암호화된 공개키는 일반적으로 브라우저가 복호화할 수 있다. 인증받은 기업이므로!).
2. 클라이언트는 인증된 공개키를 가지고 새로운 키를 만들어서 암호화한 후 서버로 넘겨준다. 이 키를 세션키라고 부르며, 서버는 개인키를 가지고 있으므로 클라이언트의 공개키로 암호화된 세션키를 복호화할 수 있다.
3. 3-way handshaking이 끝나면 클라이언트는 공개키와 세션키, 서버는 개인키와 세션키를 가지고 있게 된다.
   이후 세션키를 가지고 대칭키 암호화 통신이 이루어진다.

즉 CA의 인증을 통해 비대칭키 방식으로 안전하게 대칭키(세션키)를 공유할 수 있게 되고, 대칭키 방식의 장점인 속도와 비대칭키 방식의 장점인 보안을 모두 챙길 수 있는 방식으로 통신을 진행할 수 있다.