8강 / 20강

도청 — 같은 와이파이에 앉은 사람

패킷 스니핑 · ARP 스푸핑 · 그래서 HTTPS

6강에서 HTTPS 가 통신을 암호화한다고 했습니다. 그럼 암호화하지 않으면 정확히 무슨 일이 벌어질까요? 이번 강의는 도청을 직접 봅니다.

같은 카페 와이파이, 같은 사무실 랜 — 같은 네트워크에 있는 사람은 남의 트래픽을 엿볼 수 있습니다. 어떻게 가능한지, 그리고 왜 HTTPS 가 그걸 막는지 봅시다.

고등학생같은 와이파이에 앉은 사람

6강에서 HTTPS 가 통신을 암호화한다고 했습니다. 안 하면 어떻게 될까요?

같은 네트워크의 누구나 내용을 볼 수 있다

왜 볼 수 있나

네트워크	—
무선	신호가 공중에 퍼진다 ⚠
유선 (허브)	전부에게 뿌린다

평문 통신은 큰 소리로 말하는 것과 같다

무엇이 새나

정보	암호화 안 하면
로그인 비밀번호	그대로 ⚠
세션 쿠키	그대로 — 계정 탈취 (17강)
주고받은 내용	전부

쿠키 하나면 비밀번호 없이도 로그인된다 — 그게 더 무섭다

비유 — 카페에서의 대화

방식	—
큰 소리로 말한다	옆 테이블이 다 듣는다 — HTTP
둘만 아는 암호로	들려도 모른다 — HTTPS ✔

소리를 작게 하는 게 아니라 못 알아듣게 하는 것이다

암호화는 전달을 막는 게 아니라 알아듣지 못하게 하는 겁니다.

고등학생요즘도 그런 일이 있나

"요즘은 다 HTTPS 아닌가?" 라는 물음에 답해 봅시다.

웹은 대부분 HTTPS 다 — 그런데 다른 통로가 남아 있다

아직 평문인 것들

대상	—
내부 서비스	"안전한 망이니까" 라고 방치 ⚠
IoT · 임베디드	—
DNS 조회	어느 사이트를 보는지 드러난다
오래된 앱 · 프로토콜	FTP · Telnet

"내부는 안전하다" 는 가정이 가장 위험하다

왜 위험한가

—	—
공격자가 한 대만 뚫으면	내부에서 전부 도청 ⚠

그래서 요즘은 제로 트러스트 — 내부도 안 믿는다

HTTPS 여도 새는 것

정보	—
접속한 도메인 이름	드러난다 (SNI) ⚠
통신량 · 시각	드러난다
내용	안 드러난다 ✔

"무엇을 봤는지" 는 숨겨도 "어디에 갔는지" 는 남는다

그래서 DoH(암호화 DNS)나 ECH 같은 기술이 나오고 있습니다.

보안은 계속 좁혀 가는 과정이다 — 한 번에 끝나지 않는다

평문은 그대로 보입니다

먼저 tcpdump 로 우리 서버를 지나는 패킷을 들여다봅시다. 80 포트(http)와 443 포트(https)가 어떻게 다르게 보이는지 비교하는 게 핵심입니다.

GET 요청과 응답 본문이 글자 그대로 보입니다.

🖥️ 내 가상 서버 브라우저 안에서 실행 (계산용)

# 80 포트(http)의 패킷을 잡아 봅니다 — 본문이 그대로 보입니다
sudo tcpdump -i enp1s0 -n -A port 80

암호화되어 내용을 볼 수 없습니다 — 이것이 HTTPS 의 효과.

🖥️ 내 가상 서버 브라우저 안에서 실행 (계산용)

# 443 포트(https)는? 손잡이(핸드셰이크)만 보이고 내용은 안 보입니다
sudo tcpdump -i enp1s0 -n port 443

고등학생http 로그인 = 비밀번호를 큰 소리로 외치기

note 의 이 비유를 구체적으로 봅시다.

HTTP 로 보낸 비밀번호는 패킷에 그대로 들어 있다

실제로 이렇게 보입니다

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=user&password=mypassword123

특별한 해독이 필요 없다 — 글자 그대로 보인다 ⚠

"비밀번호만 암호화하면 안 되나"

—	문제
자바스크립트로 해싱해서 보낸다	—
그런데	그 해시가 곧 비밀번호가 된다 ⚠

