개요
사용자가 HTTPS 웹 사이트를 방문하면 작업중인 것으로 응답해야합니다. 공개 키, 키를 개인, 회사 또는 조직의 ID와 연관시키는 유효한 SSL 인증서. 인증서는 항상 서명 된 인증서 자체에 포함 된 사전 정의 된 만료 날짜로 발급되며 브라우저는 항상 만료 날짜를 확인하여 만료 된 인증서를 거부합니다.
그러나 어떤 경우에는 인증서가 유효하지 않은 것으로 표시되어야하며 해당 인증서에 대한 신뢰는 취소 된) 전에 만료됩니다. 일반적인 예로는 개인 키를 소유 한 제 XNUMX자가 본질적으로 모든 브라우저 네트워크 보안 제어를 우회 할 수 있기 때문에 개인 키가 손상 (즉, 분실, 도난 또는 파괴)되었다는 증거가있는 서버 소유자가 있습니다.
결과적으로 브라우저 공급 업체는 공개적으로 신뢰할 수있는 인증 기관 (CA에) 문제가있는 인증서를 해지하고 이러한 해지 된 인증서를 거부하도록 브라우저에 알리는 방법을 하나 이상 구현합니다.
해지 확인의 문제에 대한 간략한 역사
SSL 초기에 CA가 사용한 방법은 인증서 해지 상태를 공개적으로 액세스 할 수있는 문서에 게시하는 것이 었습니다. 인증서 해지 목록 (C.R.L.). CRL은 단순히 만료 전에 CA가 해지 한 모든 인증서의 목록입니다. CA는 정기적으로 최신 버전의 CRL을 게시했습니다. 전에 각 HTTPS 연결.
당연히 HTTPS (및 SSL /TLS) 채택은 수년에 걸쳐 증가했으며 게시 된 CRL의 크기도 증가했습니다. 각 연결 전에 큰 CRL을 다운로드하고 구문 분석해야하는 요구 사항으로 인해 네트워크 오버 헤드가 계속 증가했습니다. CRL 방법이 제대로 확장되지 않는다는 것이 금방 분명해졌습니다.
이러한 스케일링 문제를 완화하기 위해 브라우저와 CA는 온라인 인증서 상태 프로토콜 (OCSP). 다음과 같이 공개적으로 신뢰할 수있는 CA SSL.com이제 간단한 HTTP 서버를 유지 OCSP 응답자. 브라우저는 이제 응답자에게 연락하여 전체 CRL을 획득하고 처리하는 대신 CA가 발급 한 단일 인증서의 해지 상태를 요청할 수 있습니다.
OCSP 응답자는 CA의 개인 서명 키로 응답에 서명하고 브라우저는 수신 한 해지 상태가 실제로 실제 CA에서 생성되었는지 확인할 수 있습니다.
불행히도, OCSP가 처음에는 효과적인 솔루션처럼 보이지만 새로운 프로토콜은 실제 성능, 보안 및 개인 정보 보호 문제가있는 것으로 입증되었습니다.
성능 문제
브라우저가 발견하는 모든 인증서에 대해 응답자에게 연락한다는 것은 브라우저가 새 HTTPS 연결마다 추가 HTTP 요청을 수행해야 함을 의미합니다. 이 네트워크 오버 헤드는 특히 원격 콘텐츠 배포 서버에 저장된 타사 콘텐츠가 포함 된 페이지 (각각 하나 이상의 인증서가있을 수 있음)에서 사용자가 인식 할 수 있습니다.
응답 좋은 사용자 인터페이스 디자인의 필수 원칙입니다. 지연 시간이 길면 사용자가 불만을 일으킬 수 있으며 사용자가 웹 사이트가 작동하지 않거나 입력 제스처가 무시되었다고 생각하게 할 수 있습니다.
더 많은 것 연구 과거에는 빠른 페이지로드 속도와 응답 성을 SEO 및 개선 된 전환율과 연결했습니다. 실제로 아마존은 단 XNUMX 초의 지연으로 인해 비용이 발생할 수 있다고 계산했습니다. $1.6 십억 매년.
페이지로드 속도가 웹 사이트에 미치는 영향 및 제안 된 최적화에 대한 자세한 내용은 기사 웹 사이트에서 혼합 컨텐츠를 제거하여 성능을 향상시키는 방법을 설명합니다.)
보안 문제
OCSP에는 중요한 보안 문제도 있습니다. 실제 OCSP 구현의 대부분이 (네트워크 지연 또는 구성 또는 응용 프로그램 오류로 인해) 신뢰성이 부족하여 브라우저 및 기타 클라이언트 소프트웨어가 OCSP 확인을 구현하도록 동기를 부여했습니다. 소프트 실패 방법.
즉, 응답을 제공하는 동안 OCSP 서버에 도달 할 수 없거나 시간 초과되면 브라우저는 인증서를 유효한 것으로 간주 어쨌든 HTTPS 연결을 진행하십시오.
그 이유는 OCSP 서버가 잠재적으로 수백만 개의 웹 사이트에 서비스를 제공 할 수 있고 OCSP 서버가 언제라도 실패 할 수 있기 때문에 모든 OCSP 실패시 연결을 끊으면 수백만 명의 사용자가 브라우징 환경을 방해 할 수 있기 때문입니다. OCSP 서버가 작동하지만 응답하는 데 시간이 오래 걸리더라도 인식되는 지연 및 사용자 불만이 추가됩니다.
MITM (Man-in-the-Middle) 공격자는 차단하여이 동작을 악용하는 것으로 알려져 있습니다. 모든 OCSP 응답자에 대한 연결. 즉, 인증서의 해지 상태에 관계없이 악의적 인 사이트에 도난 된 인증서 및 키 쌍을 사용할 수 있음을 의미합니다.
개인 정보 보호 문제
마지막으로 인증서가 키 및 도메인 이름과 연결되어 있고 브라우저는 모든 새 HTTPS 연결 전에 해지 상태를 요청하므로 브라우저가 사용자 웹 기록의 상당 부분을 OCSP 응답자에게 유출합니다.
물론 공개적으로 신뢰할 수있는 CA는 사용자 개인 정보를 침해하려는 악의적 인 조직이 아닙니다. (유명한 CA는 항상 적극적으로 노력하고 있습니다. 보호 사용자의 보안 및 개인 정보 보호.) 그러나 CA의 OCSP 응답자가 손상되는 경우 신뢰할 수없는 서버와 교환 된 데이터로 인해 민감한 개인 정보가 공개 될 수 있습니다.
구조에 OCSP 스테이플 링
이러한 문제를 완화하기 위해 브라우저와 CA는 인증서 상태를 확인하는 새로운 방법을 고안했습니다. OCSP 스테이플 링. OCSP 스테이플 링을 사용하면 브라우저 대신 웹 서버가 인증서에 대해 서명 된 OCSP 응답을 얻을 수 있으며 최대 7 일 동안 캐시 할 수 있습니다.
서버에는 다음이 포함됩니다 (또는 스테이플) SSL 인증서 자체와 함께 HTTPS 응답에서 캐시 된 OCSP 응답 이렇게하면 브라우저는 OCSP 응답에서 CA 서명을 확인할 수 있으며 보안 연결이 설정되기 전에 OCSP 서버 자체에 값 비싼 추가 요청을 수행 할 필요없이 인증서가 해지되지 않았 음을 확인할 수 있습니다.
OCSP 스테이플 링은 위에서 언급 한 문제에 대한 간단하지만 매우 효과적인 솔루션입니다. 서버는 캐시 된 OCSP 응답을 자체 시간에 검색 할 수 있으므로 CRL 및 OCSP에 의해 부과되는 성능 오버 헤드와 함께 개인 정보 보호 문제가 제거됩니다.
그러나 OCSP 스테이플 링만으로는 OCSP의 소프트 실패 보안 문제를 완전히 해결할 수 없습니다. 스테이플 링은 서버에서 구현되기 때문에 브라우저는 서버가 실제로 스테이플 링을 지원하는지 여부를 알 수 없습니다.
결과적으로 훔친 (그러나 해지 된) 인증서를 가진 MITM 공격자는 OCSP 스테이플 링없이 인증서를 제공하여 다운 그레이드 공격을 수행 할 수 있습니다. 피해자의 브라우저는 서버가 실제로 스테이플 링을 지원하는지 여부를 확증 할 수 없으며 평소처럼 OCSP 응답자에게 쿼리를 진행합니다.
그런 다음 MITM 공격자는이 OCSP 쿼리를 간단히 차단하고 브라우저가 인증서를 유효한 것으로 수락하도록 강제 할 수 있습니다.
OCSP 머스트 스테이플
이 공격으로 인해 CA 및 브라우저 공급 업체는 SSL 인증서에 대한 확장을 도입했습니다. RFC 7633, 일반적으로 불리는 OCSP 필수품 (RFC 자체는이 이름을 언급하지 않으므로 혼동을 일으킬 수 있습니다.) 이것은 단순히 인증서에 대한 OCSP 스테이플 링을 요구합니다. 브라우저가 OCSP 스테이플 링없이 사용되는이 확장명을 가진 인증서를 발견하면 거부됩니다. OCSP Must-Staple은 앞서 언급 한 다운 그레이드 공격을 완화하고 CA의 OCSP 응답자에 대한 불필요한 트래픽을 줄여 전체 OCSP 성능을 개선하는 데 도움이됩니다.
인증서에서 OCSP Must-Staple 확장을 활성화하는 데 관심이있는 경우 다음의 지원 에이전트 중 한 명에게 문의하십시오. support@ssl.com 자세한 내용은.
서버에서 OCSP 스테이플 사용
이 문제를 해결하기 위해 다음 섹션에는 OCSP 스테이플 링을 활성화하는 방법에 대한 지침이 포함되어 있습니다. 아파치 과 Nginx에 환경 :
아파치
에서 OCSP 스테이플 링을 활성화하려면 아파치 서버의 구성 파일에 다음 줄을 추가하십시오.
# OCSP 스테이플 링, httpd 2.3.3 이상에서만 SSLStaplingResponderTimeout의 SSLUseStapling 5 SSLStaplingReturnResponderOffs SSLStaplingCache shmcb에서 :
Nginx에
에서 OCSP 스테이플 링을 활성화하려면 Nginx에 서버의 구성 파일에 다음 텍스트를 추가하십시오.
# OCSP Stapling --- # ssl_certificate의 URL에서 OCSP 레코드를 가져 와서 캐시합니다. ssl_stapling on; ssl_stapling_verify on;
결론
웹은 상호 의존적 인 구성 요소로 구성된 복잡한 네트워크로, 모든 것이 일반적으로 원활한 브라우징 환경을 제공하기 위해 조화롭게 작동합니다. 그러나이 시스템의 복잡성이 계속 증가함에 따라 공격 영역이 더욱 넓어지고 새로운 네트워크 공격이 고 안되고 실행될 수 있습니다.
구성 요소의 수가 많을수록 대기 시간이 길어지고 지연이 발생하므로 기업은 사용자 경험에 영향을 미치지 않으면 서 보안을 개선 할 수있는 방법을 찾아야합니다. OCSP 스테이플 링을 활성화하면 보안을 향상시킬 수있는 드문 기회가 제공됩니다 과 동시에 귀하의 웹 사이트에 대한 성능.
항상 OCSP 스테이플 링 또는 기타 문제에 대한 귀하의 질문에 답변 해 드리겠습니다. support@ssl.com.
