The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | adapter-outbound-httpclient-c09 | TLS 실패가 CONNECT로 분류된 원인은 픽스처의 듀얼스택 호스트명이다 | security-and-trust-boundaries | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-outbound-httpclient-c09 | 2026-09-01 |
|
|
|
adapter-outbound-httpclient |
TLS 실패가 CONNECT로 분류된 원인은 픽스처의 듀얼스택 호스트명이다
이 절은 이전 사이클이 여기에 적었던 P1 진단을 철회하고 교체한다. 관측된 실패는 그대로 재현되지만, 원인으로 지목했던 기전은 측정으로 반증되었다. 근거는 EVD-332다.
본문
이 절은 이전 사이클이 여기에 적었던 P1 진단을 철회하고 교체한다. 관측된 실패는 그대로 재현되지만, 그 원인으로 지목했던 기전은 측정으로 반증되었다. 근거는 EVD-332다.
관측은 그대로다
:adapter:outbound:httpclient:test 는 HEAD 에서도 283 중 3건 실패한다. 세 건 모두 MutualTlsHandshakeContractTest.java:168 — assertThat(classified.stage()).isEqualTo(TLS_HANDSHAKE) 다. 바로 앞줄인 167행(evidence == NOT_SENT)은 통과한다.
철회하는 진단
이전 진단은 ApacheFailureClassifier.recognize의 분기 순서(pool → DNS → CONNECT → TLS)를 읽고 사슬의 모양을 추론한 것이지, 사슬을 실제로 떠본 것이 아니다. 잡힌 예외를 그대로 출력하면 사슬에 SSLHandshakeException이 없다. 그림자에 가려진 것이 아니라 애초에 도착하지 않았다. 분류기는 자기가 받은 것을 정확히 분류했다.
ApacheFailureClassifier 참조 위치
:::evidence key="adapter-outbound-httpclient-c09" alt="코드베이스에서 ApacheFailureClassifier 를 검색한 출력 5줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ApacheFailureClassifier 코드베이스 검색 — 5줄 · exit 0" zoom="true" :::
두 주소 중 마지막 것만 호출자에게 도달한다
동일한 서버 객체, 동일한 클라이언트 신뢰재료. baseUrl의 호스트 문자열만 바꿨다. 이 컨테이너의 /etc/hosts는 localhost를 두 패밀리에 준다. MockWebServer는 IPv4 루프백에만 바인딩하고, MockHttpServer.uri()는 호스트명 localhost를 돌려준다 (MockHttpServer.java:70-72).
127.0.0.1 → TCP 성공 → TLS 핸드셰이크 실패(진짜 실패) → 삼켜짐
::1 → TCP 거부(듣는 소켓 없음) → 마지막 주소 → HttpHostConnectException 으로 승격
Apache HttpClient 5의 연결 오퍼레이터는 해석된 주소를 순회하면서 마지막이 아닌 주소의 실패를 삼킨다. 호출자에게 도달하는 유일한 예외는 두 번째 주소의 연결 거부다.
성공하는 테스트가 통과하는 이유도 같은 루프다
127.0.0.1 에서 성공하면 루프가 즉시 반환하므로 ::1을 시도하지 않는다. 따라서 처음 눈에 띄었던 startTls(..., true/false) 차이는 원인이 아니라 상관관계였다 — 실패하는 케이스가 곧 두 번째 주소까지 가는 케이스다. startTls(..., false)에서 서버가 뜨지 않는다는 가설도 함께 기각했다. 두 경우 모두 원시 소켓 접속이 성공한다(raw 127.0.0.1: OK, raw localhost: OK).