➕ Topic

---

💡 [HTTPS] 1. 암호화에 대하여(대칭키, 공개키) 에서 이어지는 글입니다.

오늘은 암호화 방식에 이어서, HTTPS에 대해 알아보려고 한다.

이전 포스팅에서 다룬 대칭키, 공개키 방식을 HTTPS에서 어떻게 적용하고 있는지 확인해보자.

➕ Contents

---

HTTPS란?

위키백과에서 정의하고 있는 HTTPS는 다음과 같다.

Hypertext Transfer Protocol Secure(HTTPS) is an extension of the Hypertext Transfer Protocol
(HTTP). It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS or HTTP over SSL.

여기서 알 수 있는 사실은

1. HTTPS는 HTTP와 별개의 프로토콜이 아닌 HTTP의 extension(확장)이다.
2. HTTPS는 인터넷에서 secure communication(보안 통신)을 위해 사용된다.
3. Transport Layer Security(TLS) 또는 Secure Sockets Layer(SSL)을 사용해 암호화된다.

한 마디로 정리하면, “SSL/TLS을 사용해 암호화하여 보안 통신을 제공하는 HTTP의 확장된 버전”이라고 볼 수 있다. HTTP에는 데이터를 암호화하는 과정이 없기 때문에, 서버와 브라우저의 통신 과정에서 데이터가 그대로 노출될 위험이 크다. 그래서 HTTPS는 데이터를 암호화하여, 보안에 민감한 정보들을 안전하게 전달할 수 있게 도와준다.

이제 SSL/TLS이란 무엇이고, HTTPS가 어떤 방식으로 보안 통신을 제공하는지 알아보자.

SSL/TLS 프로토콜

이번에도 위키백과에 있는 정의를 가져와 보았다.

Transport Layer Security (TLS), the successor of the now-deprecated Secure Sockets Layer (SSL), is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

SSL/TLS는 위의 정의처럼 컴퓨터 네트워크 상에서 보안 통신을 제공하기 위해 설계된 프로토콜이다.

TLS는 SSL의 취약점들을 개선한 다음 버전의 프로토콜로, 보안 프로토콜이라는 의미에서 SSL과 혼용해서 쓰이기도 한다.

SSL/TLS는 특정 네트워크 계층에 속하는 프로토콜이 아니라, 독자적으로 존재하는 프로토콜이다. 정확하게는 응용 계층(Application Layer)과 전송 계층(Transport Layer) 사이에 위치해, 보안 과정을 수행한다.

HTTPS는 응용 계층 프로토콜인 HTTP와 전송 계층 프로토콜인 TCP 사이에 SSL/TLS 프로토콜을 거치도록 설계되어 있다. 외부로 데이터를 보낼 때는 HTTP가 TCP에 보내는 것처럼 데이터를 SSL에게 보내면, SSL이 데이터를 암호화하여 TCP에게 전달한다. 역으로 데이터를 받을 때도 TCP가 HTTP 대신 SSL에게 데이터를 보내면, SSL이 데이터를 복호화하여 HTTP에게 전달한다.

HTTPS의 통신 과정

HTTPS는 앞서 다룬 대칭키 방식과 공개키 방식을 함께 사용하고 있다. 보통 실제 데이터를 암호화할 때는 비교적 빠른 대칭키 방식을 사용한다. 그리고 서버에 대한 인증과 안전한 대칭키 전달에는 공개키 방식을 많이 사용한다.

서버와 브라우저 간의 HTTPS 통신 과정은 크게 두 가지 과정으로 나누어 생각해볼 수 있다.

• 인증: 서버가 진짜 내가 요청한 서버가 맞는지 확인
• 협상: 브라우저와 서버가 어떤 암호화 방식을 사용할 것인지 협의

1. 인증 - CA

인증 과정은 CA(Certificate Authority)라는 신뢰할 수 있는 외부 인증 기관을 거쳐서 진행된다. CA는 해당 서버가 믿을 만한 서버라는 것을 증명하는 SSL 인증서를 발급한다. 브라우저는 서버로부터 받은 인증서가 해당 CA에서 발급한 것이 맞는 지를 확인하여, 믿을 수 있는 서버인지 검증할 수 있다.

