HTTPS 동작 원리: RSA 키 교환부터 ECDHE, MITM

Об этом предложении

"HTTPS는 어떻게 동작할까?"를 파고들다 보니 생각보다 엮인 개념이 많았어. 내가 헷갈렸던 순서 그대로 정리해 볼게. "공개키로 암호화하면 되는 거 아냐?" → "근데 그 공개키를 어떻게 믿지?" → "중간에 해커가 끼어들면?" 1. HTTP는 왜 위험할까? HTTP는 데이터를 평문 그대로 보내. 클라이언트와 서버 사이에는 공유기, ISP, 라우터 같은 장비가 잔뜩 있는데, 그중 어디서든 패킷을 들여다보면 세 가지 문제가 생겨. 문제 설명 도청 비밀번호, 카드번호를 그대로 읽을 수 있어 변조 중간에서 내용을 바꿔치기할 수 있어 사칭 내가 접속한 서버가 진짜인지 알 수 없어 그래서 HTTP를 TLS 로 감싼 게 HTTPS야. 참고로 SSL은 TLS의 옛 이름이야. SSL은 보안 문제 때문에 이제 안 쓰고, 지금은 TLS 1.2랑 1.3을 써. 2. 먼저 알아둘 것: 대칭키와 비대칭키 대칭키 암호화 키랑 복호화 키가 같아. 빨라. 근데 이 키를 상대한테 어떻게 안전하게 전달하지? 이게 문제야. 비대칭키 (공개키 / 개인키) 키가 한 쌍 이야. 공개키는 누구한테나 줘도 되고, 개인키는 주인만 가져. 용도는 두 가지야. 암호화 : 공개키로 잠그면 개인키로만 열 수 있어. 서명 : 개인키로 서명하면 공개키로 "진짜 주인이 서명했네"를 확인할 수 있어. 대신 느려. 그래서 TLS는 둘을 섞어 써. 비대칭키로 안전하게 준비하고, 실제 데이터는 빠른 대칭키(세션 키)로 주고받는 거지. 3. 처음 떠올린 방법: RSA 키 교환 (TLS 1.2까지) 제일 직관적인 방법은 이거야. 서버는 통신 전에 미리 공개키랑 개인키 를 만들어 둬. 공개키는 암호화용, 개인키는 복호화용이야. 클라이언트는 세션 키(대칭키) 를 만들어. 이 키 하나로 암호화도 하고 복호화도 해. 클라이언트는 서버한테 공개키 를 받아. 그 공개키로 세션 키를 암호화해서 서버한테 안전하게 보내. 서버는 개인키로 복호화 해서 세션 키를 얻게 돼. 이제 클라이언트랑 서버는 같은 세션 키로 암호화해서 보내고, 받은 쪽은 복호화해. 중간에서 엿봐도 암호화된 세션 키만 보이고, 개인키가 없으니 못 풀어. 완벽해 보이지? 실제 TLS에서는 세션 키를 그대로 보내지 않고, pre-master secret 이라는 비밀값을 보낸 다음 양쪽이 이 값으로 세션 키를 만들어. 그래도 "공개키로 암호화해서 보내고 개인키로 푼다"는 원리는 같아. 근데 3번 에 큰 구멍이 있어. 4. 문제: 그 공개키, 진짜 서버 거 맞아? 클라이언트는 받은 공개키가 진짜 서버 건지 확인할 방법이 없어. 여기서 MITM(Man-In-The-Middle, 중간자 공격) 이 가능해지는 거야. MITM 공격 시나리오 해커가 공용 와이파이 같은 데서 클라이언트랑 서버 사이에 끼어들었다고 해 보자. 해커가 서버 공개키를 가로채고, 자기 공개키 를 서버 건 척 클라이언트한테 줘. 클라이언트는 아무것도 모르고 해커 공개키 로 세션 키를 암호화해. 해커는 자기 개인키로 복호화 해서 세션 키를 얻어. 그다음 서버 공개키로 다시 암호화 해서 서버한테 넘겨. 클라이언트도 서버도 정상적으로 통신하는 줄 알지만, 해커는 대화를 다 읽고 바꿀 수도 있게 돼. 암호화는 잘 되고 있었어. 문제는 "누구랑 암호화하고 있는지"를 확인 안 한 거 지. 5. 해결: CA와 인증서 그럼 "이 공개키는 진짜 naver.com 거야"라고 믿을 만한 제3자가 보증 해 주면 되겠지? 그게 CA(Certificate Authority, 인증기관) 야. 5-1. 인증서는 어떻게 발급될까? 서버가 키 쌍을 직접 만들어. 개인키는 절대 서버 밖으로 안 나가. CA가 대신 만들어 주면 CA도 개인키를 알게 되니까 안 되거든. 서버가 공개키 + 도메인 정보 를 담은 요청서( CSR )를 CA에 보내. CA(정확히는 등록 업무를 하는 RA )가 "이 도메인 주인이 진짜 너 맞아?" 를 확인해. 확인되면 CA가 인증서를 만들어. 인증서 내용(도메인, 서버 공개키, 유효기간, 발급자 등)으로 해시값 을 만들고, 그 해시값에 CA 개인키로 서명 해. 인증서 내용 + CA 서명 을 묶어서 서버한테 발급해. 처음엔 "CA가 서버 공개키를 암호화 한다"고 이해했는데 틀렸어. 서버 공개키는 인증서 안에 그대로 보여. CA가 하는 건 암호화가 아니라 서명 이야. 내용을 숨기려는 게 아니라 "CA가 이 내용을 보증하고, 중간에 안 바뀌었다" 를 증명하려는 거지. 5-2. 인증서에는 뭐가 들어 있을까? 5-3. 그럼 클라이언트는 인증서를 어떻게 검증할까? OS랑 브라우저에는 믿을 수 있는 CA의 인증서(공개키) 가 미리 들어 있어. 이걸 루트 인증서 저장소 라고 해. Microsoft, Apple, Google, Mozilla가 각자 기준을 정해 두고, 그걸 통과한 CA만 이 목록에 넣어줘. 검증은 이렇게 해. 인증서 내용으로 직접 해시값을 계산 해. 인증서에 붙은 서명을 미리 갖고 있던 CA 공개키로 검증 해. 서명이 맞으면 → CA가 보증한 내용이고, 중간에 안 바뀌었다 는 거지. 추가로 확인해. 도메인 이 지금 접속하려는 주소랑 같아? 유효기간 은 안 지났어? 실제로는 루트 CA가 직접 서명하지 않고 루트 CA → 중간 CA → 서버 인증서 순으로 서명이 이어져. 이걸 인증서 체인 이라고 하고, 브라우저는 이 체인을 따라 올라가서 루트 저장소에 있는 CA까지 닿는지 확인해. 5-4. 근데 인증서는 복사하면 그만 아냐? 맞아. 인증서는 공개된 정보라 해커도 naver.com의 진짜 인증서를 그대로 복사해서 보여줄 수 있어. 근데 해커한테는 그 인증서 속 공개키의 개인키 가 없잖아. RSA 키 교환 에서는 클라이언트가 인증서 속 공개키로 세션 키를 암호화해서 보내. 해커는 개인키가 없으니 못 풀어. TLS 1.3 에서는 서버가 핸드셰이크 내용에 자기 개인키로 서명 해서 보내( CertificateVerify ). 해커는 개인키가 없으니 이 서명을 못 만들어. 인증서 로 "이 공개키는 naver.com 거"라는 걸 확인하고, 개인키를 쓸 수 있는지 로 "지금 대화하는 상대가 그 주인"이라는 걸 확인하는 거야. 둘 다 있어야 신원 확인이 끝나. 5-5. 그럼 MITM은 어떻게 막히는 걸까? 해커가 할 수 있는 건 두 가지인데, 둘 다 실패해. 해커의 시도 결과 자기 공개키 로 가짜 인증서를 만들어 보여줌 믿을 만한 CA 서명이 없거나 도메인이 안 맞아서 브라우저가 경고 를 띄워 진짜 인증서를 복사 해서 보여줌 개인키가 없어서 복호화도 서명도 못 해 6. 남은 문제: 개인키가 나중에 털리면? RSA 키 교환엔 문제가 하나 더 있어. 서버 개인키 하나로 모든 세션 키를 풀 수 있다 는 거야. 해커가 오늘 암호화된 통신을 전부 녹화 해 뒀다가 몇 년 뒤에 서버 개인키를 훔치면? → 녹화해 둔 세션 키를 복호화해서 → 과거 대화를 전부 풀 수 있어. 그래서 나온 게 ECDHE 야. 6-1. ECDHE: 세션 키를 아예 안 보낸다 핵심은 "세션 키를 암호화해서 보내지 말고, 양쪽이 각자 계산해서 같은 값을 얻자" 는 거야. 작은 숫자로 직접 해 보면 바로 이해돼. (원조인 DH 방식이고, ECDHE는 거듭제곱 대신 타원곡선 연산을 쓸 뿐 원리는 같아.) 1 미리 공개된 숫자 표준으로 정해져 있어서 브라우저랑 서버 코드에 이미 들어 있어. g = 5, p = 23 ( mod 23 은 23으로 나눈 나머지) 2 각자 비밀 숫자를 골라 (절대 안 보냄) 클라이언트: a = 6 서버: b = 15 3 공개값을 계산해서 주고받아 클라이언트: 56 mod 23 = 8 → 서버한테 보내 서버: 515 mod 23 = 19 → 클라이언트한테 보내 4 받은 공개값에 내 비밀 숫자로 계산해 클라이언트: 196 mod 23 = 2 서버: 815 mod 23 = 2 둘 다 2가 나와. 이게 공유 비밀값이야. 왜 같은 값이 나올까? 클라이언트: 196 = (515)6 = 5^(15×6) 서버: 815 = (56)15 = 5^(6×15) 곱하는 순서만 다르지 결국 둘 다 5^(a×b)를 계산한 거야. 엿본 사람은 왜 못 구할까? 엿본 사람은 5, 23, 8, 19만 알아. 공유 비밀값을 구하려면 "5를 몇 번 거듭제곱해야 8이 되지?"를 풀어야 하는데, 실제로는 수백 자리 숫자를 써서 현실적으로 못 풀어. 6-2. 전방 비밀성 (Forward Secrecy) ECDHE의 E(Ephemeral) 는 "일회용"이란 뜻이야. 비밀 숫자를 연결할 때마다 새로 만들고 끝나면 버려. 그리고 서버 개인키는 이제 세션 키 계산엔 안 쓰고, 신원 증명(서명)에만 써. 그래서 나중에 개인키가 털려도 과거 대화는 안전 해. RSA 키 교환 ECDHE 세션 키 클라이언트가 만들어서 암호화해 보냄 안 보내고 양쪽이 각자 계산 서버 개인키 역할 세션 키 복호화 신원 증명(서명)만 개인키 유출 시 과거 대화까지 다 풀림 과거 대화는 안전 TLS 1.3 제거됨 이것만 남음 6-3. 그럼 ECDHE만 있으면 MITM도 막힐까? 아니야. ECDHE만으로는 MITM을 못 막아. 해커가 중간에서 클라이언트랑은 해커 공개값으로, 서버랑은 또 다른 해커 공개값으로 각각 키 교환을 하면, 연결 두 개를 따로 맺고 중계 할 수 있거든. 4장에서 본 공격이랑 똑같은 구조야. 그래서 TLS 1.3에서는 서버가 ECDHE 공개값이 들어 있는 핸드셰이크 전체에 개인키로 서명 해. 해커가 공개값을 바꿔치기하면 서명이 안 맞아서 바로 들통나. ECDHE는 "도청"을 막고, 인증서 + 서명은 "사칭(MITM)"을 막아. 둘 다 있어야 해. 7. TLS 1.3 핸드셰이크 전체 흐름 단계 하는 일 ClientHello / ServerHello 쓸 방식을 맞추고, 랜덤값이랑 키 교환 재료를 주고받아 세션 키 계산 각자 공유 비밀값을 계산하고 랜덤값이랑 섞어서 세션 키를 만들어 Certificate 서버가 인증서를 보내고, 브라우저가 CA 체인으로 검증해 CertificateVerify 서버가 개인키로 서명해서 인증서의 진짜 주인이라는 걸 증명해 Finished 지금까지 주고받은 메시지가 안 바뀌었는지 서로 확인해 TLS 1.2는 왕복이 2번 필요했는데, TLS 1.3은 키 교환 재료를 첫 인사에 바로 실어서 왕복 1번(1-RTT) 으로 줄였어. 세션 키가 일찍 만들어지니까 인증서부터 암호화 되는 것도 차이점이야. 헷갈리는 키 세 종류 키 언제 만들어지나 용도 ECDHE 비밀 숫자 / 공개값 연결마다 새로 만들고 버림 공유 비밀값 계산 서버 개인키 / 공개키 서버가 미리 만들어서 오래 보관 신원 증명 (서명) 세션 키 핸드셰이크 중에 양쪽이 계산 실제 데이터 암호화 (대칭키) 8. 그래도 MITM이 성공하는 경우 TLS가 MITM을 막아 주긴 하는데, 이런 경우엔 뚫릴 수 있어. 사용자가 인증서 경고를 무시할 때 "이 연결은 안전하지 않습니다"에서 "계속 진행"을 누르면 해커 인증서를 믿게 돼. 해커의 루트 인증서가 PC에 설치됐을 때 악성 프로그램이 루트 저장소에 가짜 CA를 넣으면, 그 CA로 서명한 인증서는 다 통과해. (회사 보안 프록시가 트래픽을 검사하는 것도 사실 이 방식이야.) CA가 해킹당하거나 잘못 발급했을 때 이걸 대비해서 인증서 폐기 목록(CRL, OCSP)이나, 발급 기록을 공개하는 Certificate Transparency 같은 장치가 있어. 처음 접속을 HTTP로 할 때 (SSL Stripping) http:// 로 들어오는 순간 해커가 HTTPS로 넘어가는 걸 막고 평문으로 중계할 수 있어. 서버가 HSTS 헤더로 "앞으로 무조건 HTTPS로만 접속해"라고 알려줘서 막아. 9. 정리 HTTP는 평문이라 도청, 변조, 사칭 에 취약해. 공개키로 세션 키를 암호화해 보내면 도청은 막지만, 공개키가 진짜인지 모르면 MITM에 당해. 그래서 CA가 서버 공개키에 서명한 인증서 로 공개키 주인을 보증하고, 서버는 개인키 서명 으로 자기가 그 주인이라는 걸 증명해. RSA 키 교환은 개인키가 털리면 과거 대화까지 풀려서, TLS 1.3은 세션 키를 아예 안 보내는 ECDHE 만 남겼어. 결국 비대칭키로 신원 확인이랑 키 합의를 하고, 실제 데이터는 대칭키(세션 키)로 빠르게 암호화 하는 거야.