OCSP 스테이플링

OCSP stapling

Online Certificate Status Protocol(OCSP) 스테이플링은 공식적으로 TLS Certificate Status Request 확장으로 알려져 있으며 X.509 디지털 [1]증명서의 실효 상태를 확인하기 위한 표준입니다.증명서 발표자는 최초 TLS 핸드쉐이크에 CA에 의해 서명된 타임스탬프 OCSP 응답을 추가(스탬핑)함으로써 Online Certificate Status Protocol(OCSP) 응답 제공에 관련된 자원 비용을 부담할 수 있습니다.이것에 의해, 시큐러티 향상과 퍼포먼스 양쪽 모두를 목적으로, 클라이언트가 CA에 연락할 필요가 없어집니다.e.

동기

최초의 OCSP 실장에는 몇 가지 문제가 있습니다.

첫째, CA(인증국)는 특정 증명서의 모든 클라이언트에 실시간으로 응답을 제공해야 하기 때문에 상당한 비용이 소요될 수 있습니다.예를 들어 증명서가 고트래픽 웹 사이트에 발행되면 증명서의 [2]유효성을 문의하는 대량의 OCSP 요구에 의해 CA 서버가 타격을 받을 가능성이 있습니다.

또, OCSP 체크에서는, 클라이언트가 서드 파티(CA)에 연락하고,[2][3] 각 증명서의 유효성을 확인할 필요가 있기 때문에, 유저의 프라이버시가 침해되어 브라우징이 늦어질 가능성이 있습니다.

게다가 클라이언트가 OCSP 응답을 위해서 CA에 접속할 수 없는 경우, 클라이언트는 (a) 접속을 계속하는 것, (b) 공격이 있는 것을 전제로 접속을 종료하는 것, 또는 (b) 과도한 오경고와 [4]블록의 원인이 될 수 있습니다.

OCSP 스테이플링은 원래 OCSP [5][6]구현에서 이러한 문제에 대처하는 것을 목적으로 합니다.

솔루션

OCSP 스테이플링으로 Kerberos 티켓을 연상시키는 방법으로 두 문제를 해결합니다.스테이플링 시나리오에서는 증명서 보유자 자신이 정기적으로 OCSP 서버에 문의하여 서명 첨부 OCSP 응답을 얻습니다.사이트 방문자가 사이트에 접속하려고 하면 이 응답은 증명서 상태 요청 확장 응답을 통해 TLS/SSL 핸드쉐이크에 포함됩니다(스태핑됨). (주의: TLS 클라이언트는 ClientHello TLS/SSL 핸드쉐이크 [7]메시지에 증명서 상태 요청 확장을 명시적으로 포함해야 합니다).

사이트 오퍼레이터가 검증 응답을 제어할 수 있도록 허용하면 부정한 사이트에서 취소된 증명서에 대해 잘못된 검증을 발행할 수 있는 것처럼 보일 수 있지만 스테이플러에 저장된 응답은 [6]서버가 아닌 인증 기관에서 직접 서명해야 하므로 위조할 수 없습니다.클라이언트는 스테이플에 의한 응답을 수신하지 [4]않으면 OCSP 서버에 단독으로 접속합니다.단, 클라이언트가 유효하지 않은 스테이플 응답을 수신하면 [1]접속이 중단됩니다.OCSP 스테이플링의 유일한 리스크는 증명서 실효 통지가 마지막 서명된 OCSP 응답이 만료될 때까지 지연될 수 있다는 점입니다.

그 결과 클라이언트는 증명서가 현재 유효(또는 최근)하지만 OCSP 서버에 개별적으로 연락할 필요가 없다는 것을 인증국으로부터 계속 확인할 수 있습니다.이는 리소스 부담의 가장 큰 부분을 증명서 소유자에게 되돌려 놓는 것을 의미합니다.또, 클라이언트 소프트웨어가 유저의 브라우징 습관을 [2]제삼자에게 공개할 필요도 없어졌습니다.

