[3회차] 왜 HTTP로 충분하지 않고, HTTPS가 필요하지?

[github-actions[bot]]

🚀 발표 주제

왜 HTTP로 충분하지 않고, HTTPS가 필요하지?

---

📅 발표일

2026-06-15

🙋 발표자

도우너

🗂️ 카테고리

🌐 Network

📚 발표 자료

업로드 예정

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

HTTP의 문제점

평문 통신이라 세 가지 위협이 존재

• 도청 — 중간에서 패킷을 그대로 읽을 수 있음
• 변조 — MITM 공격(중간자 공격)으로 데이터를 바꿔치기 가능
• 위장 — 상대방이 진짜 서버인지 확인할 방법이 없음

암호화 방식

• 대칭키

  • 공통키 1개로 복호화/암호화
  • 빠르지만, 키 탈취 시 위험

• 비대칭키 (공개키)

  • 공개키와 개인키 존재
  • 키 탈취해도 비교적 안전
  • 대칭키에 비해 느림

HTTPS = 하이브리드 암호화

둘의 장점만 조합

핸드쉐이크 (비대칭키) → 대칭키를 안전하게 교환
실제 통신   (대칭키)  → 빠르게 데이터 전송

인증서와 CA

서버의 "위장" 문제를 해결

1. 서버가 CA에 공개키 등록 요청
2. CA가 자신의 개인키로 서명한 인증서 발급
3. 클라이언트가 브라우저 내장 CA 공개키로 인증서 검증
   → 복호화 성공 = 신뢰할 수 있는 서버
   → 복호화 실패 = 위조된 서버

HTTPS 핸드쉐이크 흐름

클라이언트                                서버
    |                                      |
    |——— 1. ClientHello ————————————————>  |
    |                                      |
    |  <———————————————————— 2. ServerHello|
    |  <————————————————————— 3. Certificate
    |  <————————————————— 4. ServerHelloDone
    |                                      |
    |——— 5. ClientKeyExchange ——————————>  |
    |——— 6. ChangeCipherSpec ———————————>  |
    |——— 7. Finished ———————————————————>  |
    |                                      |
    |  <——————————————— 8. ChangeCipherSpec|
    |  <———————————————————————— 9. Finished
    |                                      |
    |======= 10. Application Data ========|

각 단계

1. ClientHello — 클라이언트가 지원하는 암호화 방식 목록 + 랜덤값 전송

2. ServerHello — 그 중 서버가 선택한 암호화 방식 + 랜덤값 응답

3. Certificate — 서버가 CA에게 발급받은 인증서 전송

   • 클라이언트는 브라우저에 내장된 CA 공개키로 인증서 검증
   • 검증 성공 → 서버의 공개키 획득

4. ServerHelloDone — "나는 할 말 다 했어" 신호

5. ClientKeyExchange — 대칭키(세션키) 생성 후 서버 공개키로 암호화해서 전송

   • 서버는 자신의 개인키로 복호화 → 대칭키 공유 완료

6→9. ChangeCipherSpec + Finished — "이제부터 우리 대칭키로 암호화해서 얘기하자" 선언. 양쪽이 각각 주고받음
10. Application Data — 이제부터 대칭키로 실제 데이터 통신

🔗 미션과의 연결

작성 예정

📚 참고 자료

작성 예정

---

🙋‍♀️ 질문

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

[2Jaeheon]

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

TLS에서 핸드쉐이크가 하는 일은 다음과 같이 크게 세 가지임

1. 상대가 진짜 서버가 맞는지 (가짜 서버인지 진짜 서버인지 - 중간자 공격 방지)
2. 어떤 암호 방식으로 소통할지 (TLS 버전, 암호 알고리즘 등)
3. 실제 데이터 전송에 쓸 대칭키를 생성 (이 대칭키를 그대로 네트워크에 보내는 게 아니라, 핸드셰이크 과정에서 양쪽이 계산해서 같은 키를 갖게 된다)

