HTTP-HTTPS.md

HTTP / HTTPS

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다.

출처: MDN - HTTP 개요

HTTP

HTTP(Hypertext Transfer Protocol)는 위에 MDN에서 설명한 것과 같이 웹에서 통신을 함에 있어 가장 중요한 프로토콜중 하나이다.

여기서 프로토콜이란? 통신을 위해 상호간에 정의한 규칙 정도로 설명이 가능할 것 같다.

여러 나라 사람들이 대화를 할 때, 자신들만의 언어로만 말을 한다면? 아에 대화 자체가 이루어지지 않는다! 그렇기에 하나의 공용어나 해당 언어로 통역을 해줄 통역사를 놓고 회담을 진행하듯이 컴퓨터 간에 대화를 하기 위해 우리는 프로토콜이란 것을 만들어 사용하게 된 것이다.

HTTP은 OSI 7계층에서 애플리케이션 계층의 프로토콜로서, 신뢰가 가능한 프로토콜이면 무엇이든 가능하다.(이론상) 보통 TCP 혹은 TLS를 통해 전송된다.

HTTP의 특징

• 간단하다!

  HTTP는 사람이 읽을 수 있으며 간단하게 고안이 되었다. HTTP/2가 기존 1.1에 비해 많이 복잡해지긴 했지만, 여전히 HTTP 메시지를 프레임별로 캡슐화하여 간결함을 유지한다.

• 확장이 가능하다.

  HTTP/1.0에서 소개된 HTTP 헤더는 HTTP를 확장하고 실험하기 쉽게 만들어 주었다. 클라이언트와 서버가 새로운 헤더에 대해 간단한 합의를 한다면, 언제든지 새로운 기능을 추가 할 수 있다.

• 상태는 없지만, 세션은 존재!

  HTTP는 상태를 저장하지 않는다.(Stateless) 동일한 연결 상에서 두개의 요청 사이에는 연결고리는 존재하지 않는다. HTTP의 핵심은 상태가 없는 것이지만, HTTP 쿠키를 사용하면 상태가 존재하는 세션을 만들어 준다. 헤더 확장성을 사용하여, 동일한 컨텍스트와 상태를 공유하기 위해 각각의 요청들에 세션을 만들 수 있도록 HTTP 쿠키가 추가된다.

• HTTP와 연결

  데이터를 주고 받기위해 서로 연결하는 과정은 애플리케이션 계층이 아닌 전송 계층에서 이루어지므로 HTTP의 역할에서 벗어난다. 따라서 HTTP는 연결에 있어 신뢰할 수 있거나, 손실이 없는(최소한으로 오류는 표시) 방법을 요구할 수 밖에없다.

  인터넷 상에서 가장 일반적인 전송 프로토콜은 UDP와 TCP가 존재한다. UDP는 알다시피 손실이 일어날 수 있는 전송 프로토콜이므로 HTTP는 TCP 표준에 의존한다.

HTTP의 제어

앞서 말한 HTTP의 특징중 하나인 확장이 가능하다는 덕분에 계속해서 웹의 많은 기능들을 제어할 수 있도록 진화해왔다. 과연 어떤 기능들이 생겨났고 어떻게 제어를 한다는 것일까?

• 캐시

  HTTP로 문서가 캐시되는 방식을 제어가능하다. 서버는 캐시 대상과 기간을 클라이언트와 프록시에게 지시할 수 있으며, 클라이언트에서는 저장된 문서를 무시하라고 중간에 존재하는 캐시 프록시에게 지시를 할 수 있다.

• Origin 제약사항 완화

  스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저에서는 웹 사이트 간의 엄격한 분리를 강제한다.(Same-origin policy) 하지만 이를 HTTP 헤더를 통해 완화 시킬 수 있으며, 이덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크 할 수 있다.

• 인증

  기본 인증은 HTTP를 통해 WWW-Authenticate 또는 유사한 헤더를 통해 제공되거나 HTTP 쿠키를 통해 특정 세션을 설정하여 이루어질 수 있다.

• 프록시와 터널링

  보통 HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 되는데, 모든 프록시가 HTTP만 동작이 가능한 것이 아닌 좀더 저수준에있는 SOCKS 프로토콜 등도 동작이 가능하도록 해준다.

• 세션

  쿠키의 사용으로 클라이언트의 상태를 서버에 전송 할 수 있게 된다. 이는 HTTP가 상태가 없는 프로토콜이지만, 세션을 만들어 줄 수 있게 한다.

HTTP/2

