그림으로 배우는 Http&Network Basic 정리 - 7장. 웹을 안전하게 지켜주는 HTTPS

Study Platform📚/그림으로 배우는 Http&Network Basic

그림으로 배우는 Http&Network Basic 정리 - 7장. 웹을 안전하게 지켜주는 HTTPS

쿄코코 2025. 3. 2. 22:02

7.1. HTTP의 약점

- 평문 통신이기때문에 도청이 가능핟.

- 통신 상대를 확인하지 않기 때문에 위장이 가능핟.

- 완전성을 증명할 수 없기때문에 변조 가능하다.

7.1.1. 평문이기 때문에 도청 가능

HTTP는 TCP/IP 프로토콜을 통해 데이터를 전송하지만, 자체적으로 암호화를 제공하지 않는다.
따라서 패킷 캡처 도구(예: Wireshark)로 네트워크 트래픽을 감청하면 요청/응답 내용을 그대로 확인할 수 있다.

해결 방법

1️⃣ 통신 암호화

=> HTTPS 사용: SSL/TLS 암호화를 통해 데이터가 암호화된 상태로 전송되므로 도청이 불가능하다.

2️⃣ 콘텐츠 암호화

=> 콘텐츠 암호화는 웹이나 네트워크를 통해 전송되는 데이터(콘텐츠)를 암호화하여 보호하는 기술이다.(ex. DRM, E2EE, 파일 암호화)

7.1.2. 통신 상대를 확인하지 않기 때문에 위장 가능

기본적인 HTTP는 통신 상대를 확인하는 인증 과정이 없기 때문에 위장이 가능하다.
이러한 문제로 인해 스푸핑(Spoofing) 공격이 발생할 수 있다.

SSL/TLS를 이용한 HTTPS 접속 시, 클라이언트(웹 브라우저)는 서버가 신뢰할 수 있는 대상인지 확인한다.

SSL/TLS는 디지털 인증서(Digital Certificate)와 인증 기관(CA, Certificate Authority)을 이용해 상대를 확인한다.
이 과정에서 서버가 진짜인지 검증하는 과정(서버 인증, Server Authentication)이 포함된다.

1️⃣ 클라이언트 → 서버: "TLS 연결을 시작할게요!" (ClientHello)
2️⃣ 서버 → 클라이언트: "내 SSL/TLS 인증서 여기 있어요!" (ServerHello + 인증서 전송)
3️⃣ 클라이언트 → 서버 인증 확인:

인증서의 발급 기관(CA) 확인
인증서가 변조되지 않았는지 확인
도메인과 일치하는지 확인

4️⃣ 검증 성공 시, 보안 통신 진행

5️⃣ 이후 대칭키로 데이터 암호화하여 안전한 통신 진행

7.1.3. 완전성을 증명할 수 없기 때문에 변조 가능

중간자 공격(MITM)은 네트워크에서 데이터를 가로채거나 변조하는 공격 방식이며, HTTPS, VPN, 보안 네트워크 등을 이용하면 이를 방어할 수 있다.

파일 무결성 검증 → SHA-256 (추천)
비밀번호 저장 → Argon2 (최신), bcrypt (여전히 사용)
보안이 중요한 환경 → SHA-512, BLAKE2
MD5, SHA-1은 보안상 사용하지 않는 게 좋다..

SSL 3.0 사용되는경우도 잇긴

TLS 1-> 크롬에서도 사용불가능

TLS2/TLS3만 지원

SSL3 ->2017년이 마지막

TLS2 이상버전으로 암호화,,?

인증서를 통해서 서버의 공개키를 담아서 줌 -> 이건 아무데나 뿌려줘도 된다.

RSA 방식은 사실 중간의 대칭키 유도가능할수있따.

TLS3부터는 필수알고리즘으로 사용한다.

7.2 HTTP + 암호화 + 인증 + 완정성 보호 = HTTPS

7.2.1. HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS

7.2.2. HTTPS 는 SSL의 껍질을 덮어쓴 HTTP

HTTPS(HyperText Transfer Protocol Secure)는 HTTP에 보안 계층을 추가한 프로토콜이다. HTTP 자체는 데이터를 평문(plaintext)으로 전송하기 때문에, 중간에서 데이터를 가로채거나 변조할 수 있는 보안 문제가 있다. 이를 해결하기 위해 HTTPS는 SSL/TLS 암호화 계층을 추가하여 데이터의 기밀성, 인증, 무결성을 보장한다.

🔹 HTTP와 HTTPS의 차이

