Sandworm Lazarus แฟ้มคดี / CASE-009

CASE-009ระดับ 2 · เปิดฝาดูกลไกต่อยอดจาก CASE-008

HTTPS & ใบรับรองดิจิทัล

HTTPS & Certificates

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

เขียนและวาดภาพโดย Sandworm เวลาอ่าน ประมาณ 28 นาที ภาพอธิบาย 6 ภาพ อ่านจบแล้วจะ อ่านคำเตือนของเบราว์เซอร์ออก และไม่ถูกกุญแจหลอกอีก

สีในภาพประกอบของแฟ้มนี้: แดง ผู้โจมตีเหลือง จุดเสี่ยงเขียว การป้องกันฟ้า ข้อมูลของเรา

01ส่งโปสการ์ดบนอินเทอร์เน็ต HTTP vs HTTPS

บ่ายวันเสาร์ ร้านกาแฟแถวมหาวิทยาลัยคนแน่นร้าน ทุกคนต่อ Wi‑Fi ชื่อเดียวกันที่แปะไว้บนเคาน์เตอร์ โต๊ะข้าง ๆ มีคนหนึ่งเปิดโน้ตบุ๊กนั่งเงียบ ๆ ไม่ได้ทำงาน ไม่ได้ดูหนัง แต่หน้าจอของเขาเต็มไปด้วยตัวอักษรที่วิ่งไม่หยุด ทุกบรรทัดคือข้อมูลที่ลอยไปมาในอากาศของร้านนี้

เวลาเราเปิดเว็บ เบราว์เซอร์คุยกับเซิร์ฟเวอร์ด้วยภาษาที่ชื่อว่า HTTP (HyperText Transfer Protocol) ซึ่งออกแบบมาตั้งแต่ยุคที่อินเทอร์เน็ตยังเป็นของนักวิจัยไม่กี่กลุ่มที่ไว้ใจกัน HTTP จึงส่งทุกอย่าง แบบตัวหนังสือธรรมดา เหมือน โปสการ์ด ที่บุรุษไปรษณีย์ทุกคนตลอดเส้นทางพลิกอ่านได้ ทั้งเจ้าของ Wi‑Fi เราเตอร์ ผู้ให้บริการอินเทอร์เน็ต หรือคนที่นั่งดักฟังอยู่ในร้าน

HTTPS คือ HTTP ตัวเดิม ที่ถูกห่อด้วยชั้นป้องกันชื่อว่า TLS (Transport Layer Security) ก่อนส่งออกไป เปรียบเหมือนเอาโปสการ์ดใส่ ซองปิดผนึก ที่มีแค่ผู้รับตัวจริงเปิดได้ แถมซองนี้ยังมีตราประทับกันแกะ ถ้ามีใครแอบเปิดหรือเปลี่ยนของข้างในระหว่างทาง ปลายทางจะรู้ทันที

สิ่งที่ TLS ทำ คือเอาเครื่องมือทั้งหมดจาก CASE-008 มาประกอบกันอย่างลงตัว: Diffie–Hellman ตกลงกุญแจ ลายเซ็นดิจิทัลพิสูจน์ตัวตนของเว็บ และกุญแจดอกเดียวอย่าง AES ล็อกข้อมูลจริง ถ้ายังไม่ได้อ่านบทนั้น แนะนำให้ย้อนไปอ่านก่อน บทนี้จะเข้าใจง่ายขึ้นมาก

ศัพท์น่ารู้: SSL กับ TLS
SSL คือชื่อรุ่นแรก ๆ ของเทคโนโลยีนี้ ซึ่งเลิกใช้ไปนานแล้วเพราะมีจุดอ่อน รุ่นต่อมาเปลี่ยนชื่อเป็น TLS รุ่นที่ควรใช้ตอนนี้คือ TLS 1.2 และ TLS 1.3 ส่วน TLS 1.0 กับ 1.1 ถูกประกาศเลิกใช้อย่างเป็นทางการในปี 2021 แต่คนในวงการยังติดปากเรียกว่า “ใบรับรอง SSL” อยู่ ได้ยินคำไหนก็หมายถึงเรื่องเดียวกัน

02คนดักฟังเห็นอะไรบ้าง What an eavesdropper sees

ลองกลับไปที่ร้านกาแฟ ถ้าเราล็อกอินเว็บร้านค้าออนไลน์ผ่าน Wi‑Fi ของร้าน คนที่ดักฟังอยู่จะเห็นข้อมูลต่างกันมาก ขึ้นอยู่กับว่าเว็บนั้นใช้ HTTP หรือ HTTPS ภาพข้างล่างจำลองหน้าจอของเขาทั้งสองกรณี

FIG 01โปสการ์ดกับซองปิดผนึก: สิ่งที่คนดักฟังเห็น

