Step 85. 프로젝트 — HTTP vs HTTPS 비교 보고서

Level 1 — 프로그래밍과 컴퓨터 내부 | 난이도 ★★★☆☆ | 예상 소요 시간 3시간

전제: Step 83~84의 캡처·필터·프로토콜 분석을 마쳤다. curl과 파이썬 간이 서버를 다룰 수 있다.

• 준비물: Wireshark(또는 tshark), 터미널 2개, 웹 브라우저, 문서 작성 도구.
• 주의: ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 평문 실험은 전부 내 컴퓨터 안(127.0.0.1)에서, HTTPS 실험은 공개 사이트에 대한 정상 접속만으로 이뤄집니다. 이 챕터의 패킷 출력은 2026-09-09에 WSL 리눅스(TShark 4.2.2, curl 8.5.0)에서 실측했고, 브라우저·GUI 화면 설명은 “화면 예시”입니다.

주소창의 자물쇠 — HTTPS입니다. 그런데 자물쇠가 있고 없고가 실제 전선 위에서 어떤 차이를 만드는지 직접 본 사람은 거의 없습니다. 이번 프로젝트의 목표는 단 하나입니다. 같은 내용을 HTTP(평문)로 한 번, HTTPS(암호문)로 한 번 보내고, 캡처로 둘을 나란히 찍어 비교 보고서를 쓴다. 직접 눈으로 확인하면 “HTTPS가 안전하다”는 말이 교과서 문구가 아니라 여러분이 스스로 증명한 사실이 됩니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

• 로컬에 평문 웹 서버를 열고, 요청/응답이 패킷에 글자 그대로 실리는 것을 캡처로 증명한다
• 평문 POST 본문(비밀번호 포함)이 노출되는 장면을 재현하고 기록한다
• TLS 외부 레코드 유형과 암호화된 내부 내용을 구분하고 수동 캡처로 판단할 수 없는 것을 설명합니다.
• 암호화가 가려 주는 것과 가려 주지 못하는 것(메타데이터)을 대조표로 정리한다
• 스크린샷(또는 캡처 인용)에 해석을 붙인 비교 보고서 한 부를 완성한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

2-1. 평문(plain text)이란

수동 관찰자는 해당 패킷을 볼 수 있어야 합니다. 같은 Wi-Fi에 있다는 사실만으로 그 접근이 보장되지는 않습니다. 자신의 루프백 서버와 가짜 값으로 캡처 위치에서 보이는 것을 비교하세요.

2-2. HTTPS와 TLS 한눈에 보기

HTTPS는 “HTTP를 TLS(Transport Layer Security)라는 암호화 통로 안에 넣은 것”입니다. 통로를 만드는 과정이 TLS 핸드셰이크입니다.

1. 양쪽이 지원하는 TLS 매개변수를 협상합니다.
2. 클라이언트가 신뢰 정책에 따라 서버 인증서와 요청 호스트 이름을 검증합니다.
3. TLS 버전에 따른 키 교환으로 트래픽 비밀값과 방향별 키를 도출합니다.
4. TLS는 애플리케이션 레코드를 보호하며 끝점은 여전히 평문을 처리합니다.

암호화된 뒤의 패킷을 열어 봐도 나오는 것은 의미 없는 바이트 나열, 즉 암호문(cipher text)입니다.

2-3. 보고서를 쓰는 이유

실무 보안에서 관찰은 절반이고, 나머지 절반은 문서화입니다. 침해 사고 보고서, 진단 결과 보고서 — 전부 “내가 본 것을 남이 재현할 수 있게 적는 기술”입니다. 형식은 단순합니다.

[보고서 뼈대]
1. 실험 목적
2. 실험 환경 (날짜, 운영체제, 도구 버전)
3. 실험 절차
4. 관찰 결과 (캡처 증거 + 해석)
5. 결론 — 암호화가 가려 준 것과 가려 주지 못한 것

3. 따라 하기

3-1. 내 컴퓨터 안에 평문 웹 서버 열기

입력 (터미널 1)

mkdir -p http-lab && cd http-lab
echo "<h1>hello plain world</h1>" > index.html
python3 -m http.server 8000 --bind 127.0.0.1

출력 (화면 예시):

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

