HTTP / HTTPS

SooHyung Kim·2020년 9월 2일

HTTP(HyperText Tranfer Protocol)

인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜
- OSI 7 Layer의 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동되며 기본 포트는 80번을 사용
HTML, 이미지, 동영상, 오디오 등 어떤 종류의 데이터든 전송할 수 있도록 설계

작동 방식

클라이언트의 HTTP request를 보내면 서버에서 처리하여 클라이언트에 HTTP response를 보내는 형식

특징

Connectless : 클라이언트와 서버가 서로 연결하여 Request와 Response가 발생하면 연결이 끊어짐
Stateless : 클라이언트와 서버 간에 주고 받은 정보는 Connectless가 되면 그 이후에 알 수 없음
- 만약 로그인과 같이, 정보를 지속적으로 유지해야하는 경우는 어떻게 해야할까? 답은 Cookie!

데이터 포맷

HTTP Request 구조

HTTP request는 크게 3부분으로 구성
1) Start LIne
2) Headers
3) Body

Start Line

HTTP의 첫 라인으로 3부분으로 구성되어 있음
- HTTP Method
  - 해당 request가 의도한 action을 정의
  - GET, POST, PUT, DELETE, OPTIONS 등이 있음
  - 주로 GET, POST가 쓰임
    
    1) GET
    1. 서버로부터 데이터를 그대로 받아 올 때 주로 사용하는 메소드
    2. 데이터 생성/수정/삭제 없이 받아오기만 할 때 사용
    3. 가장 간단하고 많이 사용되는 HTTP 메소드
    4. 데이터를 받아올 때 사용되기 때문에 request에 body를 안보내는 경우가 많음
    2) POST
    1. 데이터를 생성/수정/삭제 할 때 주로 사용되는 메소드
    2. 데이터를 생성/수정할 때 많이 사용하기 때문에 대부분의 경우 request body를 안보내는 경우가 많음
    3) PUT
    1. POST와 비슷하며 데이터를 생성할 때 사용되는 메소드
    2. 최근에는 POST에 밀려 사용 빈도가 줄어듦
    4) DELETE
    1. 특정 데이터를 서버에서 삭제 요청할 때 쓰이는 메소드
    2. 최근에는 POST에 밀려 사용 빈도가 줄어듦
- Request target
  - 해당 request가 전송되는 목표 uri
  - ex. /login, /user 등
- HTTP Version
  - 사용되는 HTTP 버전을 1.0, 1.1, 2.0 등이 있음

Headers