비대칭키/키 교환: 안전하지 않은 네트워크 위에서 공유 비밀을 만들기 위해
대칭키: 그 뒤의 HTTP 데이터를 빠르게 암호화하기 위해

단, TLS 1.3 기준으로는 서버 공개키로 대칭키를 암호화해서 보낸다가 아닌,
보통 ECDHE(디피헬만 키 기반의 암호)로 양쪽이 같은 비밀값을 계산하고,
인증서는 서버가 진짜인지 확인하는 데 쓴다.

---

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

클라이언트는 서버가 준 인증서 체인을 따라가면서, 각 인증서의 서명이 다음 CA의 공개키로 검증되는지 봄.
마지막에 브라우저나 OS의 신뢰 저장소에 있는 루트 CA까지 연결되면 신뢰가능한 발급 경로가 있음을 알게됨.

또한 인증서의 주체/대체 이름이 접속한 도메인과 일치하는지, 유효기간과 폐기 여부 등을 확인한다
그리고 서버가 해당 인증서의 공개키에 대응하는 개인키를 실제로 갖고 있는지도 핸드셰이크 서명으로 확인한다.

---

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

중간자 공격 (MITM) 공격에서 HTTP에서는 공격자가 중간에서 서버인 척을 해도 클라이언트가 확인할 방법이 없다.

HTTPS에서는 여기서 막히는 지점이 생긴다. 공격자가 진짜 서버인 척하려면 example.com에 대해 신뢰된 CA가 서명한 인증서와,
그 인증서 공개키에 대응하는 개인키가 필요. 클라이언트는 인증서 체인과 도메인 일치를 확인하고,
TLS 핸드셰이크에서 서버가 개인키를 가진 것도 확인.

[wontop02]

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

비대칭키 방식이 안전하지만, 속도가 느리기 때문에 처음에만 비대칭키로 연결을 맺고, 그 이후에는 속도가 빠른 대칭키를 사용합니다.

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

CA의 개인키로 암호화된 디지털 서명을, 클라이언트가 CA 공개키로 복호화했을 때 성공하면 신뢰할 수 있습니다.

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

HTTP에는 서버를 위장하는 문제가 발생할 수 있습니다.
이를 해결하기 위해 서버가 CA에 공개키를 등록하고, CA의 개인키로 서명한 인증서를 발급받아 클라이언트에 전달하는 방식으로 문제를 해결할 수 있습니다.

[Jihyun3478]

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

비대칭키는 공개키/개인키 쌍을 사용해 키 전달은 안전하지만 수학적 연산이 복잡해 느립니다. 반면에 대칭키는 빠르지만 양쪽이 같은 키를 공유해야 하므로 처음 키를 전달하는 과정이 위험합니다. HTTPS는 두 방식을 조합해 핸드셰이크에서 서버의 공개키로 대칭키(세션 키)를 암호화해 전달하고, 개인키를 가진 서버만 복호화할 수 있으므로 안전하게 키를 교환합니다. 이후 실제 데이터 전송은 교환된 대칭키로 빠르게 처리합니다.

---

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

클라이언트는 CA의 디지털 서명을 검증하는 방식으로 인증서를 신뢰합니다. CA는 인증서 발급 시 자신의 개인키로 서명을 남기고, 클라이언트는 CA의 공개키로 그 서명을 검증합니다. 서명이 유효하면 해당 인증서가 신뢰할 수 있는 CA가 발급한 것임을 확인할 수 있습니다. CA의 공개키는 브라우저나 OS에 Root CA 형태로 미리 내장되어 있어 서버나 외부에 의존하지 않습니다. 만약 인증서가 중간에 변조됐거나 신뢰할 수 없는 CA가 발급했다면 서명 검증이 실패해 브라우저가 경고를 띄웁니다.

---

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

위장 공격은 2가지로 막을 수 있습니다. 먼저 CA가 인증서 발급 전 도메인 소유권을 검증해서 공격자는 타인의 도메인 인증서를 발급받을 수 없습니다. 또한, 클라이언트가 인증서 안의 도메인과 실제 접속한 도메인을 비교해서 불일치하면 경고를 띄웁니다.

