ปี 2025 — HTTP ใน production = ตาย#

เอาตรงๆ ครับ — ปี 2025 ที่เรากำลังเข้าใกล้นี้ — ไม่มีข้ออ้างใดๆ ทั้งสิ้นที่จะรันเว็บ production เป็น HTTP. เหตุผลคือ:

1. Let’s Encrypt = CA ฟรี + ออก cert อัตโนมัติ + อายุ 90 วัน + renew อัตโนมัติ — ตั้งแต่ปี 2016. ต้นทุน = 0 บาท
2. Cloudflare = CDN ฟรี + ให้ HTTPS ฟรี + ตั้ง 5 นาทีจบ. ต้นทุน = 0 บาท
3. Browser = Chrome / Firefox / Safari ทุกตัว — แสดง “Not Secure” สีแดง ถ้าเป็น HTTP — ตั้งแต่ปี 2018-2019
4. SEO = Google ลด ranking เว็บที่เป็น HTTP — ตั้งแต่ปี 2014

ถ้าตอนนี้บริษัทคุณยังมีเว็บที่เป็น HTTP อยู่ มี 2 กรณีเท่านั้นที่เป็นไปได้ครับ (1) เป็น internal tool ที่อยู่หลัง VPN จริงๆ หรือ (2) ทีม dev ของคุณไม่ได้อัปเดทตัวเองมา 5 ปีแล้ว ซึ่งกรณีหลังนี้น่ากลัวกว่าเรื่อง HTTP เยอะครับ

มุมผู้บริหาร: สั่งทีม IT ทำ audit ภายใน 1 สัปดาห์ — list ทุก domain + subdomain ของบริษัท + ทุก URL ที่ลูกค้าใช้ — ติ๊กว่ายังเป็น HTTP อยู่ตรงไหนบ้าง. ถ้าเจอแม้ 1 URL ที่เป็น HTTP + รับ data จากผู้ใช้ (login, form, payment) — fix ภายใน 24 ชั่วโมง. ต้นทุนการ fix = 0 บาท (Let’s Encrypt / Cloudflare ฟรี) — ต้นทุนของการไม่ fix = ค่าปรับ PDPA + ข่าวลงหน้า 1 ตอนที่ password ลูกค้าหลุดผ่าน Wi-Fi ร้านกาแฟ

Handshake 5 ขั้น แบบไม่ต้องอ่าน RFC#

ลองนึกเป็นบทสนทนาระหว่าง Client (browser ของคุณ) กับ Server (www.google.com) ครับ:

ขั้นที่ 1 — Client Hello

Client: “สวัสดีครับ ผมเป็น Chrome version 130. ผมรู้จัก TLS 1.2 + 1.3. ผมรู้จัก cipher suite พวกนี้ (AES-256-GCM, ChaCha20-Poly1305, …). นี่คือ random number ของผม. คุณอยากใช้อะไรล่ะ?”

ขั้นที่ 2 — Server Hello + Certificate

Server: “สวัสดีครับ ผมเลือก TLS 1.3 + AES-256-GCM. นี่ random number ของผม. และนี่คือ certificate ของผม — เซ็นโดย GTS CA 1C3 — ที่เซ็นโดย GTS Root R1. ตรวจสอบดูเถิด”

ขั้นที่ 3 — Verify Certificate Chain

Client: (ใน 0.01 วินาที) ตรวจ chain — GTS Root R1 อยู่ใน trusted root store ของระบบ + ลายเซ็นถูกต้อง + ยังไม่หมดอายุ + ชื่อตรงกับ www.google.com + ไม่อยู่ใน revocation list (OCSP) — ผ่าน

ขั้นที่ 4 — Key Exchange (Diffie-Hellman / ECDH)

Client + Server: ใช้คณิตศาสตร์ — ที่ EP.21 (Asymmetric crypto) ผมจะอธิบายลึก — ในการ “ตกลงกุญแจร่วม” โดยไม่ส่งกุญแจตรงๆ ผ่านสาย. โจรที่ฟังอยู่กลางทาง — เห็นทั้งหมด — แต่คำนวณกุญแจไม่ออก เพราะคณิตศาสตร์มันบิดมาก ๆ (ECDH / Diffie-Hellman key exchange)

ขั้นที่ 5 — Encrypted Session

