CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

13. TLS certificate·Domain validation·CA 완전 초보 강의

비유, 단계별 예시, 자체 흐름도, 강의 스크립트 원본, 시험 답안까지 한 페이지에서 연결합니다.

시험 구조와 출제 신호Crypto / AuthNetwork / DNS / BGP / TLSWeb / Software SecurityPrivacy / Forensics / SecLab

CSS 1타 강사 · CONCEPT 13/25

Browser는 HTTPS 서버가 진짜 그 domain의 서버인지 어떻게 확인할까요?

Browser는 certificate chain, hostname, validity, server의 private-key possession을 확인합니다. BGP로 traffic만 Eve에게 돌려도 Eve가 bob.com의 valid certificate/private key가 없으면 TLS 검증은 실패합니다. 하지만 CA의 HTTP challenge 경로까지 Eve가 가로채 token을 제공하면 잘못된 인증서 발급 위험이 생깁니다.

전문 용어를 보기 전에 이 장면부터 잡으세요

택시가 잘못된 건물로 데려가도, 문 앞 직원이 올바른 신분증을 못 보여 주면 들어가지 않는 것과 같습니다.

TLS는 올바른 이름과 키를 확인하지 인터넷 경로의 진실을 보장하지 않습니다

00

한 장면으로 문제를 시작해 봅시다

이번 페이지에서 끝까지 따라갈 예시

사용자가 https://bob.com에 접속했지만 BGP 공격으로 traffic이 Eve에게 향한 상황을 생각합니다.

비유와 실제 시스템을 정확히 연결하기

  • 잘못된 건물로 데려간 길 안내BGP route hijack
  • bob.com 이름과 public key가 적힌 신분증TLS certificate
  • 신분증의 secret을 실제로 가진 증명private-key possession in handshake

이 예시에서 사람·장치·데이터·화살표를 먼저 찾습니다. 아직 용어를 완벽히 몰라도 “누가 무엇을 가지고, 어떤 처리를 거쳐, 무엇이 달라지는가”를 말할 수 있으면 출발점은 충분합니다.

01

긴 이름을 작은 용어로 분리하기

한 제목에 여러 단어가 들어 있어도 같은 기능을 뜻하지 않습니다. 아래 카드를 하나씩 읽고 각 용어의 대상과 역할을 따로 잡으세요.

TLS certificate가 확인하는 것과 확인하지 않는 것

Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.

TERMS FROM ZERO

TLS certificate가 확인하는 것과 확인하지 않는 것 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

Certificate

domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다.

CA

Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다.

Certificate chain

server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다.

Hostname verification

접속한 domain 이름이 certificate에 허용된 이름과 일치하는지 확인하는 절차입니다.

CA의 HTTP domain validation challenge

CA는 certificate를 발급하기 전에 신청자가 domain을 통제하는지 확인한다. HTTP challenge에서는 CA가 무작위 token을 주고 신청자가 해당 domain의 정해진 URL에 token을 올리게 한다. CA가 DNS로 domain IP를 찾고 HTTP로 token을 읽으면 통제권이 있다고 판단한다. 공격자가 CA의 확인 traffic을 BGP나 DNS로 자신에게 돌리면 거짓 검증을 시도할 수 있다.

TERMS FROM ZERO

CA의 HTTP domain validation challenge 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

Domain validation

Certificate 신청자가 그 domain을 제어하는지 CA가 확인하는 절차입니다.

HTTP challenge

CA가 지정한 token을 domain의 특정 HTTP 경로에서 제공하게 하는 검증 방식입니다.

Validation token

신청자가 domain 제어를 증명하기 위해 올바르게 반환해야 하는 일회성 값입니다.

Mis-issuance

권한 없는 주체에게 certificate가 잘못 발급되는 사건입니다.

BGP hijack과 longest-prefix routing

BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.

TERMS FROM ZERO

BGP hijack과 longest-prefix routing 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

BGP hijack

잘못되거나 악의적인 route announcement로 traffic이 다른 AS로 향하게 되는 사건입니다.

Longest-prefix match

Router가 목적지 IP를 포함하는 route 중 가장 구체적인 prefix를 우선하는 forwarding 규칙입니다.

Origin AS

BGP path에서 해당 prefix를 최초로 광고한 AS입니다.

RPKI / ROV

어떤 AS가 prefix를 origin으로 광고할 권한이 있는지 검증하는 체계와 절차입니다.

02

실제 시스템에서는 이 순서로 움직입니다

모바일에서는 그림 안을 좌우로 움직이며 번호 순서대로 읽으세요.

예시를 단계별로 해체하기

  1. 1단계Server가 hostname과 public key가 포함된 certificate chain을 보냅니다.
  2. 2단계Browser가 trusted root까지 signature chain을 검증합니다.
  3. 3단계Certificate의 hostname과 접속한 bob.com이 일치하는지 확인합니다.
  4. 4단계Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명합니다.
  5. 5단계Eve가 route만 통제하고 valid certificate와 private key가 없다면 TLS 검증은 실패합니다.
  6. 6단계CA domain-validation challenge까지 가로채면 잘못된 certificate 발급 위험이 생깁니다.

이 단계들은 시험 답안에서 원인과 결과가 빠지지 않도록 만든 설명 순서입니다.

