ตรวจความปลอดภัย HTTPS ด้วย SSL Labs: อย่าหยุดแค่กุญแจเขียว

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

กุญแจเขียวบอกอะไรเราได้บ้าง

เว็บไซต์ที่เปิดผ่าน HTTPS อาจยังใช้ TLS เวอร์ชันเก่า เปิด Cipher Suites ที่อ่อนแอ หรือติดตั้ง Certificate Chain ไม่ครบได้ นอกจากนี้ การเปลี่ยนเส้นทางจาก HTTP ไป HTTPS อาจตั้งค่าไม่ถูกต้องจนผู้ใช้บางส่วนยังเข้าถึงเว็บไซต์ผ่านการเชื่อมต่อที่ไม่ได้เข้ารหัส

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

เริ่มตรวจ HTTPS ด้วย SSL Labs

SSL Labs เป็นเครื่องมือที่ช่วยทดสอบการตั้งค่า HTTPS ของเว็บไซต์จากหลายมุม เมื่อระบุชื่อโดเมนและเริ่มการสแกน ระบบจะตรวจองค์ประกอบสำคัญแล้วสรุปผลเป็นเกรดตั้งแต่ A+ ลงไปถึงระดับที่มีความเสี่ยง

ขั้นตอนพื้นฐานมีดังนี้

1. เปิดเครื่องมือ SSL Server Test ของ SSL Labs
2. ระบุโดเมนที่ต้องการตรวจ เช่น example.com
3. รอให้ระบบทดสอบ Certificate, Protocol และ Cipher Suites
4. อ่านทั้งเกรดและรายละเอียดของคำเตือนแต่ละรายการ

ไม่ควรตัดสินจากเกรดเพียงอย่างเดียว เพราะเว็บไซต์ที่ได้เกรด A อาจยังมีข้อสังเกตที่ควรแก้ไข รายละเอียดใต้ผลคะแนนจะช่วยบอกว่าปัญหาเกิดจาก Certificate, TLS, Cipher, HSTS หรือความเข้ากันได้กับ Client รุ่นต่าง ๆ

ตรวจ Certificate และ Chain ให้ครบ

ส่วน Certificate เป็นจุดแรกที่ควรตรวจ ชื่อโดเมนต้องตรงกับชื่อที่ระบุในใบรับรอง วันหมดอายุไม่ควรใกล้เกินไป และ Issuer ควรเป็น Certificate Authority ที่อุปกรณ์ทั่วไปเชื่อถือ

อีกประเด็นสำคัญคือ Certificate Chain ต้องสมบูรณ์ หากเซิร์ฟเวอร์ส่งเฉพาะใบรับรองของเว็บไซต์แต่ไม่ส่ง Intermediate Certificate อุปกรณ์บางเครื่องอาจแสดงคำเตือน แม้ใบรับรองหลักจะยังถูกต้องและไม่หมดอายุก็ตาม

ปัญหานี้พบได้บ่อยเมื่อติดตั้ง Certificate บน Nginx หรือ Apache แล้วเลือกไฟล์ไม่ครบ ผู้ดูแลระบบจึงควรตรวจว่าเซิร์ฟเวอร์ส่งทั้งใบรับรองเว็บไซต์และ Intermediate Certificate ตามลำดับที่ถูกต้อง

ปิด Protocol รุ่นเก่า

เว็บไซต์สมัยใหม่ควรปิด SSLv2, SSLv3, TLS 1.0 และ TLS 1.1 แล้วรองรับ TLS 1.2 และ TLS 1.3 เป็นหลัก Protocol รุ่นเก่ามีข้อจำกัดด้านความปลอดภัยและไม่ควรถูกเปิดทิ้งไว้เพียงเพราะต้องการรองรับอุปกรณ์ที่ล้าสมัย

หากระบบยังเปิด TLS 1.0 เพื่อรักษาความเข้ากันได้ ควรประเมินว่าผู้ใช้กลุ่มนั้นยังมีความสำคัญจริงหรือไม่ สำหรับระบบ Login, Payment และ Admin Dashboard ความเข้ากันได้กับ Client เก่าไม่ควรถูกแลกด้วยความเสี่ยงที่ตรวจพบได้ยาก

ตรวจ Cipher Suites และจุดที่จบ TLS

Cipher Suites กำหนดวิธีเข้ารหัสที่ Client และ Server ใช้ร่วมกัน ควรหลีกเลี่ยง RC4, 3DES, CBC รุ่นเก่า และ Cipher ที่ไม่รองรับ Forward Secrecy พร้อมเลือกชุดการเข้ารหัสที่เหมาะสมกับ TLS เวอร์ชันปัจจุบัน

หากใช้ Nginx ควรทบทวนค่า ssl_ciphers และพิจารณา ssl_prefer_server_ciphers ตามบริบทของระบบ แต่ถ้าเว็บไซต์อยู่หลัง Cloudflare, AWS Application Load Balancer หรือ CDN อื่น การตั้งค่าที่ต้องแก้อาจอยู่ใน Security Policy ของบริการเหล่านั้นแทนที่จะอยู่ในเว็บเซิร์ฟเวอร์

หลายกรณีปัญหาไม่ได้เกิดจากโค้ดของแอปพลิเคชัน แต่เกิดจาก Load Balancer หรือ Reverse Proxy ที่รับการเชื่อมต่อจากผู้ใช้ ทีมพัฒนาจึงควรรู้ให้ชัดว่า TLS สิ้นสุดที่ระบบใดก่อนเริ่มแก้ Configuration