비교	HTTP	HTTPS
보안	없음	암호화, 인증, 무결성 보장
사용 포트	80	443
인증서 필요 여부	필요 없음	필요함 (SSL/TLS 인증서)
속도	빠름	암호화 과정으로 인해 약간 느림
주 사용처	일반 웹페이지	로그인, 결제, 민감한 데이터 처리 사이트

7.2.3. 상호간에 키를 교환하는 공개키 암호화 방식

🔹 공통키 암호화 ( 대칭키 암호화, Symmetric Encription)

- 암호화와 복화에 같은 키를 사용한다.

https://velog.io/@minj9_6/대칭키와-비대칭키는-무슨-차이가-있을까

공통키 암호화는 암호화와 복호화에 동일한 키(공통키)를 사용하는 방식이다.
이 방식의 장점은 속도가 빠르다는 것이지만, 단점은 키를 안전하게 공유하는 것이 어렵고, 키가 유출되면 보안이 완전히 무너진다는 점이다.

이러한 단점을 해결하기 위해 등장한 방식이 공개키 암호화(비대칭키 암호화, Asymmetric Encryption) 이다.

🔹 공개키 암호화( 비대칭키 암호화, Asymmetric Encrytion )

공개키 암호화는 공개키(Public Key)와 개인키(Private Key) 두 개의 키를 사용하는 방식이다.
이 두 키는 한 쌍이며, 다음과 같은 특징을 가진다.

공개키로 암호화한 데이터는 개인키로만 복호화할 수 있다.
개인키로 암호화한 데이터는 공개키로 복호화할 수 있다.

이를 이용하면 공개키를 사용해 데이터를 암호화하고, 개인키를 가진 사람만 이를 복호화할 수 있도록 만들 수 있다.
예를 들어, 서버가 개인키를 가지고 있고, 클라이언트에게 공개키를 전달한다면 공개키를 가로챈 공격자가 있더라도 개인키가 없으면 데이터를 복호화할 수 없다.
이 때문에 공개키 암호화는 키 공유가 안전한 장점이 있지만, 암호화 속도가 느리다는 단점이 있다.

참고로, 개인키로 암호화된 데이터는 공개키로 복호화하는 방식은 전자서명(Digital Signature) 에서 주로 사용된다.

일반적인 데이터 암호화에서는 공개키로 암호화하고 개인키로 복호화하는 방식을 사용한다.
그러나 CA(Certificate Authority, 인증 기관) 같은 전자서명에서는 개인키로 암호화(서명)하고, 공개키로 복호화(검증)하여 발신자가 인증된 사람인지 확인하는 용도로 사용한다.
그리고 이 방식은 은행, 금융기관, 정부 시스템 등도 전자서명을 적극적으로 활용한다.

이처럼 HTTPS는 공통키 기법과 공개키 기법을 함께 사용하여 서로의 단점을 보완한 하이브리드 암호 시스템이다.

초기 키 교환 (공개키 암호화 사용)
- 클라이언트가 서버의 공개키를 받아서 세션키(공통키)를 암호화하여 서버에 보냄
- 서버는 자신의 개인키로 이를 복호화하여 세션키(공통키)를 얻음
- 이렇게 하면 안전하게 공통키를 공유할 수 있다.
데이터 통신 (공통키 암호화 사용)
- 이후 실제 데이터 전송은 공통키 암호화(AES 등)를 사용하여 빠르게 진행됨

즉, 공개키 암호화는 안전한 키 교환을 위해 사용되고, 공통키 암호화는 빠른 데이터 전송을 위해 사용된다.
이러한 방식을 통해 HTTPS는 보안성과 성능을 모두 확보할 수 있다.

7.2.4. 공개키가 정확한지 아닌지를 증명하는 증명서

✅ CA 인증서란?

CA 인증서(Certificate Authority Certificate) 는 공인된 인증 기관(CA, Certificate Authority)이 발급한 디지털 인증서이다.
이 인증서는 웹사이트, 서버, 소프트웨어, 사용자 등이 신뢰할 수 있음을 증명하는 데 사용된다.

1️⃣ 웹사이트(서버)가 CA에게 인증서를 요청

웹사이트(예: example.com)는 CSR (Certificate Signing Request, 인증서 서명 요청서) 을 생성하여 CA에 제출한다.

CSR에는 다음 정보가 포함된다.

도메인 이름 (example.com)
공개키 (서버가 생성한 키 쌍 중 공개키)
회사 정보 (OV, EV 인증서의 경우)

