[Network] HTTP & HTTPS

jiny·2026년 2월 15일

computer science network

Computer Science

목록 보기

12/16

1. HTTP (HyperText Transfer Protocol)

✨ 기본 개념

HTTP는 웹에서 클라이언트와 서버 간에 리소스(HTML, JSON, 이미지 등)를 주고받기 위한 가장 기초적인 애플리케이션 계층 프로토콜이다.
기본적으로 80번 포트를 사용하며, 클라이언트(브라우저)가 요청을 보내면 서버가 응답하는 요청/응답(Request/Response) 구조로 동작한다.

✨ HTTP 메시지 구조

HTTP 통신은 다음과 같은 정형화된 메시지 형식을 따른다.

구성 요소	설명
시작 라인 (Start Line)	요청 시에는 메서드(GET, POST 등)와 URL, 응답 시에는 상태 코드(200, 404 등)가 포함된다.
헤더 (Header)	메시지 본문의 크기, 타입, 인증 정보 등 통신에 필요한 부가 정보를 담는다.
공백 라인 (Empty Line)	헤더와 본문을 구분하기 위한 필수적인 빈 줄이다.
본문 (Body)	실제 전송할 데이터(HTML, JSON, 이미지 등)가 담기는 곳이다.

✨ HTTP의 주요 특징

비연결성 (Connectionless)
- 개념: 클라이언트가 요청을 보내고 서버가 응답을 마치면 즉시 연결을 끊는 방식이다.
- 장점: 서버의 연결 유지 부담을 줄여 더 많은 클라이언트의 요청을 처리할 수 있다.
- 단점: 매번 새로운 연결(3-Way Handshake)을 맺어야 하므로 오버헤드가 발생한다.
  - 보완: HTTP/1.1부터는 Keep-Alive 옵션을 통해 일정 시간 동안 연결을 유지하여 성능을 개선했다.

무상태성 (Stateless)
- 개념: 서버가 클라이언트의 이전 상태(로그인 여부 등)를 기억하지 않는다.
- 의미: 모든 요청은 독립적이며, 서버는 요청에 필요한 모든 정보를 매번 새로 받아야 한다.
- 해결: 상태 유지가 필요한 서비스(장바구니, 로그인 등)는 쿠키(Cookie)나 세션(Session), 토큰(JWT) 등을 활용해 보완한다.

텍스트 기반 프로토콜
- 개념: 사람이 읽을 수 있는 텍스트 형태로 통신한다.
- 장점: 디버깅이 쉽다.
- 단점: 보안에 취약하다.

✨ 주요 통신 메서드 및 상태 코드

주요 메서드 (Methods)
- GET: 리소스 조회 (데이터를 URL에 포함하여 전송)
- POST: 리소스 생성 (데이터를 본문에 담아 전송)
- PUT: 리소스 전체 수정
- DELETE: 리소스 삭제

상태 코드 (Status Codes)
- 2xx (Success): 요청 성공 (예: 200 OK)
- 3xx (Redirection): 요청 완료를 위해 추가 동작 필요
- 4xx (Client Error): 클라이언트 오류 (예: 404 Not Found)
- 5xx (Server Error): 서버 오류 (예: 500 Internal Server Error)

✨ HTTP의 발전 과정

버전	핵심 문제 및 해결	특징	전송 계층
HTTP/1.1	기본	- Keep-Alive: 매번 연결 끊지 않고 재사용 - Pipelining: 요청을 미리 보냄 (단, 앞 요청 처리가 늦으면 뒤도 다 밀리는 HOL Blocking 문제 발생)	TCP
HTTP/2.0	성능 개선	- Multiplexing: 한 연결로 여러 데이터를 동시에 스트리밍 (HOL Blocking 해결) - Header Compression: 중복 헤더를 압축해서 전송량 감소 - Server Push: 클라이언트가 요청 안 해도(CSS, JS 등) 미리 보내줌	TCP
HTTP/3.0	속도 혁신	- QUIC 프로토콜: TCP 대신 UDP 사용 - 0-RTT: 연결 설정 시간(Handshake)을 획기적으로 단축 - TCP의 고질적인 지연 문제를 근본적으로 해결	UDP (QUIC)

✨ HTTP의 보안 취약점과 한계

HTTP는 텍스트 기반의 평문 통신(Plain Text)을 하기 때문에 보안상 매우 취약하다.

GET /login?id=user&pw=1234 HTTP/1.1
Host: example.com

위와 같은 요청이 그대로 네트워크에 노출된다.