손으로 따라가는 초보 예제

BGP가 Eve에게 데려가도 Browser가 경고하는 이유

사용자는 `https://bob.com`을 입력했지만 route 공격으로 TCP 연결은 Eve server에 도착합니다.

  1. 1단계Eve는 network route를 바꿔 connection을 자기 server로 받을 수 있습니다.
  2. 2단계Browser는 여전히 URL의 hostname `bob.com`을 기대합니다.
  3. 3단계Eve가 valid bob.com certificate를 보내지 못하면 hostname 또는 chain 검증이 실패합니다.
  4. 4단계남의 certificate만 복사해도 대응 private key가 없으면 handshake proof를 만들 수 없습니다.
  5. 5단계따라서 route control만으로 정상 TLS impersonation이 자동 성공하지 않습니다.
  6. 6단계하지만 Eve가 CA의 HTTP challenge traffic까지 통제해 token을 제공하면 잘못된 certificate 발급 위험이 생깁니다.

그래서 무엇을 배웠나? Routing이 어디로 연결할지 정하고 TLS가 연결된 상대의 hostname/key를 검증합니다. 두 계층의 성공 조건을 분리해야 합니다.

03

관련 개념도 하나씩 따로 이해하기

TLS certificate가 확인하는 것과 확인하지 않는 것

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · 건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.

정확한 뜻 · Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.

  1. 1단계URL의 hostname과 certificate의 SAN 이름을 비교한다.
  2. 2단계CA signature와 trust chain을 확인한다.
  3. 3단계Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다.
  4. 4단계Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.

CA의 HTTP domain validation challenge

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · 집 소유를 확인하려고 임의의 문구를 현관에 붙이라고 했는데, 검사관이 가는 길을 공격자가 가짜 집으로 바꾸면 공격자가 문구를 보여 줄 수 있는 상황이다.

정확한 뜻 · CA는 certificate를 발급하기 전에 신청자가 domain을 통제하는지 확인한다. HTTP challenge에서는 CA가 무작위 token을 주고 신청자가 해당 domain의 정해진 URL에 token을 올리게 한다. CA가 DNS로 domain IP를 찾고 HTTP로 token을 읽으면 통제권이 있다고 판단한다. 공격자가 CA의 확인 traffic을 BGP나 DNS로 자신에게 돌리면 거짓 검증을 시도할 수 있다.

  1. 1단계공격자가 bob.net certificate를 신청해 challenge token을 받는다.
  2. 2단계Token을 자신의 server에 준비한다.
  3. 3단계CA가 bob.net을 확인하는 동안 route 또는 DNS를 조작해 CA traffic을 공격자 server로 유도한다.
  4. 4단계CA가 token을 보고 통제권을 잘못 인정하면 certificate가 발급될 수 있다.

BGP hijack과 longest-prefix routing

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · ‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.

정확한 뜻 · BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.

  1. 1단계정상 prefix와 공격자가 광고한 prefix를 비교한다.
  2. 2단계목적지 주소에 두 prefix가 모두 일치하는지 본다.
  3. 3단계일치하면 prefix length가 더 긴 route를 선택한다.
  4. 4단계길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.

04

강의 스크립트 원본과 연결하기

WebPKI chain validation과 domain validation attack를 보여 주는 대표 슬라이드입니다. 먼저 위의 초보 설명을 읽고, 원본에서는 같은 개념이 어떤 기호와 독일어·영어 용어로 표현되는지 확인하세요.

TLS certificate·Domain validation·CA 관련 강의 스크립트 대표 슬라이드
원본 Vorlesung/09.pdf · p.10, p.11, p.15, p.16 · WebPKI chain validation과 domain validation attack
  • 09.pdf · p.10, p.11, p.15, p.16

05

시험 함정과 답안에 적용하기

  • TLS certificate가 확인하는 것과 확인하지 않는 것 · 사기 사이트도 자신이 통제하는 domain에 대해서는 valid certificate를 받을 수 있다.
  • CA의 HTTP domain validation challenge · 공격은 TLS 암호를 직접 깨는 것이 아니라 certificate 발급 전의 domain validation 경로를 속이는 것이다.
  • BGP hijack과 longest-prefix routing · AS_PATH가 짧다는 이유만 보기 전에 longest-prefix match가 먼저 경로 후보를 결정한다는 점을 확인한다.

서술형 답안 골격

route control, certificate possession, CA challenge control을 별도 조건으로 나눠 confidentiality와 availability 결과를 씁니다.

정의 → 등장 주체 또는 입력 → 작동 순서 → 보안 효과 → 조건과 한계 순서로 쓰고, 위 단계별 예시에서 필요한 문장을 골라 붙이세요.

30초 자가 확인

책을 덮고 “Browser는 HTTPS 서버가 진짜 그 domain의 서버인지 어떻게 확인할까요?”에 대해 핵심 용어 두 개, 작동 단계 세 개, 대표 함정 하나를 말해 보세요.

다음 개념으로 넘어가기 전 확인

  1. Valid certificate만 복사해도 impersonation이 안 되는 이유는?
  2. Hostname verification은 무엇과 무엇을 비교하는가?
  3. CA HTTP challenge가 공격받으면 어떤 추가 위험이 생기는가?