[Network] HTTP & HTTPS 개념 및 동작방식

HTTP와 HTTPS의 개념을 정리하고 HTTPS 동작 방식에 대해 이해해보자 ❕

 

 

 

1. HTTP (HyperText Transfer Protocol)

---

HTTP는 인터넷에서 *하이퍼텍스트를 전송하기 위한 통신 규약이며, 클라이언트/서버 간에 데이터를 주고 받기 위해 사용한다. 클라이언트가 HTTP 메시지 양식에 맞춰 요청을 보내면, 서버도 HTTP 메시지 양식에 맞춰 응답을 한다. HTTP는 주로 TCP/IP 프로토콜 위에서 작동하며 HTML 문서, 이미지, 오디오 등 거의 모든 형태의 데이터 리소스를 전송하는데 사용된다.

 

출처 : wikipedia

 

 

*하이퍼링크(Hyperlink), 하이퍼텍스트(Hypertext)?
하이퍼링크는 문서 안에서 특정 부분을 클릭했을 때 해당 위치로 이동할 수 있도록 만들어주는 기능이다.
하이퍼텍스트는 하이퍼링크를 통해 서로 연결된 문서를 말한다. 하이퍼링크를 클릭해 하이퍼텍스트를 이동해 다닐 수 있다.

 

 

출처 : https://raonctf.com/essential/study/web/layer

 

HTTP는 응용 계층(Application Layer)의 프로토콜로 사용되며 TCP/IP 위에서 작동한다. (`HTTP/3`은 UDP와 QUIC을 기반으로 동작한다)

URL을 확인했을 때 http://~처럼 되어있다면 HTTP 프로토콜을 사용해 통신을 수행한다는 뜻이다.

역사

• HTTP/1.0 : 메서드(GET, POST, HEAD), 헤더, 상태코드 추가. 기본적으로 한 연결당 하나의 요청을 처리. 
• HTTP/1.1 : 지속연결(keep-alive) 표준화. 헤더가 압축되지 않아 무거움.
• HTTP/2 (2015) : 멀티플렉싱, 헤더 압축, 서버 푸시 등 성능 개선. 많이 사용되는 버전
• HTTP/3 (2019~) : TCP 대신 UDP를 이용한 QUIC 프로토콜 사용

특징

• Client - Server 구조
  • HTTP 통신은 클라이언트와 서버로 나누어진 구조에서 이뤄진다.
  • 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 구조
• 무상태성 (Stateless)
  • 클라이언트와 서버 사이에 상태를 유지하지 않는다.
  • 서버는 클라이언트가 이전에 어떤 요청을 했는지 기억하지 않는다.
  • 기억해야 할 정보는 클라이언트가 가지고 있기 때문에 서버 스케일 아웃(Scale-Out)에 유리하다.
    (아무 서버에게 호출해도 클라이언트가 보낸 정보를 가지고 데이터를 처리하면 되기 때문)
• 비연결성 (Connectionless)
  • 클라이언트 요청에 대해 서버가 응답을 마치면, 맺었던 TCP/IP 연결을 끊는다.
  • 서버의 자원을 아낄 수 있다.
    (클라이언트 요청에 대한 응답을 하고 바로 연결을 끊는다면 한정적인 서버의 자원으로 더 많은 클라이언트 요청에 대해 대응할 수 있기 때문)
  • 동일한 클라이언트 요청에 대해 매번 새로운 연결을 맺어야 한다는 점에서는 비효율적이다.
• 상태 코드 (Response Code)
  • 클라이언트 요청에 대한 서버의 응답에 대해 알려주는 기능으로, 100~500번대 숫자로 나타낸다.
  • 상태코드를 토대로 클라이언트는 적절한 대응을 할 수 있다.

HTTP 비연결성의 한계와 극복
HTTP의 비연결성 모델은 매번 연결을 끊고, 다시 연결할 때 마다 TCP handshake가 발생되므로 다소 비효율적이었다. HTTP/1.1부터는 지속 연결(Persistent Connections)로 이를 해결하고 있다. 클라이언트는 서버와 연결을 한 다음 일정 시간 동안 유지함으로써, 필요한 자원을 모두 다운받을 때까지 연결이 종료되지 않고 요청/응답이 반복된다.

 

구성

출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

 

HTTP 메시지는 사람이 읽을 수 있는데 보통 Method, Path, Version, Headers, Body 등이 포함된다. HTTP는 암호화 되지 않은 평문 데이터로 전송되기 때문에 메시지 안에 중요한 정보를 주고 받을 경우 누군가 탈취해 정보를 확인할 수 있는 문제가 있다. 이를 해결하기 위해 HTTPS가 등장하게 되었다.

 

 

 

2. HTTPS (HyperText Transfer Protocol Secure)

---

 

출처 : https://seopressor.com/blog/http-vs-https

 