전체적인 퍼포먼스도 향상됩니다.클라이언트가 CA에서 직접 OCSP 응답을 취득할 때는 보통 DNS에서 CA의 OCSP 서버의 도메인 이름 검색과 OCSP 서버로의 접속 확립이 포함됩니다.OCSP 스테이플링을 사용하면 증명서 상태 정보가 이미 확립된 채널을 통해 클라이언트에 전달되므로 오버헤드가 감소하고 [5]퍼포먼스가 향상됩니다.

사양

TLS Certificate Status Request 확장은 RFC 6066 섹션8에 규정되어 있습니다.

RFC 6961에서는 Multiple Certificate Status Request 확장이 정의되어 있습니다.이를 통해 서버는 TLS 핸드쉐이크로 여러 OCSP 응답을 전송할 수 있습니다.

2013년 4월에 만료된 X509v3 확장 필드의 초안 제안에서는 TLS 클라이언트hello에서 status_request [8]확장이 지정되어 있는 경우 해당 확장이 포함된 증명서를 제시하는 준거 서버가 응답으로 유효한 OCSP 토큰을 반환해야 한다고 명시되어 있습니다.제안의 현재 버전이 추가 TLS [9]확장을 지원하도록 확장되었습니다.TLS 개발자 Adam Langley는 Heartbleed OpenSSL [10]버그 수정 후 2014년 4월 기사에서 확장 기능에 대해 설명했습니다.

도입

OCSP 스테이플링 지원은 점진적으로 구현되고 있습니다.OpenSSL 프로젝트에는 Mozilla Foundation의 지원으로 0.9.8g 릴리스의 지원이 포함되어 있습니다.

아파치 HTTP서버 버전 2.3.3,[11]부터 온라인 인증서 상태 프로토콜 스테이 플링의 nginx웹 서버를 지원한 이후 버전 1.3.7,[12]LiteSpeed 웹 서버부터 버전 4.2.4,[13]마이크로 소프트의 IIS이후 WindowsServer2008,[14]HAProxy 이후 버전 1.5.0,[15]F5네트웍스 BIG-IP 이후 버전 11.6.0,[16]KEMPLoadMasters 이후 버전 7.2.37.1,lighttpd부터 versio.n1.4.56.[17]

많은 웹 서버가 OCSP 스테이플링 지원을 애드버타이즈하고 있지만 구현이 항상 신뢰할 [18]수 있는 것은 아닙니다.예를 들어 Apache가 OCSP 서버에 쿼리할 때 일시적인 장애가 발생했을 경우 이전 요청에서 캐시된 정상 응답을 폐기하고 잘못된 [19]응답 서비스를 시작합니다.Nginx는 OCSP 응답의 느린 로드를 수행합니다.즉, 처음 몇 개의 웹 요구에 대해서는 OCSP [20]응답을 추가할 수 없습니다.

브라우저 측에서는 OCSP 스테이플링이 Firefox 26,[4][21] Windows Vista [22]이후 Internet Explorer, Linux,[23] Chrome OS 및 Windows Vista 이후 Google Chrome에 구현되었습니다.

SMTP의 경우 Exim 메시지 전송 에이전트는 클라이언트 모드와 서버 모드 모두에서 OCSP 스테이플링을 지원합니다.

제한 사항

OCSP 스테이플링은 클라이언트와 OCSP 응답측의 양쪽 모두에서 OCSP 검증 비용을 절감하도록 설계되어 있습니다.특히 다수의 동시 사용자에게 서비스를 제공하는 대규모 사이트에서는 더욱 그렇습니다.단, OCSP 스테이플링은 한 번에 1개의 OCSP 응답만 지원합니다.이는 중간 CA 증명서를 [26][27]가진 증명서 체인에는 불충분합니다.

이 제한은 RFC 6961에 규정되어 있는 여러 증명서 상태 요구 확장에 의해 해결되었습니다.복수의 OCSP [28]응답을 송신하는 서포트가 추가되었습니다.

TLSv1.3에서는 이 제한이 자동으로 삭제되어 브라우저의 RFC 6961 무트 지원이 가능해집니다.이는 TLS 1.2에 대한 지원을 폐기하는 웹 서버가 증가하고 있기 때문입니다.TLS 1.2에서는 서버에서 송신할 수 있는 스테이플화된 응답은 1개뿐입니다.이것은 최종 증명서와 관련된 OCSP 응답입니다.TLS 1.3 에서는, 서버는 복수의 OCSP 응답을 송신할 수 있습니다(통상은 증명서 체인내의 증명서 마다 1개).[29]