หลังจากนั้น — ทั้ง client + server มี กุญแจร่วม (symmetric key) ที่เหมือนกัน — ใช้กุญแจนี้เข้ารหัสทุก message ต่อจากนั้นด้วย AES-256-GCM. โจรที่ฟังอยู่ — เห็นแค่ตัวอักษรขยะ — อ่านไม่ออกครับ

ทั้งหมดนี้ — ใช้เวลารวมประมาณ 50-100 millisecond (เร็วกว่าคุณกระพริบตา 3 เท่า)

TLS 1.2 vs TLS 1.3 — ทำไม 1.3 ดีกว่า#

TLS 1.2 (2008) — มี 2 round trip (browser ส่งไป-มา 2 รอบก่อนเริ่มคุย). TLS 1.3 (2018) — รวบเหลือ 1 round trip + ตัด cipher suite เก่าๆ ที่อันตรายออกหมด (RC4, DES, MD5, SHA-1, …)

ผลคือ TLS 1.3 — เร็วกว่า + ปลอดภัยกว่า ในเวลาเดียวกัน. 0-RTT mode (zero round trip — ใช้กุญแจเก่าที่จำได้) ทำให้ resume session ได้แทบจะ instant. ปัจจุบันปี 2025 — server ใหม่ทุกตัวต้องรองรับ TLS 1.3. browser ทุกตัวรองรับมาตั้งแต่ปี 2018-2019

มุมผู้บริหาร: ขอ list จากทีม IT ว่า TLS version ต่ำสุดที่เปิดอยู่บน production คืออะไร. ถ้าเปิด TLS 1.0 หรือ 1.1 อยู่ — fix ทันที (ปิดทั้งคู่ — keep แค่ 1.2 + 1.3). PCI-DSS บังคับให้ปิด TLS 1.0 มาตั้งแต่ปี 2018 + 1.1 ตั้งแต่ 2020. ถ้าบริษัทคุณเป็น merchant ที่รับบัตรเครดิต + ยังเปิด TLS 1.0/1.1 อยู่ — คุณ non-compliant ทันที + เสี่ยงถูก Visa/Mastercard ถอน license

1. Confidentiality in transit — ไม่มีใครระหว่างทางอ่านได้#

นี่คือสิ่งที่คนส่วนใหญ่นึกถึงเป็นอันดับแรก. HTTPS เข้ารหัสข้อความทั้งหมดระหว่าง browser ของคุณกับ server ปลายทาง. คนระหว่างทาง — Wi-Fi ของร้านกาแฟ / ISP ของคุณ / Tier-1 ISP / ใครก็ตามที่ดักฟัง — เห็นแค่ขยะที่ถอดรหัสไม่ออก

แต่ — สังเกตคำว่า in transit ครับ. แปลว่า — ระหว่างทางเท่านั้น. พอข้อมูลถึง server แล้ว — HTTPS หมดหน้าที่. ข้อมูลใน database ของ server เก็บยังไง — เข้ารหัสหรือเปล่า — เป็นอีกเรื่อง (เรียกว่า data at rest encryption ซึ่งคนละเรื่องกับ HTTPS เลย — รายละเอียดอยู่ใน EP.18)

2. Integrity in transit — ไม่มีใครระหว่างทางแก้ได้#

นี่คืออย่างที่ 2 ที่ HTTPS ทำให้ — แต่หลายคนนึกไม่ถึง. นอกจากการ “อ่าน” ไม่ได้แล้ว — คนระหว่างทางยัง “แก้” ไม่ได้ด้วย

ลองนึกตัวอย่าง. ถ้าคุณส่งคำสั่งโอนเงินผ่าน HTTP — โจรที่อยู่กลางทาง — เห็นว่าคุณส่ง “โอน 1,000 บาท ไปบัญชี 12345” — เปลี่ยนเป็น “โอน 100,000 บาท ไปบัญชี 99999” (บัญชีของโจร) — ส่งต่อไปให้ server. server เห็นข้อความ — ดูเหมือนมาจากคุณ — โอนตามนั้น. คุณซวย

ใน HTTPS — ทุก message ที่ส่งมีค่า MAC (Message Authentication Code) ติดมาด้วย (ผ่าน AEAD cipher อย่าง AES-GCM หรือ ChaCha20-Poly1305). ถ้าโจรแก้แม้ 1 bit — MAC ไม่ตรงกัน — server reject message ทันที + ตัดการเชื่อมต่อ. integrity protected

