HTTP/HTTPS Protocol

wldbs._.·2024년 11월 28일

WEB-STUDY

목록 보기

2/9

< 참고 Reference >
AWS: HTTP와 HTTPS의 차이점은 무엇인가요?
Http와 Https 이해와 차이점 그리고 오해(?)
CLOUDFLARE: HTTP가 안전하지 않은 이유는? | HTTP와 HTTPS의 비교
CLOUDFLARE: 암호화란?
웹 브라우저의 렌더링이란?
HTTP와 HTTPS 차이
HTTP와 HTTPS의 개념과 차이
정보통신기술용어해설: HTTP
HTTPS 통신 과정 쉽게 이해하기
HTTP와 HTTPS의 차이점과 보안성
SSL 인증서 신청 및 설치 방법
CHATGPT

🌐 HTTP와 HTTPS란 무엇일까?

HTTP와 HTTPS는 인터넷에서 데이터를 주고받는 데 사용되는 응용 계층(Application Layer)의 프로토콜이다.
두 프로토콜은 웹 브라우저와 서버 간의 통신 방식을 정의하는데, 보안 측면에서 중요한 차이가 존재한다.

1. HTTP란

🌐 HTTP(HyperText Transfer Protocol)는
데이터를 텍스트 형태로 전송하는 기본 프로토콜이다.

특징

데이터를 암호화하지 않는다 → 누구나 통신 내용을 가로챌 수 있다
기본적으로 80번 포트를 사용한다
빠르고 가벼운 프로토콜이지만, 보안이 필요하지 않은 경우에 적합하다

한계

데이터가 암호화되지 않는다 → 민감한 정보를 주고받을 때 보안 위협에 취약하다 (예: 비밀번호)

1-1. HTTP의 동작 과정

HTTP는 클라이언트(주로 웹 브라우저)와 서버 간의 요청(Request)과 응답(Response)을 기반으로 동작한다.

동작 예시

1. 웹 브라우저에서 http://example.com/index.html 요청

2. 요청: 클라이언트가 GET /index.html 요청을 보냄.

요청 메시지의 구성 → 요청 메서드(GET/POST/PUT/DELETE), URL, HTTP 버전, Header, Body(PUT/POST의 경우)
사용자의 브라우저에서 생성된 아래 텍스트 섹션은 인터넷을 통해 전송되는데,
문제는 연결을 모니터링하는 모든 사람이 읽을 수 있는 일반 텍스트로 전송된다는 것!

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

3. 응답: 서버는 index.html 파일을 찾아서 클라이언트에게 보냄.

응답 메시지의 구성 → 상태 코드(요청 처리 결과, 200 OK, 404 NOT FOUND), HTTP 버전, Header, Body(요청한 리소스)

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024

<html>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

4. 렌더링: 클라이언트는 받은 HTML을 기반으로 화면에 표시.

웹페이지는 미리 만들어진 것을 가져오는 게 아니라, 실시간으로 그리는 것 → 그려지는 과정을 "렌더링"

5. 추가 요청: HTML에 포함된 이미지, CSS, JS 파일 등을 추가로 요청.

예시: 네이버 메인 홈페이지에서 F12

위 사진은 네이버 홈페이지에서 F12 개발자 도구를 활용해 네트워크 트래픽을 확인하는 과정 중 일부이다.
응답/요청 헤더를 캡처해보았다.

1-2. HTTP 요청-응답의 특징

🔍 1. 비연결성 (Stateless)

클라이언트가 요청을 보내고, 서버가 응답을 보내면 연결이 종료
요청-응답 작업이 끝나면 서버는 더 이상 클라이언트와 연결 상태를 유지하지 않음
- HTTP는 각 요청과 응답이 독립적으로 처리된다.
- 이전 요청에 대한 정보를 기본적으로 유지하지 않는다.
(쿠키, 세션 등을 사용해 상태를 유지할 수 있다.)

▷ 한 번 요청하고 응답을 받으면, 클라이언트와 서버는 서로 "더 이상 연결된 상태가 아니야!"라고 생각

🔍 2. 무상태성

서버는 이전 요청에 대한 정보를 기억하지 않음
매번 새로운 요청을 보낼 때, 클라이언트는 필요한 모든 정보를 다시 제공 (예: 요청 url, 쿠키 등)
클라이언트와 서버는 요청-응답 이후 연결 상태를 유지하지 않으며, 새 요청마다 새 연결을 수립한다.

▷ "서버는 이전 요청에서 무슨 일이 있었는지 몰라. 내가 뭘 요청했는지 매번 알려줘야 해!"

2. HTTPS란

🌐 HTTPS(HyperText Transfer Protocol Secure)는
HTTP에 SSL(Secure Sockets Layer)/TLS(Transport Layer Security)라는 암호화 계층을 추가한 프로토콜이다.

SSL/TLS는 전송 계층(Transport Layer) 위에서 동작하며, 응용 계층과 전송 계층 사이에서 데이터를 암호화하고 보안을 제공

특징

