목차

• HTTP의 문제점
• 대칭키 암호화 방식
• 공개키(비대칭키) 암호화 방식
• HTTPS (HTTP + SSL)
• HTTPS 의 동작방식

HTTP의 문제점

도청이 가능하다

HTTP 프로토콜로 통신하는 HTTP 요청/응답 메시지는 암호화되지 않은 평문으로 통신하기 때문에, 패킷을 탈취당하면 탈취자는 어떤 메시지가 네트워크 상에서 오고가는지 확인할 수 있습니다.
만약 결제를 하기 위해, 카드번호와 결제비밀번호를 HTTP 프토로콜로 요청을 보냈는데 도청당한다면? 내 카드가 내 카드가 아닐 것입니다...

통신 상대를 확인하지 않기에 위장이 가능하다

HTTP를 사용한 요청, 응답에서는 통신 상대를 확인하지 않습니다. 또한 IP주소, 포트 제한이 있는 것이 아니라면 요청이 들어오면 상대가 누구든 응답을 반환해줍니다.

클라이언트가 보낸 요청에 대한 응답의 출처가 클라이언트가 의도한 웹서버로부터 전송된 것 인지 알 수 없다. 몇 년전 한창 시끄러웠던 피싱 사이트가 그 예시이다. 반대로 서버도 보낸 응답이 의도한 클라이언트에게 전송된 것인지 알 방법이 없다. 즉, 요청을 받은 웹 서버가 위장한 웹 서버일수도 있고, 응답을 받은 클라이언트가 위장한 클라이언트일수도 있다.

---

대칭키 암호화 방식

HTTPS에 대해 알아보기에 앞서서, 배경지식으로 대칭키 암호화 방식과 공개키(비대칭키) 암호화 방식에 대해 알아보겠습니다. 먼저 대칭키 암호화 방식입니다.

대칭키 암호화 방식은 암호화, 복호화할 때 동일한 키가 사용되는 방식입니다. 같은 키를 사용하기 때문에 "대칭키"라는 이름으로 불립니다. 그리고 후술할 비대칭키 방식에 비해 암호화/복호화 속도가 빠릅니다.

대칭키 암호화 방식의 문제점

하지만,대칭키 암호화 방식을 사용하기 위해서, 한쪽에서 다른 한쪽으로 대칭키를 전송하는 과정이 필요합니다. 이 과정에서 대칭키 자체가 제 3자에게 도난당할 위험성이 존재합니다.

아무리 메시지를 암호화한들 대칭키를 도난당하게 된다면, 해커는 손쉽게 메시지를 복호화할 수 있으므로 암호화가 무용지물이 될 것 입니다.

공개키(비대칭키) 암호화 방식

대칭키 암호화 방식과 다르게, 공개키(비대칭키) 암호화 방식은 서로 다른 키로 암호화와 복호화를 수행하는 암호화 기법입니다.

공개키 암호화 방식은 2개의 비대칭키를 관리하는데, 하나는 공개를 하고, 다른 하나는 서버에서만 관리하는 방식을 채택합니다. 여기서 공개하는 키는 공개키라고 하고, 비밀로 관리하는 키는 개인키(비밀키) 라고 합니다.

공개키는 호스트로 보내는 메시지를 암호화하기 위해서 모두를 위해 공개하고, 개인키는 호스트에서만 관리하고 있는 키로 호스토로 오는 메시지를 복호화할 때 사용되는 키입니다.

공개키 암호화 방식의 문제점

하지만, 공개키 암호화 방식은 앞서 언급했듯이 대칭키 암호화 방식에 비해 암호화 연산 시간이 더 소모되어 비용이 큰 방식입니다.

정리하자면, 대칭키 방식의 장점(빠르다)이 공개키 방식의 단점(느리다)가 되고, 대칭키 방식의 단점(키 보안성 미흡)이 공개키 방식의 장점(키 보안성 우수)이 됩니다.

---

HTTPS (HTTP + SSL)

사람들은 HTTP 통신을 사용하여, 클라이언트-서버 통신, 서버간 통신 등 다양한 곳에서 사용합니다. 하지만, HTTP 메시지가 그대로 노출된다면 이는 사용자들로 하여금 웹을 신뢰하지 않고 중요한 정보를 입력하지 않게 됩니다.