เปิด HSTS อย่างระมัดระวัง

เมื่อเว็บไซต์พร้อมให้บริการผ่าน HTTPS ทั้งระบบแล้ว สามารถเพิ่ม Strict-Transport-Security เพื่อบังคับให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS ในครั้งต่อไป ตัวอย่างค่าที่พบบ่อยคือ max-age=31536000; includeSubDomains ซึ่งกำหนดระยะเวลาหนึ่งปีและครอบคลุมทุก Subdomain

อย่างไรก็ตาม includeSubDomains จะมีผลกับ Subdomain ทั้งหมด หากมีบาง Host ที่ยังไม่รองรับ HTTPS ผู้ใช้จะไม่สามารถเปิด Host นั้นได้หลังเบราว์เซอร์จดจำนโยบาย HSTS แล้ว จึงควรสำรวจทุก Subdomain และวางแผนย้อนกลับก่อนเปิดใช้จริง

ส่วน HSTS Preload ต้องระวังมากกว่าเดิม เพราะเป็นการขอให้เบราว์เซอร์บังคับ HTTPS ตั้งแต่ก่อนเชื่อมต่อเว็บไซต์ ไม่ควรเปิดใช้จนกว่าจะมั่นใจว่าทั้งโดเมนและ Subdomain ที่เกี่ยวข้องรองรับ HTTPS อย่างสมบูรณ์

อย่าตรวจเฉพาะโดเมนหลัก

เว็บไซต์หนึ่งระบบอาจมีหลาย Host เช่น www.example.com, api.example.com, admin.example.com และ app.example.com แต่ละ Host อาจใช้ Certificate และจบ TLS คนละตำแหน่ง จึงไม่สามารถนำผลตรวจของโดเมนหลักไปยืนยันความปลอดภัยของทุก Subdomain ได้

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

รายการ Host ที่ควรนำมาตรวจประกอบด้วย

• เว็บไซต์หลักและโดเมนที่มี www
• API ที่เปิดให้แอปพลิเคชันหรือบุคคลภายนอกใช้งาน
• หน้า Admin และระบบหลังบ้าน
• แอปพลิเคชันบน Subdomain แยก
• Host ที่ผ่าน CDN, Proxy หรือ Load Balancer คนละชุด

สแกนซ้ำและเก็บหลักฐานก่อนกับหลัง

หลังแก้ Configuration แล้วควรล้าง Cache ของผลทดสอบใน SSL Labs และสแกนอีกครั้ง เพื่อให้แน่ใจว่าค่าที่ระบบภายนอกมองเห็นเปลี่ยนไปตามที่ตั้งใจ ไม่ควรสรุปว่าแก้สำเร็จจากไฟล์ Configuration หรือหน้าจอควบคุมเพียงอย่างเดียว

ควรบันทึกผลก่อนและหลังไว้ใน Ticket เช่น ปิด TLS 1.0 แล้วเกรดเปลี่ยนจาก B เป็น A, แก้ Certificate Chain แล้วคำเตือนหาย หรือเปิด TLS 1.3 แล้วการเชื่อมต่อรองรับ Protocol ใหม่ หลักฐานเหล่านี้ช่วยให้ทีมพัฒนา Infrastructure และ Security ตรวจสอบผลลัพธ์ร่วมกันได้ชัดเจน

Checklist สำหรับระบบ Production

SSL Labs สามารถใช้เป็น Checklist ก่อนเผยแพร่ระบบใหม่และหลังเปลี่ยนโครงสร้างเครือข่ายได้ การตรวจควรครอบคลุมประเด็นต่อไปนี้

• ชื่อโดเมน Issuer วันหมดอายุ และความสมบูรณ์ของ Certificate Chain
• การปิด SSL และ TLS รุ่นเก่าที่ไม่ควรใช้งาน
• Cipher Suites และการรองรับ Forward Secrecy
• การตั้งค่า Redirect จาก HTTP ไป HTTPS
• ความพร้อมก่อนเปิด HSTS, includeSubDomains และ Preload
• ความเข้ากันได้กับ Client ที่องค์กรจำเป็นต้องรองรับ
• ทุก Subdomain และทุกจุดที่สิ้นสุดการเชื่อมต่อ TLS

ควรทำการตรวจทุกครั้งก่อนเปิดเว็บไซต์ใหม่ หลังเปลี่ยน CDN, Load Balancer หรือ Certificate และเมื่อมีการปรับ Security Policy นอกจากนี้ควรตั้งระบบแจ้งเตือนล่วงหน้าก่อน Certificate หมดอายุ เพื่อไม่ให้บริการหยุดชะงักจากงานดูแลรักษาที่วางแผนได้

สรุป

SSL Labs ไม่ได้เป็นเพียงเว็บไซต์สำหรับให้เกรด แต่เป็นเครื่องมือสำรวจสุขภาพของ HTTPS ในระบบ Production ตั้งแต่ Certificate และ TLS ไปจนถึง Cipher Suites, HSTS และความเข้ากันได้ของ Client กุญแจบนเบราว์เซอร์จึงควรเป็นสัญญาณให้เริ่มตรวจสอบอย่างเป็นระบบ ไม่ใช่จุดสิ้นสุดของงานด้านความปลอดภัย