한국어
메뉴

HTTPS란?

HTTP를 TLS로 보호한 통신. 주고받는 내용의 암호화, 변조 검출, 서버 인증서에 의한 서버 인증을 수행한다. URL은 https://로 시작하며, 기본 포트 번호는 443. 요청이나 응답의 형태는 HTTP와 같고, 그 아래에 TLS 계층이 들어간다.

일본어 명칭: HTTPS

HTTPS은(는) 네트워크 기초, 웹 기술 기초, 정보 보안 기초 등 6개 분야의 연습 문제 12개에 나와요.

분야: 웹 기술 기초

연결 과정

브라우저는 먼저 서버와 TCP 연결을 만들고(HTTP/3에서는 QUIC), 이어서 TLS 핸드셰이크를 수행합니다. 브라우저는 사용할 수 있는 암호 방식과 키 교환에 쓰는 값, 접속하려는 서버의 이름(SNI)을 보내고, 서버는 자신의 인증서와 키 교환 값을 돌려줍니다. 양쪽은 ECDHE 등의 키 교환으로 통신할 때마다 새로운 공통 키를 만들고, 브라우저는 서버의 인증서를 확인합니다. 그 후의 HTTP 요청과 응답은 AES-GCM 등의 대칭 키 암호로 암호화와 변조 검출을 하면서 전송됩니다. TLS 1.3에서는 핸드셰이크가 1왕복으로 끝납니다.

인증서로 서버를 확인한다

서버 인증서는 도메인 이름과 공개 키의 쌍을 인증 기관(CA)이 디지털 서명으로 보증한 것입니다. 브라우저는 인증서가 신뢰하는 루트 인증 기관까지 서명의 연쇄로 이어져 있는지, 유효 기간 안인지, URL의 호스트 이름과 일치하는지, 폐기되지 않았는지를 확인합니다. 이로써 도중에 통신을 가로채 진짜 서버로 위장하는 중간자 공격을 막습니다. 확인할 수 없을 때는 브라우저가 경고를 내고 연결을 중단합니다.

지킬 수 있는 것과 지킬 수 없는 것

HTTPS는 페이지 내용, URL의 경로와 쿼리, 헤더, 쿠키를 도중의 도청과 변조로부터 지킵니다. 반면 서버의 IP 주소, 통신량이나 시각은 보이며, 접속 대상의 도메인 이름도 DNS 질의나 SNI로부터 알 수 있는 경우가 있습니다. 또한 HTTPS는 통신 경로를 지킬 뿐 사이트 운영자가 신뢰할 수 있다는 것은 보증하지 않습니다. 가짜 사이트도 인증서를 받아 HTTPS로 만들 수 있기 때문입니다. HTTP로의 다운그레이드를 막는 HSTS나, HTTPS일 때만 쿠키를 보내는 Secure 속성 등과 조합해 씁니다.

도전해 보기: HTTPS 관련 문제

Kubernetes 클러스터에서 하나의 호스트 이름으로 도착한 HTTPS 요청 중 경로가 /api로 시작하는 것은 api의 Service로, 그 밖의 것은 web의 Service로 분배하고 싶다. 이 분배 규칙을 정하는 데 적합한 리소스는?

  1. AIngress
  2. BReplicaSet
  3. Ctype: ClusterIP인 Service
정답과 해설 보기

정답: A. Ingress

Ingress는 호스트 이름이나 URL 경로에 따라, 클러스터 밖에서 온 HTTP나 HTTPS 요청을 각 Service에 분배하는 규칙을 정하는 리소스이며, TLS 종단도 여기서 설정할 수 있습니다. 실제로 요청을 받아 분배하는 것은 클러스터에 도입한 Ingress 컨트롤러(리버스 프록시로 동작하는 것)입니다. type: ClusterIP인 Service는 클러스터 안에서만 사용할 수 있는 접속 대상으로, 경로로 분배하는 기능은 없습니다. ReplicaSet은 Pod의 수를 유지하기 위한 것으로, 통신의 분배와는 관계가 없습니다.

RTT(왕복 시간)가 100 ms인 웹 서버에 HTTPS(TCP 위의 TLS 1.3)로 새로 접속하여, 첫 요청을 보내고 응답을 받기 시작할 때까지 걸리는 시간에 가장 가까운 것은? DNS 이름 해석은 끝났으며, 서버의 처리 시간과 데이터 전송 시간은 무시한다.

  1. A약 100 ms
  2. B약 300 ms
  3. C약 200 ms
정답과 해설 보기

정답: B. 약 300 ms