물론, HTTP의 인증, 다이제스트 인증, 메시지 무결성 기능을 활용할 수도 있습니다. 하지만 이커머스 시스템, 은행 업무, 보안 자료 등과 같은 부분에서는 강력하지 못한 솔루션입니다.

그래서 HTTP 요청/응답을 암호화해주는 HTTPS가 등장합니다.

SSL (Secure Sockets Layer)

아래의 그림에서 처럼 HTTP 방식은 어플리케이션 계층에서 직접 TCP 레이어와 통신하지만, SSL을 사용하면 HTTP와 SSL이 통신하고, SSL과 TCP 가 통신하게 됩니다. 이렇게 통신하는 방식을 HTTPS 라고 부르는 것 입니다.

SSL 통신 과정

SSL(또는 TLS)는 웹서버와 웹 브라우저 간의 보안을 위해 만들어진 프로토콜입니다. SSL은 대칭키 암호화 방식과 개인키 암호화 방식을 모두 사용하여 각각의 단점을 보완해줍니다.

자세하게 말해보자면, SSL은 대칭키를 공개키 방식으로 안전하게 전달하며, 이후 통신은 주고 받은 대칭키를 통해 진행됩니다. 이렇게 됨으로써 대칭키를 중간에서 탈취당하지 않고, 공개키 방식보다 빠르게 통신할 수 있게 됩니다.

친절한 설명은 해당 동영상을 참고해주세요.

SSL Hand shake

암호화된 HTTP 메시지를 보내기 전에, 클라이언트와 서버는 SSL 핸드셰이크를 해야합니다. 핸드셰이크에서는 다음과 같은 일들이 일어납니다.

• 프로토콜 버전 번호 교환
• 양쪽이 알고 있는 암호선택
• 양쪽의 신원을 인증
• 채널을 암호화하기 위한 임시 세션 키 생성

---

HTTPS 의 동작방식

그런데, 앞서 이야기한 것 처럼 HTTP는 통신 상대를 확인하지 않습니다. 클라이언트가 피싱사이트로 접속한 것 일수도 있다. 위 과정에서 클라이언트는 서버로부터 받은 공개키가 진짜인지 가짜인지 어떻게 판별할 수 있을까요? 바로 CA (Certicifate Authority)라는 제 3자를 통해 가능합니다.

CA는 이런 공개키가 진짜인지 인증해주는 공인된 민간 기업입니다. 정말 엄격한 인증 과정을 거쳐야 CA가 될 수 있다고 합니다. 이 과정을 조금 더 자세히 알아보겠습니다.

먼저, 서버는 CA에게 자신의 공개키를 건넵니다. 그러면 CA는 서버의 공개키를 CA의 개인키로 암호화하여 서명합니다. 이렇게 암호화된 것을 공개키 인증서(Public key Certificate) 라고 합니다. 서버는 이 공개키 인증서를 클라이언트에게 보냅니다.

클라이언트의 웹 브라우저에는 기본적으로 CA의 공개키 정보가 담겨있습니다. 앞서 공개키 인증서는 서버의 공개키를 CA의 개인키로 암호화한 것이라고 이야기했습니다. 그렇다면, CA의 공개키로 복호화가 가능할 것입니다. 만약 CA에서 인증받지 않은 인증서는 복호화가 불가능하게 될 것이고 브라우저는 사용자에게 신뢰할 수 없는 보안 인증서라는 메시지가 표시될 것입니다.

웹 브라우저에서 지원하는 CA의 리스트가 존재하며, 리스트에 있는 CA들에 대해선 공개키를 관리하고 있습니다.

이렇게 서버의 공개키를 안전하게 전달받은 클라이언트는 드디어 이 공개키 암호화 방식을 통해 서버와 대칭키를 주고받을 수 있게 되고, 그 대칭키를 통해 암호화된 메시지를 주고받을 수 있게 되었습니다.

추가로, 구글은 HTTPS 를 통해 서비스하는 사이트는 SEO(Serach Engine Optimization) 순위가 높다고 합니다. SEO 순위가 높을수록, 페이지를 상단에 노출시켜 많은 사람이 볼 수 있게끔 최적화됩니다.

Reference

HTTP 완벽 가이드
그림으로 배우는 Http & Network
면접을 위한 CS 전공지식 노트
https://www.youtube.com/watch?v=H6lpFRpyl14&t=2s
https://www.youtube.com/watch?v=wPdH7lJ8jf0
https://hudi.blog/https/
http://www.ktword.co.kr/test/view/view.php?m_temp1=3132