도청자가 해시를 그대로 보내면 로그인된다 — 소용없다

그리고 더 큰 문제

—	—
중간자가 페이지 자체를 바꿀 수 있다	—
해싱 코드를 지워 버리면	평문으로 오게 만든다 ⚠

평문 통신에서는 어떤 클라이언트 대책도 소용없다

그래서 결론

전송 구간 암호화(HTTPS)가 먼저다 — 대안이 없다

비유 — 봉투 없는 편지

—	—
내용을 암호로 써도	중간에서 편지를 바꿔치기할 수 있다 ⚠
봉인된 봉투	바꿔치기가 드러난다 ✔

기밀성만이 아니라 무결성도 필요하다 — 1강의 CIA

ARP 스푸핑 — '내가 게이트웨이다'라는 거짓말

그런데 공격자는 어떻게 남의 트래픽을 자기 쪽으로 끌어올까요? 여기서 ARP 의 약점이 등장합니다. ARP 는 "그 IP 주소 쓰는 사람 누구예요?"라고 네트워크에 묻는 규약인데, 인증이 없습니다. 아무나 "저요!" 하고 답할 수 있어요.

공격자가 "게이트웨이는 내 MAC 이야"라고 계속 방송하면, 같은 랜의 장비들이 인터넷으로 나가는 패킷을 공격자에게 보냅니다. 이것이 중간자(MITM)예요.

'게이트웨이는 내 MAC' 이라는 거짓 방송이 나갑니다.

🥷 공격자 브라우저 안에서 실행 (계산용)

# 공격자가 게이트웨이 행세를 시작합니다 (시뮬레이션)
arpspoof -t 192.168.10.10 192.168.10.1

한 MAC 이 두 IP 를 갖고 있으면 스푸핑입니다.

🖥️ 내 가상 서버 브라우저 안에서 실행 (계산용)

# 서버에서 ARP 표를 보면 흔적이 남습니다
arp -a

그래서, 어디서나 HTTPS

도청과 중간자를 막는 근본 방어는 암호화입니다. 공격자가 트래픽을 자기 쪽으로 끌어와도, 내용이 HTTPS 로 암호화돼 있으면 읽지도 바꾸지도 못해요. 게다가 인증서(6강) 덕분에 공격자가 가짜 서버로 위장해도 이름이 안 맞아 브라우저가 경고합니다.

ARP 스푸핑 자체를 줄이려면 스위치의 Dynamic ARP Inspection 같은 기능도 있지만, 현실적으로 가장 확실한 방어는 "어차피 다 암호화돼 있어서 훔쳐도 소용없게" 만드는 것입니다.

고등학생중간자 공격 — ARP 스푸핑

도청보다 한 걸음 더 나간 공격입니다.

도청은 듣기만 — 중간자는 바꿀 수도 있다

ARP 스푸핑이 하는 일

단계	—
1	"내가 공유기다" 라고 거짓말
2	피해자의 통신이 공격자를 거친다
3	보고 · 바꾸고 · 넘긴다

양쪽 모두 정상인 줄 안다 — 그래서 "중간자" 다

왜 이런 거짓말이 통하나

—	—
ARP 는 확인 절차가 없다	옛날 설계 ⚠
먼저 말하는 쪽을	믿는다

1980년대 프로토콜에는 인증이 없었다 — 신뢰하는 망을 전제했다

HTTPS 가 막아 줍니다

공격	HTTPS 면
도청	내용을 못 본다 ✔
변조	드러난다 ✔ — 인증서 오류

6강의 인증서 확인이 여기서 결정적이다

⚠ 그래서 인증서 경고를 무시하면 안 됩니다

브라우저 경고	가능한 이유
"이 연결은 비공개가 아닙니다"	설정 실수 또는 중간자 공격 ⚠

"그냥 진행" 을 누르는 습관이 가장 위험하다

비유 — 가짜 안내 데스크

—	—
건물 입구에 가짜 안내원이 앉는다	—
서류를 대신 전달해 준다	보고 · 바꾸고 ⚠
신분증(인증서)을 확인하면	가짜가 드러난다 ✔

🤔 확인 문제

공격자가 ARP 스푸핑으로 내 트래픽을 전부 자기 쪽으로 끌어갔습니다. 하지만 나는 모든 사이트를 HTTPS 로만 씁니다. 공격자는?

🤔 확인 문제

ARP 스푸핑이 가능한 근본 원인은?