데이터가 암호화되어 → 네트워크 상에서 통신 내용을 보호한다
기본적으로 443번 포트를 사용한다
클라이언트와 서버 간에 데이터 전송 중 도청, 변조, 위조를 방지한다
브라우저 주소창에 자물쇠 아이콘이 표시되어 보안이 강화된 연결임을 알린다

장점

민감한 정보를 안전하게 전송할 수 있다
신뢰할 수 있는 사이트라는 이미지를 제공한다

왜 사용할까?

🔍 데이터 보호: 개인정보, 비밀번호, 금융 정보 등의 민감한 데이터를 보호한다
🔍 사용자 신뢰 구축: HTTPS를 사용하는 웹사이트는 사용자가 더 신뢰할 가능성이 높다
🔍 규제 준수: 일부 산업(예: 금융, 의료)에서는 HTTPS 사용이 필수이다

2-1. TLS/SSL

TLS/SSL은 HTTP의 특성을 보완하기 위해 추가되는 보안 계층이며, HTTP와는 동작 방식이 다르다.

1. TLS/SSL의 연결 유지

세션을 통해 클라이언트와 서버 간의 보안 연결을 유지
한번 TLS 핸드셰이크를 통해 세션이 설정되면, 해당 세션이 지속되는 동안에는 암호화된 데이터 교환이 가능
- 세션: 클라이언트와 서버 간의 하나의 대화 상태를 유지하기 위한 과정/정보
  = 클라이언트가 서버에 접속한 이후부터 접속이 종료될 때까지의 상태를 추적 [like 놀이공원 팔찌]

따라서 TLS 자체는 연결성을 유지하며, 비연결적인 HTTP와는 다르다.

2. TLS/SSL에서의 상태 관리

TLS는 상태를 유지
세션 키, 암호화 알고리즘, 인증 정보 등이 핸드셰이크 후 세션 내에서 유지 → 이를 통해 효율적인 데이터 전송과 보안이 가능

HTTP와 달리, TLS는 세션 재사용(Session Resumption) 등을 통해 상태를 일시적으로 유지할 수 있다.

✅ 핵심: TLS 핸드셰이크는 처음 연결 때만 발생하며, 이후 세션 재사용으로 빠른 연결이 가능하다.

완전히 새로운 연결 상황이 아니면, 매번 핸드셰이크가 반복되지 않는다.

HTTP는 여전히 비연결적이고 무상태적이지만, TLS가 그 위에 보안 계층으로 동작하며, 연결성과 상태를 제공!

2-2. HTTPS의 동작 과정

클라이언트가 처음 HTTP 요청을 보내기 전에, HTTPS 연결을 설정하기 위한 SSL/TLS 핸드셰이크 과정이 먼저 진행된다.
이 과정에서 클라이언트와 서버는 서로 인증하고, 안전한 세션키를 공유한 후에야 요청이 처리된다.

🔑 HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있다.

HTTPS 연결 과정에서는 서버와 클라이언트 간에 세션키를 교환
- 세션키: 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키
세션키를 클라이언트와 서버가 교환하는 과정에서 비대칭키 사용
- 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키 사용
- 이후에 데이터를 교환하는 과정에서 빠른 속도를 위해 대칭키 사용

🔑 세부 과정

클라이언트(브라우저)가 서버로 최초 연결 시도
서버는 공개키(=엄밀한 인증서)를 브라우저에게 넘겨줌
브라우저는 인증서의 유효성 검사 & 유효하면 세션키(대칭키) 발급
브라우저는 서버의 공개키로 세션키를 암호화하여 서버로 전송
서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
클라이언트와 서버는 동일한 세션키를 공유 → 데이터를 전달할 때 세션키로 암호화/복호화 진행

✅ 비대칭키는 세션키 교환용, 대칭키는 데이터 통신용
✅ HTTPS는 클라이언트와 서버 간 TLS 핸드셰이크 후, 세션키 공유가 완료된 상태에서 요청과 응답을 처리

클라이언트와 서버는 HTTPS 연결을 설정하기 위해 TLS 핸드셰이크 과정을 먼저 수행
핸드셰이크 과정에서 세션키를 공유한 후에야 클라이언트의 HTTP 요청이 암호화된 채로 서버에 전달되고, 서버는 이를 처리
요청과 응답은 모두 세션키를 사용한 대칭키 암호화로 안전하게 전송

2-3. HTTPS의 발급 과정

서버는 일반적으로 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받는다.

🔑 인증서에는 A 기업의 공개키가 포함되어 있으므로, A 기업의 공개키라고 봐도 무방하다.
🔑 또한 브라우저에는 인증된 CA의 정보들이 사전에 등록되어 있어
인증된 CA의 인증서가 아닐 경우에는(= 인증서가 유효하지 않은 경우) NOT SECURE로 브라우저에서 보여지게 된다.

즉, HTTPS는 TLS(/SSL)를 사용하여 HTTP 요청과 응답을 암호화하므로, 공격자는 텍스트 대신 무작위로 보이는 문자를 보게 된다.

