[Web] HTTP와 HTTPS(정의와 프로토콜 메커니즘 이해하기)

안녕하세요. 개발자 Jindory입니다.

오늘은 HTTP와 HTTPS에 대해서 글을 작성해보려고 합니다.

[ 글 작성 이유 ]

회사에서 고객사 API를 호출할 때, 한 고객사는 http 한 고객사는 https를 사용하여 https 인증 과정으로 인해 애를 먹었던적이 있었습니다. http와 https의 정의 및 통신과정을 정리하여 각 프로토콜의 메커니즘을 이해하고자 글을 작성하게 되었습니다.

HTTP란?

HTTP(Hypertext Transfer Protocol)는 "서로 다른 시스템 간의 통신을 가능하게 하고 네트워크를 통해 정보와 데이터를 전송하는 프로토콜"입니다. 사용자가 웹 사이트를 방문하면 사용자 브라우저 웹 서버에서 HTTP 요청을 전송하고 웹 서버는 HTTP 응답하고, 서버에서 네이버 API나 Google API에 HTTP 요청을 전송하고 API 서버에서 HTTP로 응답할 수 도 있습니다.

HTTP가 발전하면서, 하이퍼미디어 문서 뿐만 아니라 이미지, 비디오, HTML 폼 결과와 같은 내용 가져올 수 있게 되었습니다. 사용자가 웹 서핑을 할 때 서버에서 브라우저로 데이터를 전송해 주는 용도로 많이 사용되기에, 인터넷 초기에 모든 웹사이트가 기본적으로 사용했던 프로토콜 입니다.

그러나 http에는 보안과 관련된 몇가지 문제가 있었습니다.

보안 취약성 : HTTP는 데이터를 암호화하지 않고 평문으로 전송합니다. 이는 중간에 제 3자가 네트워크 상에서 데이터를 엿볼 수 있으며, 개인 정보나 민감함 데이터가 노출 될 수 있는 보안 취약점이라고 할 수 있습니다.
무결성 문제 : HTTP는 데이터의 무결성을 보장하지 않습니다. 데이터가 전송 중에 변경되거나 조작될 수 있으며, 이로 인해 정보의 정확성이 보장되지 않습니다. 예를 들어 사용자가 웹 사이트에서 로그인 정보나 신용 카드 정보를 입력할 때 이 정보가 노출 될 수 있습니다.
신원 보증의 부재 : HTTP는 서버의 신원을 확인하는 기능이 없습니다. 따라서 중간에 제 3자가 서버를 위장하여 클라이언트와 통신할 수 있으며, 이는 사이버 공격의 가능성을 높이는 요인이 됩니다.

HTTPS란?

HTTPS(Hypertext Transfer Protocol Secure)는 이름에서 알 수 있듯이 HTTP에 Secure(보안)이라는 단어가 더해진 프로토콜입니다. 위에서 언급된 HTTP의 보안과 관련된 문제들을 해결하기 위해 HTTPS가 등장했습니다.
따라서 HTTPS는 HTTP와 유사하게 작동하지만 "데이터를 전송할 때 서로 다른 시스템 간의 통신을 보호"하기 위해 동합니다.

HTTPS는 암호화 키를 사용하여 데이터를 암호화하고 유효성을 검사하는 디지털 보안 프로토콜로 연결을 보호합니다.

아래와 같이 HTTP의 문제점을 보완하고 있습니다.

보안 취약성 해결 : HTTPS는 SSL/TLS 프로토콜을 사용하여 데이터의 암호화를 제공합니다. 클라이언트와 서버 간의 통신은 대칭키(세션 키)를 사용한 암호화 방식으로 이루어지며, 중간에 제 3자가 데이터를 엿볼 수 없도록 보안적으로 강화되었습니다.
무결성 보장 : HTTPS는 데이터의 무결성을 보장하기 위해 메세지 다이제스트(Message Digest)를 사용합니다. 데이터를 전송할 때 각 데이터 블록에 대한 다이제스트 값을 생성하고, 이를 서버에서 검증하여 데이터 변조 여부를 확인합니다. 이를 통해 데이터가 전송중에 변경되지 않았는지 확인하고 데이터의 무결성을 보장합니다.
신원 보증 : HTTPS는 인증 기관(Certificate Authority)에 의해 발급된 서버 인증서를 사용하여 서버의 신원을 확인합니다. 클라이언트는 서버의 인증서를 검증하고, 서버의 공개키를 획득하여 안전한 통신을 위한 대칭키 교환에 사용합니다. 이를 통해 중간에 제 3자가 서버를 위장하거나 조작하는것을 방지하고, 신뢰할 수 있는 서버와의 통신을 보장합니다.

