[네트워크] OSI 7계층(HTTP 2편 & HTTPS)

이전 시간에 HTTP 프로토콜에 대해 알아보았습니다.

HTTP 프로토콜이 중요한 만큼 내용도 많은데요! 오늘도 HTTP 프로토콜에 대해 알아보도록 하겠습니다!

혹시 HTTP 1편을 보고 싶으시다면 아래 포스팅을 확인해주세요!

[네트워크] OSI 7계층(HTTP 1편)

 

---

 

HTTP

- Stateless

이전 시간에 언급했던 Connectionless의 특징 때문에 요청에 대한 응답이 끝나면 웹 서버와 웹 브라우저의 연결도 끊기고 웹 서버가 웹 브라우저의 정보 또한 잊게 됩니다. 이를 Stateless라고 합니다. 이러한 특징 때문에 웹 브라우저가 이전과 똑같은 요청을 하면 웹 서버는 똑같은 요청을 처리하기 위해 동일한 과정을 거치게 됩니다.

웹 서버가 웹 브라우저에 대한 정보를 저장하지 않아도 되기 때문에 서버의 부담은 줄어들지만, 로그인 정보처럼 꼭 저장되어야 할 정보까지 저장하지 않으면 문제가 발생할 수 있습니다.

이를 해결하기 위해 3가지 방식을 사용합니다.

 

(1) 쿠키

쿠키는 웹 브라우저가 저장하는 데이터입니다. 웹 서버는 쿠키를 생성하여 웹 브라우저에 정보를 전송하고, 웹 브라우저는 쿠키 저장소에 받은 쿠키를 저장합니다. 쿠키는 key-value 형태로 구성되어 있으며, 웹 브라우저는 이후 웹 서버에 요청을 할 때마다 헤더에 쿠키를 실어 함께 전송합니다. 쿠키를 통해 웹 서버와 웹 브라우저는 필요한 값을 공유하고 상태를 유지할 수 있습니다.

하지만 쿠키는 치명적인 단점이 있는데, 네트워크를 통해 전달되기 때문에 중간에 유출의 위험이 있습니다. 따라서 보안상의 이유로 사용자의 개인정보인 아이디와 비밀번호를 쿠키에 저장하지 않고 세션이나 토큰처럼 다른 방식을 사용합니다.

 

(2) 세션

세션 또한 웹 브라우저의 상태를 저장합니다. 세션과 쿠키의 다른 점은 세션은 웹 서버에 저장된다는 점입니다.

웹 브라우저마다 하나의 세션을 가지며(정확히는 세션 ID만 웹 브라우저에 저장합니다.), 웹 서버는 세션 ID를 통해 어떤 웹 브라우저가 가지고 있는 세션인지 구별합니다. 웹 서버에 연결할 때 세션 ID를 보내 웹 서버가 어떤 세션을 사용해야 하는지 알려줍니다.

 

로그인을 하는 과정을 통해 세션 ID를 주고 받는 과정을 살펴보겠습니다.

HTTP - Session

로그인 요청을 하면 서버에서 세션을 생성하여 세션 ID를 웹 브라우저에 돌려줍니다. 웹 브라우저는 세션 ID를 쿠키에 저장해놨다가 다음번 요청할 때마다 세션 ID가 담긴 쿠키를 헤더에 저장해 웹 서버에 요청을 합니다. 웹 서버는 헤더에 담긴 세션 ID를 통해 세션 정보를 획득하여 어떤 웹 브라우저에서 요청을 보냈는지 확인할 수 있습니다.

 

(3) 토큰

토큰의 대표적인 방식으로는 JWT(Json Web Token)이 있습니다. 토큰 기반 인증 방식은 유저의 정보가 서버에 저장되지 않습니다. 또한 토큰은 암호화되어 있기 때문에 쿠키보다 보안에 대한 걱정이 줄어듭니다.

 

로그인하는 과정을 통해 토큰으로 어떻게 인증되는지 알아보겠습니다.

사용자가 로그인을 하면 서버에서는 세션 대신 토큰을 발급합니다. 웹 브라우저는 토큰을 local storage에 저장하거나 쿠키에 저장합니다. 웹 브라우저는 요청할 때마다 저장된 토큰을 헤더에 포함하여 보냅니다. 웹 서버는 매 요청 시 클라이언트로부터 전달받은 토큰 정보를 통해 웹 브라우저를 검증합니다.

 

---

 

- 버전

(1) HTTP 0.9

초기 버전의 HTTP를 구분하기 위해 0.9 버전이라고 부릅니다. HTTP 메시지가 단순하게 구성되어 있으며, 메서드도 GET만 존재했습니다. HTTP 헤더도 없고 파일만 전송할 수 있습니다.

 

(2) HTTP 1.0

HTTP 헤더가 도입되었고, 메서드의 종류도 GET, POST, HEAD 3가지로 구성되어 있습니다. 상태 코드도 추가되어서 웹 브라우저의 요청의 성공/실패 여부를 알 수 있습니다.

하지만 connection 하나당 요청 하나와 응답 하나만 처리 가능하다는 단점이 존재합니다.

 

(3) HTTP 1.1

오늘날 가장 많이 사용되는 HTTP 버전입니다. 메서드의 종류가 GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS 총 7가지가 사용됩니다.

