HTTPS

웹 클라이언트와 서버 간 통신을 할 때 데이터를 패킷의 형태로 주고받습니다.
그런데 악의적인 해커가 중간에 그 패킷을 가로챘을 때(Intercept) 어떻게 될까요?
패킷 내에 포함된 사용자 아이디와 비밀번호 등 민감 정보를 빼갈 수 있게 되어 보안에 매우 취약하다고 볼 수 있습니다.
이렇게 통신 중간에 끼어들어 데이터를 훔쳐보거나 변조하는 공격을 MITM(Man-In-The-Middle, 중간자 공격)이라고 부릅니다.

해커가 중간에 패킷을 가로채더라도 암호화되어 알 수 없도록 하는 것, 그것이 바로 HTTPS입니다.

암호화 방식 두 가지

HTTPS에서 사용하는 암호화는 크게 두 가지로 나뉩니다.

1. 대칭키 (Symmetric Key)

송신자와 수신자가 같은 키 하나를 공유해서 암호화와 복호화에 모두 사용합니다.

장점
- 알고리즘이 단순하고 연산이 빠르다
- 대용량 데이터 처리에 적합하다

단점
- 키를 상대방에게 어떻게 안전하게 전달할 것인가가 가장 큰 문제 (키 분배 문제)
- 키가 한 번 유출되면 그 키로 암호화된 모든 통신이 노출된다

대표 알고리즘: AES, ChaCha20, 과거에는 DES / 3DES

2. 비대칭키 (Asymmetric Key)

서로 다른 두 개의 키, 즉 공개키(Public Key) 와 개인키(Private Key) 를 한 쌍으로 사용합니다.

공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있다
개인키로 서명한 데이터는 공개키로 검증할 수 있다 → 디지털 서명
장점
- 공개키는 누구에게 공개되어도 안전하므로 키 분배 문제가 해결된다
- 디지털 서명을 통한 신원 확인이 가능하다
단점
- 연산이 복잡해서 대칭키보다 100~1000배 느리다
- 대용량 데이터 암호화에는 부적합하다

대표 알고리즘: RSA, ECDHE, ECC

Q1. “HTTPS는 비대칭키로 통신한다” — 이 말, 정확한가요?

“공개키로 암호화하니까 안전하다”까지는 흔히 알지만, 거기서 멈추면 절반만 맞는 말입니다.

정답: HTTPS는 비대칭과 대칭을 같이 씁니다.

비대칭키 → 처음에 “둘만 아는 비밀키”를 안전하게 합의하는 단계에서만 사용
대칭키 → 그 이후 모든 실제 데이터 통신에 사용

왜 둘 다 쓸까?

앞서 말했듯이 비대칭키는 대칭키보다 100~1000배 느립니다. 매 패킷마다 비대칭으로 암호화하면 서비스가 마비됩니다.

그래서 처음 키 합의만 비대칭으로 안전하게, 그 다음은 빠른 대칭키로 처리하는 거죠.

키 교환은 비대칭으로, 데이터 통신은 대칭으로

이것이 HTTPS의 안전성과 효율성을 동시에 잡는 비결입니다.

참고로 알고리즘은 계속 발전합니다.
비대칭은 RSA → ECDHE로, 대칭은 AES, ChaCha20 등으로 발전했고 앞으로도 진화할 것입니다.
우리가 알아야 할 핵심은 알고리즘 이름이 아니라 “왜 두 방식을 같이 쓰느냐” 입니다.

TLS Handshake — 실제로는 어떻게 동작할까?

SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의 옛 이름입니다.
현재는 TLS 1.2 / 1.3이 표준이지만, 관례상 ‘SSL’이라는 용어가 여전히 널리 쓰입니다.

클라이언트가 HTTPS 서버에 접속할 때 일어나는 과정을 단계별로 보겠습니다.

각 단계를 풀어보면:

Client Hello — 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록, 랜덤값을 서버에 전달
Server Hello + 인증서 — 서버가 사용할 암호화 알고리즘, 자신의 랜덤값, 그리고 SSL 인증서(공개키 포함) 를 응답
인증서 검증 — 클라이언트가 CA의 공개키로 서버 인증서의 서명을 검증
Pre-Master Secret 전송 — 클라이언트가 임의의 비밀값을 만들어, 서버의 공개키로 암호화해서 전송
세션키 생성 — 양쪽 모두 두 랜덤값 + Pre-Master Secret으로 동일한 세션키(대칭키) 를 도출
암호화된 통신 시작 — 이후 모든 데이터는 세션키(대칭키)로 암호화

즉, 비대칭키는 대칭키(세션키)를 안전하게 전달하기 위한 도구일 뿐이고, 실제 통신은 빠른 대칭키로 한다는 것입니다.

Q2. 핸드셰이크가 끝나면 서버는 요청자가 누구인지 알까요?

“TLS = 보안 통신”이니까 서로 신원 확인까지 됐을 거라고 생각하기 쉽습니다.

하지만, 정답은 NO입니다.

일반 TLS는 클라이언트가 서버를 인증할 뿐, 그 반대 방향은 인증하지 않습니다.

구글 입장에서 “지금 접속한 이 사람이 진짜 누구냐”는 따로 로그인을 받아야 알 수 있습니다.
TLS는 “이 서버가 진짜 google.com인지”만 확인해주는 거지, “당신이 누군지”는 모릅니다.