🔍 모든 HTTP 요청과 응답이 이 세션 키로 암호화되므로, 통신을 가로채는 사람은 일반 텍스트가 아닌 임의의 문자 문자열만 볼 수 있다.

2-4. HTTPS 발급 세부 과정

✅ 1. A기업이 HTTP 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키 생성

A기업은 공개키-개인키 쌍을 생성 (사용자가 직접 생성)
- 공개키: 클라이언트(브라우저)에 제공할 키
- 개인키: 서버만 알고 있어야 하는 비밀 키
이 공개키-개인키 쌍은 비대칭키 암호화를 위해 사용

✅ 2. CA에 인증서 발급 요청

A기업은 공개키와 자신의 도메인, 회사 정보 등을 포함한 CSR(Certificate Signing Request) 파일을 생성하여, 인증 기관(CA)에게 제출
CA는 인증서를 발급하는 대가로 비용을 청구

✅ 3. CA가 인증서를 생성하고 CA의 개인키로 서명하여 제공

CA는 제출받은 CSR의 정보를 확인
A기업의 도메인 소유권, 회사의 신뢰성 등을 확인
CSR 파일의 공개키와 A기업 정보를 기반으로 X.509 표준 형식의 인증서를 생성
CA는 자신의 개인키로 인증서에 디지털 서명을 추가한 뒤, A기업에게 이를 제공

✅ 4. A기업이 인증서를 서버에 설치 및 제공

A기업은 서버에 발급받은 인증서를 설치
클라이언트(브라우저)가 HTTPS 요청을 보내면, 서버는 클라이언트에게 이 인증서를 제공

✅ 5. 브라우저가 인증서를 검증

클라이언트의 브라우저는 서버가 제공한 인증서를 검증
CA의 공개키는 브라우저에 미리 설치(where? 사전 신뢰된 인증서 저장소)되어 있음
브라우저는 CA의 공개키로 인증서의 디지털 서명을 복호화하여, 인증서의 무결성을 확인
인증서가 유효하다면, 브라우저는 인증서에서 서버의 공개키를 추출

✅ 6. 브라우저가 서버의 공개키를 사용해 세션키를 공유

인증서를 통해 얻은 서버의 공개키를 사용하여 세션키를 암호화한 후 서버에 전송
서버는 자신의 개인키로 암호화된 세션키를 복호화
이후 클라이언트와 서버는 동일한 세션키를 사용해 데이터를 암호화/복호화하며 안전한 통신을 진행

2-5. 암호화 & 인증서

HTTPS는 HTTP 프로토콜에 SSL/TLS 암호화 계층을 추가한 형태이다.

보안 강화를 위한 주요 기능
🔍 암호화 Encryption: 데이터가 클라이언트와 서버 사이에서 이동 중에 노출되지 않도록 암호화
🔍 인증 Authentication: SSL/TLS 인증서를 통해 서버가 신뢰할 수 있는 대상임을 보장
🔍 데이터 무결성 Data Integrity: 데이터가 전송 중에 변조되지 않았음을 확인

SSL은 과거에 사용되던 데이터 암호화 프로토콜 → TLS는 SSL의 업그레이드 버전으로, 현재 널리 사용되는 보안 표준

우리가 흔히 "SSL 인증서"라고 부르지만, 실제로는 대부분 TLS 프로토콜을 사용

예시: 구글 인증서 메뉴

위 이미지는 구글 인증서를 보여주는 창인 것 같다
인증서 발급 기관과 공개키, 인증서를 보여준다

예시: 네이버 메인 홈페이지에서 F12

위 이미지는 네이버 페이지의 보안에 대해 알려주는 창인 것 같다.
HTTPS 설정과 인증서, 연결 인증 등등에 대해 위에서 알아본 내용이 보인다.

3. HTTP vs HTTPS

특징	HTTP	HTTPS
보안	암호화 없음	SSL/TLS로 암호화
속도	상대적으로 빠름	암호화로 인해 약간 느림
포트	80번	443번
신뢰성	보안 취약	신뢰할 수 있는 통신 제공
주소 표시	`http://` 로 시작	`https://` 로 시작
사용 사례	비보안 정보 전송 (일반 콘텐츠 등)	민감한 정보 전공 (로그인, 결제 등)

4. 결론

HTTP는 간단하고 빠르지만 → 보안이 취약하다
HTTPS는 보안을 강화해 → 데이터 보호에 적합한 프로토콜이다

특히, 민감한 정보를 다루거나 사용자의 신뢰를 얻고자 하는 경우 → HTTPS를 사용하는 것이 필수적이다.

현재 웹 환경에서는 HTTPS가 사실상 표준으로 자리 잡았으며, 대부분의 웹사이트는 HTTPS🌐를 기본으로 채택한다.

HTTP는 데이터를 일반 텍스트로 전송하지만, HTTPS는 SSL/TLS를 통해 암호화된 데이터를 전송한다.
HTTPS는 서버와 클라이언트 간에 인증서 교환과 암호화 키 설정을 위한 절차가 추가된다.

wldbs._.

공부 기록용 24.08.05~ #LLM #RAG

이전 포스트

Web Basic Concept

다음 포스트