요약

  • LACNIC의 RPKI 트러스트 앵커 페이지는 공개 호스트에/rpki/lacnic.tal과/rpki/lacnic-as0.tal을 표시하지만, 저장된 링크는 두 개의/innovaportal/file/4983/1/대상을 가리킵니다.
  • 8월 30일, 표시된 두 주소는 모두 HTTP 200,text/html, 7,014바이트와 동일한 SHA-256을 반환했습니다. 두 링크 대상은 서로 다른 502바이트 및 518바이트 TAL 텍스트 파일을 반환했습니다.
  • 일반 TAL과 AS0 TAL은 서로 다른 트러스트 앵커 인증서를 명명했으며, 두 인증서 URL 모두 회수 가능했습니다. 따라서 근거는 레포지토리 장애, 무효 키 또는 검증기 실패가 아니라 라벨/대상 배포 불일치를 보여줍니다.
  • TAL 게시 영수증은 페이지가 인쇄하는 것과 링크하는 것을 모두 검사한 뒤, 미디어 타입, TAL 문법, 아티팩트 해시, 명명된 인증서, 정정 계보를 하나의 공개 판본에 결합해야 합니다.

동일한 지시의 두 가지 실행 경로

LACNIC의 공개 페이지 제목은RPKI Trust Anchors - TAL입니다. 이 페이지는 일반 LACNIC TAL의 역할을 설명한 다음, AS0 정책을 위한 별도의 TAL을 제시합니다. 끝부분에서 파일 두 개를 두 링크에서 내려받을 수 있다고 안내합니다.

표시 텍스트는 모호하지 않습니다:

  • LACNIC 공개 호스트의/rpki/lacnic.tal
  • LACNIC 공개 호스트의/rpki/lacnic-as0.tal

그러나 콘텐츠 4984에 대한CMS 기록은 다른 동작을 보존하고 있습니다. 첫 번째 라벨의 href는/innovaportal/file/4983/1/lacnic.tal이고, 두 번째는/innovaportal/file/4983/1/lacnic-as0.tal을 가리킵니다. LACNIC의 현재프런트엔드 환경은innova.lacnic.net/innovaportal을 Innovaportal 기반으로 선언합니다.

이는 미묘하지만 재현 가능한 분기를 만들어냅니다. 링크를 따라가면 브라우저는 레거시 콘텐츠 대상을 해석합니다. 화면에 표시된 단어를 복사하면 요청은 새 사이트의/rpki/경로로 갑니다. 사람에게는 이 동작들이 서로 바꿔 쓸 수 있는 것처럼 보입니다. 기계에게는 서로 다른 응답 문법을 가진 서로 다른 URL입니다.

두 개의 성공한 HTTP 응답은 두 개의 TAL이 아니었다

2026년 8월 30일 04:48 UTC에 캐시를 우회한 요청이 두 표시 주소 모두로 보내졌습니다.일반 표시 주소는 HTTP 200과text/html을 반환했습니다.AS0 표시 주소도 마찬가지였습니다.

각 응답은 7,014바이트를 담았고, SHA-256은 모두7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416였습니다. 각각 동일한 최종 수정 시각, 8월 28일 13:20:15 GMT를 실었습니다. 바이트는 두 개의 TAL 문서가 아니라 LACNIC의 HTML 애플리케이션 셸이었습니다.

공통 타임스탬프는 유용한 응답 메타데이터이며, 불일치의 시작 시점이 아닙니다. 이 캡처는 두 경로가 이렇게 얼마나 오래 동작했는지, 다른 곳의 캐시는 어떻게 응답했는지, 누구든 라벨을 복사했는지를 확립하지 않습니다. 또한 200 응답이 요청된 객체를 유효하게 만들지 않습니다. HTTP 성공은 서버가 하나의 표현을 반환했다는 것만 말합니다. 그 표현이 TAL 문법을 충족한다는 것은 말하지 않습니다.

이 구분은.tal로 끝나는 파일명이 무인 회수를 유도하기 때문에 중요합니다. 상태 코드와 지연 시간만 기록하는 헬스 체크는 두 주소 모두 정상으로 표시할 것입니다. 인증서 URI의 순서 있는 집합 뒤에 공개키 자료가 이어지기를 기대하는 검사는 두 HTML 응답을 즉시 기각할 것입니다.

클릭 대상은 두 개의 실제 아티팩트를 보존한다

근거의 다른 절반은 이 발견이 장애 주장으로 변질되지 않게 막습니다. 실제 일반Innovaportal 대상은 HTTP 200,application/aux, 502바이트, SHA-256d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a를 반환했습니다. 그 처음 두 줄은 LACNIC 일반 트러스트 앵커 인증서의 HTTPS 및 rsync 위치를 명명합니다.

AS0 대상은 HTTP 200,application/aux, 518바이트, SHA-256671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff를 반환했습니다. 이 파일은 AS0 레포지토리 경로 아래의 다른 인증서를 명명하고 다른 공개키 자료를 담고 있습니다.

명명된 두 HTTPS 인증서도 이어서 회수되었습니다.일반 인증서는 1,166바이트,AS0 인증서는 1,160바이트를 반환했습니다. 서로 다른 바이너리 객체였습니다.

이 일련의 과정은 배포 계층의 비대칭을 확립합니다. 어느 인증서가 잘못 발급되었다거나, 어느 키가 틀렸거나, 의존 당사자가 무언가를 기각했거나, 어느 경로가 변경되었다는 것을 확립하지 않습니다. 페이지 자체도 대부분의 검증 도구가 이미 필요한 TAL 파일을 포함하고 있다고 말합니다. 다운스트림 영향은 발견되지 않았습니다.