บันทึกเป็นภาพ
บรรทัดสีแดงฝั่ง HTTP คือของที่คนร้ายอยากได้ที่สุด ฝั่ง HTTPS ยังมีบรรทัดสีเหลืองหลุดออกมา คือชื่อเว็บและที่อยู่ IP ปลายทาง ส่วนเนื้อหาข้างในกลายเป็นเลขฐานสิบหกที่อ่านไม่ออก ที่อยู่ IP ในภาพเป็นเลขสำหรับใช้ในตัวอย่างเท่านั้น
อ่านภาพนี้เป็นข้อความ
  1. ฉาก: เครื่องเราต่อ Wi‑Fi ร้านกาแฟที่มีคนดักฟังอยู่ เพื่อไปที่เว็บ shop.example
  2. แบบ http:// (โปสการ์ด): คนดักฟังเห็นคำสั่ง POST /login, ชื่อเว็บ, คุกกี้ session, ชื่อผู้ใช้ somchai และรหัสผ่าน rakthai123 ครบทุกตัว และแก้ไขข้อมูลระหว่างทางได้ด้วย
  3. แบบ https:// (ซองปิดผนึก): คนดักฟังเห็นแค่ว่ามีการเชื่อมต่อ TLS 1.3 ไปที่ shop.example ที่อยู่ IP ปลายทาง เวลา และขนาดข้อมูล ส่วนเนื้อหา รหัสผ่าน และคุกกี้ เป็นตัวอักษรมั่วที่อ่านและแก้ไม่ได้

สังเกตว่า HTTPS ไม่ได้ซ่อนทุกอย่าง คนดักฟังยังรู้ว่าเราไปเว็บไหน ตอนกี่โมง และรับส่งข้อมูลมากน้อยแค่ไหน ข้อมูลรอบ ๆ แบบนี้เรียกว่า เมทาดาทา (Metadata) ชื่อเว็บหลุดออกมาเพราะตอนเริ่มจับมือ เบราว์เซอร์ต้องบอกเซิร์ฟเวอร์ว่าอยากคุยกับเว็บไหน (เซิร์ฟเวอร์หนึ่งเครื่องอาจดูแลหลายร้อยเว็บ) ช่องนี้เรียกว่า SNI (Server Name Indication) และถูกส่งก่อนที่การเข้ารหัสจะเริ่ม

เทคโนโลยีใหม่ชื่อ ECH (Encrypted Client Hello) เข้ามาปิดรูนี้ โดยเข้ารหัสช่วงทักทายด้วย Firefox เปิดใช้เป็นค่าเริ่มต้นแล้ว แต่ต้องรอให้เว็บปลายทางรองรับด้วยจึงจะได้ผล ระหว่างนี้ให้จำไว้ว่า HTTPS ปกป้อง “สิ่งที่เราพูด” ไม่ได้ปกป้อง “ว่าเราไปคุยกับใคร”

ศัพท์น่ารู้: Man-in-the-Middle บน Wi‑Fi สาธารณะ
คนร้ายอาจตั้ง Wi‑Fi ชื่อเหมือนของร้าน (Evil twin) หรือดักอยู่ในเครือข่ายเดียวกัน เพื่อให้ข้อมูลของเราวิ่งผ่านเครื่องเขา ถ้าเว็บเป็น HTTP เขาอ่านและแก้ได้หมด ถ้าเป็น HTTPS ที่ตั้งค่าถูก เขาได้แค่ซองปิดผนึก อ่านวิธีใช้ Wi‑Fi สาธารณะให้ปลอดภัยได้ใน CASE-006

03จับมือกันก่อนคุย: TLS 1.3 The TLS handshake

ก่อนจะส่งข้อมูลจริงได้ เบราว์เซอร์กับเซิร์ฟเวอร์ต้องทำความรู้จักกันก่อน ขั้นนี้เรียกว่า การจับมือ (Handshake) มีงานสามอย่างที่ต้องทำให้เสร็จ คือ ตกลงวิธีเข้ารหัส ตกลงกุญแจลับร่วมกัน และ พิสูจน์ว่าเซิร์ฟเวอร์เป็นตัวจริง ภาพข้างล่างคือ TLS 1.3 ฉบับย่อ ซึ่งเป็นรุ่นปัจจุบันที่ออกเป็นมาตรฐานในปี 2018

FIG 02การจับมือ TLS 1.3 ฉบับย่อ

บันทึกเป็นภาพ
อ่านจากบนลงล่าง ลูกศรสีเขียวที่มีรูปกุญแจคือข้อความที่ถูกเข้ารหัสแล้ว สังเกตว่าใน TLS 1.3 แม้แต่ใบรับรองของเซิร์ฟเวอร์ก็ส่งแบบเข้ารหัส ทั้งหมดนี้ใช้การส่งไปกลับเพียงรอบเดียวก่อนเริ่มส่งข้อมูลจริง
อ่านภาพนี้เป็นข้อความ
  1. ClientHello: เบราว์เซอร์ทักทาย บอกวิธีเข้ารหัสที่รองรับ แนบส่วนผสมสำหรับแลกกุญแจ (key share) และชื่อเว็บที่ต้องการ ช่วงนี้ยังไม่เข้ารหัส คนดักฟังเห็นชื่อเว็บได้
  2. ServerHello: เซิร์ฟเวอร์เลือกวิธีเข้ารหัสและแนบส่วนผสมของตัวเองกลับมา ถึงตรงนี้ทั้งสองฝั่งคำนวณกุญแจลับร่วมกันได้แล้วด้วย Diffie–Hellman
  3. เซิร์ฟเวอร์ส่งใบรับรอง ลายเซ็นยืนยันว่าถือกุญแจส่วนตัวคู่กับใบรับรองจริง และข้อความ Finished ทั้งหมดเข้ารหัสแล้ว
  4. เบราว์เซอร์ตรวจใบรับรอง: ชื่อตรงกับเว็บไหม ยังไม่หมดอายุไหม ไล่ลายเซ็นถึง CA ที่ไว้ใจได้ไหม ถ้าไม่ผ่านจะขึ้นหน้าเตือนและหยุด
  5. เบราว์เซอร์ส่ง Finished ยืนยันว่าข้อความที่คุยกันมาไม่มีใครแอบแก้
  6. ข้อมูลจริง เช่น หน้าเว็บ รหัสผ่าน คุกกี้ วิ่งในอุโมงค์เข้ารหัส คนดักฟังเห็นแต่ตัวอักษรมั่ว

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