스니핑 (Sniffing): 네트워크 경로상의 누구나 패킷을 가로채서 아이디, 비밀번호 등 민감한 정보를 그대로 읽을 수 있다.
중간자 공격 (MITM): 클라이언트와 서버 사이에서 데이터를 가로채 내용을 수정하거나 가짜 정보를 주입할 수 있다.
신원 확인 불가: 내가 접속한 사이트가 진짜 네이버인지, 해커가 만든 가짜 사이트인지 확인할 방법이 없다.

2. HTTPS (HyperText Transfer Protocol Secure)

✨ 기본 개념

HTTPS는 HTTP의 하부 계층에 SSL/TLS 프로토콜을 더해 보안을 강화하여, 전송되는 모든 데이터를 암호화한다. 기본 포트는 443번이다.

✨ SSL/TLS란?

SSL (Secure Sockets Layer): 1990년대 넷스케이프사에서 처음 개발했다. 하지만 보안 취약점이 발견되어 현재는 더 이상 사용되지 않는다.
TLS (Transport Layer Security): SSL의 보안 결함을 수정하고 개선하여 나온 표준 프로토콜로, TLS 1.2, TLS 1.3이 주로 사용된다.
현재 상황: 기술적으로는 TLS를 사용하지만, 관습적으로 여전히 'SSL' 또는 'SSL/TLS'라고 혼용해서 부르는 경우가 많다.

✨ HTTPS의 3대 보안 핵심 (CIA Triad)

HTTPS는 다음 세 가지 요소를 통해 안전한 통신을 보장한다.

보안 요소	설명	구현 방법
기밀성 (Confidentiality)	제3자가 데이터를 읽을 수 없도록 암호화한다.	대칭키 암호화 (예: AES)
무결성 (Integrity)	전송 중 데이터가 변조되지 않았음을 보장한다.	MAC/HMAC (메시지 인증 코드)
인증 (Authentication)	접속한 서버가 신뢰할 수 있는 진짜 서버인지 확인한다.	디지털 인증서 (CA 발급)

✨ HTTPS 통신 흐름: SSL HandShake

HTTPS 통신이 시작될 때, 클라이언트와 서버는 서로를 확인하고 암호화에 사용할 키를 나누어 갖는 '핸드셰이크' 과정을 거친다.

Client Hello (인사 및 제안)
클라이언트가 서버에 접속하면 가장 먼저 인사를 건넨다. 이때 다음과 같은 정보를 보낸다.
- 클라이언트 난수: 나중에 대칭키를 만들 때 재료로 쓰일 무작위 숫자
- 암호화 방식(Cipher Suite) 목록: 클라이언트가 지원하는 암호화 알고리즘 리스트 (예: AES, RSA 등)

Server Hello (응답 및 선택)
서버는 클라이언트의 인사를 받고 응답한다.
- 서버 난수: 서버가 생성한 무작위 숫자
- 선택된 암호화 방식: 클라이언트가 보낸 목록 중 서버도 지원하는 가장 안전한 방식을 하나 선택한다.

Certificate (인증서 전달)
서버는 자신의 신원을 증명하기 위해 CA(인증 기관)로부터 발급받은 인증서를 클라이언트에게 보낸다.
이 인증서 안에는 서버의 공개키가 들어 있다.

Certificate Verification (인증서 검증)
클라이언트(브라우저)는 받은 인증서가 진짜인지 확인한다.
- 브라우저에 내장된 CA의 공개키를 이용해 인증서의 서명을 해독한다.
- 해독에 성공하면, 이 서버의 공개키는 믿을 수 있는 것으로 간주한다.

Client Key Exchange (비밀 재료 전달)
이제 가장 중요한 단계이다. 클라이언트는 데이터를 암호화할 진짜 열쇠의 재료인 'Pre-Master Secret'이라는 난수를 생성한다.
- 이 난수를 서버의 공개키로 암호화하여 서버에 보낸다.
- 중요: 이 데이터는 서버의 개인키로만 풀 수 있기 때문에, 해커가 중간에 가로채도 절대 열어볼 수 없다.

Master Secret 생성 (비밀 열쇠 완성)
서버는 자신의 개인키로 클라이언트가 보낸 데이터를 복호화한다. 이제 클라이언트와 서버 모두 동일한 세 가지 재료를 갖게 된다.
- 클라이언트 난수
- 서버 난수
- Pre-Master Secret
  이 세 가지를 조합하여 실제 통신에 사용할 Master Secret(대칭키)를 만들어 낸다.