해당 request에 대한 추가 정보를 담고 있는 부분으로 key:value형태로 되어 있음
headers 역시 general headers, request headers, entity headers로 구성
headers에는 아래의 정보가 담겨 있음(주로 메타 정보)
- Host : 요청이 전송되는 target의 host url (ex. google.com)
- User-Agent : 요청을 보내는 클라이언트에 대한 정보(ex. 웹브라우저 정보)
- Accept : 해당 요청이 받을 수 있는 응답(response) 타입
- Connection : 해당 요청이 끝난 후 클라이언트와 서버가 계속해서 커넥션을 유지할 것인지를 지시하는 부분
- Content-Type : 해당 요청이 보내는 메세지 body의 타입(ex. application/json)
- Content-Length : 메세지 body의 길이

    Accept: */*
    Accept-Encoding: gzip, deflate
    Connection: keep-alive
    Content-Type: application/json
    Content-Length: 257
    Host: google.com
    User-Agent: HTTPie/0.9.3

Body

해당 request의 실제 메세지 / 내용
Body가 없는 request도 많음
(GET request들은 대부분 body가 없는 경우가 많음)

   POST /payment-sync HTTP/1.1

  Accept: application/json
  Accept-Encoding: gzip, deflate
  Connection: keep-alive
  Content-Length: 83
  Content-Type: application/json
  Host: intropython.com
  User-Agent: HTTPie/0.9.3

  {
      "imp_uid": "imp_1234567890",
      "merchant_uid": "order_id_8237352",
      "status": "paid"
  }

HTTP Response 메시지

Request와 마찬가지로 3부분으로 구성

1) Status line
2) Headers
3) Body

Status Line

Response의 상태를 간략하게 나타내주며 3부분으로 구성

1) Http version

2) Status code : 응답 상태를 나타내는 숫자 코드(200, 301, 400 등)

3) Status text : 응답 상태를 간략하게 설명해주는 부분(Not Found 등)
- 200 OK : 문제가 잘 실행 되었을 때 보내는 코드
- 301 Moved Permanenely : 해당 URI가 다른 주소로 바뀌었을 때 보내는 코드
- 400 Bad Request
  - 해당 요청이 잘못된 요청일 때 보내는 코드
- 401 Unauthorized : 로그인, 회원 가입 등 유저가 해당 요청이 필요하다는 것을 나타내는 코드
- 403 Forbidden : 유저가 해당 요청에 대한 권한이 없다는 뜻(유료 컨텐츠 등)
- 404 Not Found : 요청된 uri가 존재하지 않는다는 뜻
- 500 Internal Server Error : 서버에서 에러가 났을 때 사용하는 코드(백엔드 에러)

Headers

Request의 header와 동일하나, 예외적으로 user-agent 대신에 server가 사용

Body

Request와 마찬가지로 데이터를 전송할 필요가 없을 경우 body가 비어있게 됨

HTTP/1.1 404 Not Found

Connection: close
Content-Length: 1573
Content-Type: text/html; charset=UTF-8
Date: Mon, 20 Aug 2018 07:59:05 GMT

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>

HTTPS(HTTP + Secure)

기존 HTTP 평문데이터의 위.변조 공격을 방어할 수 있도록 설계되었으며, 공인받은 인증서를 통해 신뢰성을 판단
- 이에 보안을 강화하기 위해 SSL 위에 HTTP를 통과시키는 HTTPS 방식이 도입됨

SSL

SSL은 전자상거래에서 데이터 보안을 위해 개발한 통신 레이어로, OSI 7계층에서 표현 계층에 속한 프로토콜로 응용 계층의 아래에 있기 때문에 어떤 데이터라도 암호화해서 보낼 수 있음

SSL 인증서

SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서로, 클라이언트가 서버에 접속한 직후 서버에서는 클라이언트에게 이 인증서의 정보를 전달하고 클라이언트는 인증서가 신뢰할 수 있는 것인지 검증

암호화

SSL의 핵심은 암호화로 '대칭키' 방식과 '공개키' 방식을 혼용하여 사용하고 있음

대칭키 방식

먼저, 키는 암호화를 할 때 사용하는 일종의 비밀번호와 같으며, 키를 모른다면 암호화된 내용을 풀어낼 수가 없음
대칭키는 동일한 키로 암호화와 복호화를 같이할 수 있는 방식을 말함
- 그러나, 대칭키 방식은 전달 과정에서 대칭키가 유출될 경우 암호의 내용이 그대로 복호화 될 수 있다는 치명적인 단점을 가짐

공개키 방식

대칭키의 단점을 보완하여 등장한 것이 공개키 방식으로, 두 개의 키로 암호화를 하는 방식
- A라는 키로 암호화된 데이터는 B로 복호화가 가능하고, B라는 키로 암호화된 데이터는 A로 복호화할 수 있다는 것이 핵심 아이디어
- 두 개의 키는 각각 비공개키, 공개키로 지정하게 되는데 비공개키는 자신만 가지고 있으며 절대로 공개되어서는 아니되는 키이며, 공개키는 타인에게 공개되는 키

SSL 통신 과정

SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용
클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받음
SSL 통신은 3단계 과정으로 진행 : 악수 -> 세션 -> 세션종료

1. 악수 (handshake)

실제 데이터를 주고 받기 전에 클라이언트와 서버는 Handshake를 통해 서로 상대방이 존재하는지, 또 상대방과 데이터를 주고 받기 위해서는 어떤 방법을 사용해야하는지를 파악
먼저 클라이언트가 서버에 접속하며, 이 단계를 Client Hello라고 칭함
- 클라이언트 측에서 생성한 랜덤 데이터, 클라이언트가 지원하는 암호화 방식을 서버에 전달
서버는 Client Hello에 대한 응답으로 Server Hello를 진행
- 서버 측에서 생성한 랜덤 데이터, 서버가 선택한 암호화 방식, 인증서를 클라이언트에 전달
클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인
- 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화
  
  => 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이기 때문에 인증서를 전송한 서버를 신뢰할 수 있게 됨
클라이언트는 Hello 단계에서 전송한 클라이언트와 서버가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성
- 이 때 생성된 키는 실제 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해서 사용되며 대칭키로써의 역할을 함
이제 클라이언트는 생성한 pre master secret 키 값을 서버에 전달해야하는데, 이 때 사용하는 것이 바로 서버로부터 인증서와 함께 받은 서버의 공개키!
- 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화
이제 서버와 클라이언트가 모두 pre master secret 키 값을 공유하게 되었으며, 일련의 과정들을 통해 pre master secret 키는 session key로 새로 생성
그리고 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알림

2. 세션

세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계
핵심은 정보를 상대방에게 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화 한다는 점

공개키 방식이 더 확실한 보안을 가짐에도 대칭키를 조합하는 이유는?

공개키 방식이 많은 컴퓨터 파워를 사용하며, 많은 접속이 몰리는 서버는 매우 큰 비용을 지불해야 하기 때문

3. 세션종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고 통신에서 사용한 대칭키인 세션키를 폐기

SooHyung Kim

Slow and steady win the race

이전 포스트

HTTP / HTTPS

HTTP(HyperText Tranfer Protocol)

작동 방식

특징

데이터 포맷

HTTP Request 구조

Start Line

Headers

Body

HTTP Response 메시지

Status Line

Headers

Body

HTTPS(HTTP + Secure)

SSL

SSL 인증서

암호화

대칭키 방식

공개키 방식

SSL 통신 과정

1. 악수 (handshake)

2. 세션

공개키 방식이 더 확실한 보안을 가짐에도 대칭키를 조합하는 이유는?

3. 세션종료

[TIL] Domain Name Server

0개의 댓글