เรื่องที่สามคือ ความเร็ว TLS รุ่นก่อนต้องส่งไปกลับสองรอบก่อนเริ่มคุย TLS 1.3 ลดเหลือรอบเดียว และตัดอัลกอริทึมเก่าที่มีจุดอ่อนทิ้งไปหมด ความปลอดภัยที่ดีขึ้นจึงมาพร้อมเว็บที่โหลดเร็วขึ้นด้วย ไม่ได้แลกกัน และอย่างที่เห็นใน CASE-008 เบราว์เซอร์หลักเริ่มใช้การแลกกุญแจแบบผสมที่ทนต่อคอมพิวเตอร์ควอนตัม (X25519MLKEM768) ในขั้นนี้แล้ว

04ใบรับรองดิจิทัลคืออะไร What a certificate is

ใบรับรองดิจิทัล (Digital certificate) คือ บัตรประจำตัวของเว็บไซต์ มันผูกชื่อโดเมน เช่น shop.example เข้ากับกุญแจสาธารณะดอกหนึ่ง แล้วมีองค์กรที่เรียกว่า ผู้ออกใบรับรอง (Certificate Authority, CA) เซ็นรับรองว่า “กุญแจดอกนี้เป็นของเจ้าของโดเมนนี้จริง”

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

FIG 03หน้าตาของใบรับรอง เทียบกับบัตรประชาชน

บันทึกเป็นภาพ
ข้อมูลในภาพเป็นตัวอย่างที่ย่อให้อ่านง่าย ใบจริงมีช่องมากกว่านี้ อยากดูใบจริงของเว็บไหน ให้กดไอคอนหน้าชื่อเว็บในแถบที่อยู่ แล้วเลือกเมนูดูข้อมูลการเชื่อมต่อหรือใบรับรอง
อ่านภาพนี้เป็นข้อความ
  1. ออกให้กับ (Subject): shop.example และ www.shop.example เหมือนชื่อ-นามสกุลบนบัตรประชาชน
  2. กุญแจสาธารณะ: EC P-256: เหมือนรูปถ่ายบนบัตร ไว้เทียบว่าคนตรงหน้าคือเจ้าของบัตรจริง เซิร์ฟเวอร์ต้องพิสูจน์ว่าถือกุญแจส่วนตัวที่คู่กัน
  3. ผู้ออกใบ (Issuer): Example Intermediate CA: เหมือนสำนักงานเขตที่ออกบัตรให้
  4. ใช้ได้ตั้งแต่ 1 ต.ค. 2026 ถึง 29 ธ.ค. 2026 เหมือนวันออกบัตรและวันหมดอายุ
  5. เลขประจำใบ (Serial): เหมือนเลขที่บัตร
  6. ลายเซ็นของผู้ออก: เหมือนตราประทับและลายมือชื่อเจ้าหน้าที่ ที่ปลอมไม่ได้
  7. ข้อควรจำ: ใบรับรองยืนยันว่าเจ้าของคุมโดเมนนี้จริง แต่ไม่ได้ยืนยันว่าเจ้าของเป็นคนดี

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

CA ตรวจอะไรก่อนออกใบ

ใบรับรองสำหรับเว็บส่วนใหญ่เป็นแบบ DV (Domain Validated) CA ตรวจแค่ว่าคนขอใบ คุมโดเมนนั้นได้จริง เช่น ให้วางไฟล์ลับบนเว็บ หรือเพิ่มค่าพิเศษในระบบ DNS ของโดเมน ทำได้อัตโนมัติในไม่กี่วินาที ส่วนแบบ OV และ EV จะตรวจตัวตนขององค์กรเพิ่ม เมื่อก่อนเบราว์เซอร์เคยโชว์ชื่อบริษัทเป็นแถบสีเขียวให้ใบแบบ EV แต่เลิกไปตั้งแต่ปี 2019 เพราะผู้ใช้ส่วนใหญ่ไม่ได้สังเกตหรือเข้าใจมัน

ศัพท์น่ารู้: Certificate Authority (CA)
องค์กรที่ได้รับความไว้ใจให้เซ็นรับรองใบรับรองของเว็บไซต์ทั่วโลก ต้องผ่านการตรวจสอบตามกฎของ CA/Browser Forum (ที่ประชุมของ CA กับผู้ผลิตเบราว์เซอร์) และนโยบายของผู้ผลิตเบราว์เซอร์แต่ละราย CA ที่ทำพลาดร้ายแรงจะถูกถอดความไว้ใจ ซึ่งเท่ากับปิดกิจการ อย่างที่จะเห็นในคดี DigiNotar ท้ายบท

05ห่วงโซ่ความไว้ใจ Chain of trust