먼저 TCP의 3-way 핸드셰이크에 1왕복이 걸립니다(클라이언트는 마지막 ACK와 함께 TLS의 첫 메시지를 보낼 수 있습니다). 다음으로 TLS 1.3 핸드셰이크에 1왕복, 그 후 HTTP 요청과 응답에 1왕복이 걸려 합계 3왕복, 3 × 100 = 300 ms입니다. TLS 1.2에서는 키 교환에 2왕복이 걸리므로 4왕복인 400 ms가 됩니다. 이 대기 시간은 거리로 정해지는 RTT의 횟수로 결정되므로 회선의 대역폭을 늘려도 짧아지지 않습니다. HTTP/3에서 사용되는 QUIC은 전송 계층과 암호의 핸드셰이크를 1왕복으로 합치고, 재접속할 때는 첫 왕복에서 데이터를 보내는 방법(0-RTT)도 제공합니다.

자주 묻는 질문

HTTP와 HTTPS의 차이는 무엇인가요?

HTTPS는 HTTP의 주고받기를 TLS로 암호화하고 변조 검출과 서버 인증을 더한 것입니다. 요청이나 응답의 형태는 같으며, 기본 포트 번호는 HTTP가 80, HTTPS가 443입니다. HTTP에서는 도중의 기기가 내용을 읽거나 바꿔 쓸 우려가 있습니다.

HTTPS 사이트라면 안전하다고 할 수 있나요?

통신 도중에 엿보이거나 바꿔 쓰이지 않는다는 것과 그 도메인 이름의 서버에 연결되어 있다는 것은 확인할 수 있습니다. 그러나 사이트 자체가 진짜인지, 악의가 없는지까지는 보증하지 않습니다. 피싱 사이트도 HTTPS를 쓸 수 있으므로 도메인 이름을 잘 확인해야 합니다.

HTTPS 암호화에는 공개 키 암호와 대칭 키 암호 중 어느 것을 쓰나요?

둘을 나누어 씁니다. 핸드셰이크에서는 키 교환과 인증서에 의한 인증에 공개 키 암호 기술을 쓰고, 실제 데이터는 거기서 만든 키를 사용해 처리가 빠른 대칭 키 암호로 암호화합니다.

해설 속 HTTPS

HTTPS이(가) 나오는 문제 (12)

  1. Kubernetes 클러스터에서 하나의 호스트 이름으로 도착한 HTTPS 요청 중 경로가 /api로 시작하는 것은 api의 Service로, 그 밖의 것은 web의 Service로 분배하고 싶다. 이 분배 규칙을 정하는 데 적합한 리소스는?
  2. RTT(왕복 시간)가 100 ms인 웹 서버에 HTTPS(TCP 위의 TLS 1.3)로 새로 접속하여, 첫 요청을 보내고 응답을 받기 시작할 때까지 걸리는 시간에 가장 가까운 것은? DNS 이름 해석은 끝났으며, 서버의 처리 시간과 데이터 전송 시간은 무시한다.
  3. HTTPS(HTTP를 TLS로 보호한 통신)로 보호되는 것으로 올바른 것은?
  4. NAPT를 수행하는 라우터(외부 공인 주소는 198.51.100.7) 안쪽에 있는 단말 A(192.168.1.10)가 출발지 포트 50000으로 웹 서버 203.0.113.5의 443번 포트에 접속했다. 라우터는 출발지를 198.51.100.7의 포트 61000으로 변환했다. 웹 서버가 돌려보내는 응답 패킷의 목적지는?
  5. 프로토콜과 그 서버가 표준으로 사용하는 포트 번호의 조합으로 올바른 것은?
  6. 위의 헤더로 설정된 Cookie에 대한 설명으로 올바른 것은?
  7. Service Worker에 대한 설명으로 올바른 것은?
  8. 리버스 프록시에 대한 설명으로 올바른 것은?
  9. 게시판 웹 애플리케이션에서 이용자가 게시한 글 안의 스크립트가 다른 열람자의 브라우저에서 실행되어 버리는 취약점이 있었다. 이 취약점의 이름과 근본적인 대책의 조합으로 올바른 것은?
  10. 웹 애플리케이션에서 로그인 전과 후에 같은 세션 ID를 계속 사용하면, 공격자가 미리 준비한 세션 ID를 이용자가 사용하게 하고, 이용자가 로그인한 뒤 그 ID로 이용자를 사칭할 우려가 있다. 이 공격에 대한 대책으로 가장 적절한 것은?
  11. 1 GiB = 2³⁰바이트, 1 EiB = 2⁶⁰바이트로 한다. 블록 길이가 64비트인 블록 암호(3DES 등)를 CBC 모드로 사용하여, 하나의 키로 대량의 데이터를 암호화한다. 암호문 블록을 무작위 64비트 값으로 간주할 때, 생일 역설에 의해 같은 암호문 블록 쌍이 나타날 확률을 무시할 수 없게 되는 데이터양의 기준은?
  12. WAF(웹 애플리케이션 방화벽)에 대한 설명으로 올바른 것은?

관련 용어

HTTP(하이퍼텍스트 전송 프로토콜) URL TLS 쿠키(Cookie) IP 주소(IP Address) 크로스 사이트 스크립팅(XSS) 리버스 프록시(Reverse Proxy) DNS(도메인 네임 시스템) 포트 번호(Port Number) Kubernetes

용어집으로 돌아가기