OCSP stapling อธิบาย (และทำไมเป็นทางเลือก)

ปัญหา của OCSP ธรรมดา

เมื่อได้รับใบรับรอง เบราว์เซอร์สามารถถาม OCSP responder ของ CA ว่าใบรับรองถูกเพิกถอนหรือไม่ คำขอนั้นเป็นการเชื่อมต่อแยกไปยังบุคคลที่สาม เพิ่มความหน่วง และเปิดเผยว่าผู้เข้าชมกำลังเข้าเว็บใด ก่อนที่หน้าจะโหลดด้วยซ้ำ

ถ้า responder ช้าหรือเข้าถึงไม่ได้ เบราว์เซอร์จะปล่อยผ่าน (ไม่สนใจการตรวจ) หรือบล็อกเว็บ ขึ้นกับไคลเอนต์ ทั้งสองอย่างไม่ดี

stapling เปลี่ยนอะไร

ด้วย stapling เซิร์ฟเวอร์ดึง OCSP response ที่ลงนามแล้วมาเอง แคชไว้ และแนบไปกับ TLS handshake เบราว์เซอร์ได้คำตอบเรื่องการเพิกถอนโดยไม่ต้องติดต่อใคร ไม่มีรอบเพิ่มและไม่มีการรั่ว

ยังตัดการพึ่งพาว่า CA ต้องเข้าถึงได้จากเครือข่ายของผู้เข้าชม ซึ่งสำคัญในภูมิภาคที่ OCSP responder ถูกบล็อกเป็นระยะ

เปิดและตรวจสอบ

บน nginx stapling ต้องมี resolver และไฟล์เชน ถ้าขาดอย่างใดอย่างหนึ่งมันจะเงียบ ๆ ไม่ทำอะไร บน Apache คำสั่งแคชต้องอยู่ระดับเซิร์ฟเวอร์ หลัง reload ให้ตรวจจากภายนอก บรรทัดคอนฟิกที่มีแต่ไม่ทำงานหน้าตาเหมือนบรรทัดที่ไม่มีเลย

# 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+ ไม่บังคับ

stapling เป็นการปรับปรุงความเป็นส่วนตัวและความหน่วง ไม่ใช่ความแข็งแรงของโปรโตคอล เซิร์ฟเวอร์ที่ไม่ staple ไม่ได้ปลอดภัยน้อยลงแบบที่เซิร์ฟเวอร์ที่เสนอ TLS 1.0 เป็น CertH ถือเป็นสัญญาณบวกในส่วนสุขภาพคอนฟิก แต่ไม่บังคับสำหรับเกรดสูงสุด

อย่างไรก็ตาม มันเป็นการปรับปรุงที่ถูกที่สุดอย่างหนึ่ง คือคอนฟิกสองบรรทัด ไม่กระทบไคลเอนต์ และได้ความเป็นส่วนตัวที่วัดได้สำหรับผู้เข้าชมทุกคน

FAQ