웹은 초기 모습과는 달리 매우 복잡한 동작을 요구로하는 모습으로 진화되었다. 그렇기에 더 많은 데이터들이 더 많은 요청으로 주고 받는 데이터의 양들이 많아지게 되었고, HTTP/1.1로 만은 그 많은 양을 감당하기에 힘든 감이 존재한다. HTTP의 기본 동작 방식을 보며 왜 힘든지에 대해 알아보자.

이전 HTTP 동작방식

1.0

HTTP/1.0에서 클라이언트는 추가적인 요청을 하기 위해서는 TCP 연결을 끊고 다시 연결을 맺고 해야만 했다. 따라서 시간과 자원 측면에서 많은 비용이 소요되었다.

1.1

HTTP/1.0의 단점을 보완하기 위해 지속적인 연결, 파이프 라이닝을 도입하여 계속해서 연결을 맺고 끊는 것으로 인한 오버헤드를 줄이게 되었다.

지속적인 연결(Persistent Connection) 을 했을 경우에는 클라이언트에서 응답을 받지 않더라도 해당 연결을 통해 여러 요청으 보낼 수 있으므로 이전보다 성능이 많이 개선되었다.

출처 : HTTP/1.1 의 HTTP Pipelining 과 Persistent Connection 에 대하여

연결을 끊지 않는 것만으로도 많은 개선이 되었지만, 또 다른 단점은 여전히 존재했다. 아래의 왼쪽 그림(no pipelining)과 같이 HTTP/1.1의 경우 기본적으로 하나의 Connection당 하나의 요청을 처리하게 설계를 해놓아 동시 전송이 불가능하며 요청과 응답이 순차적으로 이루어진다.

출처 : HTTP/1.1 의 HTTP Pipelining 과 Persistent Connection 에 대하여

이런 점을 보완하기 위해 1.1에서는 Pipelining이라는 기법을 통해 요청을 연속해서 보낼 수도 있다. 이를 통해 하나의 Connection에서도 다수의 요청과 응답을 처리하여 네트워크 지연을 줄일 수 있어졌다.

하지만, 이는 단순히 요청들에 대한 응답 처리를 미루는 방법을 사용한 것이므로 각 응답에 대한 처리는 순차적으로 처리가 되어, 첫번째 응답의 처리가 늦을 수록 뒤에 있는 응답은 지연될 수 밖에 없다. 이를 Head Of Line(HOL) Blocking라고 부르며 Pipelining의 큰 문제점이다.

또한 헤더에 많은 설정 값들을 넣어 요청/응답 바디보다 더 큰 값을 전송하는 경우가 존재했다.

이와 같이 HTTP/1.0, 1.1의 단점들을 해결하기 위한 방법들을 개발해왔으나 근본적인 문제는 여전히 해결할 수 없었다. 그렇기에 구글에서는 지연율 관점에서 HTTP를 고속화한 SPDY(NAVER D2 SPDY)라 불리우는 프로토콜을 구현하였는데, 이는 HTTP/2가 세상에 나오게 될 수 있는 발판을 마련했다.

HTTP/2 특징

"HTTP/2는 프로토콜을 완전히 다시 작성하는 것이 아닌, 성능에 초점을 두고 있다." - HTTP/2 공식 Github

과연 어떠한 특징들로 HTTP/1.1의 단점들을 보완하고 있을까?

• Multiplexed Streams

  한 커넥션으로 동시에 여러개 메시지를 주고 받을 수 있으며, 응답은 순서에 상관 없이 Stream으로 주고 받는다. 이는 1.1에서 Connection Keep-Alive, Pipelinig의 개선점이다.

• Stream Prioritization

  Multiplexed Streams 라는 특징으로 응답 순서를 상관없이 Stream으로 주고 받고 있다고 했다. 만약, HTML에 CSS가 존재하는데 CSS의 응답이 지연이 되어 렌더링이 늦어진다면 문제가 발생할 수 있다. 따라서, 2에서는 리소스간에 의존관계(우선순위)를 설정할 수 있게 하여 해당 문제를 해결한다.

• Server Push

  1.1에서는 HTML 문서를 요청하고 응답을 받은 후에 파싱을 하며 필요한 리소스를 재요청을 했다고 한다면, 2에서는 클라이언트가 요청을 하지 않더라도 미리 리소스를 주는 방법으로 클라이언트와의 커넥션을 최소화 할 수 있도록 한다. 이는 PUSH_PROMISE라고 부르며, PUSH_PROMISE를 통해 서버가 전송한 리소스에 대해서는 클라이언트는 요청을 하지 않는다.