[MODUGGAGI]

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

비대칭키 암호화는 공개키만 알면 상대방에게 안전하게 데이터를 전달할 수 있기 때문에, 처음 통신을 시작할 때 대칭키를 안전하게 교환하는 용도로 사용합니다.
하지만 비대칭키 암호화는 연산 비용이 크기 때문에 모든 데이터를 암호화하기에는 비효율적입니다.
반면 대칭키 암호화는 암·복호화 속도가 빠르므로 실제 HTTP 데이터 전송에는 대칭키를 사용합니다.

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

클라이언트는 서버가 보낸 인증서의 서명을 검증합니다.
인증서는 CA(Certificate Authority)가 자신의 개인키로 서명한 정보입니다.
브라우저나 운영체제에는 신뢰할 수 있는 CA의 공개키가 미리 저장되어 있습니다.

따라서 클라이언트는

1. 인증서의 발급자를 확인하고
2. 해당 CA의 공개키로 서명을 검증하며
3. 인증서의 유효기간, 도메인 정보 등을 함께 확인합니다.
   검증이 성공하면 해당 인증서가 신뢰할 수 있다고 판단하고 TLS 연결을 계속 진행합니다.

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

HTTP는 평문으로 데이터를 전송하기 때문에 네트워크 중간에 있는 공격자가 요청과 응답 내용을 그대로 볼 수 있습니다.
HTTPS는 TLS를 통해 대칭키 암호화를 사용하여 데이터를 암호화한 상태로 전송합니다.
따라서 공격자가 패킷을 가로채더라도 암호화된 데이터만 확인할 수 있으며 실제 내용은 알 수 없습니다.
즉 TLS의 데이터 암호화 메커니즘이 HTTP의 도청 문제를 해결합니다.

[Jiihyun]

Q1. HTTPS가 핸드쉐이크에서는 비대칭키, 실제 데이터 전송에서는 대칭키를 사용하는 이유는 무엇인가요?

비대칭키는 공개키와 개인키를 이용해 안전하게 세션키를 교환하고 서버의 신원을 검증하는 데 사용된다. 하지만 비대칭키 암호화는 연산 비용이 크기 때문에 실제 HTTP 데이터까지 암호화하기에는 비효율적이다. 따라서 TLS 핸드셰이크 과정에서 비대칭키로 세션키를 안전하게 공유한 뒤, 실제 데이터 전송은 빠른 대칭키를 사용하여 성능과 보안을 모두 확보한다.

Q2. 클라이언트가 서버로부터 인증서를 받았을 때, 이 인증서가 신뢰할 수 있는지 어떻게 검증하나요?

클라이언트는 인증서의 전자서명을 검증하여 인증서의 신뢰성을 확인한다.
브라우저에는 미리 신뢰하는 CA의 루트 인증서들이 저장되어 있다. 서버가 보낸 인증서가 신뢰된 CA에 의해 서명되었는지, 인증서가 만료되지 않았는지, 그리고 접속하려는 도메인과 인증서의 도메인이 일치하는지 검증하여 신뢰성을 판단한다.

Q3. HTTP에서 발생할 수 있는 도청, 변조, 위장 중 하나를 골라서 — HTTPS의 어떤 메커니즘이 그 문제를 어떻게 해결하는지 설명해보세요.

HTTP는 평문으로 데이터를 전송하기 때문에 네트워크 중간에 있는 공격자가 패킷을 가로채면 내용을 확인할 수 있는 문제점을 지니고 있다.
HTTPS는 TLS 핸드셰이크 과정에서 클라이언트와 서버가 공유할 세션키를 생성하고, 이후 데이터를 대칭키로 암호화하여 전송한다.
따라서 공격자가 패킷을 가로채더라도 암호화된 데이터만 볼 수 있고, 세션키를 알 수 없기 때문에 내용을 해독할 수 없어 도청을 방지할 수 있다.