[네트워크] HTTP와 HTTPS

728x90

✔️ HTTP란?

HTTP는 HyperText Transfer Protocol의 약자로, 클라이언트/서버 모델을 따라 데이터를 주고 받기 위한 프로토콜이다. 인터넷 상에서 자원을 주고 받을 때 사용하는 통신 규약으로, 80번 포트를 사용한다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.

HTTP의 구조

HTTP은 애플리케이션 레벨(OSI 7계층)의 프로토콜로, TCP/IP 위에서 작동한다. 또한, HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

그러나 HTTP는 평문 데이터(텍스트)를 전송하는 프로토콜이므로,

누군가 네트워크에서 신호를 가로채면 내용이 노출될 수 있다는 보안 이슈가 존재한다.

이러한 보안 문제를 해결하기 위해 HTTPS가 등장하게 되었다.

✔️ HTTPS란?

HTTPS란 HyperText Transfer Protocol Secure의 약자로, HTTP에 데이터 암호화를 추가하여 보안성을 강화한 프로토콜이다. HTTP Secure라고도 불리는 HTTPS는 HTTP 레이어 바로 밑단에 SSL을 추가하여 인터넷 상에서 정보를 암호화한다. HTTP 메세지를 TCP로 보내기 전에 먼저 SSL에서 모든 데이터를 암호화하므로써, 공격에 취약한 HTTP와 달리, 데이터의 송수신 과정에서 데이터를 가로채려는 공격 등으로부터 대응할 수 있게 된다. 단, HTTPS는 애플리케이션 계층의 새로운 프로토콜이 아니며, HTTP 통신을 하는 소켓 부분은 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체하는 형태이다.

HTTPS는 443번 포트를 사용한다.

대칭키 암호화와 비대칭키 암호화

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용(혼용)한다.

각각의 암호화 방식은 여기에서 자세하게 확인할 수 있다. 여기서 비대칭키만 잠깐 다시 살펴보면,

비대칭키 암호화는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.

공개키: 모두에게 공개가능한 키
개인키: 나만 가지고 알고 있어야 하는 키

암호화를 공개키로 하느냐 개인키로 하느냐에 따라 얻는 효과가 다르고,

공개키와 개인키로 암호화하면 각각 다음과 같은 효과를 얻을 수 있다.

공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다 -> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다 -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션키란, 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.

문제는 이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐이고, 이 과정에서 비대칭키 방식이 사용된다.

정리하자면, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키 암호화 방식이 사용되는 것이고, 이후 데이터를 교환하는 과정에서는 빠른 연산 속도를 위해 대칭키 암호화 방식이 사용되는 것이다.

실제 HTTPS 연결 과정이 성립되는 흐름을 살펴보면 다음과 같다.

HTTPS 통신 흐름

클라이언트(브라우저)가 서버로 최초 연결을 시도한다.
서버는 공캐키(엄밀히는 인증서)를 브라우저에게 넘겨준다.
브라우저는 인증서의 유효성을 검사하고 세션키를 발급한다.
브라우저는 세션키를 보관하며, 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송한다.
서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻는다.
클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행한다.

HTTPS 인증서 발급 과정

앞선 HTTPS 통신 흐름에서 추가적으로 살펴봐야할 부분은 바로 서버가 비대칭키를 발급받는 과정이다.

서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야하는데, 일반적으로 인증된 기관(CA, Certificate Authority)에 공개키를 전송하여 인증서를 발급받는다. CA란 Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간 기업이다.

자세한 과정은 다음과 같다.

애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 생성한다.
신뢰할 수 있는 CA 기업을 선택한 뒤 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청한다(선택한 CA 기업에게 내 공개키 관리를 부탁하며 계약을 한다)
계약 완료된 CA 기업은 CA 기업의 이름, A 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
A 서버는 암호화된 인증서를 갖게 되고, 이후 접속을 시도하는 클라이언트에게 암호화된 인증서를 제공한다.
브라우저는 CA 기업의 공개키를 이용하여 인증서를 복호화한다. (CA 기업의 공개키는 브라우저가 이미 알고 있다. 세계적으로 신뢰할 수 있는 기업으로 등록되어있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것이다)
암호화된 인증서를 복호화하여 얻는 A 기업의 공개키로 세션키를 공유한다.

HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서를 발급한 경우 등)

이러한 경우, HTTPS 이지만, 주의 요함 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

인증서를 사용하지 않은 웹 서버의 경우 위 그림의 오른쪽처럼 '주의 요함' 이라는 문구가 출력되는데, 이는 데이터가 암호화되지 않은 채로 전송되고 있으며 네트워크에 존재할 수 있는 공격자가 스니핑, 스푸핑 등을 통해 패킷을 훔쳐볼 경우 데이터가 전부 유출될 수 있음을 뜻한다.

✔️ 기술 질문/예상 질문

HTTP 프로토콜에 대해 아는대로 설명해보세요

HTTP는 HyperText Transfer Protocol의 약자로, 클라이언트/서버 모델에 따라 데이터를 주고 받기 위해 사용하는 프로토콜입니다. HTTP는 애플리케이션 계층의 프로토콜로 TCP/IP 위에서 작동합니다. 또한 상태를 가지고 있지 않은 Stateless 프로토콜로, Method, Path, Version, Headers, Body 등으로 구성됩니다.

여기서 무상태성(Stateless)란, 연결이 해제됨과 동시에 서버와 클라이언트는 이전에 요청한 결과에 대해 잊어버려 '상태'를 유지하지 않는다는 의미입니다.

HTTP는 별도로 평문 데이터를 전송하기 때문에, 누군가 중간에서 네트워크를 가로챌 경우 내용이 노출될 수 있다는 보안 이슈가 존재합니다.

HTTP와 HTTPS의 차이에 대해 설명해보세요

HTTP는 인터넷 상에서 클라이언트와 서버가 자원을 주고받기 위한 통신규약으로, 텍스트로 자원을 주고받기 때문에 네트워크를 가로챈다면 내용이 유출되는 보안 이슈가 발생할 수 있습니다.

이를 해결하는 것이 HTTPS입니다.

HTTPS에 SSL 프로토콜을 사용해 정보를 암호화하는데, 메모리나 리소스를 더 많이 쓸 수 있다는 특징이 있습니다.

HTTPS가 동작하는 방식에 대해 설명해보세요

처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키 암호화 방식이 사용되고, 이후 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키 암호화 방식이 사용된다.

HTTPS 통신 흐름
1. 클라이언트(브라우저)가 서버 최초로 연결을 시도한다.
2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨준다.
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급한다.
4. 브라우저는 세션키를 보관하며, 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송한다.
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻는다.
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행한다.