• Header Compression

  방대한 헤더 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하는데 이를 HPACK 압축 방식이라 부른다. 또한, 여러번의 요청에서 Static/Dynamic Header Table 개념을 사용하여 중복된 헤더를 검출하여 전체를 보내는 것이 아닌 헤더 정보값만 전송하게 된다.

HTTPS

HTTPS는 HTTP + Secure Socket 으로 기존 HTTP로 데이터를 주고 받는 것에서 SSL(Secure Socket Layer) 프로토콜을 통해 데이터 암호화를 추가한 것이다.

TLS(Transport Layer Security)로 알고있는 사람이 있을텐데 이는 SSL의 업그레이드 버전이며 표준화가 되면서 이름이 변경되었다. 하지만 아직도 TLS보다는 SSL이란 이름으로 더 널리 사용되고 있다.

왜 HTTPS를 사용할까?

HTTP로 데이터를 주고 받을 때는 주로 평문(text)을 사용하는데, 이는 굉장히 위험한 일이다.

예를들어 어떠한 사이트에 로그인을 한다고 하자. 로그인을 하기 위해서 클라이언트는 서버에게 아이디, 비밀번호를 넘기게 된다. 이 과정에서 해커가 해당 데이터를 중간에 가로챌 수 있으며, 암호화가 되어있지 않아 굉장히 치명적이다.

따라서, 이를 극복하고자 HTTP에 SSL이라는 프로토콜을 사용하여 데이터에 암호화를 진행한다.

SSL(TLS)

암호화 방식

SSL에서는 보안과 성능상의 이유로 두가지 암호화 기법을 혼용해서 사용하는데, SSL이 어떻게 동작하는지에 대해서 알기 위해서는 해당 암호화 기법을 알고 있어야 한다.

• 대칭키

  대칭키는 말 그대로 암호화/복호화 시에 동일한 키를 사용하는 암호화 방식을 말한다. 즉, Jongnan이라는 키를 사용하여 암호화를 했다면, Jongnan을 사용하여 복호화를 한다.

• 공개키

  대칭키에서의 큰 단점은 같은 키를 사용하고 있기때문에 해커가 키를 얻는다면, 쉽게 복호화를 할 수 있다는 것이다. 이 때문에 나온 암호화 방식이 바로 공개키 방식이다.

  공개키 방식은 두개의 키를 가지게 되는데, 하나는 암호화를 하는 키, 또 다른 하나는 복호화를 하는 키이다. 이 때 자신만 가지고 있는 키를 비공개키, 타인에게 제공되는 키를 공개키라고 한다. 공개키를 제공 받은 타인은 공개키를 이용하여 정보를 암호화 하고 이를 전송한다. 암호화된 정보를 비공개키로 복호화하는 방식으로 데이터를 주고 받는다. 이 과정에서 공개키가 해커에 의해 탈취 당해도 암호화만 가능하므로 대칭키에 비해 안전하다.

  해당 방식을 응용해서 다음과 같이 사용할 수 도 있다.

  • 비공개키의 소유자가 비공개키를 이용해서 정보를 암호화 한 뒤에 공개키와 함께 전송
  • 공개키를 이용하여 암호화된 정보를 복호화

  이와 같은 방식으로 데이터를 전송하는데, 중간에 해당 키가 탈취당하여 정보가 노출이 될 수 있다.

  그런데 왜 암호화를 하는 것인가?

  이 방식의 주요 목적은 신원을 보장하는데 있다. 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개 키에 의해 암호화 되었다는 것을 의미한다. 즉, 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것이다.

  이가 바로 전자 서명이다.

SSL 인증서

SSL 프로토콜을 사용하기 위해서는 인증서가 필요하다. 이는 제 3자(CA)가 클라이언트와 서버간의 통신을 보증해주는 전자 문서이다. 이러한 인증서는 크게 2가지로 구분되어 진다.

• 서비스 정보(인증서를 발급한 CA, 서비스 도메인 등)

  클라이언트가 접속한 서버가 적절한 서버인지에 대한 내용

• 서버측 공개키(공개키 내용, 공개키 암호화 방법)

  통신에 사용될 공개키와 암호화 방식

이 내용들은 CA에 의해 비공개키를 사용하여 암호화를 하고, 서버는 이를 가지고 있으면서 클라이언트에게 증명하기 위해 전달한다. 이후 클라이언트는 이 인증서가 신뢰할 수 있는 것인지를 검증한 뒤 통신을 시작하게 된다.