3. Authentication of server — ยืนยันว่า server คือเจ้าของตัวจริง#

อันนี้คือสิ่งที่คนพลาดมากที่สุดครับ. HTTPS — ผ่าน certificate ที่เรียนใน EP.23 — ยืนยันว่า คุณกำลังคุยกับ www.google.com ตัวจริง ไม่ใช่ใครก็ตามที่แอบขึ้น domain ปลอม + บอกว่าตัวเองเป็น Google

นี่สำคัญมาก — เพราะถ้าไม่มีการยืนยัน server — โจรสามารถทำ Man-in-the-Middle (MitM) attack ได้ง่ายๆ. โจรสร้าง server ปลอมที่ก็อปหน้า login ของ google.com ทุกอย่าง — แทรกตัวเองอยู่กลางทาง — รับ traffic จากคุณ — ส่งต่อให้ google จริง — ทำตัวเป็น “middleman”. คุณไม่รู้ตัวด้วยซ้ำ

HTTPS ป้องกันด้วยการบังคับให้ server แสดง certificate ที่เซ็นโดย CA ที่ browser เชื่อ + ระบุชื่อ domain ที่ตรงกัน. โจรไม่มีทางขอ certificate ของ www.google.com ได้ (เพราะ CA ไม่ออกให้ — เคยอ่านเคส DigiNotar ใน EP.23 มาแล้ว ว่าทำไม)

ภาพรวม 3 อย่าง — ขอย้ำอีกครั้ง#

ลองนึกเป็น checklist สั้นๆ ครับ:

• Confidentiality in transit = อ่านไม่ออก
• Integrity in transit = แก้ไม่ได้
• Server Authentication = ยืนยัน server คือตัวจริง

3 อย่างนี้ + ไม่มากกว่านี้. ทุกอย่างที่นอกเหนือจากนี้ — HTTPS ไม่ป้องกันให้ — และนี่คือจุดที่คนผิดพลาดเยอะที่สุด — section ถัดไปครับ

มุมผู้บริหาร: ตอนทีม dev หรือ vendor บอกคุณว่า “เว็บเรามี HTTPS แล้ว ปลอดภัยแล้ว” — ขอให้ถามกลับ 3 ข้อนี้: (1) Data at rest เข้ารหัสหรือเปล่า? (HTTPS ไม่ครอบคลุม), (2) ระบบมีกันการคลิก phishing link หรือเปล่า? (HTTPS ไม่ป้องกัน), (3) TLS version + cipher suite ที่เปิดใช้ ผ่าน SSL Labs A+ หรือเปล่า? (ลองเช็คฟรีที่ ssllabs.com/ssltest). ถ้าตอบไม่ได้ทั้ง 3 ข้อ — คุณยังมี gap ทั้งที่คิดว่าตัวเอง “ปลอดภัย”

1. Data at rest — HTTPS หมดหน้าที่ตอนถึงปลายทาง#

ตัวอย่างจริง — ลองนึกเว็บ shop.example.com. คุณกรอกบัตรเครดิต — HTTPS เข้ารหัสตอนส่ง — ปลอดภัยระหว่างทาง. ของถึง server ของ shop. server เก็บบัตรเครดิตของคุณ — เก็บยังไง?

ถ้า shop เก็บบัตรเครดิตเป็น plain text ใน database (ผิด PCI-DSS — แต่บริษัทเล็กๆ ทำกันเยอะ) — วันที่ database ถูกแฮก — เลขบัตรลูกค้าทั้งหมดหลุดในรูปแบบที่อ่านได้ทันที. HTTPS ของ shop = A+ rating บน SSL Labs ทุกอย่าง — แต่ไม่ช่วยอะไรเลย เพราะ HTTPS ปกป้องตอนเดินทางเท่านั้น — ไม่ได้ปกป้องตอนเก็บ

ภาพในใจ: รถ Brink’s หุ้มเกราะส่งเงินถึงสาขาธนาคารแล้ว — เอาเงินไปวางบนโต๊ะหน้าธนาคารโดยไม่ใส่ตู้เซฟ. โจรไม่ต้องปล้นรถ Brink’s — เดินมาหยิบจากโต๊ะเอา. นั่นคือ data at rest ที่ไม่ได้เข้ารหัส