Finished (종료 및 확인)
서버와 클라이언트는 각자 "이제 준비 끝났어! 앞으로 이 열쇠로 암호화해서 보낼게"라는 확인 메시지를 주고받으며 핸드셰이크를 마친다.

3. 암호화 방식 이해하기

✨ 대칭키 암호화 (Symmetric Key Encryption)

암호화와 복호화에 동일한 하나의 키를 사용하는 방식이다.

특징
- 속도: 구조가 단순하여 연산 속도가 매우 빠르다. 대용량 데이터를 실시간으로 암호화하기에 적합하다.
- 효율성: CPU 리소스를 적게 소모한다.
한계 (키 교환 문제)
- 상대방과 통신하기 위해 키를 전달하는 과정에서 키가 탈취되면 보안이 완전히 무너진다.
- 사용자가 많아질수록 관리해야 할 키의 개수가 기하급수적으로 늘어난다. ➡️ N명이 서로 통신하려면 N(N-1)/2개의 키 필요의 키 필요
주요 알고리즘
- AES (Advanced Encryption Standard): 현재 전 세계 표준으로 가장 많이 사용된다. (128, 192, 256비트 키 지원)
- ChaCha20: 모바일 환경이나 저사양 기기에 최적화된 빠른 알고리즘이다.

✨ 공개키 암호화 (Asymmetric Key Encryption)

서로 수학적으로 연결된 공개키(Public Key)와 개인키(Private Key) 쌍을 사용하는 방식이다.

특징
- 보안성: 공개키는 누구나 가질 수 있지만, 암호화된 데이터는 오직 주인만 가진 개인키로만 풀 수 있어 키 교환 문제를 해결한다.
- 확장성: 각 사용자는 자신의 키 쌍 하나만 관리하면 되므로 관리가 효율적이다.
한계
- 속도: 대칭키 방식보다 100~1000배 정도 느리며, CPU 부하가 크다.
주요 알고리즘
- RSA: 가장 대표적인 공개키 알고리즘이다.
- ECC (Elliptic Curve Cryptography): RSA보다 짧은 키 길이로 동일한 보안 수준을 제공하며 속도가 더 빨라 최근 많이 사용된다.

✨ HTTPS의 선택: 하이브리드 암호화

HTTPS는 두 방식의 장점만을 취하기 위해 하이브리드 방식을 사용한다.

단계	사용 방식	역할
연결 초기 (Handshake)	공개키 방식	실제 통신에 쓸 대칭키(세션키)를 안전하게 공유
실제 데이터 전송	대칭키 방식	공유된 대칭키를 이용해 데이터를 빠르게 암호화

4. HTTPS 통신 과정 상세 분석

✨ 사전 준비 단계

1단계: 서버의 인증서 발급
1. 공개키/개인키 쌍 생성
2. CSR(Certificate Signing Request) 생성: 회사 정보, 도메인, 공개키 포함
3. CA(인증기관)에 CSR 제출 및 도메인 소유권 증명

2단계: CA의 인증서 발급
1. 신청자의 신원 확인
2. 디지털 인증서 생성: 도메인 정보, 서버의 공개키, 유효기간, CA 정보
3. CA의 개인키로 인증서에 전자서명
4. 서버에 인증서 전달

✨ 실제 통신 과정 (TLS HandShake)

1단계: Hello 메시지 교환

클라이언트 ➡️ 서버: Client Hello
- 지원하는 TLS 버전
- 지원하는 암호화 알고리즘 목록
- 클라이언트 난수 (Client Random)
서버 ➡️ 클라이언트: Server Hello
- 선택한 TLS 버전
- 선택한 암호화 알고리즘
- 서버 난수 (Server Random)
- 서버 인증서 (CA가 서명한)

2단계: 인증서 검증 (클라이언트의 작업)

브라우저에 내장된 CA의 공개키로 인증서 검증
- 인증서가 신뢰할 수 있는 CA가 발급했는지 확인
- 인증서가 위조되지 않았는지 확인
인증서 내용 확인
- 도메인 이름 일치 확인
- 유효기간 확인
- 인증서 폐기 여부 확인 (CRL/OCSP)
서버의 공개키 추출

3단계: 대칭키 생성 및 교환

