Foundry
보안
중급
핵심

HTTPS와 TLS 핸드셰이크

자물쇠 아이콘 뒤에서 실제로 벌어지는 일

HTTPS와 TLS 핸드셰이크

TLS 1.3 핸드셰이크 (1-RTT)

Client                     Server
  |-- ClientHello --------->|  지원 암호 + 키 공유
  |<- ServerHello ----------|  선택 암호 + 키 공유
  |<- Certificate, Finished-|  인증서 + 서명
  |-- Finished ------------>|
  |==== 암호화 통신 ========|
  • 1.2는 2-RTT, 1.3은 1-RTT다. 1.3은 RSA 키 교환과 취약 알고리즘을 제거했다
  • 비대칭키는 신원 확인과 키 합의에만 쓰고, 데이터는 대칭키로 암호화한다(성능)

무엇을 보장하나

항목수단
기밀성대칭키 암호화
무결성AEAD 인증 태그
신원인증서 체인 검증

실무 포인트

  • 장애 원인 1순위는 알고리즘이 아니라 인증서 만료다. 자동 갱신과 만료 알림을 함께 둔다
  • HSTS 헤더로 첫 요청의 평문 리다이렉트 구간을 없앤다
  • 사내 인증서를 쓰려고 검증을 끈 코드가 그대로 배포되는 사고가 흔하다
  • 로드밸런서에서 TLS를 종료하면 내부 구간은 평문이다. 내부 암호화 여부를 설계에 명시한다
면접에서 이렇게 나옵니다

Q.HTTPS인데도 중간자 공격이 가능한 경우는 언제인가요?

암호화는 되어도 상대가 진짜인지 확인하는 단계가 무너지면 통합니다.

상황왜 뚫리나
인증서 검증을 건너뜀앱이나 클라이언트가 오류를 무시하도록 설정된 경우
신뢰 저장소에 공격자 인증서가 설치됨사내 프록시나 악성 프로그램이 루트 인증서를 심는다
첫 접속이 평문 HTTP그 순간 HTTPS 로 가는 것을 막고 가로챈다
인증 기관이 잘못 발급도메인 소유자가 아닌데 발급된 인증서
도메인 이름 검증 누락유효한 인증서지만 다른 도메인의 것

세 번째가 실무에서 가장 흔합니다. 그래서 HSTS 를 걸어 브라우저가 처음부터 HTTPS 로만 접속하게 하고, 사전 등록 목록에 올리면 첫 접속까지 보호됩니다.

흔한 실수: HTTPS 를 켜면 끝이라고 답하는 것. HTTPS 는 암호화와 인증 두 가지를 하고, 뚫리는 지점은 대개 인증 쪽입니다. 앱이라면 인증서 고정을 추가로 고려합니다.

Q.TLS 1.3에서 핸드셰이크가 1-RTT로 줄어든 이유를 설명해주세요

협상과 키 교환을 한 번에 합쳤기 때문입니다.

버전왕복하는 일
TLS 1.21왕복지원 암호 목록을 주고받아 무엇을 쓸지 정한다
TLS 1.22왕복정한 방식으로 키를 교환한다
TLS 1.31왕복클라이언트가 첫 메시지에 추측한 키 교환 값을 함께 보내고, 서버가 그 값으로 바로 키를 만들어 응답한다

가능해진 이유는 선택지를 줄였기 때문입니다. 취약한 방식과 옛 키 교환 방식을 제거해 클라이언트가 미리 추측해도 맞을 확률이 높아졌습니다. 추측이 틀리면 한 번 더 왕복합니다.

재접속에는 세션 정보를 재사용해 0왕복도 가능하지만, 첫 데이터가 재전송 공격에 노출될 수 있어 상태를 바꾸지 않는 요청에만 씁니다.

흔한 실수: 암호화가 강해져서 빨라졌다고 답하는 것. 알고리즘 속도가 아니라 왕복 횟수가 줄어든 것이 이유이고, 편도 지연이 큰 환경에서 체감이 큽니다.

Q.비대칭키만으로 전 구간을 암호화하지 않는 이유는?

너무 느립니다. 비대칭 연산은 대칭 연산보다 수백에서 수천 배 비쌉니다.

방식상대 속도쓰는 곳
비대칭 (RSA, 타원곡선)느리다신원 확인과 키 교환. 한 번만
대칭 (AES)빠르다. 하드웨어 가속도 있다실제 데이터 전송

10MB 파일을 비대칭으로 암호화하면 서버 CPU 가 감당하지 못합니다. 그래서 비싼 방식으로 한 번, 싼 방식으로 계속이라는 구조가 나옵니다.

비대칭키가 해결하는 문제는 속도가 아니라 처음 만난 상대와 사전 공유 없이 공통 키를 만드는 것입니다. 그 문제만 풀고 바로 대칭키로 넘깁니다.

흔한 실수: 비대칭키가 더 안전하니 계속 쓰면 좋다고 답하는 것. 같은 보안 강도를 기준으로 보면 대칭키가 훨씬 짧은 키로 같은 강도를 냅니다. 안전성 차이가 아니라 역할 분담입니다.

Q.로드밸런서에서 TLS를 종료하는 구성의 트레이드오프는 무엇인가요?

관리와 성능을 얻고 내부 구간의 보호를 잃습니다.

얻는 것잃는 것
인증서를 한곳에서 관리한다로드밸런서 뒤 구간이 평문이 된다
애플리케이션 서버의 암복호 부담이 없다클라이언트 IP 와 프로토콜 정보를 헤더로 전달해야 한다
L7 라우팅과 캐싱이 가능하다로드밸런서가 평문을 보므로 신뢰 경계가 그곳으로 옮겨진다

내부 구간을 어떻게 다룰지가 판단 지점입니다.

상황내부 구간 처리
같은 VPC 안이고 규제가 없다평문 허용. 가장 단순하고 빠르다
민감 정보나 규제 대상내부도 TLS 로 다시 감싼다
전 구간 무결성이 필요로드밸런서가 복호화하지 않고 그대로 전달한다 (L4)

마지막 방식은 안전하지만 경로 기반 라우팅과 캐싱을 포기해야 합니다.

흔한 실수: 내부망은 안전하다고 전제하는 것. 내부에서 옆으로 번지는 공격이 흔하고, 규제 심사에서도 구간 암호화를 요구하는 경우가 많습니다.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

읽었으면 문제로 확인해보세요

보안 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.