คำถามต่อไปคือ เบราว์เซอร์รู้ได้อย่างไรว่าลายเซ็นของ CA บนใบนั้นเชื่อได้ คำตอบคือมันไล่ ห่วงโซ่ (Chain) ขึ้นไปทีละชั้น ใบของเว็บไซต์ถูกเซ็นโดย CA ตัวกลาง (Intermediate) และใบของตัวกลางถูกเซ็นโดย CA ราก (Root) ซึ่งเป็นจุดยึดของความไว้ใจทั้งหมด ใบรับรองราก ถูกฝังมากับระบบปฏิบัติการและเบราว์เซอร์ตั้งแต่โรงงาน เครื่องเราจึงรู้จักมันก่อนจะเปิดเว็บไหนเลย

FIG 04ห่วงโซ่ความไว้ใจ จาก Root ถึงใบของเว็บไซต์

บันทึกเป็นภาพ
ลูกศรสีเหลืองชี้ลงคือทิศของการเซ็นรับรอง จากบนลงล่าง ลูกศรสีเขียวชี้ขึ้นคือทิศที่เบราว์เซอร์ตรวจ จากใบของเว็บไล่ขึ้นไปจนเจอ Root ที่อยู่ในรายชื่อที่ไว้ใจ ขาดชั้นไหนไปชั้นเดียว ความไว้ใจก็ขาดทั้งสาย
อ่านภาพนี้เป็นข้อความ
  1. ใบรับรองราก (Root CA) เซ็นรับรองตัวเอง ถูกฝังมากับระบบปฏิบัติการและเบราว์เซอร์ และเก็บกุญแจไว้ออฟไลน์
  2. Root เซ็นรับรองให้ใบรับรองตัวกลาง (Intermediate CA) ซึ่งใช้ออกใบให้เว็บไซต์ในชีวิตประจำวัน
  3. ตัวกลางเซ็นรับรองให้ใบของเว็บไซต์ shop.example ซึ่งเซิร์ฟเวอร์ส่งมาให้ตอนจับมือ
  4. เบราว์เซอร์ไล่ตรวจจากล่างขึ้นบน: ลายเซ็นบนใบเว็บไซต์ตรวจด้วยกุญแจของตัวกลาง ลายเซ็นบนใบตัวกลางตรวจด้วยกุญแจของ Root และ Root ต้องอยู่ในรายชื่อที่ไว้ใจ (Trust store) ทุกใบต้องยังไม่หมดอายุ ไม่ถูกเพิกถอน และชื่อตรงกับเว็บ
  5. ถ้าไล่ไปไม่ถึง Root ที่ไว้ใจ เช่น ใบที่เซ็นเอง หรือ CA ปลอมของคนดักฟัง เบราว์เซอร์จะขึ้นหน้าเตือน

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

ใบรับรองที่กุญแจส่วนตัวหลุด หรือออกให้ผิดคน สามารถถูก เพิกถอน (Revoke) ก่อนหมดอายุได้ แต่ในทางปฏิบัติ การเช็กการเพิกถอนแบบทันทีทำได้ไม่สมบูรณ์นัก วงการจึงหันไปใช้อีกทาง คือทำให้ ใบรับรองมีอายุสั้นลง ใบที่หลุดจะได้หมดอายุไปเองเร็ว ๆ ซึ่งจะเล่าในหัวข้อที่ 08

ความเชื่อ

“ติดตั้งใบรับรองที่บริษัทหรือแอปไหนให้มาก็ได้ ยิ่งมีมากยิ่งปลอดภัย”

ความจริง

การกดติดตั้งใบรับรองราก (Root) เพิ่มเอง เท่ากับบอกเครื่องว่า “ใครถือใบนี้ ไว้ใจได้ทุกเว็บ” ใครมีกุญแจของใบนั้นก็ดักอ่าน HTTPS ของเราได้ อย่าติดตั้งใบรับรองหรือโปรไฟล์ที่เว็บหรือแอปไม่รู้จักขอให้ลง เครื่องขององค์กรอาจมีใบแบบนี้ไว้ตรวจทราฟฟิก ซึ่งควรเป็นเครื่องของที่ทำงานเท่านั้น ไม่ใช่เครื่องส่วนตัว

06กุญแจบนแถบที่อยู่บอกอะไร ไม่บอกอะไร What the padlock means

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

สิ่งที่ HTTPS รับประกัน และสิ่งที่ไม่ได้รับประกัน
เรื่องHTTPS ช่วยไหมเหตุผล
คนบน Wi‑Fi แอบอ่านConfidentialityช่วยเนื้อหาถูกเข้ารหัสตลอดทาง
มีคนแก้หน้าเว็บระหว่างทางIntegrityช่วยถ้าถูกแก้ การตรวจความครบถ้วนจะล้มเหลวทันที
คุยกับโดเมนที่เห็นจริงไหมAuthenticityช่วยใบรับรองผูกกับชื่อโดเมนในแถบที่อยู่
เว็บนี้เป็นของธนาคารจริงไหมIdentity of ownerไม่ช่วยเว็บปลอมที่จดโดเมนหน้าตาคล้าย ๆ ก็มีกุญแจได้ ต้องดูชื่อโดเมนเอง
เว็บนี้ไม่มีมัลแวร์Malwareไม่ช่วยมัลแวร์ส่งผ่าน HTTPS ได้สบาย ๆ ซองปิดผนึกไม่ได้ตรวจของข้างใน
เว็บจะดูแลข้อมูลเราดีData handlingไม่ช่วยพอข้อมูลถึงเซิร์ฟเวอร์แล้ว จะเก็บดีหรือไม่ เป็นอีกเรื่องหนึ่ง