SSL 인증서
CA에서는 검증된 서버에 대한 인증서를 발급하는데, 이를 SSL 인증서 혹은 TLS 인증서라고 부른다. SSL/TLS는 보안을 제공하는 프로토콜인데, 이 인증서를 생성하는 데 직접적인 연관이 있는 것은 아니다. "SSL/TLS와 함께 사용할 인증서”라는 의미가 조금 더 정확하다.

인증서 발급

새로운 사이트를 하나 만들었다고 가정해보자. 여러 사용자들이 HTTPS를 통해 이 사이트에 접속할 수 있게 하려면, 먼저 CA로부터 SSL 인증서를 발급 받아야 한다. SSL 인증서에는 주로 서버의 공개키가 들어가 있는데, 이는 나중에 데이터 교환을 위한 대칭키 전달에 사용된다. (자세한 내용은 이후 내용에서 다시 다룬다.)

1. 서버는 공개키와 개인키를 생성하여, 자신에 대한 정보와 함께 공개키를 전달한다.
2. CA는 전달 받은 정보를 바탕으로 신뢰할 수 있는 서버인지 확인하고, 서버의 공개키를 담은 SSL 인증서를 생성한다.
3. SSL 인증서는 CA의 개인키를 통해 암호화한다. 즉, 전자 서명을 통해 해당 CA에서 발급한 인증서라는 것 증명할 수 있게 한다.
4. 암호화된 SSL 인증서를 서버에 전달하고, 서버는 이를 보관한다.

인증서 검증

이제 서버는 CA의 개인키로 암호화 된 SSL 인증서를 가지고 있다. 이 인증서는 CA의 공개키로 복호화할 수 있기 때문에, 브라우저가 CA로부터 공개키를 얻어내 인증서의 진위 여부를 확인할 수 있다. CA의 공개키로 복호화가 가능하다면 (1) CA에서 발급한 인증서이고, (2) 이 인증서를 가지고 있는 서버는 진짜 서버라는 사실을 증명할 수 있다.

1. 브라우저가 서버와 연결을 요청하면, 서버는 자신의 SSL 인증서를 브라우저에게 전달한다.
   1. SSL 인증서는 SSL Handshake 과정을 통해서 브라우저에게 전달된다.
2. 브라우저는 CA에게 인증서 검증 요청을 한다.
   1. 브라우저에는 주요 인증 기관의 리스트와 공개키를 이미 보유하고 있다. 따라서 매번 인증 기관에서 인증서 검증 요청할 필요가 없다.
   2. 브라우저의 인증 기관 리스트 중에 인증서를 발급한 기관이 없다면, 외부 인터넷에서 인증 기관과 공개키에 대한 정보를 찾는다.
3. CA는 자신의 공개키를 브라우저에게 전달한다.
4. 브라우저는 CA 공개키로 SSL 인증서를 복호화한다. 복호화가 된다면 서버의 공개키를 확보한다.

2. 협상 - SSL Handshake

신뢰할 수 있는 서버임이 인증되었다면, 서버와 브라우저가 서로 어떤 알고리즘과 대칭키로 데이터를 암호화하여 주고 받을지 협상이 필요하다. 이 과정은 전송 계층(Transport Layer)인 TCP 연결이 수립된 후, SSL/TLS 프로토콜에서 SSL Handshake을 통해 결정된다.

SSL Handshake은 데이터를 실제로 암호화 하기 위한 대칭키를 전달하는 것이 가장 큰 목적이다.

• 데이터 암호화 알고리즘(Cipher Suite) 결정
• 데이터를 암호화 할 대칭키 전달

1. Client Hello: 가능한 암호화 알고리즘 목록을 서버에게 전달한다.
2. Server Hello: 서버는 알고리즘 목록 중 하나를 선택한다.
3. Certificate: 서버가 자신의 SSL 인증서를 클라이언트에게 보낸다.
   1. 이후 클라이언트는 SSL 인증서를 검증하는 과정을 거쳐, 서버의 공개키를 획득한다.