2. Phishing site ที่มี cert ถูกต้อง — กับดักที่กุญแจสีเขียวก็โกหก#

อันนี้คือกับดักที่ผมอยากให้คุณจำตลอดชีวิตครับ

โจรปี 2025 — ไม่ได้พยายามแฮก HTTPS อีกต่อไป (ยากเกิน + ไม่คุ้ม). โจรทำง่ายกว่านั้น:

1. ซื้อ domain ที่หน้าตาคล้ายของจริง — เช่น googlee.com (มี e 2 ตัว) / gооgle.com (g, ο, ο = อักษรซีริลลิก ที่หน้าตาเหมือน g, o, o ของอังกฤษ) / google-login.com / google.com.evil.tk
2. ขอ certificate ฟรีจาก Let’s Encrypt สำหรับ domain ที่ตัวเองซื้อมา — ฟรี + ไม่มีการตรวจสอบความเป็นเจ้าของบริษัท
3. ก๊อปหน้า login ของ google มาวางบน server — ใส่ certificate
4. ส่งอีเมล phishing — ให้ link ไป googlee.com (ที่ตัวเองทำ)

เหยื่อคลิก — เห็น กุญแจสีเขียว บน browser — สบายใจ — กรอก username + password — กด login. password ตกในมือโจรเรียบร้อย

กุญแจสีเขียวบอกอะไรในเคสนี้? บอกว่า — “connection นี้เข้ารหัสปลอดภัย + คุณกำลังคุยกับเจ้าของ domain googlee.com ตัวจริง”. ทุกอย่าง ถูกต้องทุกประการ — เพราะคุณคุยกับ googlee.com ตัวจริงครับ — ที่บังเอิญเป็นโจร

กุญแจสีเขียว ≠ เว็บนี้ปลอดภัย. กุญแจสีเขียว = (1) เข้ารหัส + (2) เป็นเจ้าของ domain นี้จริง. มันไม่ได้บอกว่า domain นี้ตรงกับบริษัทที่คุณตั้งใจจะคุยด้วยหรือเปล่า — เรื่องนั้นคุณต้องดูเอง

นี่คือสาเหตุที่ในปี 2019 — APWG (Anti-Phishing Working Group) รายงานว่า — กว่า 74% ของ phishing site มี HTTPS + กุญแจสีเขียว. ปี 2020 ตัวเลขนี้ขึ้นเป็น 78%. ปี 2023 = 84%. กุญแจสีเขียวกลายเป็นมาตรฐานของโจร — ไม่ใช่สัญญาณของความปลอดภัยอีกต่อไป

อ้าว — แล้ว Let’s Encrypt ผิดไหม? ไม่ผิดครับ. Let’s Encrypt มีหน้าที่ออก DV (Domain Validation) cert เท่านั้น — ยืนยันว่าคุณเป็นเจ้าของ domain. ไม่ใช่ตำรวจที่ต้องตรวจสอบว่าใครเป็นโจร. คนที่ต้องตรวจคือ — ผู้ใช้ + browser + registrar

3. Misconfig — TLS เปิดแบบผิดๆ ก็ไร้ค่า#

HTTPS ที่ “configured ไม่ถูก” ก็เหมือนใส่ตู้เซฟแบบเปิดประตูทิ้งไว้ครับ. ตัวอย่างของ misconfig ที่เจอบ่อย:

• เปิด TLS 1.0 / 1.1 ที่ deprecated แล้ว — เปิด attack surface สำหรับ POODLE / BEAST
• เปิด weak cipher suite — RC4, DES, 3DES, MD5, NULL cipher — โจรถอดรหัสได้ในเวลาไม่นาน
• Cert หมดอายุ — แล้ว user override warning — ฝึก user ให้ “กดผ่านเรื่อย” — วันที่ MitM ของจริงเข้ามา user ก็จะกดผ่านอยู่ดี
• No HSTS — โจรหลอกให้ browser downgrade จาก HTTPS ลงเป็น HTTP ได้ (SSL Strip attack)
• Self-signed cert ใน production — browser ไม่เชื่อ — user เห็น warning — ปิด warning ทิ้ง — ไม่มีประโยชน์