만약 양쪽이 서로 인증서를 주고받아야 하는 경우라면, 그건 mTLS(Mutual TLS)라고 따로 부릅니다. 주로 서버 간 통신이나 회사 내부망에서 씁니다. 모바일 앱이 자기네 API 서버에만 접속하도록 강제할 때도 mTLS를 활용하죠.

Q3. SSL 인증서를 왜 ‘체인(Chain)’이라고 부를까요?

신뢰가 한 단계씩 위임되는 사슬 구조이기 때문에 인증서 체인이라고 부릅니다.

Root CA → 중간 CA → 사이트 인증서

사이트 인증서는 “내가 진짜야”라고 혼자 외칠 수 없습니다.
중간 CA가 “맞아, 얘 진짜야” 서명해주고, 그 중간 CA는 다시 Root CA가 “맞아, 이 중간 CA 진짜야” 서명해줍니다.

즉, 보증인의 보증인의 보증 구조입니다.

그래서 고리 중 하나만 무효가 되어도 (만료, 폐기, 서명 오류 등) 내 사이트는 통째로 ‘신뢰할 수 없는 사이트’가 됩니다. 브라우저에 빨간 경고창이 뜨는 그 상황이죠.

Q4. 그럼 Root CA는 누가 보증하나요?

체인을 따라 한 단계씩 위로 올라가다 보면, 결국 맨 꼭대기에서 막힙니다.
Root CA 위에는 아무도 없으니까요.

정답: Root CA는 자기가 자기를 서명합니다. 이를 Self-signed(자체 서명) 라고 합니다. 면접에서, 이 용어가 입에서 나오느냐 아니냐가 중요합니다.

그럼 우리는 어떻게 Root CA를 신뢰할까요?

OS와 브라우저가 대신 합니다.
OS와 브라우저에는 ‘공인 Root CA 명단(Trust Store)’이 미리 박혀 있고, 해당 OS / 브라우저를 쓰는 순간 우리는 그 명단을 무조건 신뢰하기로 약속한 거예요.
그래서 출처가 의심스러운 브라우저는 함부로 쓰지 말아야 합니다.

e.g. 대표 Root CA: DigiCert, GlobalSign, Let’s Encrypt(무료), Sectigo 등

Q5. 회사가 사내 HTTPS 트래픽을 다 본다고요?

“HTTPS면 암호화되니까 회사도 못 보겠지?”라고 생각하기 쉬운데,
회사 Root CA가 박힌 노트북에서는 다 볼 수 있습니다.

어떻게 가능한 걸까?

회사가 자체 Root CA를 만들어서 직원 노트북에 미리 깔아둠
직원이 외부 사이트(예: google.com)에 접속하면, 회사 프록시 서버가 중간에 끼어들어 가짜 인증서를 그 자리에서 만들어 클라이언트에게 전달
노트북은 회사 Root CA를 신뢰하니까 이 가짜 인증서를 의심 없이 받아들임
프록시는 진짜 google.com과 따로 TLS 연결을 맺고, 중간에서 모든 데이터를 복호화해서 들여다봄

이게 바로 Corporate MITM입니다.
MITM은 일반적으론 공격 기법이지만, 회사 보안 정책상으로는 합법적인 운영입니다. (DLP, 악성코드 차단 등이 목적)
회사 노트북으로 사적인 일 처리할 때 이 점을 기억해두시기 바랍니다.

그 밖에 알아두면 좋은 상식!!

포트 차이: HTTP는 80번, HTTPS는 443번 포트
TLS 1.3: 핸드셰이크 왕복(RTT)을 줄여 더 빠르고, 취약한 구버전 알고리즘을 제거해 더 안전해진 최신 표준
HSTS (HTTP Strict Transport Security): 브라우저가 해당 도메인에 무조건 HTTPS로만 접속하도록 강제하는 응답 헤더
성능 부담은 거의 없다: 과거의 “HTTPS는 느리다”는 인식은 오해. 현대 CPU의 AES 가속과 TLS 1.3 덕분에 사실상 무시할 수준
SEO에도 영향: 구글은 HTTPS 적용 여부를 검색 순위 신호로 활용

요약 정리

HTTPS는 단순히 “암호화한다“가 아니라,

대칭키의 속도 + 비대칭키의 안전한 키 교환을 조합하고
CA 체인을 통한 신원 보증으로 통신 상대가 진짜임을 검증하며
TLS 프로토콜로 이 모든 절차를 표준화한 것

면접 꼬리질문 5개 핵심 답변 정리

질문	핵심 답변
비대칭이냐 대칭이냐?	둘 다 씁니다. 비대칭은 키 교환용, 대칭은 데이터 통신용
핸드셰이크 끝나면 서버가 클라이언트를 인증한 거냐?	아니요. TLS는 서버만 인증합니다. 양방향은 mTLS
왜 ‘체인’이라고 부르나?	사이트 → 중간 CA → Root CA로 이어지는 신뢰의 사슬이기 때문
Root CA는 누가 보증하나?	자기 자신(Self-signed). OS / 브라우저의 Trust Store가 이를 신뢰하기로 약속
회사가 HTTPS 트래픽을 어떻게 보나?	회사 Root CA를 노트북에 미리 심어두면 Corporate MITM이 가능

다음에 누군가 “HTTPS가 뭐예요?”라고 물으면, 이제 자신 있게 풀어 설명해보아요!

[참고]

0 글이 마음에 드시면 하트를 눌러주세요! 행복한 고민이 됩니다!

HTTPS, 어디까지 설명할 수 있나요?

HTTP, 그리고 S가 붙기까지