HTTP

HTTP(Hypertext Transfer Protocol)은 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을수 있는 프로토콜입니다.

클라이언트-서버 구조를 따르며 TCP/IP위에서 작동합니다.

클라이언트 - 서버 구조**

클라이언트(e.g 브라우저)가 HTTP메시지를 통해 서버에 요청하면 서버가 요청에 대한 결과를 만들어 클라이언트로 응답하는 구조를 의미합니다..

클라이언트와 서버는 개별적인 메시지 교환에 의해 통신
요청(requests) : 클라이언트에 의해 전송되는 메시지
응답(responses) : 요청에 대해 서버에서 응답으로 전송되는 메시지

<!-- - 특징 - 간단함 - HTTP 메시지 사람이 읽을 수 있음 (HTTP/2 이전) - HTTP 메시지를 프레임별로 캡슐화해 간결함 유지 (HTTP/2) - 확장 가능한 프로토콜 - HTTP헤더를 통해 언제든지 새로운 기능 추가 가능 - 상태는 없지만 세션은 있음 - HTTP는 상태를 저장하지 않음(stateless) - 하지만 쿠키를 통해 상태가 있는 세션을 만들도록 함 - 어플리케이션 계층의 프로토콜 - 이론상 신뢰 가능한 전송 프로토콜이란면 무엇이든 사용 가능 - 실제로는 TCP 혹은 TLS(암호화된 TCP 연결)를 통한 전송

약점
- 암호화 되지 않은 평문 통신으로 도청 가능
- 통신하려는 상대를 확인하지 않음 -->

TCP/IP

TCP/IP는 OSI 7 Layers에서 Layer3, Layer4를 다루는 프로토콜입니다.

TCP/IP를 사용하겠다는 것은 IP주소 체계를 따르고 TCP의 특성을 이용해 신뢰성을 확보하겠다는것을 의미합니다. ( OSI Layers 참고 (opens in a new tab), 3-Way Handshake참고 (opens in a new tab), 4-Way Handshake참고 (opens in a new tab) )

HTTP의 흐름(1.1버전기준)

TCP 연결 열기
1. 클라이언트는 새 연결 열기, 기존 열결 재사용, 서버에 대한 여러 TCP연결을 열 수 있음

HTTP 메시지 전송 (요청)
```
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
```
요청의 구성
- Method : GET
  - 클라이언트가 수행하고자 하는 동작
- Path : /
  - 가져오려는 리소스의 경로
- Version of the protocal : HTTP/1.1
  - HTTP 프로토콜의 버전
- Headers Host: developer.mozilla.org Accept-Language: fr - 서버에 대한 추가 정보 전달하는 선택적 헤더들

서버에 의해 전송된 응답 읽기

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
 
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

응답의 구성

Version of the protocol : HTTP/1.1
- HTTP 프로토콜의 버전
Status code : 200
- 요청의 성공 여부과 그 이유를 나타내는 상태코드
Status message : OK
- 상태코드의 짧은 설명을 나타내는 상태 메시지
Headers : Date: 부터 끝까지

HTTPS

HTTPS(Hypertext Transfer Protocol Secure)은 서버에서 브라우저로 전송되는 정보가 암호화되지 않는 HTTP의 문제점을 SSL을 사용항 암호화한 프로토콜이다.

HTTPS : HTTP 프로토콜의 보안버전

HTTPS는 HTTP(응용계층 프로토콜)와 TCP(전송 계층 프로토콜) 사이에 SSL/TLS 프로토콜을 거치도록 설계
데이터 전송, 수신 시
- (HTTP/TCP)가 SSL에게 데이터 전송 시 SSL이 데이터를 (암호화/복호화)하여 (TCP/HTTP)에게 전달
안전한 데이터의 전달이 브라우저와 웹 서버 사이 전달 구간에서 이뤄짐
- 보안채널, 전송 보안이라고도 불림
HTTPS 통신

대칭키 방식과 공개키 방식 함께 사용
- 대칭키 방식
  - 실제 데이터 암호화 시 사용
- 공개키 방식
  - 서버에 대한 인증과 안전한 대칭키 전달 시 사용