Google เองก็เห็นปัญหานี้ ในปี 2023 ทีม Chrome เขียนว่างานวิจัยของพวกเขาพบว่า มีผู้เข้าร่วมเพียง 11% ที่เข้าใจความหมายของไอคอนกุญแจได้ถูกต้อง และเตือนว่า เว็บฟิชชิงเกือบทั้งหมดก็ใช้ HTTPS จึงมีกุญแจโชว์เหมือนกัน ตั้งแต่ Chrome 117 (กันยายน 2023) จึงเปลี่ยนไอคอนกุญแจเป็นไอคอนรูปปุ่มปรับค่า (tune) ที่ไม่ได้สื่อว่า “ปลอดภัย” อีกต่อไป เพราะการเข้ารหัสควรเป็นเรื่องปกติที่ทุกเว็บต้องมี ไม่ใช่ป้ายรับรองความน่าเชื่อถือ

ความเชื่อ

“เว็บมีกุญแจ มี https แปลว่าเป็นเว็บจริงของธนาคาร กรอกรหัสได้เลย”

ความจริง

เว็บหลอกที่ชื่อคล้ายธนาคารก็ขอใบรับรองให้โดเมนของตัวเองได้ภายในไม่กี่นาที สิ่งที่ต้องดูคือ ชื่อโดเมนทั้งหมด ตัวสะกดตรงไหม ส่วนท้ายถูกไหม และดีที่สุดคืออย่ากดลิงก์จาก SMS หรือแชต ให้เปิดแอปหรือพิมพ์ชื่อเว็บเอง วิธีสังเกตเพิ่มเติมอยู่ใน CASE-003

07เมื่อเบราว์เซอร์ขึ้นหน้าเตือน Browser warnings

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

รหัสคำเตือนใบรับรองที่พบบ่อย ความหมาย และสิ่งที่ควรทำ
รหัสที่เห็นความหมายควรทำอย่างไร
ใบหมดอายุERR_CERT_DATE_INVALIDใบรับรองหมดอายุ หรือนาฬิกาในเครื่องเราผิดเช็กวันเวลาในเครื่องก่อน ถ้าถูกแล้ว แปลว่าเว็บลืมต่ออายุ อย่ากรอกข้อมูลสำคัญ
ชื่อไม่ตรงERR_CERT_COMMON_NAME_INVALIDใบที่ได้รับเป็นของโดเมนอื่น ไม่ใช่เว็บที่เราจะไปอาจตั้งค่าผิด หรือมีคนดักกลางทาง ไม่ควรไปต่อ โดยเฉพาะบน Wi‑Fi สาธารณะ
ผู้ออกไม่น่าเชื่อถือERR_CERT_AUTHORITY_INVALIDไล่ห่วงโซ่ไปไม่ถึง Root ที่เครื่องไว้ใจ เช่น ใบที่เซ็นเองถ้าเป็นเว็บดังที่ปกติใช้ได้ ให้สงสัยว่ามีคนดักกลางทาง ปิดหน้านั้น แล้วเปลี่ยนเครือข่าย
เว็บไม่ใช้ HTTPSNot secureเชื่อมต่อแบบ http ธรรมดา ไม่มีการเข้ารหัสเลยอ่านข้อมูลทั่วไปได้ แต่ห้ามกรอกรหัสผ่าน เลขบัตร หรือข้อมูลส่วนตัว

ข่าวที่ควรรู้: Google ประกาศว่าตั้งแต่ Chrome 154 (ตุลาคม 2026) ตัวเลือก “ใช้การเชื่อมต่อที่ปลอดภัยเสมอ” (Always Use Secure Connections) จะเปิดเป็นค่าเริ่มต้นสำหรับเว็บสาธารณะ Chrome จะพยายามใช้ HTTPS ก่อนเสมอ และถ้าเว็บไหนไม่รองรับ จะขึ้นคำเตือนถามเราก่อนเปิดหน้านั้น เว็บที่ยังใช้ http จึงจะเห็นคำเตือนบ่อยขึ้นมาก

เจอหน้าเตือนแล้วทำอะไร

  1. อย่ากดข้าม ถ้ากำลังจะกรอกข้อมูลสำคัญ

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

  2. เช็กวันเวลาในเครื่อง

    นาฬิกาที่เพี้ยนไปหลายวันทำให้ใบรับรองดูเหมือนหมดอายุได้ ตั้งให้เครื่องดึงเวลาอัตโนมัติ

  3. เปลี่ยนเครือข่าย แล้วลองใหม่

    ถ้าเว็บดังที่ปกติเข้าได้ อยู่ ๆ ขึ้นเตือนเฉพาะบน Wi‑Fi สาธารณะ ให้ปิด Wi‑Fi แล้วลองผ่านเน็ตมือถือ ถ้าหายเตือน แปลว่าเครือข่ายแรกมีปัญหา

  4. Wi‑Fi ที่ต้องล็อกอินก่อนใช้

    Wi‑Fi โรงแรมหรือห้างที่มีหน้าให้กดยอมรับ (Captive portal) อาจทำให้เว็บแรกที่เปิดขึ้นเตือน ให้ล็อกอินหน้านั้นให้เสร็จก่อน แล้วค่อยเปิดเว็บสำคัญ

  5. ถ้าเป็นเว็บของที่ทำงานหรือโรงเรียน ให้แจ้งฝ่ายไอที

    บอกรหัสข้อผิดพลาดที่เห็น จะช่วยให้แก้ได้เร็ว เช่น ใบหมดอายุก็แค่ต่ออายุ