HTTPS는 HTTP에 암호화 인증을 추가한 프로토콜이다. 기본 구성과 사용 목적 등은 HTTP와 비슷하지만 데이터를 주고받는 과정에 보안 요소가 추가되어 보다 안전하다. SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 통해 데이터를 암호화한다. (TLS는 SSL 프로토콜이 발전하여 이름이 변경된 것)

출처 : https://feel5ny.github.io/2019/08/26/HTTP_004_01

HTTP는 TCP와 직접 통신을 했지만, HTTPS에서 HTTP는 TCP와 직접 통신을 하지 않고 사이에 보안 계층을 두어 이를 통해 TCP와 통신한다.

 

 

비교

프로토콜	HTTP	HTTPS
url	http://	https://
보안	취약	안전
port	80	443
암호화	X	O
TLS	X	O (TLS는 응용계층과 전송계층 사이에서 동작)
비용	X	O

 

 

 

3. HTTPS 통신 흐름

---

HTTPS 통신에서 SSL 방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부르며, 공인인증기관의 경우 웹 브라우저는 미리 CA 리스트와 함께 각 CA의 공개키를 알고 있다.

 

 

암호화 방식

HTTPS는 통신 내용이 암호화되어 전송되는데, 이때 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다. 공개키 암호화 방식으로 대칭키(세션키)를 전달하고, 서로 공유된 대칭키를 이용해 데이터를 암복호화한다.

 

 

대칭키 암호화 방식

• 동일한 키를 사용해 암호화/복호화를 진행
• 키가 노출되면 위험하지만 연산 속도가 빠름

 

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

• 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용
  • 공개키는 모두에게 공개 가능한 키, 개인키는 나만 알고 있어야 하는 키
  • 공개키로 암호화하면 개인키로 복호화, 개인키로 암호화하면 공개키로 복호화 가능
• 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

 

 

HTTPS handshake 과정에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다. 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.
즉, 공개키는 클라이언트와 서버가 처음 연결을 성립하여 안전하게 세션키(대칭키)를 공유하는 과정에서 사용된다. 연결을 성립한 이후 데이터를 교환하는 과정에서는 빠른 연산 속도를 위해 세션키(대칭키)가 사용된다.

 

 

출처 : https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained

 

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

 

공개키는 누구나 얻을 수 있고 공개키를 알면 서버가 주는 데이터(Response)를 해독할 수 있기 때문에 보안상의 의미는 없다. 다만, 공개키로 해독이 가능했다는 것은 해당 서버의 개인키로 암호화되었다는 것이니까 해당 서버로부터 온 응답임을 보장할 수 있는 것이다.

 

HTTPS 통신 흐름

1. 서버 T를 만든 기업은 HTTPS를 적용하기 위해 공개키, 개인키를 만든다.
   신뢰할 수 있는 CA를 선택하고 공개키와 사이트정보를 전달한다.
2. CA기업은 CA기업의 이름과 T서버의 공개키, 공개키 암호화 방법 등의 정보를 담은 인증서를 만든다. 해당 인증서는 CA기업의 개인키로 암호화한다.
3. 이 인증서를 T서버에게 발급해준다.
4. CA기업은 웹 브라우저에게 CA기업만의 공개키를 제공한다.

 

 

5. 클라이언트는 T서버에 접속을 요청한다.
6. 요청 중 T서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면 T서버는 (3)에서 발급받은 인증서를 클라이언트에게 전달한다.
   (신뢰할 수 있는 CA기업의 공개키는 이미 브라우저가 알고 있다)
7. 브라우저는 CA기업 리스트를 탐색하면서 인증서에 적혀있는 CA기업의 공개키를 이용해 T서버의 공개키를 얻는다.
8. 브라우저는 T서버의 공개키로 세션키(대칭키)를 발급
9. 브라우저는 세션키를 보관하고, T서버의 공개키로 세션키를 암호화해 T서버에 전송
10. T서버는 암호화된 세션키를 T서버의 개인키로 복호화하여 세션키를 얻음
11. 이제 클라이언트와 서버는 통신할 때 세션키로 암호화/복호화를 진행하여 데이터를 주고받음

참고자료 😃
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-http%EB%9E%80-%ED%8A%B9%EC%A7%95-%EB%AC%B4%EC%83%81%ED%83%9C-%EB%B9%84%EC%97%B0%EA%B2%B0%EC%84%B1/

https://inpa.tistory.com/entry/HTTP-%F0%9F%8C%90-%EB%B0%B1%EC%97%94%EB%93%9C-%EB%A1%9C%EB%93%9C%EB%A7%B5-HTTP%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94#http%EC%9D%98_%ED%86%B5%EC%8B%A0_%EA%B5%AC%EC%A1%B0

https://mangkyu.tistory.com/98

https://seo.tbwakorea.com/blog/https-http/

https://jeong-pro.tistory.com/89