요약

  • OCSP 스테이플링은 TLS 협상 중 서버가 제3자가 서명한 인증서 상태 응답을 전달할 수 있게 했다. 전달 방식이 바뀌었지만, 응답에 서명할 권한과 클라이언트가 이를 검증할 책임은 그대로였다.
  • 재사용 가능한 상태 정보는 별도의 연결에 대한 필요를 줄였지만, 신선도 검사와 갱신 작업을 요구했다. 인증서에 지원 여부를 선언하면 스테이플 누락이 실질적 결과를 갖게 되지만, 그 대가는 인증서 배포가 상태 증거의 가용성에 결합된다는 점이었다.

검사 대상 당사자가 제공하는 증거

서버가 클라이언트에 자신의 인증서를 제시하는 상황을 생각해 보자. 그와 함께 그 인증서의 폐기 상태에 대한 진술이 전달된다. 두 객체 모두 서버가 전달했다. 그렇다면 두 번째 객체는 서버가 "모든 것이 정상"이라고 직접 주장하는 것보다 어째서 더 믿을 만한가?

이유는 전달이 작성과 다르기 때문이다. 그 진술은 OCSP 응답으로서, 클라이언트가 해당 인증서에 대해 응답할 자격이 있다고 인정해야 하는 권한 당국이 서명한 것이다. 자신의 평범한 TLS 개인 키를 보유한 침해된 서버가 그렇다고 해서 수용 가능한 상태 응답을 발급할 권한을 얻지는 못한다. 서명된 진술을 운반할 수는 있지만, 그렇다고 그 진술의 발급자가 되는 것은 아니다.

이 구분이 OCSP 스테이플링을 가능하게 한 핵심 아이디어였다. 클라이언트는 자신이 검사하고 있는 바로 그 당사자를 통해 유용한 증거를 얻을 수 있었는데, 조건은 그 증거가 운반자와 독립적으로 검증 가능해야 한다는 것이었다. 이를 통해 만족스러운 검사가 매번 인증서 상태 서비스와의 새로운 클라이언트 측 대화에 의존하게 되는 일을 피할 수 있었다.

2003년에 이미 규정된 더 짧은 경로

이 메커니즘은 2003년 6월의RFC 3546 섹션 3.6에 이미 존재했다. 클라이언트는status_request를 통해 상태 정보를 요청할 수 있었고, 서버는 인증서 뒤에 OCSP 응답을 보낼 수 있었다. 이 사양은 이를 제한된 네트워크, 왕복 절약, 인증서 폐기 목록 전송 회피와 연결지었다.

따라서RFC 6066의 2011년 문서는 스테이플링의 발명이 아니었다. 이 문서는 이후의 TLS 프레임워크에서 확장을 기술했다. 그 핸드셰이크에서는 별도의CertificateStatus메시지가 응답을 운반했다. 서버는 TLS 교환이 새로 만들어낸 주장이 아니라 완전히 인코딩된 객체를 전송한 것이다.

상태를 이 경로에 올리면 제3자를 별도로 방문할 필요가 사라질 수 있었다. 그에 따른 프라이버시 이익도 구체적이었다. 적절한 스테이플이 검사를 충족하면 방문자는 그 추가 상태 질의를 할 필요가 없었다. 그렇다고 방문 전체가 익명이 되는 것도, 응답자가 상태를 계속 공급하는 역할이 사라지는 것도 아니었다.

"good"이라는 단어는 겉보기보다 적은 것을 담보했다

운반되는 객체는 일반적인 인증서 보증보다 좁았다. 2013년에 발표된RFC 6960은good,revoked,unknown을 구분했다. good 응답이 인증서가 실제로 발급되었다는 사실을 확립한다고 볼 수도 없고, 웹사이트가 안전하다는 것은 더더욱 아니었다.

클라이언트는 여전히 응답이 인증서와 대응하는지, 서명은 유효한지, 서명자에게 권한이 있는지 확인해야 했다. 발급 CA, 명시적으로 신뢰되는 응답자, 적절히 지정된 응답자는 인정되는 경우였지만, 웹사이트 자신은 그 경우에 해당하지 않았다. 인증서 체인 및 기타 수용 요건은 호의적인 상태 단어로 대체되지 않았다.

이처럼 스테이플링은 "서버가 스스로를 증명한다"는 단순한 그림이 혼동하는 세 가지 활동, 즉 응답을 만들어내는 것, 운반하는 것, 충분한지 판단하는 것을 분리했다. 이 분할 덕분에 운반자가 주장을 재작성할 재량 없이 재사용이 가능했다.

이동할 수 있는 답에는 나이도 있었다