08Let's Encrypt และยุคใบรับรองอายุสั้น Free, automated, short-lived

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

ปลายปี 2015 องค์กรไม่แสวงกำไรชื่อ Let's Encrypt เปิดให้บริการ CA ที่ ฟรี และอัตโนมัติทั้งหมด ผ่านโปรโตคอลชื่อ ACME โปรแกรมบนเซิร์ฟเวอร์ (เช่น Certbot) คุยกับ CA เอง พิสูจน์เองว่าคุมโดเมนได้ ขอใบเอง และต่ออายุเองก่อนหมดอายุ ไม่ต้องมีคนมานั่งกด การเข้ารหัสจึงกลายเป็นของพื้นฐานที่เว็บเล็ก ๆ ก็มีได้ เป็นแรงสำคัญที่ทำให้เว็บส่วนใหญ่ทุกวันนี้เป็น HTTPS

เมื่อการต่ออายุเป็นงานของโปรแกรม อายุของใบรับรองก็สั้นลงได้ ซึ่งดีต่อความปลอดภัย เพราะใบที่กุญแจหลุดหรือออกผิดจะหมดอายุไปเองเร็วขึ้น ไม่ต้องพึ่งระบบเพิกถอนที่ทำงานไม่สมบูรณ์ ในปี 2025 ที่ประชุม CA/Browser Forum ลงมติลดอายุสูงสุดของใบรับรองเว็บเป็นขั้น ๆ

อายุสูงสุดของใบรับรองเว็บตามมติ CA/Browser Forum
ใบที่ออกตั้งแต่อายุสูงสุดผลต่อเจ้าของเว็บ
15 มี.ค. 2026NOW200 วันต่ออายุอย่างน้อยปีละสองครั้ง
15 มี.ค. 2027NEXT100 วันทำมือเริ่มไม่ไหว ควรตั้งระบบอัตโนมัติ
15 มี.ค. 2029FINAL47 วันต้องอัตโนมัติเท่านั้น

Let's Encrypt เองออกใบอายุ 90 วันเป็นค่าเริ่มต้นมาตั้งแต่แรก มีใบอายุแค่ 6 วันให้เลือกใช้ และประกาศว่าจะลดอายุสูงสุดเหลือ 45 วันภายในเดือนกุมภาพันธ์ 2028 ข้อความถึงคนทำเว็บชัดเจนมาก: ถ้ายังต่ออายุใบรับรองด้วยมือ ถึงเวลาเปลี่ยนแล้ว

ตัวอย่างสำหรับผู้ดูแลเว็บขอใบรับรองฟรีและตั้งต่ออายุอัตโนมัติด้วย Certbot (nginx)

# ขอใบรับรองและให้ Certbot แก้ไฟล์ตั้งค่า nginx ให้
sudo certbot --nginx -d shop.example -d www.shop.example

# ทดสอบว่าการต่ออายุอัตโนมัติทำงานจริง (ไม่ได้ต่อจริง)
sudo certbot renew --dry-run

09HSTS และเนื้อหาปะปน HSTS & mixed content

ต่อให้เว็บรองรับ HTTPS แล้ว ก็ยังมีช่องโหว่เล็ก ๆ ตรง จังหวะแรก เวลาเราพิมพ์แค่ bank.example ลงแถบที่อยู่ เบราว์เซอร์รุ่นเก่า ๆ จะเริ่มต้นด้วย http ก่อน แล้วเว็บค่อยสั่งให้ย้ายไป https จังหวะสั้น ๆ นั้นแหละที่คนกลางบน Wi‑Fi ปลอมใช้แทรกตัว แล้วกันไม่ให้เราขึ้นไปถึง https เลย เทคนิคนี้เรียกว่า SSL stripping

ทางแก้คือ HSTS (HTTP Strict Transport Security) เว็บส่งคำสั่งบอกเบราว์เซอร์ว่า “ต่อจากนี้ ห้ามคุยกับฉันแบบ http อีก เป็นเวลา 1 ปี” เบราว์เซอร์จะจำไว้ ครั้งต่อไปพิมพ์ชื่อเว็บเมื่อไร ก็ไป https ทันทีโดยไม่แวะ http และถ้าใบรับรองมีปัญหา หน้าเตือนจะ ไม่มีปุ่มให้กดข้าม สำหรับเว็บสำคัญมาก ๆ ยังสมัครเข้า รายชื่อ HSTS preload ที่ฝังมากับเบราว์เซอร์ได้ด้วย จะได้ปลอดภัยตั้งแต่การเข้าครั้งแรกสุด

FIG 05HSTS ปิดจังหวะแรกที่คนกลางชอบแทรก

บันทึกเป็นภาพ
ครึ่งบน: ไม่มี HSTS คนกลางรับหน้าที่คุยกับธนาคารแทนเรา และให้เราคุยแบบ http ต่อไป ครึ่งล่าง: เบราว์เซอร์จำคำสั่ง HSTS ไว้ จึงไป https ตั้งแต่คำขอแรก คนกลางไม่มีจังหวะให้แทรก
อ่านภาพนี้เป็นข้อความ
  1. ไม่มี HSTS: เราพิมพ์ bank.example เบราว์เซอร์เริ่มด้วย http://bank.example ซึ่งวิ่งผ่านคนกลางบน Wi‑Fi ปลอม
  2. คนกลางกันไม่ให้เราขึ้นไปถึง https (SSL stripping) โดยคุยกับธนาคารแบบ https แทนเรา แต่คุยกับเราแบบ http
  3. รหัสผ่านของเราวิ่งแบบ http คนกลางอ่านได้ทุกตัว
  4. มี HSTS: เบราว์เซอร์จำได้ว่าเว็บนี้ต้อง https เท่านั้น จากครั้งก่อนหรือจากรายชื่อ preload
  5. เบราว์เซอร์ไป https ตั้งแต่คำขอแรก คนกลางไม่มีจังหวะแทรก
  6. คนกลางพยายามลากกลับเป็น http หรือยื่นใบรับรองปลอม แต่ไม่สำเร็จ และหน้าเตือนไม่มีปุ่มให้กดข้าม