클라이언트의 작업
1. Pre-Master Secret 생성 (임의의 48바이트)
2. 서버의 공개키로 Pre-Master Secret 암호화
3. 암호화된 데이터를 서버에 전송
서버의 작업
1. 자신의 개인키로 암호화된 데이터 복호화
2. Pre-Master Secret 획득
양측의 작업
1. Client Random + Server Random + Pre-Master Secret
2. Master Secret 생성
3. Session Key (대칭키) 생성

4단계: 통신 시작

클라이언트 ➡️ 서버: Finished (암호화) "이제부터 대칭키로 통신합니다"
서버 ➡️ 클라이언트: Finished (암호화) "확인했습니다."
이후 모든 통신은 Session Key로 암호화/복호화

✨ 시각화된 흐름도

5. 인증서의 체인 구조

✨ 계층적 역할 분담

인증서 체인은 최상위 기관으로부터 하위 기관으로 신뢰를 전달하는 계층적 구조를 말한다.

Root CA (최상위 인증기관)
- 신뢰의 뿌리이다. 전 세계적으로 몇 안 되는 기관(DigiCert, Sectigo 등)만이 이 지위를 가진다.
- 자신의 공개키를 스스로 증명하는 '자체 서명 인증서(Self-signed)'를 가진다.
Intermediate CA (중간 인증기관)
- Root CA로부터 권한을 위임받은 기관이다.
- 실제로 웹사이트 운영자들에게 인증서를 발급해 주는 '창구' 역할을 한다.
End-Entity Certificate (서버 인증서)
- 우리가 접속하는 naver.com, google.com 등이 발급받는 최종 인증서이다.

✨ 체인 구조를 사용하는 이유

단순히 Root CA가 직접 발급해 주면 편할 것 같지만, 보안상의 이유로 중간 단계를 반드시 둔다.

Root CA의 개인키 보호
Root CA의 개인키가 유출되면 전 세계 인터넷 보안이 무너진다. 따라서 Root CA는 평소에 네트워크와 완전히 분리된(Offline) 안전한 곳에 보관하고, 아주 가끔 중간 기관에 권한을 줄 때만 사용한다.
피해 최소화
만약 중간 기관의 키가 유출되더라도, 해당 중간 기관이 발급한 인증서만 폐기하면 된다. Root CA는 안전하므로 전체 시스템을 다시 구축할 필요가 없다.
운영 효율성
전 세계 수억 개의 웹사이트 인증서를 Root CA 하나가 일일이 검토하고 발급하는 것은 물리적으로 불가능하다.

✨ 인증서 검증 과정

브라우저가 서버 인증서를 받으면, 신뢰할 수 있는 뿌리를 찾을 때까지 위로 거슬러 올라간다.

1단계: "이 naver.com 인증서, 중간 기관 A가 서명했네? 그럼 중간 기관 A의 인증서를 가져와 봐."
2단계: "중간 기관 A의 인증서는 Root CA B가 서명했구나. 그럼 Root CA B의 인증서를 확인하자."
3단계: "어? Root CA B는 내(브라우저)가 이미 알고 있는 '신뢰하는 기관 목록'에 있네! 그럼 이 체인은 모두 진짜야!"

✨ 브라우저의 역할

우리가 크롬이나 사파리를 설치할 때, 이미 수십 개의 Root CA 공개키가 프로그램 안에 내장되어 있다. 이 내장된 키들과 연결 고리가 닿지 않는 인증서를 만나면 브라우저는 즉시 "이 사이트는 안전하지 않습니다"라는 경고를 띄우게 된다.

6. HTTPS의 장단점

✨ 장점

구분	주요 내용	기대 효과
강력한 보안	데이터 암호화, 무결성 검증, 서버 인증	스니핑, 중간자 공격(MITM), 데이터 변조 원천 차단
SEO 우대	구글 등 주요 검색 엔진의 랭킹 가산점	동일 콘텐츠일 경우 HTTPS 사이트가 검색 상단에 노출
사용자 신뢰	주소창의 자물쇠 아이콘 및 '안전함' 표시	개인정보 유출 불안감 해소 및 서비스 이탈 방지
차세대 기술	HTTP/2, HTTP/3 프로토콜의 필수 조건	최신 웹 가속 기술을 사용하기 위해 HTTPS가 반드시 필요
광고 삽입 방지	통신 경로 중간의 ISP 등이 광고를 강제 삽입하는 것을 방지	사용자에게 원래 의도한 꺠끗한 웹 화면 제공

✨ 단점과 오해

과거에는 HTTPS가 무겁다는 인식이 있었으나, 현대의 기술은 이러한 단점들을 대부분 극복했다.

