{
  "test_id": "T17",
  "verdict": "fail",
  "observed": "run 1의 mock.istio-verify-ext.svc.homelab.local(in-cluster k8s Service를 MESH_EXTERNAL ServiceEntry 대역으로 위장) 대신, harness-notes.md CORRECTION bullet4에 따라 진짜 외부 호스트 httpbin.org로 교체해 재실행(mesh-test 네임스페이스의 cnn-ext/httpbin-ext/wiki-ext 등 기존 패턴과 동일). 이 교체로 'in-cluster k8s Service가 이미 레지스트리에 있어 unregistered 대역으로 부적절'이라는 confound를 제거했다. 결과: Phase 1(protocol: HTTP로 정확히 등록)에서 registered_http=200, client의 RDS route에 domains==\"httpbin.org\" 매치가 실제로 1건 존재(length=1), istio_requests_total 중 httpbin 관련 라인 수가 Phase 0의 1건(PassthroughCluster로 attribution)에서 Phase 1의 2건(신규 라인은 destination_service_name=\"httpbin.org\"로 정상 attribution)으로 증가 — C2는 이번에도 실측대로 지지된다. 반면 Phase 2(같은 평문 포트를 protocol: TLS로 오등록)에서는 misdeclared_tls=200, exit=0으로 다시 연결이 정상 성공했다 — pass_criteria가 기대한 tls_inspector의 ClientHello 탐지 실패로 인한 connection reset은 관측되지 않았다. istioctl proxy-config listener로 0.0.0.0_80 리스너를 직접 확인한 결과, raw_buffer+application_protocols(http/1.1,h2c) 매치 filterChain(ALLOW_ANY 익명 HTTP 패스스루, 항상 존재)과 serverNames=[\"httpbin.org\"] SNI 매치 filterChain(TLS SE가 신규 추가)이 나란히 존재했다. 클라이언트가 평문 HTTP만 보내 TLS ClientHello/SNI가 전혀 없으므로 SNI 전용 체인은 애초에 매치 대상이 아니며, 요청은 그냥 기존 HTTP 패스스루 체인으로 흘러 익명으로 성공한다 — TLS 오등록이 '기존 평문 패스스루 경로를 대체/차단'하는 것이 아니라 '추가로 SNI 경로 하나를 얹는 것'일 뿐임을 확인했다. 이는 run 1의 결론과 기술적 메커니즘까지 동일하며, mock-in-registry confound와 무관하게 재현된다는 점에서 run 1 지적이 환경 혼선(environment mismatch)만으로 설명되지 않음을 보여준다. Phase 0(SE 미등록 상태)에서도 istio_requests_total에 destination_service=\"httpbin.org\", request_protocol=\"http\"인 라인이 이미 1건 존재(http_inspector 프로토콜 스니핑에 의한 결과, destination_service_name은 \"PassthroughCluster\"로 남아 다소 부실한 identity). 즉 SE 등록 없이도 Host 기반 기초 가시성(request_protocol/destination_service/response_code)은 이미 확보되나, SE 등록은 destination_service_name/canonical_service/workload_namespace 등 훨씬 풍부한 identity attribution을 추가로 제공한다는 뉘앙스가 이번 재실행에서 더 명확히 드러났다 — 'SE 등록이 L7 가시성의 유일한 실익'이라는 문서 주장은 여전히 반증(correction)된다.",
  "claims": [
    {
      "doc": "gw__src-egress-http-vs-https",
      "cid": "C2",
      "empirical": "supports-claim",
      "note": "protocol: HTTP로 정확히 등록하면(대상: 진짜 외부 호스트 httpbin.org, in-cluster 서비스 confound 제거) Host 기반 RDS route가 생성되고(domains==\"httpbin.org\" length=1), istio_requests_total의 httpbin 관련 L7 메트릭 라인 수도 1->2로 증가함을 실측 확인. run 1과 동일한 결론이며 confound 제거 후에도 재현됨."
    },
    {
      "doc": "gw__src-egress-http-vs-https",
      "cid": "C5",
      "empirical": "refutes-claim",
      "note": "진짜 외부 호스트(httpbin.org)로 confound를 제거하고 재실행해도 평문 포트를 protocol: TLS로 오등록 시 misdeclared_tls=200/exit=0으로 연결이 성공했다. 원인은 istioctl proxy-config listener로 직접 확인: 0.0.0.0_80 공유 리스너에는 TLS SE가 추가한 serverNames 기반 SNI-only filterChain 외에, ALLOW_ANY 모드에서 항상 존재하는 raw_buffer+http/1.1 catch-all filterChain이 그대로 남아있어 SNI가 없는 평문 요청은 그 경로로 흘러 익명 패스스루로 처리된다. TLS 오등록은 기존 평문 경로를 막지 못하고 병행 경로를 추가할 뿐이다 — run 1의 결론이 domain-mismatch confound와 무관하게 재현되어 신뢰도가 올라감."
    },
    {
      "doc": "gw__src-egress-http-vs-https",
      "cid": "C9",
      "empirical": "supports-correction",
      "note": "ServiceEntry 미등록(Phase 0, 진짜 외부 호스트 httpbin.org 기준) 상태에서도 istio_requests_total에 destination_service=\"httpbin.org\", request_protocol=\"http\"인 라인이 이미 1건 존재 — http_inspector 프로토콜 스니핑만으로 Host/프로토콜/응답코드 수준의 기초 L7 가시성은 확보됨을 in-cluster-service confound 없이 재확인. 다만 destination_service_name은 \"PassthroughCluster\"에 머물러 SE 등록(Phase 1)이 제공하는 canonical_service/workload_namespace 등 풍부한 identity attribution과는 질적으로 다름 — 'SE 등록이 L7 가시성의 유일한 실익'이라는 주장은 여전히 반증(correction)되나, SE 등록이 '더 풍부한' 가시성을 준다는 점은 유효."
    }
  ]
}