ตั้งค่าฝั่งเซิร์ฟเวอร์nginx: ส่ง http ไป https ทุกครั้ง แล้วเปิด HSTS

server {
    listen 80;
    server_name shop.example;
    return 301 https://$host$request_uri;   # ไม่ให้บริการแบบ http เลย
}
server {
    listen 443 ssl;
    server_name shop.example;
    ssl_protocols TLSv1.2 TLSv1.3;            # ปิดรุ่นเก่าที่เลิกใช้แล้ว
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

ค่า max-age=31536000 คือจำนาน 1 ปี (นับเป็นวินาที) ส่วน includeSubDomains ให้ครอบคลุมโดเมนย่อยทั้งหมด ก่อนเปิดใช้ ต้องมั่นใจว่าทุกโดเมนย่อยรองรับ HTTPS แล้วจริง ๆ เพราะเมื่อเบราว์เซอร์จำไปแล้ว จะถอยกลับยาก

เนื้อหาปะปน (Mixed content)

อีกปัญหาที่พบบ่อยคือหน้าเว็บที่โหลดผ่าน https แต่ข้างในไปดึงรูป สคริปต์ หรือไฟล์ CSS มาแบบ http เหมือนส่งจดหมายในซองปิดผนึก แต่แนบโปสการ์ดมาด้วยหนึ่งใบ ถ้าส่วนที่ปนมาเป็นสคริปต์ คนกลางก็แก้สคริปต์นั้นให้ทำอะไรก็ได้บนหน้าเว็บที่ดูเหมือนปลอดภัย เบราว์เซอร์ยุคนี้จึงพยายามอัปเกรดของพวกนี้ไปเป็น https ให้อัตโนมัติ และบล็อกส่วนที่อัปเกรดไม่ได้ ฝั่งคนทำเว็บควรแก้ลิงก์ทุกจุดให้เป็น https และใส่คำสั่ง Content-Security-Policy: upgrade-insecure-requests ไว้ช่วยอีกชั้น

10Certificate Transparency และคดี DigiNotar When a CA falls

ระบบ CA มีจุดอ่อนใหญ่ข้อหนึ่ง: เบราว์เซอร์ไว้ใจ CA หลายสิบรายพร้อมกัน และ CA รายไหนก็ออกใบให้โดเมนไหนก็ได้ ถ้า CA สักรายถูกเจาะ หรือทำงานหละหลวม คนร้ายก็ได้ใบรับรองของ google.com หรือของธนาคารที่ถูกต้องตามกฎทุกประการไปใช้ดักฟัง และเบราว์เซอร์ทั่วไปจะไม่เตือนอะไรเลย นี่ไม่ใช่แค่ทฤษฎี มันเกิดขึ้นจริงแล้ว

FIG 06ลำดับเหตุการณ์คดี DigiNotar

บันทึกเป็นภาพ
สีแดงคือความเสียหาย สีเหลืองคือจุดที่มีคนสังเกตเห็นหรือต้องรับมือ สีเขียวคือการป้องกันที่ได้ผล บทเรียนที่ใหญ่ที่สุดของคดีนี้ ไม่ใช่การถูกเจาะ แต่คือการปิดเรื่องเงียบ ซึ่งทำให้ความไว้ใจที่เป็นทุนทั้งหมดของ CA หายไปในพริบตา
อ่านภาพนี้เป็นข้อความ
  1. กลางปี 2011: ผู้บุกรุกเข้าระบบของ DigiNotar ผู้ออกใบรับรองสัญชาติดัตช์ บริษัทพบร่องรอยในเดือนกรกฎาคม แต่ไม่ได้แจ้งต่อสาธารณะ
  2. กรกฎาคมถึงสิงหาคม 2011: ใบรับรองปลอมถูกออกไปหลายร้อยใบ รวมถึง *.google.com ภายหลังพบว่ามีอย่างน้อย 531 ใบ
  3. ปลายสิงหาคม 2011: ผู้ใช้ในอิหร่านเจอคำเตือนบน Chrome เพราะ Chrome จำใบรับรองของ Google ไว้ล่วงหน้า (pinning) ใบปลอมถูกใช้ดักการเชื่อมต่อจากที่อยู่ IP ราว 300,000 แห่ง ส่วนใหญ่ในอิหร่าน
  4. ตั้งแต่ 29 สิงหาคม 2011: Mozilla, Microsoft, Google และ Apple ทยอยถอด DigiNotar ออกจากรายชื่อ CA ที่ไว้ใจ
  5. 3 กันยายน 2011: รัฐบาลเนเธอร์แลนด์เข้าควบคุมระบบ เพราะ DigiNotar ออกใบรับรองให้บริการภาครัฐด้วย
  6. 20 กันยายน 2011: DigiNotar ล้มละลาย
  7. หลังจากนั้น: วงการผลักดัน Certificate Transparency ให้ใบรับรองทุกใบถูกบันทึกในสมุดบัญชีสาธารณะ

เหตุการณ์ในช่วงนั้นผลักให้วงการหาทางป้องกันแบบใหม่ ผลที่ได้คือ Certificate Transparency (CT) แนวคิดคือ ใบรับรองทุกใบที่ CA ออก ต้องถูกจดลงใน สมุดบัญชีสาธารณะ (CT log) ที่เขียนเพิ่มได้อย่างเดียว ลบหรือแก้ย้อนหลังไม่ได้ ใครก็เปิดอ่านได้ เบราว์เซอร์หลักอย่าง Chrome และ Safari จะไม่ยอมรับใบรับรองสาธารณะที่ไม่มีหลักฐานว่าถูกจดลงสมุดแล้ว

ผลคือ CA ออกใบแบบเงียบ ๆ ไม่ได้อีกต่อไป ถ้ามีคนแอบขอใบให้โดเมนของเรา เจ้าของโดเมนจะเห็นในสมุดบัญชี เจ้าของเว็บสามารถค้นใบรับรองทั้งหมดที่เคยออกให้โดเมนตัวเองได้ฟรีผ่านเว็บค้นหา CT อย่าง crt.sh หรือสมัครบริการแจ้งเตือนเมื่อมีใบใหม่โผล่ขึ้นมา เป็นหนึ่งในตัวอย่างที่ดีที่สุดของแนวคิด “ไว้ใจได้ เพราะตรวจสอบได้”

ศัพท์น่ารู้: CAA record
ค่าที่เจ้าของโดเมนตั้งในระบบ DNS เพื่อบอกว่า “อนุญาตให้ CA รายไหนบ้างออกใบให้โดเมนนี้” CA ที่ไม่อยู่ในรายชื่อต้องปฏิเสธคำขอ ใช้คู่กับ CT ได้ดี ตัวหนึ่งกันก่อนออกใบ อีกตัวช่วยจับได้หลังออกใบ

11สรุปให้จำ Recap

HTTPS คือซองปิดผนึกที่ทำงานให้เราเงียบ ๆ ทุกวัน สิ่งที่เราต้องทำเหลือไม่มาก แต่ทุกข้อสำคัญ

  • ห้ามกรอกข้อมูลสำคัญบนเว็บ http ไม่ว่าจะต่อเน็ตจากที่ไหน
  • กุญแจไม่ได้แปลว่าเว็บจริง ดูชื่อโดเมนให้ครบทุกตัว และเปิดเว็บสำคัญจากแอปหรือบุ๊กมาร์ก ไม่ใช่จากลิงก์
  • หน้าเตือนใบรับรองคือสัญญาณหยุด ไม่กดข้ามบนเว็บที่ต้องล็อกอิน และลองเปลี่ยนเครือข่าย
  • ไม่ติดตั้งใบรับรองหรือโปรไฟล์แปลก ๆ ลงเครื่องส่วนตัว
  • คนทำเว็บ: ใบรับรองอัตโนมัติ (ACME) + เปลี่ยนเส้นทาง http ไป https + HSTS + ไม่มีเนื้อหาปะปน + เฝ้าดู CT log ของโดเมนตัวเอง

ลองทบทวนดู

ใช้ HTTPS บน Wi‑Fi ร้านกาแฟ คนดักฟังยังเห็นอะไรได้บ้าง

เห็นเมทาดาทา เช่น ชื่อเว็บที่ไป (จากช่อง SNI ถ้าไม่ได้ใช้ ECH) ที่อยู่ IP ปลายทาง เวลา และปริมาณข้อมูล แต่เนื้อหา รหัสผ่าน และคุกกี้ อ่านไม่ได้และแก้ไม่ได้

ถ้าคนร้ายได้สำเนาใบรับรองของเว็บธนาคารไป จะปลอมเป็นธนาคารได้ไหม

ไม่ได้ ใบรับรองเป็นของสาธารณะอยู่แล้ว ตอนจับมือ เซิร์ฟเวอร์ต้องพิสูจน์ด้วยลายเซ็นว่าถือกุญแจส่วนตัวที่คู่กับใบนั้น คนร้ายที่ไม่มีกุญแจส่วนตัวจึงผ่านขั้นนี้ไม่ได้

ทำไมเว็บฟิชชิงถึงมีรูปกุญแจได้

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

HSTS แก้ปัญหาอะไร

แก้จังหวะแรกที่เบราว์เซอร์อาจเริ่มด้วย http ซึ่งคนกลางใช้แทรกตัวแล้วกันไม่ให้เราไปถึง https (SSL stripping) เมื่อเบราว์เซอร์จำคำสั่ง HSTS ไว้ จะไป https ตั้งแต่คำขอแรกเสมอ และไม่ให้กดข้ามคำเตือนใบรับรอง

Certificate Transparency ช่วยอะไร ถ้ามี CA ถูกเจาะแบบคดี DigiNotar อีก

ทุกใบรับรองต้องถูกจดในสมุดบัญชีสาธารณะที่แก้ย้อนหลังไม่ได้ ใบปลอมที่ออกให้โดเมนของใครก็จะโผล่ให้เจ้าของโดเมนและนักวิจัยเห็น จับได้เร็วขึ้นมาก และเบราว์เซอร์ไม่ยอมรับใบที่ไม่ได้ถูกจดไว้