웹 사이트에서 HTTPS를 사용하고 보안 도메인을 갖는 가장 일반적인 방법은 SSL(Secure Sockets Layer) 또는 TLS(전송 계층 보안) 인증서를 얻는 것입니다. HTTPS 프로토콜을 사용하기 위해서는 인증기관(CA)으로부터 SSL 인증서를 발급 받아야 합니다.

SSL(Secure Socket Layer)는 네트워크상의 두 디바이스 또는 애플리케이션 간에 보안 연결을 생성하는 통신 프로토콜 또는 규칙 세트입니다. 인터넷을 통해 보안 인증이나 데이터를 공유하기 전에 신뢰를 구축하고 상대방을 인증하는것이 중요합니다. SSL 애플리케이션 또는 브라우저가 모든 네트워크에서 안전하고 암호화된 통신 채널을 만드는 데 사용할 수 있는 기술입니다.
TLS(Transport Layer Security)는 기존 SSL 취약성을 수정하는 업그레이드된 SSL 버전입니다.

HTTPS 통신과정

Client와 Server간 HTTPS 프로토콜을 통해 데이터를 주고 받기 위해서는 아래와 같은 과정을 거쳐야 합니다.

TCP 3-way handshake : 데이터 통신을 시작하기 위해서 Client와 Server가 연결을 설정하는 과정
SSL/TLS handshake : SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 통해 보안된 연결을 설정하는 과정
데이터 교환 : 암호화 과정을 거친 데이터를 Client와 Server 사이에 주고받는 과정

이제 각각의 과정에 대해서 자세히 알아 보도록 하겠습니다.

TCP 3-way handshake

TCP 3-way handshake란 TCP(Transmission Control Protocol) 통신에서 Client/Server 와 Server 간의 연결을 생성하는 과정입니다. 쉽게 말하면 사람이 서로 악수를 하듯이 두 기기간 연결이 제대로 이뤄졌는지 3단계로 하여 연결을 맺는 과정이라고 할 수 있습니다.

TCP 3-way handshake 흐름

TCP 3-way handshake의 과정을 그림으로 나타내면 아래와 같습니다.

Client가 Server에 SYN 보내기
1. Client가 Server에 랜덤 SYN(synchronize) 숫자 packet을 서버로 보냅니다.
Server가 Client에 SYN-ACK 보내기
1. Server가 SYN을 잘 받았다면, 그에 대한 응답으로 SYN-ACK 패킷을 Client에 보냅니다.
Client가 Server로 ACK 보내기
1. Client가 서버의 시퀀스 번호를 확인하는 ACK 번호를 서버에 보냅니다.

이 후에도 추가적은 절차를 거쳐 데이터를 주고 받는데 본 글은 HTTPS의 프로토콜을 이해하는데 목적이 있으므로 자세한 내용은 여기를 참고하시는것이 좋을것 같습니다.

SSL/TLS handshake

SSL/TLS handshake는 두 기기간 안전한 통신을 위해 "클라이언트와 서버 간에 암호화 및 인증 프로토콜"을 설정하는 과정입니다. TCP 3-way handshake가 기기간 연결에 목적이 있었다면, SSL/TLS handshake는 데이터를 주고 받기전 인증과 암호화에 더 목적이 있다고 할 수 있습니다.

SSL/TLS handshake 흐름

SSL/TLS handshake 흐름은 아래의 그림과 같습니다.