읽는 법: “8000번 포트에서 HTTP 서비스 중”이라는 뜻입니다. 이 창은 실험 내내 닫지 마세요. 요즘 인터넷의 웬만한 사이트는 전부 HTTPS라, 평문을 관찰하려면 이렇게 직접 만들어야 합니다.

3-2. 평문 트래픽 캡처 — 글자가 그대로 보인다

입력

# 터미널 2 (캡처)
tshark -i lo -a duration:6 -w plain.pcap
# 캡처가 도는 사이 터미널 3에서
curl -s http://127.0.0.1:8000/ > /dev/null
curl -s -X POST http://127.0.0.1:8000/login -d "username=hacker&password=mypw123" > /dev/null

읽는 법: 127.0.0.1 트래픽은 랜카드를 거치지 않으므로 반드시 루프백(lo, 윈도우는 Npcap Loopback Adapter)에서 캡처합니다. 간이 서버는 POST를 처리하지 못해 501 오류를 냅니다 — 하지만 패킷은 이미 전선에 나갔다는 점이 중요합니다.

3-3. 평문 로그인 — 비밀번호가 훤히 보이는 순간

캡처 파일에서 POST 대화를 통째로 복원해 봅니다.

입력

tshark -r plain.pcap -Y http
tshark -r plain.pcap -q -z follow,tcp,ascii,1

출력 (2026-09-09 실측, 스트림 복원 일부):

