[네트워크] HTTP & HTTPS

네트워크

[네트워크] HTTP & HTTPS

위시리 2025. 2. 27. 17:07

HTTP 란

HTTP (Hypertext Transfer Protocol)
텍스트 기반의 통신 규약
인터넷에서 데이터를 주고 받을 수 있는 프로토콜
인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
클라이언트-서버 구조를 따르며 TCP / IP 위에서 작동

클라이언트 - 서버 구조란?

https://github.com/jmxx219/CS-Study/blob/main/network/HTTP.md

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

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

HTTP 흐름 (1.1 버전 기준)

1. TCP / IP 연결 열기

앞서 HTTP는 TCP / IP 위에서 작동한다고 했는데 이는 TCP의 특성을 이용하여 신뢰성을 확보하겠다는 것을 의미한다.

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

2. HTTP 메세지 전송 (클라이언트 → 서버 요청)

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

요청의 구성

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

3. 서버에 의해 전송된 응답 읽기 (서버 → 클라이언트)

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~

HTTP 상태 코드 : https://wishlee0204.tistory.com/310

HTTP의 전송되는 요청과 응답 구성을 보면 데이터를 암호화하지 않고 평문(텍스트)으로 전송되어 보안에 취약하다는 문제가 있다.

HTTP의 보안 문제점

도청 가능
- 평문으로 통신 : 헤더와 본문이 암호화되지 않음
- 네트워크에서 패킷을 가로채면 모든 내용(로그인 정보, 쿠키 등)을 확인 가능
- → 이를 해결하기 위해 통신자체를 암호화(HTTPS)하거나 데이터를 암호화하는 방법 등이 잇다.
- 데이터를 암호화하는 경우 수신측에서 복호화 과정 필요
데이터 변조 가능
- 완전성을 보장하지 않기 때문에 변조 가능
- 중간에 데이터를 변경하여 악성 코드 삽입 가능
- HTTPS에 메세지 인증 코드 (MAC), 전자 서명 등을 통해 변조를 방지
위장 가능
- 피싱 위험 → 클라이언트가 신뢰할 수 없는 서버에 연결할 수도 있음
- 통신 상대를 확인하지 않기 때문에 위장된 상대와 통신할 수 있다.

따라서 이러한 보안의 문제점을 보완해 줄 HTTPS가 등장하게 되었다.

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

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

HTTPS 는 HTTP (응용계층 프로토콜)와 TCP (전송 계층 프로토콜) 사이에 SSL / TLS 프로토콜을 거치도록 설계되었다.
- TLS(Transport Layer Security)를 사용하여 데이터를 암호화하고, 서버 인증서(SSL / TLS 인증서)를 통해 신뢰성 보장
데이터 전송 및 수신
→ (HTTP / TCP)가 SSL에게 데이터 전송
→ SSL이 데이터를 (암호화 / 복호화)
→ (TCP / HTTP)에게 전달
안전한 데이터의 전달이 브라우저와 웹 서버 사이 전달 구간에서 이루어진다.
- 보안 채널, 전송 보안이라고도 불림
HTTPS 통신 : 대칭키 방식과 공개키 방식 함께 사용
- 대칭키 방식 : 실제 데이터 암호화 시 사용
- 공개키 방식 : 서버에 대한 인증과 안전한 대칭키 전달 시 사용
SSL / TLS : 컴퓨터 네트워크 상에서 보안 통신을 제공하기 위해 설계된 프로토콜
- TLS는 SSL의 취약점들을 개선한 다음 버전의 프로토콜
- 특정 네트워크 계층에 속하는 프로토콜이 아닌, 독자적으로 존재하는 프로토콜
  - 응용 계층과 전송 계층 사이에 위치하여 보안 과정 수행
SSL / TLS 인증서 : SSL / TLS 기술을 수행하기 위해 웹 서버에 설치하는 것
- CA에서 검증된 서버에 대해 발급한 인증서
- SSL 인증서에는 주로 서버의 공개키가 들어가 있으며, 이는 나중에 데이터 교환을 위한 대칭키 전달에 사용
- 탑재된 보안 기술
  - 대칭키 / 비대칭키 암호화 방식
  - 통신 대상을 서로가 확인하기 위한 신분 확인
  - 믿을 수 있는 SSL 인증서를 위한 디지털 서명 및 인증 기관의 확인
  - 안전한 공개 키 전달, 공유를 위한 프로토콜
  - 암호화된 메세지의 변조 여부를 확인하는 메세지 무결성 알고리즘

HTTPS 통신 흐름

애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
신뢰할 수 잇는 CA 기업을 선택하고, 그 기업에게 나의 공개키 관리를 부탁하며 계약을 한다.
- CA 란 : Certificate Authority, 공개키를 저장해주는 신뢰성이 검증된 민간 기업
계약 완료된 CA 기업은 해당 기업의 이름, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
A서버는 암호화된 인증서를 갖게 되었다.
이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
클라언트가 main.html 파일을 달라고 A서버에 요청했다고 가정 -
HTTPS 요청이 아니기 때문에 CA 기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다.
클라언트가 A서버와 Handshaking 과정에서 주고 받는 난수를 조합하여 pre-master-secret-key 를 생성한 뒤, A서버의 공개키로 해당 대칭키를 암호화하여 서버로 보낸다.
A서버는 암호화된 대칭키를 자신의 개인키로 복호화하여 클라이언트와 동일한 대칭키를 획득
클라이언트, 서버는 각각 pre-master-secret-key를 master-secret-key로 만든다.
master-secret-key를 통해 session-key를 생성하고 이를 이용하여 대칭키 방식으로 통신
각 통신이 종료될 때마다 session-key를 파기

SSL은 어떤 방식으로 암호화를 할까? : by 대칭키 & 비대칭키

HTTPS는 대칭키 암호화, 비대칭키 암호화 방식을 모두 사용한다.

https://wishlee0204.tistory.com/309

SSH Handshake 과정 (TLS Handshake)

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

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

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

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

서버 (2) Server Hello 패킷 전송

클라이언트로부터 패킷을 받아 cipher suite 중 자신이 지원하는 것 중 하나를 선택해 Server Hello 에 담아 전송

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

서버 (2) Certificate

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

Certificate 패킷 정보

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

서버 (2) Server Key Exchange / ServerHello Done

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

클라이언트 (3) Client Key Exchange

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

클라이언트 (3) ChangeCipherSpec / Finished

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

서버 (4) ChangeCipherSpec / Finished

reference

https://chatgpt.com/c/67bed1c5-88d0-8002-ab10-6789db49ebfe

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/HTTP%20%26%20HTTPS.md

tech-interview-for-developer/Computer Science/Network/HTTP & HTTPS.md at master · gyoogle/tech-interview-for-developer

👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖. Contribute to gyoogle/tech-interview-for-developer development by creating an account on GitHub.

github.com

저작자표시