레퍼런스

  1. ^ a b Eastlake, D. (January 2011). "Transport Layer Security (TLS) Extensions: Extension Definitions: Certificate Status Request". Internet Engineering Task Force (IETF). Retrieved March 2, 2015.
  2. ^ a b c A., Jesin (June 12, 2014). "How To Configure OCSP Stapling on Apache and Nginx". Community Tutorials. Digital Ocean, Inc. Retrieved March 2, 2015.
  3. ^ 주의: Microsoft CA 및 OCSP 서비스(일반 Active Directory 도메인의 일부로 사용되는 유형 등)에서는 OCSP 서비스가 증명서 상태를 확인할 때마다(이를 통해 CA 로드를 줄임으로써) CA를 통해 다시 확인할 필요가 없습니다.OCSP 서비스(일반적으로 CA와는 다른 서버에서 실행)는 CA에 의해 일반적으로 일주일에 한 번 발행되는 CRL(증명서 취소 목록)을 참조하고 이를 증명서 상태를 확인하기 위한 정보 소스로 사용합니다.
  4. ^ a b c Keeler, David (July 29, 2013). "OCSP Stapling in Firefox". Mozilla Security Blog. Mozilla Foundation. Retrieved March 2, 2015.
  5. ^ a b Prince, Matthew (October 29, 2012). "OCSP Stapling: How CloudFlare Just Made SSL 30% Faster". CloudFlare, Inc. Retrieved March 2, 2015.
  6. ^ a b Gibson, Steve. "Security Certificate Revocation Awareness: The case for "OCSP Must-Staple"". Gibson Research Corporation. Retrieved March 2, 2015.
  7. ^ "OCSP Stapling". GlobalSign Support. GMO GlobalSign Inc. August 1, 2014. Retrieved March 2, 2015.
  8. ^ P. Hallam-Baker, X.509v3 확장: OCSP 스테이플링 필요
  9. ^ P. Hallam-Baker X.509v3 TLS 기능 확장 draft-hallambaker-tlsfeature-05
  10. ^ A. Langley, 아니요, 해지 체크를 활성화하지 마십시오. 2014년 4월 19일.
  11. ^ Apache HTTP Server mod_ssl 설명서 - SSLoSeStapling 지시문
  12. ^ nginx-mailing list - nginx-1.3.7
  13. ^ 릴리스 로그 - Litespeed Tech (라이트스피드 기술)2014-02-07 취득,
  14. ^ Duncan, Robert. "Microsoft Achieves World Domination (in OCSP Stapling)". Netcraft Ltd. Retrieved 28 April 2014.
  15. ^ HAProxy 웹사이트
  16. ^ 릴리즈 노트: BIG-IP LTM 및 TMOS 11.6.0
  17. ^ "lighttpd 1.4.56 release info". redmine.lighttpd.net.
  18. ^ OCSP 스테이플링 문제
  19. ^ Apache OCSP 버그
  20. ^ Nginx OCSP 버그
  21. ^ 실효성 향상 - MozillaWiki, 2014-04-28 취득
  22. ^ "How Certificate Revocation Works". TechNet. Microsoft. 16 March 2012. Retrieved 28 April 2014.
  23. ^ "Issue 361820: Check For Server Certificate Revocation checkbox is confusing". Google Code. 10 April 2014.
  24. ^ 2015-01-24를 취득한 smtp 전송
  25. ^ 주 구성, 2015-01-24 검색
  26. ^ Mozilla NSS Bug 360420, Adam Langley 코멘트
  27. ^ Mozilla NSS Bug 611836 - 여러 OCSP 스테이플링 확장 구현
  28. ^ Pettersen, Yngve N. (June 2013). "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension". Internet Engineering Task Force. Retrieved 31 October 2014.
  29. ^ "OCSP stapling (GnuTLS 3.7.4)".