TAL은 접미사 이상이다

RFC 8630은 TAL에 단순하지만 중대한 구조를 부여합니다: 하나 이상의 순서 있는 인증서 URI, 빈 줄, 그리고 트러스트 앵커의 Base64 인코딩된 SubjectPublicKeyInfo. 의존 당사자는 인증서를 회수하고, 그것이 현재 유효한 자체 서명 RPKI CA 인증서인지 검증하며, 공개키가 TAL과 일치하는지 확인합니다.

이 순서는 최소 다섯 가지 상태를 분리합니다: URL이 해석되었다; HTTP 표현이 도착했다; 표현이 TAL로 파싱되었다; 명명된 인증서를 회수할 수 있었다; 인증서의 키가 일치했다. 어느 하나도 “요청이 200을 반환했다”는 진술로 대체될 수 없습니다.

현재 LACNIC 페이지는 여섯 번째 상태를 드러냅니다: 독자에게 인쇄된 주소와 링크가 활성화하는 주소가 다를 수 있습니다. HTML은 그 차이를 허용하고, 리디렉션이나 다운로드 서비스는 이를 정당하게 흔히 사용합니다. 문제는 href가 레거시 저장소를 사용한다는 것이 아닙니다. 문제는 페이지가 운영자에게 어떤 URL이 그 파일이라고 말하면서, 실제로는 다른 URL에 의존해 그 파일을 전달한다는 점입니다.

보통의 웹 브로슈어라면 그것은 미관상의 문제일 수 있습니다. 부트스트랩 신뢰 자료에서 라벨은 운영 데이터입니다. 라벨은 스크립트, 티켓, 런북, 구성 검토, 인시던트 노트에 복사됩니다. 클릭할 때만 작동하는 URL은 복사할 때 작동하는 URL과 동일한 게시 객체가 아닙니다.

가장 강한 선의적 해석

근거는 절제된 설명을 지지합니다. LACNIC의 새 프런트엔드는 두/rpki/*.tal경로에 동일한 애플리케이션 셸을 제공하는 반면, CMS는 작동하는 레거시 파일 대상을 유지합니다. 일반 TAL과 AS0 TAL 바이트는 여전히 서로 다르고, 그 안에 명명된 인증서도 계속 이용 가능합니다. 이는 신뢰 자료의 파괴가 아니라 경로 별칭 또는 콘텐츠 마이그레이션 불일치로 보입니다.

표시 라벨을 해석 대상과 동일하게 만들거나, 두 표시 경로가 각각의 TAL을 제공하거나 리디렉션하도록 구성함으로써 수정할 수 있습니다. LACNIC은 어느 아키텍처든 선택할 수 있습니다. 공개 요건은 클릭, 복사, 자동 회수가 동일한 선언된 아티팩트로 수렴한다는 것뿐입니다.

라벨을 조용히 바꾸면 미래의 사용은 복구되지만, 이전 스크립트가 무엇을 받았는지에 대한 기록은 남지 않습니다. 짧은 정정 또는 기계 판독 가능한 영수증은 관찰을 사건으로 부풀리지 않으면서 보존할 수 있습니다. 어느 페이지 판본이 바뀌었는지, 어느 별칭이 정식인지, 두 회수 경로가 언제부터 동일한 TAL 문법을 반환하기 시작했는지 명시할 수 있습니다.

라벨, 동작, 객체를 위한 하나의 영수증

간결한 게시 영수증은 이 부류의 표류가 배포되기 어렵게 만들 수 있습니다. 각 다운로드 요소에 대해 페이지와 콘텐츠 버전, 표시 라벨, 원시 href, 완전 해석된 대상, 기대되는 미디어 타입, 아티팩트 역할—일반 또는 AS0—을 기록합니다.

카나리아는 그런 다음 표시 URL과 해석된 대상 모두를 회수합니다. 상태, 콘텐츠 타입, 바이트 길이, 강한 다이제스트를 저장하고; 기대되는 TAL 문법을 파싱하고; 순서 있는 인증서 URI와 공개키를 추출하고; 선호되는 인증서를 회수하며; 그 인증서가 현재 유효하고 자체 서명되며 키가 일치하는지 기록합니다. 불일치가 있으면 새 페이지 판본을 차단하거나 좁은 배포 경보를 발생시켜야 하며, RPKI가 무효라고 선언해서는 안 됩니다.

정정에는 기억이 필요합니다. 영수증은 이전 페이지 해시, 이전 URL 쌍, 탐지 시각, 사유 범주, 대체 상태, 의도적으로 지원되는 별칭을 유지해야 합니다. 그러면 소비자는 이전 관찰이 존재한 적이 없었다고 가장하지 않고도 오래된 캡처된 응답과 현재 정식 객체를 구분할 수 있습니다.

정책 부담은 적습니다. LACNIC은 이미 페이지, TAL 내용, 인증서를 게시합니다. 빠져 있는 것은 페이지가 말하는 것, 브라우저가 하는 것, 서버가 반환하는 것 사이의 결합입니다.

캡처에서 두 클릭 모두 작동했습니다. 인쇄된 두 주소도 모두 200을 반환했습니다. 각 쌍에서 단 하나의 경로만이 라벨이 약속한 객체를 반환했습니다. 바로 그렇기 때문에 HTTP 가용성과 게시 정체성에 별도의 영수증이 필요합니다.

출처