4. (Optional) Server Key Exchange: SSL 인증서에 서버의 공개키가 없는 경우, 서버가 직접 전달한다.
   1. 키 교환 알고리즘이 공개키 방식이 아니라면 인증서 안에 공개키가 들어있지 않다. 이 경우 서버에서 키 교환에 필요한 다른 값을 서버에서 직접 전달한다.
   2. Diffie-Hellman(DH) 알고리즘은 공개된 특정 값을 통해 대칭키를 계산하기 때문에, 이 값을 Server Key Exchange 과정에서 전달한다.
5. Server Hello Done: 서버의 작업이 종료되었다.
6. Client Key Exchange: 클라이언트가 대칭키(데이터를 실제로 암호화 할 키)를 생성하여, SSL 인증서에 있던 서버의 공개키로 암호화하여 전달한다.
   1. 공개키가 없는 경우는 클라이언트에서 서버가 대칭키를 계산할 수 있는 특정 값을 전달한다.
7. ChangeCipherSpec: 클라이언트와 서버가 교환할 정보를 패킷으로 전달한다.
   1. 서버는 클라이언트가 보낸 대칭키를 서버의 개인키로 복호화 해 대칭키를 얻는다.
8. Finished: SSL Handshake를 종료한다.

결론

두 편에 나눠서 HTTPS에 대해 다루어보았는데, 암호화에 대해서 정리하고 나서 보니 확실히 이해가 더 잘되는 것 같다. 이 포스팅부터 접했다면 꼭 1편, 암호화에 대하여를 읽고 나서 보기를 추천한다.

마지막으로 오늘 다룬 내용에 대한 요약 정리를 하며 마치도록 하겠다.

• HTTPS는 전송 계층(Transport Layer)과 응용 계층(Application Layer) 사이에 독립적으로 존재하는 SSL/TLS 프로토콜을 통해 보안을 강화했다.
• HTTPS는 공개키 방식과 대칭키 방식을 적절히 혼합하여 사용한다.
• HTTPS는 크게 인증과 협상을 거쳐 보안을 유지한다.
  • 인증은 CA라는 인증 기관을 통해 브라우저가 요청한 서버가 진짜 서버인지를 확인하는 과정이다. CA에서는 진짜 서버에게 서버의 공개키를 넣은 SSL 인증서를 발급해준다. 브라우저는 서버로부터 SSL 인증서를 받아 CA에게 인증서 검증을 요청한다.
  • 협상은 데이터를 어떤 방식으로 암호화할 지를 결정하는 과정이다. SSL Handshake 과정을 통해 암호화 알고리즘을 결정하고, 암호화에 쓰일 대칭키를 교환할 수 있다.
• SSL Handshake는 Client Hello → Server Hello → Certificate → (Server Key Exchange) → Server Hello Done → Client Key Exchange → Server ChangeCipherSpec/Finished → Client ChangeCipherSpec/Finished 과정을 거친다.
  • 가장 중요한 대칭키 교환은 Client Key Exchange에서 일어난다.

➕ References

---

• HTTPS
  • 참고 링크: [10분 테코톡] 🍭 다니의 HTTPS
  • 참고 링크: HTTPS 통신과정 쉽게 이해하기 #1(HTTPS의 개요)
  • 참고 링크: Https는 공개키? 대칭키? 비대칭키?
  • 참고 링크: HTTP vs HTTPS 차이, 알면 사이트의 레벨이 보인다. - wishket
  • 참고 링크: HTTPS - Wikipedia
• SSL/TLS
  • 참고 링크: SSL vs. TLS - 차이점은 무엇인가?
  • 참고 링크: Crocus
  • 참고 링크: Transport Layer Security - Wikipedia
• SSL Handshake
  • 참고 링크: HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)
  • 참고 링크: [네트워크] TLS & SSL Handshake