POST /login HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: curl/8.5.0
Accept: */*
Content-Length: 32
Content-Type: application/x-www-form-urlencoded

username=hacker&password=mypw123

HTTP/1.0 501 Unsupported method ('POST')
Server: SimpleHTTP/0.6 Python/3.12.3
...

읽는 법: 맨 아래 줄을 보세요. username=hacker&password=mypw123이 평문 그대로 실려 있습니다. 서버가 거절(501)했든 말든, 패킷을 본 사람은 이미 비밀번호를 알았습니다. GUI에서는 POST 패킷 우클릭 → Follow → HTTP Stream으로 같은 창이 뜹니다 (화면 예시). 이것이 증거 1 — 평문 대화 복원 화면입니다.

이 위치에서 캡처한 애플리케이션 데이터가 평문이므로 가짜 HTTP 값이 보입니다. 다른 관찰자의 가시성은 네트워크·캡처 접근에 달려 있으며 같은 Wi-Fi만으로 판단할 수 없습니다.

3-4. HTTPS 트래픽 캡처 — 보이는 것과 보이지 않는 것

이제 암호문 쪽입니다. 공개 사이트에 정상 접속하며 캡처합니다.

입력

tshark -i eth0 -f "tcp port 443" -a duration:10 -w tls.pcap
# 다른 터미널에서
curl -s https://example.com -o /dev/null

출력 (2026-09-09 실측):

    4 0.016170231 192.168.39.82 → 172.66.147.243 TLSv1   583 Client Hello (SNI=example.com)
    6 0.032460886 172.66.147.243 → 192.168.39.82 TLSv1.3 3750 Server Hello, Change Cipher Spec
    7 0.032461144 172.66.147.243 → 192.168.39.82 TLSv1.3 372  Application Data
   10 0.035322790 192.168.39.82 → 172.66.147.243 TLSv1.3 146  Change Cipher Spec, Application Data
   11 0.035690588 192.168.39.82 → 172.66.147.243 TLSv1.3 152  Application Data
   14 0.048524337 172.66.147.243 → 192.168.39.82 TLSv1.3 619  Application Data, Application Data
   ...

TLS 1.3의 암호화된 핸드셰이크 메시지도 application_data라는 외부 레코드 유형을 사용할 수 있습니다. 그 표시만으로 암호화된 내용이 HTTP 요청이라고 입증되지 않습니다. 인증서는 암호화된 핸드셰이크 안에 있습니다. ServerHello 뒤에는 TCP ACK 등도 나타날 수 있습니다.

Application Data 패킷의 내용을 열면 (2026-09-09 실측, 16진 덤프 일부):

0ed0  7e ae 32 45 54 c9 5b 9f 53 1c 24 fc c6 2f 00 33   ~.2ET.[.S.$../.3
0ee0  71 5d 76 25 15 64 6d 78 b2 06 59 82 33 c9 d8 c5   q]v%.dmx..Y.3...
0ef0  65 b8 b5 a5 57 9d 3d d0 77 8b 9b fa 66 79 93 b1   e...W.=.w...fy..

덤프에는 암호화된 레코드 바이트가 보입니다. 트래픽 비밀값 없이는 내부 평문을 알 수 없습니다. application_data라는 외부 유형만으로 암호화된 핸드셰이크와 HTTP 내용을 구분할 수 없습니다.

3-5. 그런데도 보이는 것 — SNI와 메타데이터

암호문 시대에도 새어 나가는 것이 있습니다. Client Hello를 펼쳐 봅시다.

입력

tshark -r tls.pcap -Y "tls.handshake.type == 1" -V | grep -A2 "Server Name"

출력 (2026-09-09 실측):

Server Name Indication extension
    Server Name Type: host_name (0)
    Server Name: example.com

이 캡처에서는 ClientHello의 암호화되지 않은 SNI가 보입니다. 항상 그런 것은 아닙니다. Encrypted Client Hello(ECH)가 협상되면 내부 서버 이름이 보호될 수 있습니다. 목적지 IP, 시간, 크기는 이 관찰 지점에서 여전히 보일 수 있습니다. 이 캡처가 보여 주는 범위만 기술하세요.

올바르게 구성한 TLS는 트래픽 비밀값이 없는 관찰자로부터 전송 중 애플리케이션 내용을 보호합니다. IP·시간·크기는 보일 수 있고 SNI 가시성은 ECH에 따라 달라집니다. 이 관찰만으로 사람이나 특정 행동을 확정할 수 없습니다.

3-6. 인증서 구경 — 자물쇠의 정체

브라우저의 사이트 정보 기능에서 연결과 인증서를 확인하세요. 아이콘·메뉴는 버전에 따라 달라지며 자물쇠 아이콘이 항상 있는 것은 아닙니다. 이 실습을 위해 인증서 경고를 우회하지 마세요.

화면 예시: 인증서 창이 열리며 발급 대상(누구에게), 발급자(누가 보증), 유효 기간이 보입니다.

인증서 검증은 요청 호스트 이름, 신뢰 체인, 유효 기간, 관련 정책을 확인합니다. 그 신뢰 모델 안에서 TLS 상대 키의 인증을 지원하지만 사이트의 콘텐츠·사업·애플리케이션이 선량하다고 보장하지는 않습니다.

3-7. 보고서 조립 — 대조표와 해석 붙이기

문서 도구를 열고 2-3의 뼈대에 맞춰 작성합니다. 핵심은 이 대조표입니다 (오늘 실측으로 검증됨):

각 행에서 캡처에 보이는 사실과 추정을 구분하세요. TLS 버전·분석기에 제공한 키·ECH·캡처 위치가 가시성에 영향을 줍니다. 비교 결과에 그 조건을 함께 기록하세요.

왜: 표는 “내가 본 것”을 “독자가 한눈에 비교할 수 있는 형태”로 바꾸는 장치입니다. 보안 보고서에서 표 하나는 문장 열 줄의 일을 합니다. 각 증거(캡처 인용 또는 스크린샷) 아래에는 반드시 해석 두세 줄을 붙이세요 — 그림은 증거이고, 해석이 주장입니다.

4. 미션과 연습문제

미션 — 《HTTP vs HTTPS 비교 분석 보고서》 완성

1. 실험 목적·환경(날짜, OS, 도구 버전)·절차를 2-3 뼈대로 적습니다.
2. 증거 4건을 붙입니다: ① 평문 대화 복원(Follow Stream) ② 평문 POST 본문의 비밀번호 ③ HTTPS Application Data 암호문 ④ 인증서 창. GUI가 없으면 tshark 출력 인용으로 대체합니다.
3. 각 증거마다 해석 2~3줄을 붙입니다 (“이 화면에서 봐야 할 것은 X이며, 이것은 Y를 의미한다”).
4. 3-7의 대조표를 채우고, “중간에서 바꿔치기” 행까지 포함시킵니다.
5. 결론: TLS가 가려 준 것 2가지 + 가려 주지 못한 것 1가지를 한 문장씩으로 씁니다. 파일명 step85_http_vs_https로 저장합니다.

연습문제

문제 1. 평문 HTTP의 위험을 “엽서”에, HTTPS를 “봉인된 편지”에 비유할 때, 이 비유가 정확히 설명하는 것과 놓치는 것(메타데이터)은 무엇인가요?

문제 2. 서버가 POST를 거절(501)했는데도 비밀번호가 새었다고 말하는 이유는 무엇인가요?

문제 3. TLS 1.3 캡처 목록에 Certificate 줄이 없는 이유는 무엇이며, 이것이 감시자 입장에서 무엇을 어렵게 하나요?

문제 4. HTTPS 통신에서 감시자가 알 수 있는 것을 세 가지 들어 보세요.

- HTTP: the owned plaintext fixture exposes the dummy request and response at this capture point.
- TLS: encrypted records conceal their inner content from this passive observer without keys.
- Metadata: destination IP, timing and sizes may remain visible. SNI visibility depends on ECH.
- Limits: compare the recorded conditions; an outer record type does not prove the inner content type.

6. 흔한 실수와 해결

벽 1. loopback에서 아무것도 안 잡혀요

증상: 127.0.0.1 실험인데 패킷이 0개입니다.

원인: 일반 네트워크 카드를 캡처하고 있습니다. 127.0.0.1 트래픽은 카드를 거치지 않고 운영체제 안에서만 돕니다.
해결: 루프백 전용 인터페이스(리눅스 lo, 윈도우 Npcap Loopback Adapter)를 고르세요. 윈도우에 목록이 없다면 Wireshark를 Npcap 포함으로 재설치해야 합니다.

벽 2. http 필터인데 안 보여요

증상: curl은 성공했는데 http 필터가 조용합니다.

http 필터에 없으면 대상 TCP 포트로 찾아 캡처를 확인하세요. TLS·다른 프로토콜·잘린 데이터·미해석 HTTP일 수 있습니다. 실습 서비스가 HTTP임을 알 때만 Decode As를 사용하세요. TCP가 있다고 포트 인식 문제로 확정되지 않습니다.

벽 3. HTTPS인데 Client Hello도 안 잡혀요

증상: tls 필터가 텅 빕니다.

원인: 브라우저가 이미 열어 둔 연결을 재사용(핸드셰이크는 이미 끝남)하거나 캐시만으로 페이지를 그렸을 수 있습니다.
해결: 브라우저를 완전히 닫았다가 다시 열어 접속하세요. 그래도 안 되면 필터를 tcp.port == 443으로 넓혀 확인합니다. curl로 새 접속을 만드는 것(3-4)이 가장 확실합니다.

벽 4. Application Data가 어떤 건지 못 찾겠어요

증상: 온통 TCP 패킷뿐이라 TLS 레코드를 못 고르겠습니다.

대상 TCP 대화를 따라가며 해석된 TLS 레코드 필드를 확인하세요. TLS 1.3의 application_data 유형에는 암호화된 핸드셰이크나 애플리케이션 내용이 있을 수 있습니다. ServerHello 뒤라는 시간 순서만으로 내용이 분류되지는 않습니다.

벽 5. 보고서가 “스크린샷 나열”이 돼 버려요

증상: 그림만 있고 무엇을 봐야 하는지 모르겠는 문서.

원인: 해석이 빠졌습니다. 그림은 증거이고 주장은 글입니다.
해결: 각 증거 아래 “이 화면에서 봐야 할 것은 X, 이것은 Y를 의미한다” 두 줄 공식을 쓰세요. 나쁜 예 “(스크린샷) 끝” / 좋은 예 “POST 본문에 비밀번호가 평문으로 보인다 — 같은 구간의 패킷을 열람 가능한 누구든 이 값을 읽을 수 있다.”

7. 정리

오늘의 개념

오늘의 명령어

명령어보다 중요한 감각

로컬 HTTP 캡처에는 가짜 요청 내용이 보입니다. 별도의 HTTPS 캡처는 암호화 레코드를 보여 주지만 동일한 요청을 같은 조건으로 다시 보냈음을 입증하지는 않습니다. 올바르게 설정하고 인증한 TLS는 전송 중 기밀성과 무결성을 보호하며 끝점이나 애플리케이션의 신뢰성까지 보장하지는 않습니다.

동시에 오늘의 대조표가 말해 주는 경계도 기억하세요. 자물쇠는 내용을 지키지만 여러분이 어디에 접속했는지까지 숨겨 주지는 않습니다. 그리고 관찰을 해석 붙인 문서로 남기는 일 — 침투 테스트 업계에 “기술이 절반, 보고서가 절반”이라는 말이 있는 이유가 오늘의 마지막 배움입니다.

전부 체크되면 Step 85 완료입니다.