Certificate Revocation

때때로 인증서 발행자는 수많은 이유들로 인해서 인증서를 폐지하고나 무효화 해야할 필요가 있다. 인증서의 비밀키가 이미 사용되었다던지, 인증서의 권한이 사용되는 경우들이나 회사가 변경되거나 인증서가 변경되는 것 같은 이유들 때문이다. 이 문제를 해결하기 위해서 인증서가 폐지되었는지 확인하는 방법에 대한 설명이 인증서 자체에 포함되어 있다. 인증서 체인이 협상되지 않았음을 확인하기 위해서는 내장되어 있는 설명과 서명들에 따라서 상태를 확인해야 한다.

Certificate Revocation List (CRL)

CRL 은 RFC 5280에 정의되었는데 모든 인증서의 상테를 확인하기 위한 간단한 방법을 명시했다. 각각의 인증서 권한은 폐기된 인증서 일련번호를 유지하고 주기적으로 배포한다. 인증서의 유효성을 확인하고자 하는 사람은 누구든지 폐기 목록을 다운로드하여 캐싱하거나 특정한 일련 번호가 목록안에 있는지 확인할 수 있다. 만약 목록에 존재하면 폐기된 것이다.

이 과정은 간단하면서 직관적이지만 몇가지 한계가 있다.

• 폐기되는 인증서 숫자가 증가하는 것은 CRL 목록이 길어진다는 것을 의미하고 각각의 Client는 전체 일련번호 목록을 반드시 회신해야 한다.
• 인증서 폐지에 대한 임시적인 안내 방법이 없다 만약 CRL이 인증서 폐기전에 Cache되어 있다면 CRL은 Cache가 만료될때까지 폐기된 인증서 목록이 유효하다고 판단할것이다.
• CRL 패치는 다양한 이유로 인해 실패할 수 있다

Online Certificate Status Protocol (OCSP)

CRL machanism의 한계를 혜결하기 위해서 Online Certificate Status Protocol (OCSP) 가 RFC 2560에 의해 도입되었다. OCSP는 인증서의 상태를 실시간으로 체크하는 방법을 제공한다. 모든 폐기된 일련번호를 갖고있는 CRL File과는 달리 OCSP는 Client가 CA의 인증서 DB에 바로 질의할수 있도록 한다.

결과적으로 OCSP 방법은 대역폭을 절약하고 실시간 유효성을 제공한다 그러나 실시간 OCSP 질의를 생성해서 사용하는 방식에는 몇가지 문제점이 있다.

• CA는 반드시 실시간 질의에 대한 로드를 다뤄야 한다.
• CA는 항상 전세계적으로 서비스가 실시간 제공되어야 한다.
• CA는 어떤 사이트에 방문한 Client인지를 알기 때문에 실시간 OCSP 요청들은 Client의 개인정보를 침해할수 있다
• 인증서 체인의 유효성을 확인하는 OCSP 요청하는 중에는 블럭이 된다.

OCSP Stapling

위의 몇가지 이유들로인해 CRL, OSCP둘다 보안과 성능을 보장하지 못한다. 그러나 절망하지 말아라. OCSP Stapling (RFC 6066)이 이전에 다루었던 문제들을 대부분 해결하였다. TSL handshake의 일부로 stapled 되어 보내진다.

• Client가 OCSP Request를 하는 대신 Server가 정기적으로 CA의 서명되고 타임스탬프가 반영된 OCSP 응답을 반환한다.
• 그리고 Server 는 TLS Handshake의 일부로 서명된 OCSP 응답 추가한다. Client는 인증서와 첨부된 CA로부터 서명된 OCSP 폐기 목록으로 유효성을 확인할 수 있다.

이역한 반전은 보안에 안정적이다. CA로부터 서명된 Stapled된 레코드 이기 때문에 Client 로부터 인증받을 수 있고 수많은 중요한 장점들을 제공한다.

• Client navigation 기록을 유출하지 않는다.
• Client는 OCSP Server에 질의를 하거나 블럭될 필요가 없다.

요약하면 최상의 보안과 성능을 보장받기 위해서는 Server OCSP Stapling을 설정하여 테스트 해보아야 한다.