เราอาจจะเคยได้ยินว่า “ถ้าจะเข้าเว็บไซต์ ต้องดูว่าเป็น HTTPs หรือมีรูปกุญแจบนเว็บบราวเซอร์ก็จะปลอดภัย” หรือ “หากเราทำเว็บไซต์เป็น HTTPs หรือซื้อกุญแจ SSL Certificate มาแล้ว เว็บของเราก็จะปลอดภัยไม่ถูกแฮก” ซึ่งคำกล่าวดังกล่าวถือว่าถูกต้องแต่ไม่ทั้งหมด แล้วที่ถูกต้องคืออะไร? ในบทความนี้จะมาอธิบายเรื่องเหล่านี้กัน...
SSL Certificate คืออะไร?
ถ้าอธิบายแบบง่ายที่สุด SSL Certificate คือ "บัตรประชาชนดิจิทัล" ของเว็บไซต์ที่บอกว่า "เว็บนี้เป็นของใคร ใครรับรอง และข้อมูลที่ส่งระหว่างกันจะถูกเข้ารหัสให้ปลอดภัย" ในทางเทคนิค SSL Certificate คือไฟล์ดิจิทัลที่อยู่บนเซิร์ฟเวอร์ซึ่งประกอบด้วยข้อมูลสำคัญ ได้แก่
- Public Key เป็นกุญแจสาธารณะสำหรับเข้ารหัสข้อมูล
- ข้อมูลเจ้าของ (Owner) เช่น ชื่อโดเมน, หน่วยงานขององค์กร, ชื่อองค์กร รวมไปถึงประเทศ
- ผู้ออกใบรับรอง (Certificate Authority หรือ CA) เป็นหน่วยงานที่ทำหน้าที่รับรองความถูกต้อง
- วันหมดอายุของใบรับรอง โดยทั่วไปคือ 398 วัน ซึ่งในปัจจุบันนี้ (ปี 2026) มีการเปลี่ยนแปลงวันหมดอายุให้สั้นลง (อ่านได้จากบทความนี้)
- Digital Signature เป็นลายเซ็นดิจิทัลของ CA ที่ยืนยันว่าข้อมูลไม่ถูกแก้ไข
โดยคำว่า "SSL" มาจาก Secure Sockets Layer แต่ที่ใช้จริงในปัจจุบันคือ TLS (Transport Layer Security) ซึ่งปลอดภัยกว่า เพียงแต่ชื่อ SSL ยังใช้เรียกติดปากกันมาจนถึงวันนี้
แล้วเราจะรู้ได้ว่าเว็บไซต์ที่เราเข้าใช้งานอยู่เป็นเว็บที่เข้าด้วย SSL?
ทำได้โดยการดูที่ URL ถ้ามีขึ้นต้นด้วย “https://” และมีรูปกุญแจอยู่ แสดงว่ามีการเข้ารหัสด้วย TLS แล้ว ซึ่งแต่ละเว็บบราวเซอร์ก็อาจจะมีการแสดงผลแตกต่างกัน ในที่นี้ผมยกตัวอย่างเว็บบราวเซอร์ Firefox, Google Chrome และ Microsoft Edge ในการเข้าเว็บเดียวกัน การแสดงผลอาจจะแตกต่างกันเล็กน้อย แต่ทั้งหมดก็เป็นการเข้าเว็บไซต์ https://www.ksc.net ซึ่งเป็นการเข้าเว็บไซต์ผ่านทาง HTTPs (HTTP over SSL) นั่นเอง
หลักการทำงานของ SSL (TLS Handshake)
การเชื่อมต่อ HTTPS ไม่ได้เกิดขึ้นทันที แต่ผ่านกระบวนการที่เรียกว่า TLS Handshake ซึ่งใช้เวลาไม่กี่มิลลิวินาที โดยรวมการเข้ารหัสสองแบบเข้าด้วยกัน คือ Asymmetric (ระบบกุญแจคู่) สำหรับแลกเปลี่ยนกุญแจอย่างปลอดภัย และ Symmetric (ระบบกุญแจเดี่ยว) โดยรูปแบบของการเข้ารหัสสามารถแสดงได้ดังรูป
- Symmetric ระบบกุญแจเดี่ยว จะเป็นการใช้กุญแจ (Secret Key) ในการเข้ารหัสและถอดรหัส โดยกระบวนจะเป็นการส่งข้อมูลที่ยังไม่ได้เข้ารหัส (Plain Text) เมื่อมีการเข้ารหัส (Encryption) แล้ว จะเป็นข้อมูลที่ถูกเข้ารหัสแล้ว (Cipher Text) ส่งผ่านระบบเครือข่ายไปยังปลายทาง จากนั้นถอดรหัส (Decryption) ด้วยกุญแจ เพื่อให้ได้ข้อมูลที่ต้องการเข้ารหัสกลับมา เป็นระบบที่เข้ารหัสได้เร็ว มีประสิทธิภาพสูง แต่ถ้ากุญแจหลุดก็สามารถถูกถอดรหัสได้
- Asymmetric ระบบกุญแจคู่ จะเป็นการสร้างกุญแจ 2 กุญแจขึ้นมาคือ Private Key (กุญแจส่วนตัว) และ Public Key (กุญแจสาธารณะ) ซึ่งเป็นกุญแจที่เข้าคู่กันได้คู่เดียวเท่านั้น โดยกุญแจ Public Key จะส่งออกให้คนภายนอกได้ ส่วนกุญแจ Private Key เก็บเอาไว้เอง จากรูปด้านบนข้อมูลที่จะเข้ารหัส ใช้กุญแจ Public Key เข้ารหัส ส่งข้อมูลไปยังปลายทางเพื่อแกะรหัสด้วยกุญแจ Private Key เพื่อให้ได้ข้อมูลที่จะเข้ารหัสกลับมา มีข้อดีคือมีความปลอดภัยมาก แต่ประสิทธิภาพไม่ดีนักเพราะมีการใช้งานกุญแจจำนวนมาก
โดยระบบ TLS Handshake จะมีการเข้าใช้เทคนิคทั้ง 2 แบบในการเข้ารหัสเข้าด้วยกัน และกระบวนการทำงานจริงจะดำเนินการด้วยความเร็วสูงมาก (ไม่กี่มิลลิวินาที) โดยมีรูปแบบการทำงานเป็นดังรูป
จากรูปด้านบน สามารถสรุปกระบวนการได้ดังนี้
| ขั้นตอนที่ |
กระบวนการ |
ชนิดของการเข้ารหัส |
| 1 |
ฝั่งไคลเอนต์ (เช่น เว็บบราวเซอร์) จะส่งข้อความ “Client Hello” ไปหาเซิร์ฟเวอร์ในนั้นจะบอกว่า:
- รองรับ SSL/TLS เวอร์ชันอะไรบ้าง
- ใช้ชุดการเข้ารหัส (cipher suites) แบบไหนได้
- มีวิธีบีบอัดข้อมูลยังไง
- และมีข้อมูลสุ่มตัวหนึ่งที่เรียกว่า “client random”
|
Asymmetric (กุญแจคู่) |
| 2 |
ฝั่งเซิร์ฟเวอร์จะตอบกลับด้วย “Server Hello” ซึ่งประกอบด้วย:
- public key ของเซิร์ฟเวอร์
- digital certificate
- session ID
- เลือกวิธีเข้ารหัสจากที่ไคลเอนต์ส่งมา
- และ “server random”
|
Asymmetric (กุญแจคู่) |
| 3 |
เครื่องไคลเอนต์จะตรวจสอบตัวตนของเซิร์ฟเวอร์ โดยไปเช็คกับหน่วยงานที่ออกใบรับรอง certificate (CA) ว่า certificate นี้ถูกต้องไหม |
Asymmetric (กุญแจคู่) |
| 4 |
ในขั้นตอน “Client Key Exchange” จะมีขั้นตอน
- ไคลเอนต์จะดึง public key จาก certificate ที่ตรวจแล้ว
- แล้วสร้างข้อมูลสุ่มใหม่ชื่อว่า “premaster secret” เพื่อใช้สำหรับการเข้ารหัสแบบ Symmetric ในขั้นตอนที่ 6 – 8
- จากนั้นเข้ารหัสมันด้วย public key
- แล้วส่งไปให้เซิร์ฟเวอร์
|
Asymmetric (กุญแจคู่) |
| 5 |
เซิร์ฟเวอร์ใช้ private key ของตัวเองในการถอดรหัส premaster secret ออกมา |
Asymmetric (กุญแจคู่) |
| 6 |
ตอนนี้ทั้งไคลเอนต์และเซิร์ฟเวอร์จะใช้ premaster secret มาสร้าง “shared secret key” ร่วมกัน |
Asymmetric (กุญแจคู่) |
| 7 |
ไคลเอนต์ส่งข้อความ “finished” แบบเข้ารหัสไปหาเซิร์ฟเวอร์เพื่อบอกว่า “ฝั่งฉันพร้อมแล้วนะ handshake เสร็จแล้ว” |
Symmetric (กุญแจเดี่ยว) |
| 8 |
เซิร์ฟเวอร์ส่ง “finished” กลับมาแบบเข้ารหัสเหมือนกัน เพื่อยืนยันว่า “ฝั่งฉันก็เสร็จแล้วเหมือนกัน” |
Symmetric (กุญแจเดี่ยว) |
| 9 |
เมื่อ handshake เสร็จเรียบร้อย ทั้งเครื่องไคลเอนต์และเซิร์ฟเวอร์จะเริ่มสื่อสารกันจริง ๆ |
Symmetric (กุญแจเดี่ยว) |
ประวัติของ SSL โดยย่อ
สำหรับ SSL มีการพัฒนาและใช้งานกันมาอย่างยาวนานกว่า 30 ปี ซึ่ง
ในระหว่างการใช้งานก็มีช่องโหว่ความปลอดภัยและได้มีการใช้มาตรฐานชุดใหม่ที่ปลอดภัยมากยิ่งขึ้น จนในปัจจุบันเป็น TLS เวอร์ชัน 1.3 โดยไล่ประวัติคร่าวๆ ได้ดังนี้
| ปี ค.ศ. |
เวอร์ชัน |
รายละเอียด |
สถานะในปัจจุบัน (ปี 2026) |
| 1994 |
SSL 2.0 |
โปรโตคอล SSL ตัวแรก |
ยกเลิกการใช้งาน |
| 1996 |
SSL 3.0 |
มีการปรับปรุงครั้งใหญ่ แต่โดน POODLE attack ในปี 2014 |
ไม่ปลอดภัยแล้ว ยกเลิกปี 2014 |
| 1999 |
TLS 1.0 (RFC 2246) |
เปลี่ยนชื่อจาก SSL เป็น TLS อย่างเป็นทางการ |
PCI DSS ยกเลิกปี 2018 |
| 2006 |
TLS 1.1 (RFC 4346) |
แก้ปัญหา CBC attack แต่ยังไม่เพียงพอ |
ยกเลิกในปี 2020 |
| 2008 |
TLS 1.2 (RFC 5246) |
มีการนำ SHA-256 และ AES-GCM เข้ามาใช้งาน |
ยังสามารถใช้งานได้อยู่ แต่ต้องมีคอนฟิกให้ถูกต้อง |
| 2018 |
TLS 1.3 (RFC 8446) |
พัฒนาใหม่ทั้งหมด และตัด cipher suite ที่อ่อนทิ้งทั้งหมด Handshake เร็วขึ้น (1-RTT) |
มาตรฐานปัจจุบัน |
ความปลอดภัยของ SSL
สำหรับการใช้งาน SSL จะเป็นการเข้ารหัสข้อมูลระหว่างการรับส่ง (Data in transit) ซึ่งเป็นส่วนหนึ่งของความปลอดภัย (อีก 2 ส่วนคือ “Data at rest หรือ ข้อมูลที่จัดเก็บ” และ “Data in use หรือ ข้อมูลในขณะใช้งาน”) เพราะในการใช้งานจริงบนอินเทอร์เนต การส่งข้อมูลที่สำคัญ เช่น การทำธุรกรรมทางการเงิน การซื้อของออนไลน์ การยื่นภาษีออนไลน์ การใช้งานอีเมล การใช้งานระบบคลาวด์ ล้วนแล้วแต่มีความสำคัญมาก และมีการผ่านระบบอินเทอร์เนตที่มีผู้ให้บริการเครือข่ายจำนวนมาก ความปลอดภัยในการส่งข้อมูลจึงมีความจำเป็น หรือเปรียบเสมือนว่าการเข้ารหัส SSL เป็นหัวใจในการส่งข้อมูลนั่นเอง
แล้ว SSL/TLS ปกป้องเราจากอะไรได้บ้าง?
- Eavesdropping (การดักฟัง) แม้แต่ผู้ให้บริการอินเทอร์เนต (ISP), ผู้ดูแลระบบเน็ตเวิร์ก (Network Admin) หรือแฮกเกอร์บนระบบ Wi-Fi เดียวกัน ก็อ่านข้อมูลที่เข้ารหัสไม่ได้
- Man-in-the-Middle (MITM) ใครก็ตามที่พยายาม “ดักฟัง” (หรือเป็น “ผู้ชายที่อยู่ตรงกลาง” ตามชื่อ) ในการสื่อสาร จะถูกตรวจพบได้จาก Certificate verification
- Data Tampering (การแก้ไข/ดัดแปลงข้อมูล) ใน TLS 1.3 มีการใช้กระบวนการ AEAD (Authenticated Encryption with Associated Data) ที่เป็นการเข้ารหัสและตรวจสอบความถูกต้องของข้อมูล (Confidentiality และ Integrity) ซึ่งสามารถตรวจจับการแก้ไขข้อมูลระหว่างทางได้ทันที
- Replay Attack (การดักข้อมูลเอาไว้ แล้วนำมาส่งซ้ำ) ซึ่งในขั้นตอนของ Session key ที่สุ่มขึ้นมาทุกครั้งที่มีการเชื่อมต่อ (unique) เป็นการป้องกันการนำข้อมูลที่ดักเอาไว้แล้วมาใช้งานซ้ำ
แล้วสิ่งที่ SSL/TLS ไม่ได้ช่วย?
- SSL/TLS ปกป้องเฉพาะ 'ระหว่างทาง' ไม่ได้ช่วยถ้าข้อมูลถูกแฮก (compromise) ที่ไคลเอนต์หรือเซิร์ฟเวอร์เอง
- HTTPS ไม่ได้แปลว่าเว็บนั้น 'ดี' เสมอไป เพราะเว็บไซต์ที่หลอกให้กรอกข้อมูล (Phishing sites) ก็สามารถใช้ HTTPS ได้เหมือนกัน
- SSL/TLS ไม่ได้แทนไฟร์วอลล์ (Firewall), Web Application Firewall (WAF) หรือการยืนยันตัวตน (Authentication) ที่แข็งแกร่ง เช่น Multi-Factor Authentication
แล้วเราจำเป็นต้องซื้อ Certificate หรือไม่? มีความแตกต่างระหวาง Self-Signed vs Paid Certificate เป็นอย่างไร?
เป็นคำถามคลาสสิกของ SSL เลยทีเดียว อธิบายคร่าวๆ ได้ดังนี้
- Self-Signed Certificate เสมือนกุญแจเข้ารหัสที่สร้างเอง รับรองเอง มีคุณสมบัติสามารถเข้ารหัสได้สมบูรณ์ แต่กุญแจที่ใช้ไม่มีการรับรองว่าน่าเชื่อถือจริงๆ
- Paid Certificate เสมือนกุญแจที่สร้าง และมีหน่วยงานรับรองว่าถูกต้อง น่าเชื่อถือ มีการตรวจสอบองค์กรว่ามีอยู่จริง
| หัวข้อ |
Self-Signed Certificate |
Paid / Let's Encrypt Certificate |
| ราคาค่าบริการ |
ฟรี |
ฟรี (หากใช้งาน Let's Encrypt) หรือมีค่าใช้จ่ายเป็นรายปี |
| คำเตือนบนเว็บบราวเซอร์ (Browser Warning) |
แสดงคำเตือน |
ไม่มีคำเตือน |
| การรับรองจากผู้ออกใบรับรอง (CA Verification) |
ไม่มี |
มี CA ตรวจสอบในการออกใบรับรอง |
| SSL/TLS เหมาะกับ |
การใช้ในระหว่างพัฒนาระบบ Dev/Test
การใช้งานภายในองค์กรเอง (Internal)
|
การใช้งานภายนอก (Public web)
หรือระบบ e-commerce |
| ระดับของการเข้ารหัส |
เท่ากัน (ขึ้นอยู่กับคอนฟิก) |
เท่ากัน (ขึ้นอยู่กับคอนฟิก) |
Let's Encrypt เป็นทางเลือกที่ดีที่สุดสำหรับเว็บทั่วไป เป็น CA ไม่แสวงหากำไร ออก Certificate ฟรีและได้รับการยอมรับจากเว็บบราวเซอร์ทุกตัวเหมือน Paid Certificate อายุ 90 วัน แต่ต่ออายุอัตโนมัติผ่าน ACME protocol (Certbot) ได้
สำหรับ Paid Certificate มีดังนี้
- DV (Domain Validation) ยืนยันแค่เจ้าของโดเมน ราคาถูก ออกเร็ว เหมาะกับเว็บทั่วไป
- OV (Organization Validation) ยืนยันตัวตนองค์กรด้วย เหมาะกับองค์กรที่ต้องการความน่าเชื่อถือสูง
- EV (Extended Validation) ตรวจสอบเข้มข้นที่สุด เหมาะกับธนาคาร เว็บ e-commerce ขนาดใหญ่
- Wildcard ครอบคลุมทุก subdomain (*.example.com)
- SAN/Multi-domain ใช้ได้กับหลายโดเมนในใบเดียว ประหยัดค่าใช้จ่าย
มาตรฐานที่ยอมรับได้ในปัจจุบัน
สำหรับมาตรฐานของ SSL จะสามารถสรุปได้ดังตาราง
| เวอร์ชัน |
ปีที่ออก (ค.ศ.) |
สถานะ |
หมายเหตุ |
| SSL 2.0 |
1994 |
ยกเลิก (Deprecated) |
ช่องโหว่ร้ายแรง ปิดถาวร |
| SSL 3.0 |
1996 |
ยกเลิก (Deprecated) |
POODLE attack ปิดถาวร |
| TLS 1.0 |
1999 |
ยกเลิก (Deprecated) |
PCI DSS ยกเลิกตั้งแต่ปี 2018 |
| TLS 1.1 |
2006 |
ยกเลิก (Deprecated) |
เว็บบราวเซอร์หลักปิดแล้วทั้งหมด |
| TLS 1.2 |
2008 |
ยอมรับได้ |
ต้องตั้งค่า cipher suite ให้ถูกต้อง |
| TLS 1.3 |
2018 |
แนะนำ |
มาตรฐานปัจจุบันซึ่งเร็วและปลอดภัย |
สำหรับ Cipher Suites ที่แนะนำจะมีดังนี้
- TLS 1.3 ใช้ได้ทั้งหมดที่เว็บบราวเซอร์รองรับ (เลือกแค่ AEAD ciphers อัตโนมัติ)
- TLS 1.2 สามารถใช้งานได้ แต่ต้องเปิดใช้เฉพาะ cipher suite ต่อไปนี้
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- ปิดทันที RC4, DES, 3DES, MD5, SHA-1 (ใน signature), NULL cipher, EXPORT cipher
หากเป็นไปได้เลือกใช้งาน TLS เวอร์ชัน 1.3 แทนที่ TLS เวอร์ชัน 1.2 แต่อาจจะมีความเสี่ยงสำหรับเว็บบราวเซอร์รุ่นเก่าที่ไม่สามารถใช้งานได้ด้วย เพราะถ้าหากปลอดภัยแต่ไคลเอนต์ใช้งานไม่ได้ก็จะกระทบกับธุรกิจทันที โดย TLS เวอร์ชัน 1.3 มีฟีเจอร์ที่ดีกว่าเวอร์ชัน 1.2 คร่าวๆ ดังนี้
- Perfect Forward Secrecy (PFS) บังคับ แม้ Private Key รั่วในอนาคต ก็ไม่สามารถถอดรหัสทราฟฟิกเก่าได้
- Handshake เร็วขึ้น 1-RTT แทน 2-RTT รองรับ 0-RTT Resumption สำหรับ returning connections
- ตัด cipher suites ที่อ่อนทิ้งหมด เหลือแค่ AEAD ciphers (AES-GCM, ChaCha20-Poly1305)
- ไม่มีการ Renegotiation ปิดช่องโหว่ที่มีใน TLS 1.2
สำหรับผู้ดูแลระบบที่ดูแลเว็บเซิร์ฟเวอร์ ลองตรวจสอบขั้นตอนเหล่านี้ว่าระบบของเราปลอดภัยเพียงพอแล้วหรือยัง
- เปิดใช้ TLS 1.2 และ TLS 1.3 เท่านั้น โดยปิด TLS 1.0, 1.1 และ SSL ทั้งหมด
- เปิด HSTS (HTTP Strict Transport Security) กำหนด max-age อย่างน้อย 6 เดือน
- เปิด OCSP Stapling เพื่อตรวจสอบ revocation status แบบ real-time
- ตั้งการแจ้งเตือน (Alert) การหมดอายุของ Certificate อัตโนมัติ (อย่างน้อย 30 วันล่วงหน้า)
- ทดสอบด้วย SSL Labs (https://ssllabs.com/ssltest) ควรได้เกรด A หรือ A+
- เปิด Certificate Transparency monitoring — ตรวจสอบใบปลอมในชื่อโดเมนตัวเอง
ตัวอย่างการตรวจสอบ SSL ผ่านเว็บไซต์ https://www.ssllabs.com
เนื่องจาก SSL/TLS เป็นเรื่องความน่าเชื่อถือขององค์กร และมีรายละเอียดพอสมควร การเลือกใช้งานผู้ให้บริการที่มีความรู้จะช่วยให้การทำงานขององค์กรเรามีประสิทธิภาพมากขึ้น รวมไปถึงการวางแผนการใช้งาน Certificate ให้เหมาะสมกับงานที่ใช้ก็จะเป็นการใช้งานระบบไอทีให้เหมาะสมกับงบประมาณขององค์กรเรา
เอกสารอ้างอิง