성능 오버헤드 (Performance)
- 현상: TLS Handshake 과정에서 추가적인 왕복 시간(RTT)이 발생하여 초기 접속이 약간 느려질 수 있다.
- 현실
  - TLS 1.3: 핸드셰이크 과정을 1-RTT(혹은 0-RTT)로 단축하여 지연 시간을 획기적으로 줄였다.
  - 하드웨어 가속: 최신 CPU에는 암호화 연산을 돕는 전용 명령어(AES-NI 등)가 있어 CPU 점유율 상승은 미미하다.

비용과 관리의 복잡성 (Cost & Management)
- 현상: 유로 인증서 구매 비용과 주기적인 갱신 관리의 번거로움이 있다.
- 현실
  - 무료 인증서: Let's Encrypt의 등장으로 누구나 무료로 인증서를 발급받을 수 있다.
  - 자동화: Certbot 같은 도구를 사용하면 인증서 발급부터 갱신까지 100% 자동화가 가능하다.

혼합 콘텐츠 문제 (Mixed Content)
- 현상: HTTPS 사이트 내에서 일부 이미지나 스크립트를 HTTP로 불러올 경우, 브라우저가 보안 경고를 띄우거나 차단한다.
- 해결: 모든 리소스를 HTTPS로 전환해야 하는 초기 작업의 번거로움이 있다.

✨ 결론

결론적으로 HTTPS의 단점은 기술적 발전으로 인해 '무시할 수 있는 수준'이 된 반면, 장점은 '대체 불가능한 수준'이 되었다.
이제는 보안뿐만 아니라 HTTP/2나 HTTP/3 같은 최신 기술을 사용하여 웹사이트 속도를 더 빠르게 만들기 위해서라도 HTTPS는 필수이다.

7. HTTPS의 한계와 보안의 함정

HTTPS는 강력한 보안 도구이지만, 'HTTPS = 100% 안전한 사이트'라는 오해는 위험할 수 있다. HTTPS가 보장하는 것은 '통신 경로의 안전'이지, '통신 대상의 도덕성'이 아니기 때문이다.

(1) 자체 서명 인증서 (Self-Signed Certificate)

신뢰할 수 있는 CA가 아닌, 서버 운영자가 직접 만든 인증서이다.

위험성: 제3자의 검증이 없으므로, 해커가 중간에 끼어들어 만든 가짜 인증서인지 구분할 방법이 없다.
사용자 경험: 브라우저에서 "연결이 비공개로 설정되어 있지 않습니다"라는 강력한 경고를 띄운다.
용도: 외부 노출이 없는 내부 테스트용 서버에서만 제한적으로 사용해야 한다.

(2) 인증서 관리 소홀 (만료 및 폐기)

인증서는 유효기간이 정해진 '기간제 신분증'이다.

만료된 인증서: 갱신 시기를 놓치면 브라우저는 해당 사이트를 차단한다. 이는 서비스 중단으로 이어져 기업 신뢰도에 큰 타격을 준다.
폐기된 인증서: 개인키 유출 등의 사고로 인증서가 폐기(Revocation)되었음에도 서버가 이를 계속 사용하면 보안에 구멍이 생긴다. (CRL/OCSP 확인이 중요한 이유이다.)

(3) 피싱 사이트도 HTTPS 사용 가능

가장 많은 사용자가 낚이는 부분이다. 해커도 얼마든지 정상적인 HTTPS 인증서를 발급받을 수 있다.