SSL/TLS : 컴퓨터 네트워크 상에서 보안 통신을 제공하기 위해 설계된 프로토콜

TLS는 SSL의 취약점들을 개선한 다음 버전의 프로토콜
특정 네트워크 계층에 속하는 프로토콜이 아닌, 독자적으로 존재하는 프로토콜
- 응용계층과 전송계층 사이에 위치하여 보안과정 수행

SSL/TLS 인증서 : SSL/TLS 기술을 수행하기 위해 웹 서버에 설치하는 것

CA에서 검증된 서버에 대해 발급한 인증서
SSL 인증서에는 주로 서버의 공개키가 들어가 있으며, 이는 나중에 데이터 교환을 위한 대칭키 전달에 사용
탑재된 보안기술
- 대칭키/비대칭키 암호화 방식
- 통신 대상을 서로가 확인하는 신분확인
- 믿을 수 있는 SSL 인증서를 위한 디지털 서명 및 인증기관의 확인
- 안전한 공개키 전달,공유를 위한 프로토콜
- 암호화된 메시지의 변조 여부 확인하는 메시지 무결성 알고리즘

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

HTTPS는 대칭키 암호화, 비대칭키 암호화 방식을 모두 사용하고 있습니다.

[ 대칭 키 암호화 ]

똑같은 개인 키를 송・수신자가 공유하여 정보를 암호화・복호화 하는 것

대칭 키 : 어떤 정보를 암호화・복호화 할 때 사용하는 키가 동일한 경우

암호화 된 정보의 전달, 확인을 위해선 송・수신자 둘 다 같은 키를 가져야 함
- 어떤 정보가 대칭 키를 통해 암호화 되었을 시, 똑같은 키를 갖고 있는 사용자가 아닐 경우 해당 정보 확인 불가
키의 안전한 교환이 대칭 키 암호화 방식의 가장 중요한 부분
장점
- 암・복호화 과정이 단순
- 암・복호화 과정의 속도가 빠름 ⇒ 송신자와 수신자가 동일한 키를 가지고 있기 때문
단점
- 송・수신자 간 키 교환이 이뤄져야함
- 키 교환 과정 중 키 노출 위험
- 송・수신자가 늘어날수록 관리해야할 키의 증가로 관리의 어려움

[비대칭 키 암호화]

1개의 쌍으로 구성된 공개키/개인키로 암호화・복호화 하는 것 방식

비대칭 키 : 어떤 정보를 암호화・복호화 할 때 사용하는 키가 서로 다른 경우

암호화 방식
- 개인 키 암호화 방식 : 개인 키를 통해 암호화하여, 공개 키로만 복호화 가능 = 공개키는 모두에게 공개되어 있으므로, 인증된 정보임을 알려 신뢰성을 보장할수 있다.
  - 정보를 생산(송신)한 사람의 신원 정보 필요 시 사용
  - 데이터 제공자의 신원이 보장되는 ‘전자서명’ 등의 공인인증체계의 기본
- 공개 키 암호화 방식 : 공개키를 통해 암호화하여 개인키로만 복호화 가능
  - 정보 자체에 대한 암호화가 필요 시 사용
  - 대칭 키 암호화 방식에서 키 값 교환에 따른 문제를 해결한 방법
장점
- 단 하나의 공개 키를 사용함으로 모든 수신자와 개별 키를 만들 필요 없음
- 데이터 송신과정 중 키를 탈취 당하더라도 해당 키로 복호화가 불가능하기에 공개키 방식보다 안전
단점
- 암・복호화에 서로 다른 키를 사용하므로 대칭키와 비교해 느린 속도

HTTPS의 통신 방식

비대칭 키 암호화 (Asymmetric Encryption):
- 사용 시점: Handshake 초기에 서버와 클라이언트 간의 인증과 키 교환 단계에서 사용됩니다.
- 역할: 서버와 클라이언트는 공개 키와 개인 키를 사용하여 데이터를 암호화하거나 복호화합니다. 이 과정에서 비대칭 키 암호화가 사용되는 주된 목적은 보안 채널을 설정하기 위한 대칭 키(세션 키)를 안전하게 교환하는 것입니다.
- 구체적인 사용:
  - 서버는 자신의 인증서를 클라이언트에게 전송합니다.
  - 클라이언트는 서버의 공개 키를 사용하여 대칭 키를 암호화하고 서버로 전송합니다.
  - 서버는 자신의 개인 키를 사용하여 암호화된 대칭 키를 복호화합니다.
