인증서 투명성은 어떻게 작동합니까?
CT(인증서 투명성)는 기존 CA(인증 기관) 인프라 내에서 SSL 인증서 발급에 대한 법인의 권한 부여 발급 후 검증을제공하는 방법으로 작동합니다.
인증서 발급 프로세스는 아래에 나와 있으며, CT에서 도입한 새로운 단계는 파란색으로 강조 표시되어 있습니다.
- 서버 운영자가 CA에서 인증서를 구입합니다.
- CA에서 서버 운영자를 검증합니다.
- CA에서 사전 인증서를 생성합니다.
- CA는 SCT(서명된 인증서 타임스탬프)를 반환하는 로그 서버에 사전 인증서를 기록합니다.
- CA에서 SSL 인증서를 발급합니다.
- SSL 인증서에는 SCT(서명된 인증서 타임스탬프)가 포함될 수 있습니다.
- TLS 핸드셰이크 과정에서 브라우저가 SSL 인증서를 검증합니다.
- 브라우저는 OCSP 고정, TLS 확장 또는 인증서에 포함된 정보를 통해 TLS 핸드셰이크 과정에서 제공되는 SCT를 검증합니다.
- 브라우저가 서버와 연결됩니다.
- SSL 인증서는 브라우저에서 서버로 전달되는 모든 데이터를 암호화합니다.
여기에 설명된 대로 TLS 핸드셰이크 과정에서 SCT를 전달할 수 있는 방법에는 세 가지가 있습니다. SCT 전달 방법 중 하나에 대한 프로세스 다이어그램을 아래에서 확인하십시오.
인증서 투명성 구성 요소
CT 시스템에는 CA, 인증서 로그, 인증서 모니터, 인증서 감사자라는 네 가지 구성 요소가 있습니다. 다음은 이러한 요소의 일반적인 구성을 보여주는 다이어그램입니다. 각 구성 요소는 아래에 자세히 설명되어 있습니다.
인증 기관
CT는 공개적으로 신뢰할 수 있는 기존 CA 시스템 내에서 작동합니다. CT를 사용하면 CA는 인증서 발급 증거를 공용 로그에 포함할 수 있으며, 브라우저는 핸드셰이크 과정에서 이러한 SCT를 확인할 수 있습니다. 인증서 기록은 CA가 올바르게 작동함을 보여주는 증거이며, CA 운영에 대한 인사이트를 제공합니다.
인증서 로그
이상적인 경우 초기 롤아웃은 EV 인증서로 제한되지만, 인증서 로그는 발급된 모든 SSL 인증서에 대한 기록을 유지합니다. 다음과 같은 여러 가지 이유에 따라 다양한 독립 로그가 필요합니다. 1) 여러 개의 로그를 사용하면 로그 오류가 발생해도 백업이 가능합니다. 2) 독립 로그를 사용하면 하나의 로그 또는 로그 운영자가 손상되더라도 인증서가 유효한 상태를 유지합니다. 3) 독립 로그를 사용하면 단일 거버넌스 작업으로 모든 로그에서 발급 증거를 제거할 수 없습니다. 4) 독립 로그를 여러 개 사용하면 CA와 로그 운영자가 까다로운 발급 오류 문제에 단순하게 대처할 수 있습니다.
모든 로그는 다음과 같은 특성을 가집니다.
- 추가 전용 - 로그에 인증서를 추가하는 것만 가능하며, 삭제, 수정 또는 소급하여 삽입할 수 없습니다.
- 암호화 보증 - 로그는 머클 트리 해시(Merkle Tree Hash)라는 암호화 메커니즘을 사용하여변조를 방지합니다.
- 공개 감사 가능 - 모든 사용자가 로그를 쿼리하고 잘못 발급된 인증서나 악성 인증서를 찾을 수 있습니다. 모든 인증서 로그는 인증서 로그 URL과 공개 키를 공개적으로 알려야 합니다.
인증서 모니터
인증서 모니터는 대형 브랜드 소유자 또는 CA와 같이 인증서 로그를 감시하여 의심스러운 활동을 파악하는 작업을 수행하는 주체를 지칭합니다.
모니터는 HTTP GET 명령을 사용하여 로그에서 정보를 가져올 수 있습니다. 모든 고객은 자체 로그 모니터링 서비스 역할을 수행하거나 이를 타인에게 위임할 수 있습니다. 는 고객을 위해 로그 모니터링 서비스를 제공할 계획을 가지고 있습니다.
인증서 감사자
인증서 감사자는 로그가 다른 로그와 일치하는지, 새 항목이 추가되었는지, 다른 사용자가 인증서를 소급 삽입하거나 삭제 또는 수정하여 로그가 손상되지 않았는지 확인합니다.
감사는 보통 브라우저에 내장된 자동화된 프로세스로 수행되는 경우가 많습니다. 하지만 독립 실행형 서비스이거나 모니터링의 보조 기능인 경우도 있습니다.