함정: 주소창의 자물쇠 아이콘은 "이 사이트와 주고받는 데이터가 암호화된다"는 뜻일 뿐, "이 사이트 주인이 착한 사람이다"라는 뜻이 아니다.
수법: naver.com 대신 navver.com 같은 유사 도메인을 사고, 여기에 무료 인증서(Let's Encrypt 등)를 적용하면 사용자는 자물쇠 아이콘만 보고 안심하게 된다.
대책: 자물쇠 아이콘보다 도메인 주소의 철자를 확인하는 습관이 더 중요하다.

(4) 구식 프로토콜 및 약한 암호화 (Legacy TLS)

통로가 암호화되어 있어도, 그 암호가 너무 허술하면 쉽게 뚫릴 수 있다.

취약한 버전: TLS 1.0, 1.1 버전은 이미 여러 보안 취약점이 발견되어 사용이 권장되지 않는다.
암호화 스위트(Cipher Suite): 너무 짧은 키 길이를 사용하거나, 이미 파훼된 암호화 알고리즘을 사용하면 슈퍼컴퓨터 등을 이용한 무차별 대입 공격에 노출될 수 있다.

8. HTTPS 완벽 구축 및 안전 사용 체크리스트

✨ 운영자: HTTPS 완벽 구축 가이드

서버를 운영한다면 반드시 챙겨야 할 기술적 항목들이다.

단계	항목	세부 내용 및 목적
발급	신뢰할 수 있는 CA 활용	DigiCert, Let's Encrypt 등 공인된 기관에서 발급
설치	올바른 인증서 설치	중간 인증서를 포함한 전체 체인(Chain)을 정확히 구성
전환	HTTPS 리다이렉트	HTTP(80) 요청을 HTTPS(443)로 자동 전환 (301 Redirect)
정리	Mixed Content 해결	페이지 내 이미지, 스크립트 등 모든 리소스를 `https://`로 호출
강화	HSTS 설정	브라우저가 해당 사이트에 항상 HTTPS로만 접속하도록 강제
유지	인증서 자동 갱신	만료 사고 방지를 위해 Certbot 등을 이용한 자동화 설정
방어	보안 헤더 추가	CSP: XSS 공격 방지 / X-Frame-Options: 클릭재킹 방지

HSTS (HTTP Stricdt Transport Security)
사용자가 실수로 http://로 접속하더라도, 브라우저가 이를 가로채서 강제로 https://로만 접속하게 만드는 강력한 보안 정책이다.
중간에 해커가 통신을 가로채서 HTTP로 다운그레이드시키는 공격을 원천 차단한다.
보안 헤더 (Security Headers)
- CSP (Content Security Policy): 웹사이트에서 불러올 수 있는 콘텐츠의 출처를 제한한다. 해커가 악성 스크립트를 심더라도 실행되지 않게 막아준다.
- X-Frame-Options: 내 사이트가 다른 사이트의 <iframe> 안에 들어가는 것을 막아, 사용자가 엉뚱한 곳을 클릭하게 만드는 '클릭재킹' 공격을 방지한다.

✨ 사용자: 안전한 웹 서핑 가이드

도메인 주소 철자 확인: naver.com이 맞는지, navver.com은 아닌지 확인 (피싱 방지)
보안 경고 무시 금지: "안전하지 않음" 경고가 뜨면 즉시 접속 중단
공용 Wi-Fi 주의: 민감한 금융 거래는 가급적 개인 네트워크에서 수행
최신 브라우저 유지: 최신 보안 패치가 적용된 크롬, 사파리 등 사용

jiny

이전 포스트

[Network] 대칭키 & 공개키

다음 포스트

[Network] HTTP & HTTPS

Computer Science

1. HTTP (HyperText Transfer Protocol)

✨ 기본 개념

✨ HTTP 메시지 구조

✨ HTTP의 주요 특징

✨ 주요 통신 메서드 및 상태 코드

✨ HTTP의 발전 과정

✨ HTTP의 보안 취약점과 한계

2. HTTPS (HyperText Transfer Protocol Secure)

✨ 기본 개념

✨ SSL/TLS란?

✨ HTTPS의 3대 보안 핵심 (CIA Triad)

✨ HTTPS 통신 흐름: SSL HandShake

3. 암호화 방식 이해하기

✨ 대칭키 암호화 (Symmetric Key Encryption)

✨ 공개키 암호화 (Asymmetric Key Encryption)

✨ HTTPS의 선택: 하이브리드 암호화

4. HTTPS 통신 과정 상세 분석

✨ 사전 준비 단계

✨ 실제 통신 과정 (TLS HandShake)

✨ 시각화된 흐름도

5. 인증서의 체인 구조

✨ 계층적 역할 분담

✨ 체인 구조를 사용하는 이유

✨ 인증서 검증 과정

✨ 브라우저의 역할

6. HTTPS의 장단점

✨ 장점

✨ 단점과 오해

✨ 결론

7. HTTPS의 한계와 보안의 함정

(1) 자체 서명 인증서 (Self-Signed Certificate)

(2) 인증서 관리 소홀 (만료 및 폐기)

(3) 피싱 사이트도 HTTPS 사용 가능

(4) 구식 프로토콜 및 약한 암호화 (Legacy TLS)

8. HTTPS 완벽 구축 및 안전 사용 체크리스트

✨ 운영자: HTTPS 완벽 구축 가이드

✨ 사용자: 안전한 웹 서핑 가이드

[Network] 대칭키 & 공개키

[Network] TLS/SSL HandShake

0개의 댓글