OCSP 스테이플링 해설 (그리고 왜 선택 사항인가)

일반 OCSP의 문제

브라우저는 인증서를 받으면 CA의 OCSP 응답자에 질의해 폐기 여부를 확인할 수 있습니다. 이 요청은 제3자에 대한 별도 연결이고 지연을 더하며, 페이지가 로드되기도 전에 방문자가 어느 사이트에 접속하는지 드러냅니다.

응답자가 느리거나 도달할 수 없으면 브라우저는 클라이언트에 따라 검사를 무시하거나 사이트를 차단합니다. 둘 다 좋지 않습니다.

스테이플링이 바꾸는 것

스테이플링에서는 서버가 서명된 OCSP 응답을 직접 가져와 캐시하고 TLS 핸드셰이크에 첨부합니다. 브라우저는 아무에게도 연락하지 않고 폐기 답을 얻습니다. 추가 왕복도, 유출도 없습니다.

또한 방문자 네트워크에서 CA에 도달할 수 있어야 한다는 의존을 없앱니다. OCSP 응답자가 간헐적으로 차단되는 지역에서 중요한 차이입니다.

켜고 확인하기

nginx에서는 스테이플링에 resolver와 체인 파일이 필요하고, 둘 중 하나가 없으면 조용히 아무것도 하지 않습니다. Apache에서는 캐시 지시문이 서버 수준에 있어야 합니다. 재로드 후 반드시 외부에서 확인하세요. 설정은 있는데 동작하지 않는 상태와 아예 없는 상태는 구별되지 않습니다.

# nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

# verify from outside — look for a stapled response, not just "OCSP response: none"
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A3 "OCSP Response Status"

왜 A+에 필요하지 않은가

스테이플링은 프라이버시와 지연의 개선이지 프로토콜 강도의 개선이 아닙니다. 스테이플링을 하지 않는 서버가 TLS 1.0을 제공하는 서버처럼 "덜 안전"한 것은 아닙니다. CertH는 구성 건전성 섹션에서 긍정 신호로 다루지만 최고 등급의 필수 조건으로 두지 않습니다.

그래도 가장 값싼 개선 중 하나입니다. 설정 두 줄, 클라이언트 영향 없음, 모든 방문자에게 측정 가능한 프라이버시 이득이 있습니다.

FAQ