HTTP 1.0의 단점을 보안한 프로토콜로 pipelining이 추가되었습니다. Pipelining은 앞에 보냈던 요청에 대한 응답을 기다리지 않고, 요청을 연속적으로 보낸 뒤에 요청 보낸 순서에 맞춰 응답을 기다리는 방식입니다. 하나의 connection에 여러 개의 요청이 들어 있을 뿐, 동시에 여러 개의 응답을 보내주는 것은 아닙니다. 또한 앞의 요청에 대한 응답이 너무 오래 걸리면 뒤에 보낸 요청은 block 된다는 단점이 존재합니다.

 

(4) HTTP 2.0

Multiplexing 기능이 추가되어 한번에 여러 개의 요청에 대한 여러 개의 응답을 보낼 수 있습니다. 그래서 HTTP 1.1의 단점인 block이 발생하지 않습니다.

HTTP - HTTP 버전

 

---

 

HTTPS

HTTPS는 HTTP보다 보안이 강화된 프로토콜입니다. HTTP는 데이터를 암호화하지 않기 때문에 그대로 노출되어 보안에 취약하다는 단점이 있습니다. 이를 보완하고자 만들어진 프로토콜이 HTTPS입니다.

HTTPS은 "HTTP + SSL"로 SSL이라는 보안 프로토콜과 함께 HTTP가 작동하는 프로토콜입니다. HTTPS의 동작 방식을 알아보기 전에 먼저 암호화에 대해 알아야 합니다.

 

- 암호화

암호화는 평문을 다른 사람들이 알지 못하게 암호화된 암호문으로 바꾸는 과정을 의미합니다. 또한 복호화는 암호문을 다시 평문으로 바꾸는 과정을 의미합니다.

(암호화 알고리즘 또한 깊이 들어가면 내용이 방대하기 때문에 간단히 설명하겠습니다.)

 

1) 대칭키

하나의 키로 암호화와 복호화 모두를 하는 암호화 방식입니다. 같은 키로 암호화, 복호화를 하기 때문에 대칭키라고 부릅니다.

만약 송신 측과 수신 측이 대칭키 방식으로 통신을 한다면 송신 측에서 사용하는 키를 수신 측도 알고 있어야 합니다. 따라서 복호화를 위해 송신 측에서 수신 측으로 키를 전달해야 하는데 키가 전달되는 과정에서 유출되면 안 되기 때문에 안전하게 전달하는 것이 매우 중요합니다.

 

2) 비대칭키(=공개키)

암호화는 공개키로하고 복호화는 개인키로 하는 방식을 공개키 방식이라고 합니다.

수신 측은 공개키와 개인키 두 개를 가지고 있고, 공개키는 다른 사람들이 확인할 수 있도록 공개해둡니다. 송신 측은 통신하기 전에 수신 측의 공개키를 보고 암호화하여 수신 측에 암호문을 보냅니다. 수신 측은 받은 암호문을 자기가 가지고 있는 개인키로 복호화합니다.

공개키 방식은 알고리즘의 계산 자체가 느리다는 단점이 존재합니다.

 

---

- SSL

SSL은 응용 계층과 전송 계층 사이에서 동작하는 보안 프로토콜로 클라이언트와 서버에 대한 인증 및 데이터 암호화를 수행하는 프로토콜입니다. TLS라고도 불리며 SSL과 이름만 다른 같은 프로토콜입니다.

 

(1) 인증서

SSL 인증서란 클라이언트와 서버간의 통신을 보증해주는 문서로 제3자인 공인된 CA(인증기관)로부터 발급받습니다. 클라이언트가 서버에 접속하면 서버에 설치된 인증서를 보고 신뢰할 수 있는지 판단 후에 데이터를 보내게 됩니다.

인증서 안에는 서비스의 정보, 공개키가 저장됩니다.

 

(2) 통신 과정

통신 과정은 핸드쉐이크 -> 세션 -> 세션 종료 순서대로 진행됩니다. 특징은 핸드쉐이크 과정에서 대칭키 방식과 공개키 방식을 사용한다는 점입니다.

HTTPS - SSL 통신과정

Step 1. client hello

클라이언트가 통신하려는 서버에 자신의 브라우저가 지원할 수 있는 암호화 방식 후보들과 랜덤 데이터를 생성해서 전송합니다.

 

Step 2. server hello

서버는 암호화 방식 후보들 중에 하나를 선정한 뒤 자신의 공개키가 담긴 인증서와 랜덤 데이터를 전송합니다. 

 

Step 3~5. 인증서 확인 pre master secret 암호화

클라이언트는 서버가 보낸 인증서가 CA에서 발급한 것인지 확인하고, 자신이 생성한 랜덤 데이터와 서버가 생성한 랜덤 데이터 중 하나씩 선택하여 대칭키로 활용될 pre master secret 키를 생성합니다.

클라이언트는 생성한 pre master secret를 인증서에 담긴 공개키를 통해 암호화하여 전송합니다.

서버는 자신의 개인키로 pre master secret를 복호화합니다.

 

Step 6~8. master secret 및 session key 생성

서버와 클라이언트 모두 pre master secret 키를 통해 master secret 키를 생성합니다. 이 master secret 키를 통해 session key를 생성하고, 이 session key가 서버와 클라이언트가 주고받는 데이터의 암호화 및 복호화에 사용되는 대칭키가 됩니다.

session key를 통해 데이터 전송이 완료되면 세션이 종료되면서 session key가 폐기됩니다.

 

---

 

오늘이 OSI 7계층에 대한 10번째 포스팅이었습니다. OSI 7계층에 대한 내용을 거의 포스팅한 것 같네요!

다음부터는 TCP/IP 4계층과 웹에 관한 다양한 내용을 포스팅할 계획입니다.