재사용은 두 번째 경계를 가져왔다. 서명된 답은 진위가 확인되었음에도 너무 오래되어 의존할 수 없을 수 있다. 그 답은 알려진 상태에 대해 말하는 것이지, 그 상태가 관측된 이후 발생하는 모든 사건에 대해 말하는 것이 아니다.

2007년 9월의RFC 5019경량 프로파일은 사전 제작·배포·캐시된 응답을 확장 가능한 설계의 일부로 삼았다. 이 프로파일은nextUpdate와 시간에 기반한 정확한 검사를 요구했다. 이는 해당 필드가 없을 수도 있는 기본 OCSP보다 강한 규칙이었다. 따라서 이를 모든 OCSP 응답에 대한 단일한 보편적 설명으로 평탄화해서는 안 된다.

시계들의 이름이 중요하다.thisUpdate는 표시된 상태가 정확하다고 알려진 시점을 다루고,producedAt은 서명 시각을 기록하며,nextUpdate는 새 정보가 언제 제공될지를 다룬다. 나중에 서명하는 것은 상태를 나중에 관측하는 것과 같지 않다. 서명되지 않은 HTTP 캐시 헤더는 서명된 응답이 클라이언트에게 수용하도록 허용하는 범위를 확장할 수 없다.

운영자 입장에서 수용 가능한 답의 캐시는 응답자에 접근할 수 없는 기간을 흡수할 수 있었다. 그러나 이 보호는 보유한 답들이 클라이언트의 신선도 규칙 하에서 수용 가능한 동안에만 지속되었다. 이후의 폐기는 이미 배포된 사본을 마법처럼 바꾸지 못했다. 재사용은 관측과 사용 사이의 유한한 시차를 수용함으로써 작업을 절약한 것이다.

침묵은 상태 응답이 아니었다

원래의 확장은 불편한 모호성을 남겼다. 클라이언트가 스테이플을 요청할 수 있었음에도 서버는 이를 제공하지 않을 수 있었다. 그 부재는 지원 부족을 의미할 수도 있고, 침해된 키를 사용하는 서버가 불편한 증거 제공을 꺼린다는 뜻일 수도 있었다.

RFC 6066은 자신의보안 고려사항에서 그 문제를 명시적으로 다루었다. OCSP 검증을 요구하는 클라이언트는 응답자에 직접 연락하거나 중단해야 한다. 제공된 응답이 검사에 실패하는 경우는 또 다른 경우로, 핸드셰이크를 중단해야 한다. 응답 없음, 수용 불가능한 응답, 명시적 폐기는 동등한 관측이 아니었다.

2015년 10월의RFC 7633이 이 기대를 다루었다. 인증서 내부의 TLS Feature 선언은status_request를 광고할 수 있었고, 이것이 이후 Must-Staple로 알려지게 된 기능의 기초가 되었다. 이를 지원하는 클라이언트는 이제 신뢰할 수 없는 서버의 해명 대신, 인증서로 인증된 약속을 기준으로 누락을 판단할 수 있었다.

이것이 모든 클라이언트가 스테이플 없는 모든 연결을 실패시켜야 한다는 보편적 의무는 아니었다. 해당 RFC는 대체 검증 사례를 허용했고, 모든 클라이언트가 선언된 모든 기능을 구현하도록 요구하지 않았다. 다만 서버에게 구체적인 프로비저닝 의무를 부여했다. 새로 발급된 인증서는 필요한 상태 토큰이 가용해지기 전에 활성화되어서는 안 된다. 그렇지 않으면 정당한 인증서가 서버가 충족할 수 없는 기대를 갖고 클라이언트에 도달할 수 있다.

그릇은 바뀌었지만 구분은 살아남았다

TLS 1.3은 객체가 이동하는 위치를 바꾸었다.RFC 8446 섹션 4.4.2.1에 따르면, 상태는 이전의 독립형 핸드셰이크 메시지 대신 연관된CertificateEntry의 확장으로 운반되었다. 이 이동으로 서버가 상태 권한 당국이 되거나 신선도가 무관해지지는 않았다.

따라서 이 역사적 거래는 어떤 메시지 형식보다 내구성이 있었다. 독립적으로 검증 가능한 증거는 이해당사자를 통해 이동할 수 있었고, 이는 연결 시점의 의존성을 줄이는 동시에 사용 가능한 증거를 획득하고 배포해야 하는 지속적 의무를 만들었다. 이 사양들은 그 설계를 확립하는 것이며, 현재 클라이언트나 CA 지원 현황에 대한 조사가 아니다.

출처

RFC 3546,RFC 6066,RFC 6960,RFC 5019,RFC 7633,RFC 8446이 프로토콜 기록을 제공한다. 여기서 기술된 운영 비용의 배분은 이러한 요건들로부터의 추론이며, 측정된 배포 주장이 아니다.