요약

  • 암호화된ClientHelloInner, 외부 래퍼,public_name은 서로 다른 계층에 속합니다. 마지막 항목은 사내 백엔드가 아니라 클라이언트를 향한 서버를 지칭합니다.
  • DNS 구성, ECH 수용, TLS 인증, 애플리케이션 성공은 각각 별도의 증거로 기록되어야 합니다. 어느 단계도 이전 단계의 결론을 자동으로 상속하지 않습니다.

RFC 9849는 인사말을 두 가지 형태로 나눕니다. 클라이언트는 민감한 값을ClientHelloInner에 넣고, 무해한 값은ClientHelloOuter에 남긴 뒤, 전자를 ECH 공개 키로 암호화합니다. 두 메시지는 서로 결합되어, 내부를 유지한 채 외부만 특정 방식으로 조작하는 행위를 막습니다. 이 성질은 래퍼를 보호할 뿐입니다. DNS 레코드, 공개 주소, 프론트엔드 공급자, 백엔드, 애플리케이션 주체가 동일한 행위자라고 말하지는 않습니다.

계속 노출되는 이름의 역할은 제한적입니다.public_name은 클라이언트를 접수하는 서버의 DNS 이름이며, ECH 모델 안에서 구성을 갱신하고 구식 구성을 복구하도록 돕는 것을 승인받은 이름입니다. 일반적으로 외부 SNI에 나타납니다. 비밀 백엔드의 이름이 아니며, 소유권 선언도, 익명 집합에 속한 모든 이름이 같은 운영자를 공유한다는 증거도 아닙니다.

토폴로지가 그 신중함을 요구합니다. 공유 모드에서는 프론트엔드와 TLS 종료 주체가 일치할 수 있습니다. 분리 모드에서는 프론트엔드 서버가 TLS를 종료하는 백엔드에 전달합니다. RFC 9849는 양자 간 인증된 채널과, 공격자가 두 구간을 상호 연관시킬 수 없다는 가정을 둡니다. 그 상관 관계를 막는 구체적 메커니즘은 범위 밖입니다. 관찰된 ECH 패킷은 이러한 조건을 감사하지 않습니다.

수용 역시 연쇄를 완성하지 않습니다. 서버는 ECH를 수용하고 내부를 사용하거나, 거부하고 외부를 사용합니다. 거부 후 연결은 ECH 클라이언트의 애플리케이션 데이터에 쓸 수 없으며, 새 구성으로 복구를 시작할 수 있습니다. 수용은 협상 질문에 대한 답입니다. 클라이언트가 자신의 신뢰 저장소로 인증서를 검증했는지, 기대한 이름이 일치했는지, 정책이 요청을 승인했는지, 서비스가 작업을 완료했는지는 기록하지 않습니다.

RFC 8446은 독립성을 유지합니다. TLS는 매개변수를 협상하고, 피어를 인증할 수 있으며, 키를 생성합니다. 애플리케이션 의미론은 그 밖에 남습니다. 인증서 검증은 별도로 분배된 신뢰 앵커와 로컬 결정에 의존합니다. 따라서 ECH는 신원 검증을 대체하지 않고, 노출된 인증서만으로 DNS 경로나 백엔드 거버넌스를 증명하지 못합니다.

RFC 9460은 SVCB와 HTTPS가 서로 다른 기능이나 운영자를 가진 대체 키와 엔드포인트를 전달할 수 있음을 덧붙입니다. 레코드는 클라이언트에 제공된 지시 사항을 설명할 수 있을 뿐, 실제 선택된 엔드포인트나 최종 결과를 설명하지 않습니다.

운영 검토는 ECHConfig의 발신지/TTL, 리졸버와 캐시, 수용, 기대 신원, 검증, 프론트엔드-백엔드 채널, 선택된 엔드포인트, 애플리케이션 응답을 위한 별도 열을 유지해야 합니다. 프라이버시가 실제로 담지 않는 조직적 서사를 강제로 말하게 하지 않을 때 더 정확해집니다.

출처