Client Hello(Client가 서버에 접속)
1. Client측에서 랜덤 데이터를 Server로 전송합니다.
2. Client가 사용 가능한 암호 알고리즘 목록을 보내서 서버와 데이터를 주고받을 때 사용할 암호화 방식을 제공합니다.
Server Hello(Server가 Client에게 응답)
1. Server측에서 랜덤데이터를 생성하여 Client로 전송합니다.
2. Client가 제공한 암호 알고리즘 목록 중 Server가 사용할 암호화 방법을 전송합니다.
Certificate(인증서) 전달
1. Server는 3rd Party에서 인증받은 인증서를 Client에게 전달합니다. Server로부터 인증서를 받은 Client는 CA(Certificate Authority)에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인합니다. 만일 CA 리스트에 인증서가 없다면 사용자에게 경고 메세지를 출력합니다.
2. 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화 합니다. 복호화에 성공했다면 인증서는 CA의 공개키로 암호화된 문서임을 암시적으로 알 수 있기 때문에 서버를 믿을 수 있게 됩니다.
3. 인증서 안에는 아래와 같은 내용을 담겨져 있습니다.
  1. 도메인 정보
    1. 인증서가 발급된 도메인 이름
    2. 이를 통해 Client는 해당 웹사이트가 신뢰할 수 있는 사이트 인지 확인 할 수 있습니다.
  2. 발급 기관 정보
    1. 인증서를 발급한 인증 기관(Certificate Authority) 정보를 포함합니다.
    2. CA는 해당 웹사이트의 신뢰성을 보장합니다.
  3. 공개키 정보
    1. 이 공개키는 데이터를 암호화 하는데 사용됩니다.
  4. 유효기간
    1. 유효기간 인증서의 유효기간이 명시됩니다.
    2. 만료된 인증서는 더 이상 사용할 수 없습니다.
  5. 서명 알고리즘
    1. 인증서의 서명에 사용된 알고리즘이 포함됩니다.
    2. 이를 통해 인증서의 무결성을 확인할 수 있습니다.
Server Hello Done
1. 서버는 자신이 보낼 정보를 모두 보냈음을 Client에 알립니다.
Client Key Exchange
1. Client는 암호화에 사용할 키를 만들기 위한 자료를 생성합니다. 이를 Pre Master Secret이라고 합니다.
  Client는 1번과 2번에서 주고받은 난수를 활용하여 Pre Master Secret를 생성 후 인증서에 담아 전달된 서버의 Public키로 암호화 하여 서버에 전달합니다.
Change Cipher Spec
Finish
Change Clipher Spec
Finish
1. Server는 Client가 전송한 pre master secret 값을 자신의 비공개키로 복호화 합니다. 이로서 서버와 클라이언트가 모두 pre master secret값을 공유하게 되었습니다. 그리고 서버와 클라이언트 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret값으로 만듭니다.
2. master secret은 session key를 생성하는데 이 session key 값을 이용해서 server와 client는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받습니다.

이러한 일련의 과정을 모두 거치고 나면 데이터를 주고 받을 암호화 키를 생성했기 때문에 Client와 Server의 handshake 단계의 종료를 서로 알리게 됩니다.

데이터 교환(Session 단계)

이 단계는 실제로 Server와 Client가 데이터를 주고 받는 단계입니다. 이 단계의 핵심은 서로 주고받는 데이터를 상대방에게 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화 한다는 점입니다.

Client는 데이터 패킷을 보낼 때 암호화 과정을 진행합니다. 먼저, MAC키를 통해 데이터의 MAC값을 구합니다. 이는 데이터가 변조되었는지 확인하기 위함입니다. 이후 MAC값과 데이터를 Session키로 암호화 합니다. 암호화된 데이터를 헤더와 함께 서버로 전달합니다.
Server는 Session키를 통해서 데이터와 MAC 값을 추출합니다. 데이터를 자신의 MAC키로 MAC값을 계산하고, 이를 Client로부터 받은 값과 비교합니다. 만약 MAC값이 같다면 데이터가 변조되지 않았다는 의미이고, MAC 값이 다르다면 중간에 제 3자에 의해 값이 변경되었다고 판단 할 수 있습니다. 검증을 마치면 데이터를 어플리케이션으로 올려 보냅니다.

데이터 전송이 끝나면 SSL 통신이 끝나게 되고, 이 때 통신에서 사용한 대칭키인 session key를 폐기하게 됩니다.

이렇게 HTTP와 HTTPS의 정의 및 프로토콜에 대해서 알아봤습니다.

혹시라도 정정할 내용이나 추가적으로 필요하신 정보가 있다면 댓글 남겨주시면 감사하겠습니다.

오늘도 Jindory 블로그에 방문해주셔서 감사합니다.

[ 참조 ]

HTTP와 HTTPS의 차이는 무엇일까? (velog.io)

velog

velog.io

HTTP vs HTTPS: Comparison, Pros and Cons, and More (hostinger.com)

HTTP vs HTTPS: Comparison, Pros and Cons, and More

We explain why you should switch to HTTPS and discuss the differences between HTTP vs HTTPS in terms of security, performance, and SEO.

www.hostinger.com