2️⃣ CA가 웹사이트 정보를 검증

CA는 example.com이 실제 존재하는 도메인인지 확인한다.
OV, EV 인증서라면 기업의 법적 정보까지 검증한다.
검증이 완료되면 CA는 인증서를 발급한다.

3️⃣ CA가 전자서명하여 인증서를 발급

CA는 서버의 공개키와 도메인 정보를 포함한 인증서에 자신의 개인키로 전자서명하여 발급한다.

전자서명 과정:
1. CA는 웹사이트의 정보(도메인, 공개키 등)를 해시하여 특정한 값(Hash)을 만든다.
2. 이 해시 값을 CA의 개인키로 암호화하여 서명한다.
3. 최종적으로, 서명된 인증서를 서버에 발급한다.

🔹 결과적으로, 이 인증서에는 example.com의 공개키, example.com의 도메인 정보, CA의 전자서명 (CA의 개인키로 암호화된 해시 값) 이 포함되어 있다.

4️⃣ 웹사이트(서버)가 인증서를 사용자(클라이언트)에게 전달

사용자가 https://example.com에 접속하면 서버는 CA가 서명한 인증서를 브라우저(클라이언트)에게 보낸다.

브라우저는 이 인증서가 신뢰할 수 있는지 검증한다.

5️⃣ 브라우저가 CA의 전자서명을 검증

브라우저는 먼저 CA의 신뢰 여부를 확인한다.

브라우저나 운영체제(OS)에는 미리 신뢰할 수 있는 CA 목록(루트 인증서 목록) 이 저장되어 있다.

브라우저가 인증서를 검증하는 과정:

CA의 공개키를 가져온다.
인증서에 포함된 전자서명을 CA의 공개키로 복호화한다.
복호화된 값과 인증서 내용의 해시 값이 일치하는지 확인한다.
- 일치하면 → 인증서가 위변조되지 않았으며, 신뢰할 수 있음
- 일치하지 않으면 → 위조된 인증서일 가능성이 높아 보안 경고 발생

✅ SSL 인증서 종류 (CA 인증서의 등급)

1️⃣ DV SSL (Domain Validation, 도메인 검증)

개인용, 블로그, 일반 웹사이트에서 사용
도메인 소유 여부만 확인
발급이 빠르고 무료 인증서(Let’s Encrypt 등)도 대부분 이 방식

2️⃣ OV SSL (Organization Validation, 기관 검증)

회사, 기업용 웹사이트에서 사용
도메인뿐만 아니라 회사 정보도 검증
기업의 법적 존재 여부를 확인

3️⃣ EV SSL (Extended Validation, 확장 검증)

은행, 금융기관, 대기업 웹사이트에서 사용
법적 기업 정보, 실제 운영 여부까지 검증
발급 절차가 까다롭고 가격이 비쌈
주소창에 기업 이름이 표시됨 (예전에는 초록색 주소창)

7.2.5. 안전한 통신을 하는 HTTPS의 구조

✅ 1. 클라이언트 → 서버 (암호화 방식 전달)
클라이언트가 서버에 접속하면서 지원하는 암호화 알고리즘 목록(Cipher Suite)을 전달한다.

✅ 2. 서버 → 클라이언트 (SSL/TLS 인증서 전달)
서버는 CA 인증서(공개키 포함)와 함께 암호화 방식을 선택하여 클라이언트에게 보낸다.
서버한테는 공개키 + 개인키가 있다.

✅ 3. 클라이언트 → 서버 (인증서 검증 후 공통키 생성)
클라이언트는 받은 CA 인증서가 신뢰할 수 있는지 확인한다.
검증이 완료되면, 클라이언트는 공통키(세션키)를 생성한다.
Client Random + Server Random + Pre-Master Secret을 기반으로 공통키를 생성한다.

✅ 4. 클라이언트 → 서버 (공통키 전달)
클라이언트는 생성한 공통키(세션키)를 서버의 공개키로 암호화한 후 서버로 보낸다.
(공개키 암호화 방식: RSA, ECDH 등 사용)

✅ 5. 서버 (개인키로 복호화)
서버는 자신의 개인키(비밀키)로 공통키를 복호화하여 얻는다.
이제 클라이언트와 서버는 같은 공통키(세션키)를 공유하게 된다.

✅ 6. 이후 통신 – 공통키 암호화 사용
이후 클라이언트와 서버 간의 데이터 통신은 공통키 암호화 방식을 이용해서 데이터를 보낸다