ลองเข้า ssllabs.com/ssltest กรอก domain ของบริษัทคุณดู — มันให้เกรด A+ ลงไปถึง F. target = A หรือ A+. ถ้าเกรด B ลงไป — ทีม dev ต้อง fix ภายในสัปดาห์นี้

4. Client compromise — เครื่อง user ถ้าโดนแฮก HTTPS ก็ช่วยอะไรไม่ได้#

HTTPS ปกป้องข้อมูลระหว่าง browser ของคุณ → server. แต่ถ้า browser ของคุณ + เครื่องของคุณ โดนยึดแล้ว — เกมจบครับ

ลองนึกถ้า:

• เครื่องคุณมี keylogger — บันทึกทุกตัวอักษรที่คุณพิมพ์ — รวมถึง password ก่อนที่ HTTPS จะเข้ารหัส
• Browser คุณมี malicious extension — อ่านทุกหน้าเว็บที่คุณเปิด — รวมถึงเลขบัตรเครดิตที่คุณพิมพ์
• เครื่องคุณติด info-stealer malware — ก็อปทั้ง cookie + session token — เอาไปใช้ login เป็นคุณ
• ทีม IT บริษัทคุณติดตั้ง MitM proxy ที่ฝัง root cert ของบริษัทไว้ในทุกเครื่อง — บริษัทอ่าน traffic HTTPS ของพนักงานได้หมด (ของจริง — เรียก SSL inspection — ใช้ใน enterprise)

HTTPS = transport security. ถ้า endpoint โดนยึด — security เจาะทะลุไปแล้ว — HTTPS ช่วยอะไรไม่ได้

มุมผู้บริหาร: อย่าตกหลุมพรางคำว่า “เว็บเรา HTTPS แล้ว = ปลอดภัย”. HTTPS ปลอดภัยแค่ data in transit — ส่วนที่เหลือ (data at rest / phishing / endpoint) ไม่เกี่ยวเลย. ทดสอบเร็วๆ ที่ ssllabs.com/ssltest — ถ้า domain หลักของบริษัทไม่ได้ A+ = ตั้ง TLS config ผิด เปิดประตูให้โจร downgrade attack ทันที

Heartbleed 2014 — bug ที่ทำให้โลกหยุดหายใจ 1 สัปดาห์#

Heartbleed (CVE-2014-0160) — เป็นบั๊กใน OpenSSL (library ที่ใช้ใน server กว่า 60% ของอินเทอร์เน็ตในปี 2014) ที่อนุญาตให้ใครก็ตาม อ่าน memory ของ server ได้ครั้งละ 64KB — ผ่าน feature ที่ชื่อ TLS heartbeat (ไว้ check ว่า connection ยังอยู่)

bug คืออะไร? heartbeat protocol ให้ client ส่งข้อความเล็กๆ + บอกว่า “ข้อความผมยาวเท่านี้ — เธอตอบกลับมาเท่านี้นะ”. server ที่ buggy — เชื่อ client โดยไม่ตรวจ — ถ้า client โกหกว่ายาว 64KB (จริงๆ ส่งมาแค่ 1 byte) — server ตอบกลับ memory ของตัวเอง 64KB — ที่ในนั้นอาจมี private key + password ของ user + session cookie + ของลับใดๆ ที่อยู่ใน RAM ตอนนั้น

ผลกระทบ — OpenSSL เวอร์ชั่นที่ buggy ใช้กันทั่วโลก ระหว่างปี 2012-2014. วันที่ bug ประกาศ (7 เมษา 2014) — ทุก server ในโลกที่ใช้ OpenSSL bugged version — โดนยึดได้ทันที. ในสัปดาห์เดียวกัน — Yahoo + GitHub + Reddit + Tumblr + … ต้องบังคับให้ user reset password ทั่วโลก

นี่คือสาเหตุที่ตอนนั้น browser มีไอคอน xkcd Heartbleed + ทุกเว็บส่งอีเมลให้ user “เปลี่ยน password ด่วน” พร้อมกันใน 1 สัปดาห์ — ของจริงครับ ไม่ใช่ตำนาน

POODLE 2014 — SSLv3 ตายในวันเดียว#