CA

이러한 인증서를 제공하는 기업들이 있는데 이를 CA(Certificate authority) 혹은 Root Certificate라고 부른다. CA는 아무 기업이나 할 수 있는 것이 아닌 신뢰성이 높은 기업들만 참여가 가능하다. 하지만 개발 혹은 사적인 목적을 위해 SSL의 암호화 기능을 사용한다면 직접 CA의 역할도 할 순 있지만 경고 문구는 사라지지 않는다.

CA list

브라우저에서는 인증서를 이해하는데 CA 리스트를 가지고 있으며 미리 파악을 하고 있다. 즉, 공인된 CA만 해당 리스트에 들어갈 수 있으며 브라우저는 CA 공개키를 이미 알고 있는 셈이다.

인증 과정

1. 웹 브라우저가 서버에 접속할 때, 서버는 먼저 인증서를 클라이언트에게 제공

2. 브라우저는 이 인증서가 CA 리스트에 있는지 확인

3. 포함이 되어있다면 CA의 공개키를 이용하여 인증서를 복호화

   브라우저에 존재하는 공개키로 인증서를 복호화 할 수 있다는 것은 해당 인증서가 CA의 비공개키로 암호화 되었다는 것을 의미하므로 해당 사이트는 안전하다란 것을 의미

SSL 동작 방식

앞서서 SSL이 동작하기 이전에 일어나는 일들을 알아보았다. 위 과정들이 모두 끝나고 나서 통신을 하게 되는데 어떤 방식으로 하게되는지 알아보자.

# Handshake

TCP에서 연결을 하기 위해 3way-handshaking을 사용하듯 SSL에서도 이를 통해 연결을 맺지만, 위에서 언급한 인증 과정이 추가로 이루어지게 된다.

1. 클라이언트가 서버에 접속(Client Hello)

   • 클라이언트측에서 생성한 랜덤 데이터
   • 클라이언트가 지원하는 암호화 방식들(지원하는 암호화 방식이 다를 수 있기 때문)
   • 세션 아이디(기존 세션을 재활용 하기 위해)

2. 서버에서는 이에 대한 응답을 보냄(Server Hello)

   • 서버측에서 생성한 랜덤 데이터
   • 서버가 선택한 클라이언트의 암호화 방식
   • 인증서

3. 클라이언트는 서버의 인증서를 확인

   • 브라우저에 저장되어있는 CA 리스트를 확인하며 인증서를 복호화
   • 서로 주고 받은 랜덤 데이터로 pre master secret이란 값을 생성(절대 노출 X)
   • pre master secret 값은 인증서 내부에 있는 공개키로 암호화하여 서버로 전송

4. session key 생성

   • 서버에서는 암호화된 pre master secret를 자신의 비공개키로 복호화

   • 서버와 클라이언트는 일련의 과정을 통해 master secret 값으로 변경

   • master secret 값으로 session 키를 생성(이로 데이터 암호화)

   • 클라이언트와 서버는 Handshake 단계의 종료를 서로에게 알림

# Session

세션 단계는 실제로 클라이언트와 서버가 데이터를 주고 받는 단계이다. 이 때 중요한 점은 주고 받는 데이터는 전 단계에서 생성한 session key를 이용하여 암호화/복호화 한다.

왜 한가지 방식을 선택해서 사용하지 않고 두가지 방식을 섞어서 사용하는 것일까?

대칭키 방식만 사용한다면 위에서 언급한 것과 같이 노출이 되었을 때, 엄청난 피해를 입을 수 있다. 그 반대로 공개키 방식으로만 사용한다면 대칭키 보다 더 복잡하므로 여러모로 비싼 비용을 내야한다. 그렇게 된다면 접속이 몰리는 서버의 경우 많은 비용을 지불해야한다.

따라서, 속도는 느리지만 안전한 공개키 방식으로 대칭키를 암호화하고, 실제 데이터의 경우 해당 대칭키를 이용해서 데이터를 주고 받는 것이다.

# Session 종료

데이터의 전송이 모두 완료 되었을시에 SSL 통신이 끝났음을 서로에게 알린다. 이 때 통신에 사용한 대칭키는 폐기한다.

---

Reference

• MDN - HTTP 개요
• HTTP/1.1 의 HTTP Pipelining 과 Persistent Connection 에 대하여
• 나만 모르고 있던 - HTTP/2
• HTTPS와 SSL 인증서 - 생활코딩