이전글: 1. 인증서 투명성 (Certificate Transparency) 개요
Table of Contents
인증서 투명성이 작동하는 방식
인증서 투명성은 세 가지 기능을 현행 SSL 인증서 시스템에 추가합니다.
- 인증서 로그
- 인증서 감시자 (monitors)
- 인증서 감사자 (auditors)
이들 기능 구성 요소는 서비스를 보완적으로 감시하고 감사할 수 있는 분리된 소프트웨어 모듈을 나타냅니다. 현행 SSL 인증서 시스템을 대체하거나 교체하는 것은 아닙니다. 실제로, 이들 구성 요소는 클라이언트가 도메인을 검증하고 서버와 안전한 연결을 맺는 기본적인 신뢰 체인 모델을 바꾸는 것이 아닙니다. 대신에, 전체 SSL 인증 시스템에 대한 공개적인 관찰과 조사 지원을 제공하는 신뢰 체인 모델로 강화합니다.
기본 로그 방식
인증서 투명성 시스템 중심에는 인증서 로그가 있습니다. 인증서 로그는 SSL 인증서에 대한 자료를 유지하는 간단한 네트워크 서비스입니다. 인증서 로그는 세 가지 중요한 특징이 있습니다.
- 추가만 가능: 인증서는 로그에 추가될 수만 있습니다. 인증서는 제거되거나, 수정되거나, 로그에 일괄 삽입되지 않습니다.
- 암호화 보장: 로그는 Merkle Tree Hash라고 하는 특별한 암호화 방식을 사용하여 조작과 오동작을 방지합니다.
- 공개 감사 가능: 누구든지 로그를 조회하고 올바르게 동작하는지 검증하고, SSL 인증서가 적절하게 로그에 추가되었는지 검증할 수 있습니다.
로그 수는 많을 필요가 없습니다. 충분한 수의 로그가 있으므로 로그 실패나 일시적인 접속 불가가 문제가 되지 않습니다만, 감시하기에 어려울 정도로 많아지지 않게 하세요. 이를테면, 10개보다 많지만 1000보다 적게 하세요. 각 로그는 다른 로그와 독립적으로 작동합니다. (즉, 로그 사이 자동 복제가 없다는 것입니다)
추가만 가능한 로그는, 로그가 손상되지 않았고, 로그 작성자가 로그에서 어떤 인증서도 제거하거나 변경하지 않았다는 것을 증명하는 특별한 암호화 해시를 사용할 수 있게 합니다. 이 특별한 해시(Merkle Tree Hash로 알려짐)는 감사자가, 누군가 로그를 분리했거나 오래된 인증서를 로그에 삽입하였는지 탐지할 수 있게 합니다. 더 자세한 정보는, 로그가 작동을 보장하는 방법을 보세요.
모든 인증서 로그는 반드시 (다른 것과 함께) URL과 공개키를 송출해야 합니다. 누구든지 HTTPS GET과 POST 메시지를 통해 로그와 상호작용할 수 있습니다.
기본 로그 작동
누구든지 인증서를 로그에 전송할 수 있지만, 대부분의 인증서는 인증 기관과 서버 관리자에 의해 전송될 것입니다. 누군가 올바른 인증서를 로그에 전송하면, 로그는 인증서를 로그의 어떤 시간에 등록했는지 간단히 보증하여 알려주는, 서명된 인증 타임스탬프(SCT)로 응답합니다. 이 시간은 최대 병합 지연(MMD)로 알려져 있습니다.
MMD는 합리적인 시간 내에 로그 서버가 인증서를 로그에 추가하도록 하며 로그가 복원력과 가용성을 위해 분리된 서버 집합을 실행할 수 있도록 허용하면서 인증서의 발급 또는 사용을 차단하지 않습니다. SCT는 인증서의 수명동안 인증서와 함께 제공됩니다. 특히, TLS 서버는 TLS 핸드쉐이크가 일어나는 동안 SCT를 인증서와 함께 전송해야 합니다.
인증서 투명성은 SCT를 인증서와 함께 제공하는데 세 가지 방법을 지원합니다. 각각은 아래에 설명되어 있습니다.
X.509v3 확장
인증 기관은 X.509v3 확장을 사용하여 SCT를 인증서에 첨부합니다. 1번 그림은 이 방식을 나타냅니다. 인증 기관은 로그에 사전 인증서를 전송하고, 로그는 SCT를 반환합니다. 인증 기관은 이어서 SCT를 사전 인증서에 X.509v3 확장으로서 첨부하고, 인증서를 서명하고, 인증서를 서버 운영자에게 제공합니다.
이 방식은 서버 변경을 필요로 하지 않으며, 서버 관리자가 SSL 인증서를 기존에 해오던 방식과 똑같이 관리할 수 있도록 합니다.
TLS 확장
서버 운영자는 SCT를 특별한 TLS 확장(그림 2 참고)을 통해 전달할 수 있습니다. 이 경우, 인증 기관은 인증서를 서버 운영자에게 발급하고, 서버 운영자는 인증서를 로그에 전달합니다. 서버 관리자에게 전달되고, 서버 관리자는 signed_certificate_timestamp 타입의 TLS 확장을 사용하여 TLS 핸드쉐이크 도중에 클라이언트에 SCT를 제공합니다.
이 방식은 인증 기관이 SSL 인증서를 발급하는 방식을 그대로 유지할 수 있게 합니다. 그러나, TLS 확장을 수용할 수 있도록 서버를 변경해야 합니다.
OCSP 스테이플링
서버 운영자는 SCT를 온라인 인증서 상태 프로토콜(OCSP) 스테이플링을 사용하여 전달할 수도 있습니다 (그림 2 참조). 이 경우, 인증 기관은 로그 서버와 서버 운영자 양쪽에 동시 인증서를 발급합니다. 서버 운영자는 OCSP 쿼리를 인증 기관에 보내고, 인증 기관은 SCT와 함께 응답하여, 서버가 TLS 핸드쉐이크할 때 OCSP 확장을 포함할 수 있게 합니다.
이 방식은 SCT를 비동기적으로 얻을 수 있으므로, 인증 기관이 SCT에 대한 관리 책임을 가질 수 있게 하면서도 인증서 발급에 지연을 일으키지 않습니다. 그러나, OCSP 스테이플링을 할 수 있도록 서버를 수정해야 합니다.
기본 감시자와 감사자 작업
감시자는 출처가 불분명하거나 신뢰되지 않은 인증서, 비정상적인 인증 확장 또는 이상한 권한(예를 들어 인증 기관의 인증서)을 갖고 있는 수상한 인증서를 로그에서 감시합니다. 감시자는 로그에서 모든 로그된 인증서를 검증할 수 있습니다. 로그에 추가된 새로운 항목을 주기적으로 모두 가져오는 방식으로 이런 일을 할 수 있습니다. 그 결과, 대부분의 감시자는 감시하고 있는 거의 완전한 로그를 갖게 됩니다. 로그가 일정 시간 이상 오프라인이고, 감시자가 로그의 복사본을 갖고 있다면, 감시자는 읽기 전용 로그의 백업으로 동작할 수 있고, 로그를 쿼리하려고 하는 다른 감시자와 감사자에게 로그 데이터를 제공할 수 있습니다.
감사자는 로그의 전체 투명성을 검증합니다. 일부 감사자는 특정 인증서가 로그에 등장하는지를 검증할 수 있습니다. 로그 증명을 주기적으로 가져오고 검증하는 방식으로 진행합니다. 로그 증명은 로그가 올바른지를 증명하는데 쓰이기 위해 암호화된 해시로 서명됩니다. 모든 로그는 반드시 요청시에 로그 증명을 제공해야 합니다.
감사자는 로그의 오래된 항목에 새로운 로그 항목이 항상 추가된다는 것, 인증서가 손상되거나 중도에 추가 또는 삭제, 수정되지 않았다는 것을 검증하기 위해 로그 증명을 사용할 수 있습니다. 감사자는 또한 특정 인증서가 로그에 존재한다는 것을 보이기 위해 로그 증명을 쓸 수 있습니다. 이는 인증서 투명성 프레임워크가 모든 SSL 인증서를 로그에 기록해야 하기 때문에 특히 중요합니다. TLS 클라이언트가 (감사자를 통해서) 인증서가 로그에 없다는 것을 알게 되면, 로그가 올바르게 동작하지 않았다는 증거로 로그의 SCT를 사용할 수 있습니다. 자세한 정보는 로그 증명이 작동하는 방법을 살펴보세요.
로그 증명은 감사자나 감시자가 특정 로그에 대한 자신의 관찰 내용가 과거의 관찰 내용이 일치 하는지를 검증할 수 있게 하는 한편, 특정 로그에 대한 관찰 내용이 다른 감시자 및 감사자와 일치하는지 확인해야합니다. 이 검증을 하기 위해, 감사자와 감시자는 gossip 프로토콜을 통해 로그에 대한 정보를 서로 교환합니다. 이는 발췌된 로그를 탐지하기 위해 감사자와 감시자를 돕는 비동기적 의사소통 통로입니다.
일반적인 시스템 구성
인증서 투명성 프레임워크는 기존의 SSL 인증서 시스템에 감시자와 감사자의 특별한 구성이나 배치를 지시하진 않습니다. 다시 말해, 좀 더 흔히 이루어지는 특정한 구성이 있다는 것입니다. 일반적인 구성에서, 인증 기관은 감시자를 운영하고 클라이언트(브라우저)는 감사자를 구동합니다 (그림 3 참조). 이 구성은 감시자와 감사자에게 필요한 메시지 교환을 단순화하며, 인증서 감사자와 클라이언트가 고객과 사용자의 특정한 요구를 충족할 수 있는 감시 및 감사 시스템을 스스로 개발하게 합니다. 이 구성을 수행하는 과정 중 일부가 아래 서술되어 있습니다.
인증서 발급
인증 기관은 SCT를 로그 서버에서 취득하여, X.509v3 확장(이 과정에 대한 자세한 정보는 그림 1 참조)을 사용하여 SSL 인증서에 SCT를 통합합니다. 인증 기관은 이어서 (SCT가 첨부된) 인증서를 서버 운영자에게 발급합니다. 이 방식은 서버 업데이트를 필요로 하지 않고 (현재 X.509v3 확장을 지원하는 모든 서버), 기존의 SSL 인증서를 관리한 방식 그대로 서버 운영자가 인증서를 관리할 수 있게 합니다.
TLS 핸드쉐이크
TLS 핸드쉐이크 과정에서, TLS 클라이언트는 SSL 인증서와 인증서의 SCT를 수신합니다. 보통 TLS 클라이언트는 인증서와 서명 체인을 검증합니다. 거기에, TLS 클라이언트는 (다른 인증서가 아닌) 실제로 인증서가 발급된 SCT와 올바른 로그로 발급되었는지 SCT에 있는 로그 서명을 검증합니다. 불일치가 발견되면, TLS 클라이언트는 인증서를 거부해야 합니다. 예를 들어, TLS 클라이언트는 미래의 SCT 타임스탬프를 가진 모든 인증서를 기본적으로 거부해야 합니다.
인증서 감시
대부분의 감시자는 인증 기관에 의해 운영됩니다. 이 구성은 인증 기관이 더 효과적인 감시를 만들고, 자체적으로 표준과 요구 사항을 감시할 수 있도록 합니다.
인증서 감사
대부분의 감사자는 브라우저에 들어 있습니다. 이 구성에서, 브라우저는 주기적으로 SCT 배치를 통합된 감사 구성 요소로 전송하고, SCT(와 관련된 인증서)가 올바르게 로그에 추가되었는지를 질의합니다. 감사자는 이어서 비동기적으로 로그를 확인하고 검증을 행할 수 있습니다.
다른 시스템 구성
감시자와 감사자가 기존의 TLS/SSL 구성 요소와 긴밀하게 통합된, 위에 서술한 일반적인 구성 외에도, 인증서 투명성은 수많은 다른 구성도 지원합니다. 예를 들어, 감시자는 인증 기관과 서버 운영자를 대상으로 유·무료 서비스를 제공하는 단독 항목으로 구동될 수 있습니다 (그림 4 참조). 감시자는 Google, Microsoft, Yahoo 등 거대 인터넷 기업과 같은 서버 운영자에 의해 구동될 수 있습니다. 비슷하게, 감사자도 단독 서비스로 운영되거나, 감시자의 부가 기능으로 작동할 수 있습니다.
다음글: 3. 로그 증명의 작동 방식