POODLE (Padding Oracle On Downgraded Legacy Encryption) — ปี 2014 เช่นกัน — เป็นการเจาะ SSLv3 ที่เก่าตั้งแต่ปี 1996. attacker บังคับให้ browser downgrade จาก TLS ลงเป็น SSLv3 — แล้วใช้ padding oracle attack ถอดรหัส cookie ได้

ผลคือ — ทั่วโลกปิด SSLv3 ทันทีในเดือนตุลาคม 2014. SSLv3 = ตายแล้ว ตั้งแต่นั้น — ใครยังเปิดอยู่ในปี 2025 = ตั้งใจให้โจรเจาะ

BEAST 2011 — TLS 1.0 ก็ไม่รอด#

BEAST (Browser Exploit Against SSL/TLS) — ปี 2011 — เจาะ TLS 1.0 ผ่าน weakness ใน CBC mode + predictable IV. ผลคือ — ทั่วโลกค่อยๆ ปิด TLS 1.0 — แต่ปิดช้ามาก (เพราะมี user legacy เยอะ). กว่าจะปิดสนิทจริงๆ ก็ปี 2020

DROWN 2016 — bug ข้าม protocol#

DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) — ปี 2016 — เจาะ SSLv2 (ที่ตายตั้งแต่ปี 1995) — เพื่อ break TLS connection ที่ใช้ server เดียวกัน. ผลคือ — กระตุ้นให้ทุก server ปิด SSLv2 + SSLv3 หมดสิ้น

CRIME / BREACH — compression ก็ขายความลับได้#

CRIME (Compression Ratio Info-leak Made Easy) — ปี 2012 — โจมตีผ่าน TLS compression. BREACH — ปี 2013 — version ที่โจมตี HTTP compression. ทั้งคู่อาศัยข้อเท็จจริงว่า — ตัวอักษรที่ซ้ำกันถูก compress ให้สั้นลง — โจรเดาขนาดได้ → เดาตัวอักษรได้

ผลคือ — ทั่วโลกปิด TLS compression. HTTP compression ใช้ระวังขึ้น

Lesson — update + ปิด protocol เก่า#

บทเรียนของ TLS attacks ทุกตัว — มีรูปแบบเดียวกัน:

1. มีคนเจอ bug ใน library / protocol เก่า
2. ประกาศต่อสาธารณะ (responsible disclosure ให้เวลา vendor fix ก่อน)
3. โลกแห่กัน patch + ปิด version เก่า
4. บริษัทที่ไม่ patch — โดนเจาะ 6-12 เดือนหลังจากนั้น

ถามตัวเองครับ — บริษัทคุณ patch OpenSSL ครั้งล่าสุดเมื่อไหร่? ถ้าตอบไม่ได้ — คุณคือเป้าหมาย

Equifax 2017 — เคสในกลุ่มเดียวกัน#

ในข่าว Equifax 2017 (ที่ข้อมูล 147 ล้าน user หลุด) มีรายละเอียดที่น่าสนใจครับ ในช่วงเวลาที่ Equifax ถูกเจาะ certificate ของระบบ monitoring TLS ของพวกเขาหมดอายุไป 10 เดือน ก่อนหน้านั้น ระบบ monitoring เลย ไม่ทำงาน ตลอด 10 เดือน โจรเดินเข้าออกได้สบาย ไม่มีใครเห็น traffic แปลกๆ cert ที่หมดอายุเป็นปัจจัยหนึ่งของหายนะมูลค่ากว่า $700M

บทเรียน — cert lifecycle management สำคัญพอๆ กับ TLS version. ปี 2025 — automation (Let’s Encrypt + cert-manager + ACME protocol) ทำให้ไม่มีข้ออ้างว่า “cert หมดอายุเพราะลืม renew” อีกแล้ว

มุมผู้บริหาร: ทำ 3 SLA ที่เกี่ยวกับ TLS ในบริษัท — (1) TLS library update SLA = patch ภายใน 48 ชั่วโมงหลัง CVE critical ประกาศ (OpenSSL ระดับ Heartbleed), (2) Certificate renewal SLA = renew อัตโนมัติ + alert 30 / 14 / 7 / 1 วันก่อนหมดอายุ, (3) TLS version SLA = ตรวจ SSL Labs grade ของ domain หลัก เดือนละครั้ง — target A+. 3 SLA นี้ — ทำให้คุณไม่เป็น Equifax คนต่อไป