2. Netzwerksicherheit · 실제 시험 Abschnitt 2.6
2.6. Domain Validation
Bob의 인증서, Eve의 self-signed 인증서 실패, HTTP challenge 탈취를 시험지 1–3번 순서로 구분합니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
2.6. Domain Validation (6 Punkte)
Bob hat eine Domäne bob.net. Er hat außerdem einen Server mit IP-Adresse 4.5.6.7 gemietet. Er möchte auf dem Server einen HTTPS-Server betreiben und möchte daher ein TLS-Zertifikat für bob.net beantragen.
1. Was bestätigt Bobs TLS-Zertifikat? (2 Punkte)
2. Eve hat einen eigenen Server 6.6.6.6 mit einem selbst signierten TLS-Zertifikat für bob.net. Sie hat es durch einen BGP-Angriff geschafft, dass Alice, wenn sie bob.net im Webbrowser eingibt, auf Eves Server umgeleitet wird. Allerdings stellt Eve fest, dass eine TLS-Verbindung von Alice zu Eves Server immer fehlschlägt. Woran liegt das? Was kann Eve machen, damit sich Alice mit Eves Server verbindet? (2 Punkte)
3. Eine CA SecureDomainCertCA, die TLS-Zertifikate ausstellt, verwendet eine HTTP-Challenge (Ablegen eines Token auf fester Adresse der Domain). Wie kann es Eve schaffen, sich bei dieser CA ein TLS-Zertifikat für bob.net zu holen? (2 Punkte)
# 3. Websicherheit / Web Security (54 Punkte)
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 2.6
VISUAL MAP
경로 장악과 인증서 발급 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 bob.net 접속
- 02 BGP redirect
- 03 certificate 검증
- 04 CA challenge
- 05 valid certificate
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 연결이 어느 IP로 향하는지와 TLS 검증을 분리합니다.
- 인증서의 chain, hostname, validity를 확인합니다.
- Server가 대응 private key를 증명해야 함을 적습니다.
- Self-signed가 왜 trust store 검증에 실패하는지 설명합니다.
- CA HTTP challenge traffic까지 장악하면 오발급이 가능한 조건을 씁니다.
ZERO-BASE CONCEPT LESSONS
이 묶음을 풀기 전에 필요한 개념
카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.
기초 개념 01
TLS certificate가 확인하는 것과 확인하지 않는 것
먼저 장면으로 이해해 봅시다. 건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. Certificate은(는) domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다. CA은(는) Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다. Certificate chain은(는) server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다. Hostname verification은(는) 접속한 domain 이름이 certificate에 허용된 이름과 일치하는지 확인하는 절차입니다.
실제 시스템에서는 이렇게 작동합니다. Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.
- URL의 hostname과 certificate의 SAN 이름을 비교한다.
- CA signature와 trust chain을 확인한다.
- Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다.
- Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.
여기서 넘지 말아야 할 경계: 사기 사이트도 자신이 통제하는 domain에 대해서는 valid certificate를 받을 수 있다.
13. TLS certificate·Domain validation·CA 독립 강의 →기초 개념 02
CA의 HTTP domain validation challenge
먼저 장면으로 이해해 봅시다. 집 소유를 확인하려고 임의의 문구를 현관에 붙이라고 했는데, 검사관이 가는 길을 공격자가 가짜 집으로 바꾸면 공격자가 문구를 보여 줄 수 있는 상황이다.
이제 전문 용어를 붙이면 다음과 같습니다. Domain validation은(는) Certificate 신청자가 그 domain을 제어하는지 CA가 확인하는 절차입니다. HTTP challenge은(는) CA가 지정한 token을 domain의 특정 HTTP 경로에서 제공하게 하는 검증 방식입니다. Validation token은(는) 신청자가 domain 제어를 증명하기 위해 올바르게 반환해야 하는 일회성 값입니다. Mis-issuance은(는) 권한 없는 주체에게 certificate가 잘못 발급되는 사건입니다.
실제 시스템에서는 이렇게 작동합니다. CA는 certificate를 발급하기 전에 신청자가 domain을 통제하는지 확인한다. HTTP challenge에서는 CA가 무작위 token을 주고 신청자가 해당 domain의 정해진 URL에 token을 올리게 한다. CA가 DNS로 domain IP를 찾고 HTTP로 token을 읽으면 통제권이 있다고 판단한다. 공격자가 CA의 확인 traffic을 BGP나 DNS로 자신에게 돌리면 거짓 검증을 시도할 수 있다.
- 공격자가 bob.net certificate를 신청해 challenge token을 받는다.
- Token을 자신의 server에 준비한다.
- CA가 bob.net을 확인하는 동안 route 또는 DNS를 조작해 CA traffic을 공격자 server로 유도한다.
- CA가 token을 보고 통제권을 잘못 인정하면 certificate가 발급될 수 있다.
여기서 넘지 말아야 할 경계: 공격은 TLS 암호를 직접 깨는 것이 아니라 certificate 발급 전의 domain validation 경로를 속이는 것이다.
13. TLS certificate·Domain validation·CA 독립 강의 →기초 개념 03
BGP hijack과 longest-prefix routing
먼저 장면으로 이해해 봅시다. ‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. 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으로 광고할 권한이 있는지 검증하는 체계와 절차입니다.
실제 시스템에서는 이렇게 작동합니다. BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.
- 정상 prefix와 공격자가 광고한 prefix를 비교한다.
- 목적지 주소에 두 prefix가 모두 일치하는지 본다.
- 일치하면 prefix length가 더 긴 route를 선택한다.
- 길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.
여기서 넘지 말아야 할 경계: AS_PATH가 짧다는 이유만 보기 전에 longest-prefix match가 먼저 경로 후보를 결정한다는 점을 확인한다.
11. BGP·Prefix·AS_PATH 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- Domain validated certificate가 확인하는 것은?
- Self-signed 인증서가 기본적으로 실패하는 이유는?
- HTTP challenge를 통과하려면 무엇을 통제해야 하나요?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 2.6
2.6. Domain Validation
3개 학습 항목 · 6점
2.6.1 bob.net에 대해 발급된 Bob의 TLS 인증서는 무엇을 확인해 주는가? 기존 71문항 학습 번호 34 · 2점 단답형
2.6.1 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
bob.net에 대해 발급된 Bob의 TLS 인증서는 무엇을 확인해 주는가?
TERMS FOR 2.6.1
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.
작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
TLS server certificate는 공개키, 인증 대상 domain name(SAN), 유효기간, issuer, CA signature를 담는다. 브라우저는 접속한 hostname이 SAN과 일치하고 인증서 chain이 신뢰 root까지 이어지며 기간이 유효한지 검사한다.
Domain Validation 인증서에서 CA는 신청자가
bob.net을 통제하는지 HTTP 또는 DNS challenge 등으로 확인한다. 이는 법적 인물 Bob의 신분증 검사나 회사 평판 심사와 다르다.인증서 자체는 신뢰 CA가 '이 공개키는
bob.net에 사용하도록 인증되었다'고 서명한 문서다. TLS handshake에서 server가 그 공개키에 대응하는 private key를 실제로 소유함을 CertificateVerify 등으로 증명한다.검증이 끝나면 Alice는 인증된
bob.netendpoint와 session keys를 만들고 이후 application data의 기밀성과 무결성을 보호할 수 있다. 이 보호는 TLS 연결의 성질이며 인증서 문서 하나만으로 이미 통신이 암호화되는 것은 아니다.인증서는
bob.net이 항상 IP4.5.6.7을 쓴다는 사실, server가 해킹되지 않았다는 사실, 사이트가 정직하다는 사실, DNS/BGP route가 올바르다는 사실을 보장하지 않는다.2 · 일상 장면으로 먼저 잡기
공인 도장 기관이 'bob.net 간판을 쓰는 가게는 이 자물쇠의 공개 모양을 사용한다'는 증서를 발행하고, 방문 때 가게가 실제 비밀 열쇠를 보여 주는 장면
bob.net→ Certificate SAN의 domain identity비유의 경계 실제 TLS는 private key 자체를 보여 주지 않고 signature로 소유를 증명한다. 또한 Domain Validation은 가게 주인의 법적 신원이나 성품을 확인하지 않는다.
bob.netTLS 신뢰 사슬bob.net↔ Bob의 public key binding에 서명SAN=
bob.net, 기간, CA chain 검증Handshake에서 대응 private key possession 증명
인증 후 기밀성·무결성 있는 통신
IP 4.5.6.7 고정, 운영자 선량함, DNS/BGP 정확성
CA의 certificate assertion, server의 handshake proof, channel의 보안 성질을 세 단계로 나누어 읽는다.
notes.example인증서가 확인하는 범위주어진 것과 목표 Server S가
notes.example용 CA-signed certificate와 대응 private key를 갖고 있고 IP는 바뀔 수 있다. Browser B가 접속한다.B가 URL hostname
notes.example과 certificate SAN을 비교한다.왜? 다른 domain용 인증서 재사용을 탐지하기 위해서다.
중간 결과 SAN에
notes.example이 있어 name check를 통과한다.B가 issuer signature를 따라 신뢰 root까지 chain과 유효기간을 검증한다.
왜? 임의 self-signed key가 아니라 신뢰 CA가 binding에 서명했는지 보기 위해서다.
중간 결과 인증서 assertion이 신뢰된다.
S가 handshake transcript에 대응 private key로 서명한다.
왜? 인증서를 복사한 제3자가 아니라 key holder임을 증명하기 위해서다.
중간 결과 B가 public key로 signature를 검증해 server key possession을 확인한다.
B와 S가 session keys로 application data를 보호한다.
왜? 인증 후 기밀성·무결성 있는 채널을 만들기 위해서다.
중간 결과 중간 네트워크가 내용을 읽거나 바꾸기 어려워진다.
예제 결론 인증서가 domain과 public key를 묶고 handshake가 private key possession을 확인하지만 server의 정직성이나 고정 IP는 증명하지 않는다.
실제 시험으로 옮기기 예제의
notes.example을bob.net으로 바꾸고, certificate assertion과 handshake 결과를 구분해 2점 답을 쓴다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: bob.net에 대해 발급된 Bob의 TLS 인증서는 무엇을 확인해 주는가?
이 문제의 풀이 전략: 이 소문제에서는 인증 대상 → Binding → Handshake 증명 → 연결 결과 → 범위 제한 순서로 진행합니다. 마지막에는 ‘Certificate는 `bob.net` domain identity와 public key를 묶고 handshake가 private key possession을 확인한다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
bob.net에 대해 발급된 Bob의 TLS 인증서는 무엇을 확인해 주는가?
Certificate SAN에 있는 domain identity `bob.net`을 먼저 쓴다.
인증 대상을 IP `4.5.6.7`로 바꾸지 않았는가?
최종적으로 구해야 하는 것
인증서는 Bob의 법적 정체·선량함, server 보안, 고정 IP, DNS/BGP route correctness를 보장하지 않는다.
Bob의 TLS 인증서는 신뢰된 CA가 domain `bob.net`을 인증서의 public key와 결합해 서명했다는 사실을 확인하게 한다. TLS handshake에서는 server가 대응 private key를 소유함을 증명하고, 검증 후 보호된 channel을 만든다. 그러나 Domain Validation 인증서는 사람 Bob의 법적 신원이나 사이트의 정직성을 보장하지 않는다. 또한 IP `4.5.6.7` 자체와 DNS/BGP route의 정확성을 인증하는 문서도 아니다.
사용할 공식·판정 관계
인증 대상 → Binding → Handshake 증명 → 연결 결과 → 범위 제한
CA의 certificate assertion, server의 handshake proof, channel의 보안 성질을 세 단계로 나누어 읽는다.
인증 대상
구체적으로 Certificate SAN에 있는 domain identity
bob.net을 먼저 쓴다.여기서 검산 인증 대상을 IP
4.5.6.7로 바꾸지 않았는가?다음 단계로 여기서 확인한 내용을 다음 ‘Binding’ 단계의 출발점으로 사용합니다.
Binding
구체적으로 신뢰 CA가
bob.net과 certificate public key의 binding에 서명했다고 설명한다.여기서 검산 인증서가 private key를 공개한다고 잘못 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Handshake 증명’ 단계의 출발점으로 사용합니다.
Handshake 증명
구체적으로 실제 TLS 연결에서 Bob server가 대응 private key possession을 증명하면 브라우저가 certificate holder임을 확인한다.
여기서 검산 인증서 문서와 handshake 동작을 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘연결 결과’ 단계의 출발점으로 사용합니다.
연결 결과
구체적으로 검증 후 Alice↔Bob 사이 application traffic은 TLS 기밀성·무결성으로 보호된다.
여기서 검산 인증서만 발급된 순간 이미 모든 traffic이 암호화된다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘범위 제한’ 단계의 출발점으로 사용합니다.
범위 제한
구체적으로 인증서는 Bob의 법적 정체·선량함, server 보안, 고정 IP, DNS/BGP route correctness를 보장하지 않는다.
여기서 검산 certificate validity를 site trustworthiness 전체로 확대하지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
신뢰된 CA가 bob.net이라는 도메인 이름을 인증서 안의 공개키와 결합해 서명했다는 사실을 확인한다. 서버의 선량함이나 콘텐츠의 안전성을 보장하지 않는다.
정답이 이렇게 되는 이유
Bob의 TLS 인증서는 신뢰된 CA가 domain
bob.net을 인증서의 public key와 결합해 서명했다는 사실을 확인하게 한다. TLS handshake에서는 server가 대응 private key를 소유함을 증명하고, 검증 후 보호된 channel을 만든다. 그러나 Domain Validation 인증서는 사람 Bob의 법적 신원이나 사이트의 정직성을 보장하지 않는다. 또한 IP4.5.6.7자체와 DNS/BGP route의 정확성을 인증하는 문서도 아니다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 인증서는
4.5.6.7이 Bob의 안전하고 정직한 server이며 앞으로도 그 IP를 쓴다는 보증이다.왜 틀렸나 일반 hostname certificate의 검증 대상은 SAN의 domain과 public key binding이고 IP와 운영자 평판은 범위 밖이다.
고쳐 말하면 Certificate는
bob.netdomain identity와 public key를 묶고 handshake가 private key possession을 확인한다.한 문제만 더: 개념이 정말 연결됐는지 확인
질문
bob.netserver의 IP가 4.5.6.7에서 4.5.6.8로 바뀌었지만 같은 유효 certificate와 private key를 사용한다면 hostname 검증은 반드시 실패하는가?정답 아니다. 인증서가
bob.net에 유효하고 정상 chain·기간·key proof를 통과하면 일반 hostname 인증은 IP 변경만으로 실패하지 않는다.이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
브라우저가 certificate에서 확인하는 이름은 IP인가 domain인가?
bob.net에 대해 발급된 Bob의 TLS 인증서는 무엇을 확인해 주는가?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/4 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: valid cert가 IP 1.2.3.4를 무조건 신뢰하게 만든다고 쓰기
복구 힌트: 브라우저가 certificate에서 확인하는 이름은 IP인가 domain인가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
신뢰된 CA가 bob.net이라는 도메인 이름을 인증서 안의 공개키와 결합해 서명했다는 사실을 확인한다. 서버의 선량함이나 콘텐츠의 안전성을 보장하지 않는다.
2.6.2 Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오. 기존 71문항 학습 번호 35 · 2점 프로토콜 추적
2.6.2 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오.
TERMS FOR 2.6.2
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.
작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다.
Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다.
server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
BGP hijacking은 packet이 어느 network로 가는지를 바꿀 수 있지만 TLS certificate trust를 자동으로 바꾸지 않는다. Route와 endpoint authentication은 서로 다른 보안 층이다.
Alice가 URL
https://bob.net을 열면 TLS ClientHello에는 보통 SNIbob.net이 들어간다. 응답 server는bob.net을 포함한 certificate와 handshake proof를 보내야 하며 Alice의 browser는 hostname, 유효기간, 신뢰 CA chain을 검사한다.Self-signed certificate는 issuer와 subject가 사실상 같은 key로 서명한 인증서다. Alice의 trust store에 그 certificate 또는 해당 root가 미리 신뢰 대상으로 설치되지 않았다면
bob.net이름이 맞더라도 신뢰 chain을 만들 수 없어 경고와 연결 실패가 난다.Eve가 BGP로 Alice의 packet을 자기 server
6.6.6.6에 도달시키는 데 성공해도 Bob의 certificate private key는 자동으로 얻지 못한다. 그러므로 passive interception이나 transparent MitM은 certificate validation에 막히지만 traffic을 drop해 availability를 깨는 DoS는 가능하다.Alice가 경고 없이 Eve server와 연결하게 하려면 Eve는 신뢰 CA가 서명한
bob.netcertificate와 그 private key를 얻거나, Alice가 Eve의 self-signed certificate/root를 명시적으로 신뢰하게 만들어야 한다. 다음 문항은 첫 방법을 Domain Validation 공격으로 실현하는 과정을 묻는다.2 · 일상 장면으로 먼저 잡기
도로 표지판을 조작해 손님을 가짜 호텔로 데려왔지만, 프런트가 제시한 출입증에 손님이 신뢰하는 기관의 도장이 없어 입장을 거부하는 장면
6.6.6.6→ Eve-controlled serverbob.netcertificate비유의 경계 실제 TLS browser는 chain뿐 아니라 hostname, 기간, key usage, revocation 관련 신호 등을 검사한다. 사용자가 경고를 무시하거나 공격자 root를 설치하면 비유의 보호가 사라질 수 있다.
https://bob.net, SNIbob.netClientHello 송신Traffic이 Bob
4.5.6.7대신 Eve6.6.6.6에 도달Self-signed SAN=
bob.netcertificate 응답Trusted CA chain 없음 → validation failure
CA-signed
bob.netcert+private key 또는 Alice trust 변경Network route 성공과 TLS identity 검증 성공 사이에 별도 경계가 있음을 가운데 certificate check로 읽는다.
Route는 탈취했지만
store.example인증에는 실패주어진 것과 목표 Mallory가 routing을 조작해 Browser B의
store.exampletraffic을 자기 server M으로 보낸다. M은 SAN만store.example인 self-signed certificate를 제시한다.B가 SNI
store.example인 ClientHello를 M에 보낸다.왜? Routing layer는 M까지 packet을 전달했기 때문이다.
중간 결과 Network connection은 M에 도착하지만 아직 server가 인증된 상태는 아니다.
M이 self-signed
store.examplecertificate와 자기 private-key proof를 보낸다.왜? Hostname은 맞추고 자신이 만든 key의 소유는 증명할 수 있기 때문이다.
중간 결과 Name과 key proof는 맞을 수 있지만 issuer가 B의 trust store에 없다.
B가 certificate chain을 trusted root까지 만들려고 한다.
왜? 아무 key나
store.example이라고 주장하는 것을 거부하기 위해서다.중간 결과
unknown issuer/self-signedvalidation error가 나고 protected application connection이 중단된다.Mallory가 진짜 CA-signed
store.examplecertificate를 부정 발급받은 경우를 비교한다.왜? B가 경고 없이 연결하는 데 필요한 추가 조건을 확인하기 위해서다.
중간 결과 Hostname·chain·private-key proof가 모두 맞으면 B가 M을 잘못 신뢰할 수 있다.
예제 결론 Routing control은 server 위치를 바꾸지만 trusted hostname credential이 없으면 TLS authentication을 통과하지 못한다.
실제 시험으로 옮기기 예제 이름을
bob.net, Bob IP를4.5.6.7, Eve server를6.6.6.6으로 바꾸고 ClientHello→self-signed cert→chain failure→필요 조건 순으로 쓴다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오.
이 문제의 풀이 전략: 이 소문제에서는 Network 상태 → TLS sender·message → 실패 검사 → BGP의 한계 → Eve의 필요 조건 → 보안 목표 분리 순서로 진행합니다. 마지막에는 ‘BGP는 packet destination 경로를 바꾸지만 TLS는 여전히 `bob.net` hostname과 CA-signed key binding을 검증한다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오.
Eve의 BGP 공격 때문에 Alice의 `bob.net` traffic이 Eve server `6.6.6.6`에 도달한다고 주어진 결과를 인정한다.
Routing 공격 자체가 실패했다고 답하지 않았는가?
최종적으로 구해야 하는 것
인증 실패로 confidentiality-preserving MitM은 막혀도 Eve가 packet을 drop하면 availability는 여전히 깨질 수 있다.
Alice의 packet이 Eve의 `6.6.6.6`에 도달해도 Eve가 제시한 `bob.net` certificate는 self-signed라 Alice가 신뢰하는 CA chain을 만들 수 없다. 따라서 browser는 TLS certificate validation을 실패시키며 BGP redirect만으로 경고 없는 MitM은 성립하지 않는다. Eve가 연결을 성립시키려면 신뢰 CA가 서명한 `bob.net` certificate와 대응 private key를 얻거나 Alice의 trust store·사용자 판단을 조작해야 한다. 다만 Eve는 traffic을 drop해 DoS를 일으킬 수 있다.
사용할 공식·판정 관계
Network 상태 → TLS sender·message → 실패 검사 → BGP의 한계 → Eve의 필요 조건 → 보안 목표 분리
Network route 성공과 TLS identity 검증 성공 사이에 별도 경계가 있음을 가운데 certificate check로 읽는다.
Network 상태
구체적으로 Eve의 BGP 공격 때문에 Alice의
bob.nettraffic이 Eve server6.6.6.6에 도달한다고 주어진 결과를 인정한다.여기서 검산 Routing 공격 자체가 실패했다고 답하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘TLS sender·message’ 단계의 출발점으로 사용합니다.
TLS sender·message
구체적으로 Alice → Eve로 SNI
bob.netClientHello가 가고 Eve → Alice로 self-signedbob.netcertificate가 온다.여기서 검산 어느 actor가 어떤 certificate를 보내는지 명확한가?
다음 단계로 여기서 확인한 내용을 다음 ‘실패 검사’ 단계의 출발점으로 사용합니다.
실패 검사
구체적으로 Certificate가
bob.net이름을 포함해도 Alice가 신뢰하는 CA의 signature chain이 없으므로 browser validation에서 거부된다.여기서 검산 실패 이유를 단순 IP 불일치로만 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘BGP의 한계’ 단계의 출발점으로 사용합니다.
BGP의 한계
구체적으로 BGP control은 Bob의 certificate/private key를 Eve에게 주지 않으므로 경고 없는 TLS MitM이 자동 성공하지 않는다.
여기서 검산 Route hijack과 key theft를 같은 capability로 취급하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Eve의 필요 조건’ 단계의 출발점으로 사용합니다.
Eve의 필요 조건
구체적으로 Eve가 CA-trusted
bob.netcertificate와 대응 private key를 얻거나 Alice가 Eve certificate/root를 신뢰하도록 속여야 한다.여기서 검산 단순히 self-signed certificate의 domain 글자만 바꾸면 된다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘보안 목표 분리’ 단계의 출발점으로 사용합니다.
보안 목표 분리
구체적으로 인증 실패로 confidentiality-preserving MitM은 막혀도 Eve가 packet을 drop하면 availability는 여전히 깨질 수 있다.
여기서 검산 TLS가 network availability까지 보장한다고 과장하지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
브라우저가 신뢰하는 CA chain이 없어 self-signed 인증서를 거부한다. Eve는 bob.net에 대한 신뢰 가능한 CA 서명 인증서를 얻거나, Alice가 Eve의 인증서를/루트 CA를 명시적으로 신뢰하게 만들어야 한다.
정답이 이렇게 되는 이유
Alice의 packet이 Eve의
6.6.6.6에 도달해도 Eve가 제시한bob.netcertificate는 self-signed라 Alice가 신뢰하는 CA chain을 만들 수 없다. 따라서 browser는 TLS certificate validation을 실패시키며 BGP redirect만으로 경고 없는 MitM은 성립하지 않는다. Eve가 연결을 성립시키려면 신뢰 CA가 서명한bob.netcertificate와 대응 private key를 얻거나 Alice의 trust store·사용자 판단을 조작해야 한다. 다만 Eve는 traffic을 drop해 DoS를 일으킬 수 있다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 BGP가 Alice를 Eve IP로 보냈으므로 browser는 IP가 맞다고 보고 self-signed certificate도 자동 수락한다.
왜 틀렸나 Browser가 인증하는 핵심은 URL hostname과 trusted CA chain이며 route를 선택한 BGP와 별개다.
고쳐 말하면 BGP는 packet destination 경로를 바꾸지만 TLS는 여전히
bob.nethostname과 CA-signed key binding을 검증한다.한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Eve가 traffic을 자기 server로 보내는 데 성공했지만 certificate validation을 못 넘었다. Eve가 여전히 직접 깨뜨릴 수 있는 대표 보안 목표는 무엇인가?
정답 Traffic을 drop하거나 지연시켜 availability를 깨뜨릴 수 있다. 그러나 경고 없는 TLS 기밀성 침해에는 추가 certificate/key 조건이 필요하다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
Eve가 Bob의 IP route를 가져도 Bob domain의 private key까지 가진 것은 아니다.
Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/4 slots
조건 변형: 흐름의 중간 메시지·광고·표 행 하나를 제거하거나 공격자가 바꿨다고 가정하세요. 바로 다음 상태가 무엇인지 sender, receiver, content, security impact 순서로 추적하세요.
고칠 답안: BGP redirect만으로 TLS MitM이 자동 성공한다고 쓰기
복구 힌트: Eve가 Bob의 IP route를 가져도 Bob domain의 private key까지 가진 것은 아니다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
브라우저가 신뢰하는 CA chain이 없어 self-signed 인증서를 거부한다. Eve는 bob.net에 대한 신뢰 가능한 CA 서명 인증서를 얻거나, Alice가 Eve의 인증서를/루트 CA를 명시적으로 신뢰하게 만들어야 한다.
2.6.3 TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가? 기존 71문항 학습 번호 36 · 2점 프로토콜 추적
2.6.3 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가?
TERMS FOR 2.6.3
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.
작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다.
Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다.
server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
CA의 HTTP Domain Validation은 신청자가 특정 domain의 web content를 제어하는지 시험한다. CA는 certificate 신청자에게 예측 불가능한 token과 고정 HTTP path를 주고, 그 path에서 token을 읽을 수 있는지 확인한다.
정상 흐름에서 Bob은
bob.netcertificate를 신청하고 token을bob.net의 지정 위치에 둔다. SecureDomainCertCA는bob.net을 DNS resolve하고 얻은 Bob의 주소로 HTTP GET을 보내며, 응답 body의 token이 pending challenge와 같으면 domain control을 validated로 바꾼다.이 검사는 CA가 실제로 접속한 endpoint를
bob.net이라고 전제한다. Eve가 validation 시점에 CA가 보는 DNS를 조작해bob.net→6.6.6.6으로 만들거나, CA가 Bob의4.5.6.7쪽으로 보낸 packet의 BGP route를 Eve에게 hijack하면 CA의 GET이 Eve server에 도착할 수 있다.Eve는 Bob의 기존 private key를 훔칠 필요가 없다. Eve 자신의 새 key pair로 certificate를 신청하고 CA가 challenge에 속으면 CA는
bob.net과 Eve의 public key를 묶어 서명한다.공격 성공 뒤 Eve는 CA-signed certificate와 대응 private key를 TLS에서 제시할 수 있어 Alice의 hostname·chain·key proof 검사를 통과할 수 있다. 방어에는 CA 관점의 RPKI/ROV, DNSSEC validation, 서로 다른 network 위치에서의 multi-perspective validation과 Certificate Transparency 감시가 서로 다른 공격 경로를 보완한다.
2 · 일상 장면으로 먼저 잡기
허가 기관이 특정 가게 주소에 암호 쪽지를 배달해 답을 확인하는데, Eve가 배달 경로를 자기 가짜 가게로 돌려 같은 암호를 보여 주는 장면
bob.net과 Eve public key를 묶은 CA-signed certificate비유의 경계 실제 CA challenge protocol은 token을 계정 key와 결합하고 redirect·port 정책도 갖는다. 핵심 취약점은 token을 모르는 것이 아니라 CA의 validation traffic endpoint를 공격자가 제어하게 되는 경우다.
bob.netcertificate request, Eve public keyPending HTTP challenge token + fixed path
HTTP GET이 DNS/BGP 조작으로 Eve
6.6.6.6에 도착HTTP 200, 정확한 token response
Pending → Validated →
bob.net/Eve-key certificate issuedCA의 논리적 receiver는 bob.net이지만 실제 network receiver가 Eve가 되는 지점과, 그 뒤 validation state가 잘못 바뀌는 지점을 찾는다.
portal.exampleHTTP challenge를 route hijack으로 가로채기주어진 것과 목표 정상 server O는
portal.example을 운영한다. Mallory server M은 자기 key로 certificate를 신청하며 CA V의 validation traffic에 영향을 줄 BGP capability가 있다.M이 자기 public key를 포함한
portal.examplecertificate request를 V에 보낸다.왜? 최종 certificate가 Mallory의 private key와 함께 사용 가능해야 하기 때문이다.
중간 결과 V가 pending order와 challenge token
T7K및 fixed path를 생성한다.M이 자기 web server의 지정 path에
T7K를 둔다.왜? V의 HTTP request가 M에 오면 올바른 challenge response를 내기 위해서다.
중간 결과 M은 token을 제공할 준비가 된다.
Validation 순간 Mallory가 O를 포함한 prefix의 route를 hijack해 V의 packet을 M으로 유도한다.
왜? V가 DNS로 정상 O 주소를 얻어도 실제 IP packet이 M에게 오게 만들기 위해서다.
중간 결과 V →
portal.examplefixed path의 HTTP GET receiver가 실제로는 M이 된다.M이 HTTP 200 response body로
T7K를 V에 보낸다.왜? V의 pending token과 정확히 일치시켜 domain control 검사를 속이기 위해서다.
중간 결과 V는 challenge state를 valid로 잘못 바꾼다.
V가
portal.example과 M의 public key를 묶은 certificate에 서명한다.왜? V는 HTTP endpoint 제어를 domain control 증거로 받아들였기 때문이다.
중간 결과 M은 trusted certificate와 대응 private key를 모두 갖게 된다.
예제 결론 CA가 보는 HTTP endpoint를 잠시 탈취하면 공격자는 Bob의 key 없이도 자기 key에 대한 피해 domain certificate를 발급받을 수 있다.
실제 시험으로 옮기기 예제 값을 CA
SecureDomainCertCA, domainbob.net, 정상 IP4.5.6.7, Eve server6.6.6.6으로 바꾸어 certificate request부터 issuance까지 actor와 message를 적는다.이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가?
이 문제의 풀이 전략: 이 소문제에서는 신청과 key 소유자 → Challenge 생성 → Eve endpoint 준비 → CA 관점 redirect → HTTP 메시지 교환 → CA 상태 오판 → Certificate 발급과 후속 TLS 순서로 진행합니다. 마지막에는 ‘CA 관점의 DNS/BGP path를 조작하고 CA가 준 token을 Eve server에서 응답해 domain control을 오인시킨다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가?
Sender Eve → Receiver SecureDomainCertCA로 `bob.net` certificate request와 Eve의 public key를 보낸다.
Bob의 기존 private key를 훔쳐야 한다고 전제하지 않았는가?
최종적으로 구해야 하는 것
CA가 `bob.net`과 Eve public key를 묶어 서명하고, Eve는 대응 private key와 함께 Alice에게 제시해 trusted chain 검사를 통과할 수 있다.
Eve는 자기 public key로 `bob.net` certificate를 신청하고 SecureDomainCertCA가 준 HTTP challenge token을 `6.6.6.6`의 지정 path에 둔다. CA가 검증할 때 CA 관점의 DNS를 조작하거나 Bob의 `4.5.6.7` 쪽 route를 BGP hijack해 CA의 HTTP GET이 Eve server에 도착하게 한다. Eve가 올바른 token을 응답하면 CA는 Eve가 `bob.net`을 통제한다고 잘못 판단해 challenge를 valid로 바꾼다. 그 결과 CA는 `bob.net`과 Eve의 public key를 묶은 trusted certificate를 발급하고 Eve는 대응 private key로 TLS를 성립시킬 수 있다.
사용할 공식·판정 관계
신청과 key 소유자 → Challenge 생성 → Eve endpoint 준비 → CA 관점 redirect → HTTP 메시지 교환 → CA 상태 오판 → Certificate 발급과 후속 TLS
CA의 논리적 receiver는 bob.net이지만 실제 network receiver가 Eve가 되는 지점과, 그 뒤 validation state가 잘못 바뀌는 지점을 찾는다.
신청과 key 소유자
구체적으로 Sender Eve → Receiver SecureDomainCertCA로
bob.netcertificate request와 Eve의 public key를 보낸다.여기서 검산 Bob의 기존 private key를 훔쳐야 한다고 전제하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Challenge 생성’ 단계의 출발점으로 사용합니다.
Challenge 생성
구체적으로 CA가 Eve에게 one-time token과
bob.net의 fixed HTTP path를 주고 order 상태를 pending으로 둔다.여기서 검산 Token을 Eve가 임의로 정한다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Eve endpoint 준비’ 단계의 출발점으로 사용합니다.
Eve endpoint 준비
구체적으로 Eve가 server
6.6.6.6의 지정 path에서 그 token을 HTTP response로 제공하도록 설정한다.여기서 검산 Token이 실제 어느 receiver에서 제공되는지 명확한가?
다음 단계로 여기서 확인한 내용을 다음 ‘CA 관점 redirect’ 단계의 출발점으로 사용합니다.
CA 관점 redirect
구체적으로 Validation 순간 Eve가 CA가 보는 DNS를
bob.net→6.6.6.6으로 조작하거나 Bob4.5.6.7을 포함한 route를 BGP hijack해 CA의 GET을 Eve에게 보낸다.여기서 검산 Alice의 route만 바꾸고 CA의 validation path는 그대로 두지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘HTTP 메시지 교환’ 단계의 출발점으로 사용합니다.
HTTP 메시지 교환
구체적으로 CA → apparent
bob.net으로 fixed-path GET, 실제 receiver Eve → CA로 HTTP 200과 정확한 token body가 돌아온다.여기서 검산 Sender·receiver와 token 방향이 뒤바뀌지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘CA 상태 오판’ 단계의 출발점으로 사용합니다.
CA 상태 오판
구체적으로 CA는 token match를 보고 Eve가
bob.net을 통제한다고 잘못 판단해 pending challenge를 validated로 바꾼다.여기서 검산 단순 redirect만으로 자동 발급된다고 쓰지 않고 token check를 포함했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Certificate 발급과 후속 TLS’ 단계의 출발점으로 사용합니다.
Certificate 발급과 후속 TLS
구체적으로 CA가
bob.net과 Eve public key를 묶어 서명하고, Eve는 대응 private key와 함께 Alice에게 제시해 trusted chain 검사를 통과할 수 있다.여기서 검산 발급된 certificate key가 Bob이 아니라 Eve의 key라는 점을 썼는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Eve manipulates DNS/BGP/routing seen by the CA, serves the expected HTTP challenge token, and the CA incorrectly concludes control over bob.net.
정답이 이렇게 되는 이유
Eve는 자기 public key로
bob.netcertificate를 신청하고 SecureDomainCertCA가 준 HTTP challenge token을6.6.6.6의 지정 path에 둔다. CA가 검증할 때 CA 관점의 DNS를 조작하거나 Bob의4.5.6.7쪽 route를 BGP hijack해 CA의 HTTP GET이 Eve server에 도착하게 한다. Eve가 올바른 token을 응답하면 CA는 Eve가bob.net을 통제한다고 잘못 판단해 challenge를 valid로 바꾼다. 그 결과 CA는bob.net과 Eve의 public key를 묶은 trusted certificate를 발급하고 Eve는 대응 private key로 TLS를 성립시킬 수 있다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 Eve는 Alice만 BGP로 redirect하면 CA도 자동으로 속거나, Bob의 private key를 먼저 훔쳐야 challenge를 통과한다.
왜 틀렸나 Certificate 발급 판단을 하는 관찰자는 CA이므로 CA의 validation traffic이 Eve에게 가야 한다. 새 certificate는 Eve 자신의 key에 발급될 수 있어 Bob key 절도는 필수가 아니다.
고쳐 말하면 CA 관점의 DNS/BGP path를 조작하고 CA가 준 token을 Eve server에서 응답해 domain control을 오인시킨다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 CA가 유럽·미국·아시아 세 network에서 동시에 같은 HTTP token을 확인하는 multi-perspective validation을 하면 한 지역만 영향을 주는 BGP hijack은 왜 어려워지는가?
정답 한 관찰 지점만 Eve로 향하고 나머지는 정상 Bob server로 가면 token 결과가 일치하지 않아 CA가 발급을 중단할 수 있기 때문이다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
CA는 bob.net의 실제 주인을 보는 것이 아니라, 자신이 접속한 bob.net URL에서 token이 보이는지를 본다.
TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/5 slots
조건 변형: 흐름의 중간 메시지·광고·표 행 하나를 제거하거나 공격자가 바꿨다고 가정하세요. 바로 다음 상태가 무엇인지 sender, receiver, content, security impact 순서로 추적하세요.
고칠 답안: Eve가 Bob의 private key를 훔쳐야만 한다고 생각하기
복구 힌트: CA는 bob.net의 실제 주인을 보는 것이 아니라, 자신이 접속한 bob.net URL에서 token이 보이는지를 본다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Eve manipulates DNS/BGP/routing seen by the CA, serves the expected HTTP challenge token, and the CA incorrectly concludes control over bob.net.