대칭 키 암호화 (Symmetric Encryption):
- 사용 시점: Handshake가 완료된 후, 실제 데이터를 주고받을 때 사용됩니다.
- 역할: 대칭 키 암호화는 빠르고 효율적인 데이터 전송을 위해 사용됩니다. Handshake 과정에서 교환한 대칭 키를 사용하여 클라이언트와 서버는 데이터를 암호화하여 전송합니다.
- 구체적인 사용:
  - 대칭 키는 양쪽에서 동일하게 공유되며, 이를 사용하여 모든 통신 데이터를 암호화하고 복호화합니다.

SSL Handshake 과정 (TLS Handshake)

기존의 TCP/IP 3Way Handshake 과정에서 보안을 담당하는 SSL과정이 추가되어 보안이 진행된다.

클라이언트: (1) Client Hello 패킷전송

클라이언트가 서버에 연결을 시도하며 Client Hello 패킷 전송

Client Hello 패킷 정보

브라우저가 사용하는 SSL/TLS 버전 정보
브라우저가 지원하는 암호화 방식 모음(cipher suite)
- 아래 내용을 패키지 형태로 묶어놓은 것
  - 안전한 키 교환, 전달 대상 인증, 암호화 알고리즘, 메시지 무결성 확인 알고리즘 방식
브라우저가 순간적으로 생성한 임의의 난수
이전에 SSL핸드셰이크가 완료된 상태일 경우, 그때 생성된 세션 아이디

서버: (2) Server Hello 패킷 전송

클라이언트로부터 패킷을 받아 Cipher Suite중 하나를 선택해 Server Hello에 담아 전송

Server Hello 패킷정보

브라우저의 암호화 방식 정보 중 서버가 지원하고 선택한 암호화 방식(이전과 달리 하나의 Cipher Suite가 포함됨을 볼수 있다.)
서버의 공개캐가 담긴 SSL 인증서
서버가 순간적으로 생성한 임의의 난수
클라이언트 인증서 요청(선택사항)

서버: (2) Certificate

자신의 SSL인증서가 포함된 Certificate패킷 전송

Certificate 패킷 정보

Server가 발행한 공개키(개인키는 서버가 소유)
클라이언트는 서버가 보낸 CA(인증기관)의 개인키로 암호화된 SSL인증서를 모두에게 공개된 공개키를 사용하여 복호화한다.
- 정상적 복호화 → CA발급 증명
- 등록된 CA 아님 or 가짜 인증서 → 브라우저에게 경고 보냄

서버: (2) Server Key Exchange / ServerHello Done

서버의 공개키가 SSL인증서 내부에 없을경우, 서버가 직접 전달한다는 뜻이다. 공개키가 SSL인증서 내부에 있다면 해당 패킷은 생략된다.

클라이언트: (3) Client Key Exchange

클라이언트는 데이터 암호화에 사용할 대칭키를 생성한 후 SSL인증서 내부에서 추출한 서버의 공개키를 이용해 암호화한 후 서버에게 전달한다. 여기서 전달된 대칭키가 SSL HandShake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭키다. 이제 키를 통해 클라이언트와 서버가 실제로 교화하고자 하는 데이터를 암호화한다.

클라이언트: (3) ChangeCipherSpec / Finished

ChangeCipherSpec패킷은 클라이언트와 서버 모두가 서로에게 보내는 패킷으로 교환할 정보를 모두 교환한 뒤 통신할 준비가 다 되었음을 알리는 패킷이다. Finished패킷을 보내어 SSL Handshake를 종료하게 된다.

서버: (4) ChangeCipherSpec / Finished

위와 동일

Ref

https://steady-coding.tistory.com/512 (opens in a new tab)

컨텍스트 스위칭 뷰