TLS: โปรโตคอลเบื้องหลังไอคอนรูปกุญแจทุกอัน

SSL → TLS: เรื่องราวตามลำดับเวลา

Netscape Communications ได้สร้างการใช้งาน SSL ครั้งแรกในปี 1994 เพื่อรักษาความปลอดภัยในการช้อปปิ้งออนไลน์ในเบราว์เซอร์ Netscape Navigator ใหม่ล่าสุด SSL 1.0 ไม่เคยถูกเผยแพร่ต่อสาธารณะเนื่องจากมีข้อบกพร่องร้ายแรง SSL 2.0 ที่จัดส่งในเดือนกุมภาพันธ์ พ.ศ. 2538 ใช้งานไม่ได้ในทันที และ SSL 3.0 ตามมาในปี พ.ศ. 2539 โดยเป็นการเขียนใหม่เกือบทั้งหมด

ในปี พ.ศ. 2542 IETF ได้เข้าควบคุมโปรโตคอลและเปลี่ยนชื่อเป็น Transport Layer Security เพื่อทำเครื่องหมายการเปลี่ยนจากผลิตภัณฑ์ Netscape ไปเป็นมาตรฐานแบบเปิด ประวัติเวอร์ชันตั้งแต่:

• TLS 1.0 (มกราคม 1999, RFC 2246) — เป็นหลัก SSL 3.1.
• TLS 1.1 (เมษายน 2549, RFC 4346) — ป้องกันการโจมตี CBC ผ่านการเริ่มต้นที่ชัดเจน vector.
• TLS 1.2 (สิงหาคม 2551, RFC 5246) — เพิ่มรหัส AEAD, SHA-256, อัลกอริธึมลายเซ็นที่กำหนดค่าได้ ครองอำนาจมานานนับทศวรรษ
• TLS 1.3 (สิงหาคม 2018, RFC 8446) — การออกแบบใหม่ครั้งใหญ่ ลบ Cruft แบบเดิมออก, การส่งต่อความลับที่ได้รับคำสั่ง, ลดเวลาแฝงของการจับมือกัน

SSL 3.0 เลิกใช้อย่างเป็นทางการในเดือนมิถุนายน 2558 (RFC 7568) หลังจาก POODLE TLS 1.0 และ 1.1 เลิกใช้งานในเดือนมีนาคม 2021 (RFC 8996) ในปี 2026 เซิร์ฟเวอร์สมัยใหม่ควรปฏิเสธสิ่งใดก็ตามที่ต่ำกว่า TLS 1.2 และชอบ TLS 1.3 มากกว่า

วิธีการจับมือทำงานจริง ๆ

การเชื่อมต่อ TLS ทุกอันเริ่มต้นด้วยการจับมือกันที่ทำสามสิ่ง: เห็นด้วยกับชุดการเข้ารหัส พิสูจน์ตัวตนของเซิร์ฟเวอร์ และรับคีย์ที่แชร์สำหรับส่วนที่เหลือของเซสชัน

TLS 1.2 การจับมือกัน (โฟลว์แบบคลาสสิก)

1. ClientHello: ไคลเอนต์ส่งเวอร์ชัน TLS ที่รองรับ ชุดการเข้ารหัส และตัวเลขสุ่ม
2. ServerHello: เซิร์ฟเวอร์เลือกชุดการเข้ารหัสหนึ่งชุด แล้วส่งแบบสุ่ม number.
3. Certificate: เซิร์ฟเวอร์ส่งสายใบรับรอง X.509 เพื่อให้ไคลเอ็นต์สามารถตรวจสอบตัวตนได้
4. ServerKeyExchange: เซิร์ฟเวอร์ส่งรหัสสาธารณะ Diffie-Hellman (สำหรับคีย์ชั่วคราว) exchange).
5. ClientKeyExchange: ไคลเอนต์ส่งรหัสสาธารณะ DH ตอนนี้ทั้งสองฝ่ายได้รับความลับที่ใช้ร่วมกันแบบเดียวกัน
6. Finished: ทั้งสองฝ่ายยืนยันการจับมือกันโดยการส่ง MAC ไปยังข้อความถอดเสียงทั้งหมด

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

TLS 1.3 handshake (โฟลว์สมัยใหม่)

TLS 1.3 ยุบการจับมือเป็นหนึ่งรอบโดยทั่วไป กรณี:

1. ClientHello: รวมคีย์สาธารณะ DH ของไคลเอ็นต์สำหรับกลุ่มการเข้ารหัสทุกกลุ่มที่ไคลเอ็นต์รองรับ
2. ServerHello + ทุกอย่างอื่น: เซิร์ฟเวอร์เลือกกลุ่ม ส่งคีย์สาธารณะ DH ใบรับรอง และเสร็จสิ้น ทั้งหมดในที่เดียว flight.
3. Client ตรวจสอบและตอบกลับด้วย Finished ของตัวเอง

ไปกลับหนึ่งเที่ยว สองเที่ยวบิน ด้วยการเริ่มเซสชันใหม่ (0-RTT) ลูกค้าสามารถเริ่มส่งข้อมูลด้วยข้อความแรกได้ โดยต้องเสียค่าใช้จ่ายในคุณสมบัติการส่งต่อความลับสำหรับข้อมูลเริ่มต้นนั้น

สิ่งที่ TLS 1.3 ถูกลบออก

TLS 1.3 การเคลื่อนไหวครั้งใหญ่อีกอย่างหนึ่งของการลบคือการลบ ออกไปแล้ว:

• Static RSA key exchange (ทำลายความลับไปข้างหน้า) รหัสโหมด
• CBC (เสี่ยงต่อ BEAST และ Lucky Thirteen) รหัสสตรีม
• RC4 (ใช้งานไม่ได้มานาน)
• MD5 และ SHA-1 hash สำหรับ ลายเซ็น
• การเจรจาต่อรองใหม่ (แทนที่ด้วยการรับรองความถูกต้องหลังการจับมือกัน)
• การบีบอัด (คลาสการโจมตีอาชญากรรม)
• พารามิเตอร์ Diffie-Hellman แบบกำหนดเอง (แก้ไข Logjam)

รายการชุดการเข้ารหัสเปลี่ยนจาก ~300 ใน TLS 1.2 เหลือ 5 ใน TLS 1.3 เชือกห้อยตัวน้อยลง

ประวัติการโจมตีที่หล่อหลอม TLS

• BEAST (2011) — การโจมตีข้อความธรรมดาที่เลือกไว้ในโหมด CBC ใน TLS 1.0 แก้ไขในเวอร์ชัน 1.1+ ผ่าน IVs.
• CRIME (2012) ที่ชัดเจน — ใช้การบีบอัด TLS เพื่อกู้คืนคุกกี้เซสชัน แก้ไขโดยการปิดการใช้งานการบีบอัด
• BREACH (2013) — การบีบอัดระดับ HTTP เทียบเท่ากับ CRIME บรรเทาลงโดยการปิดใช้งานการบีบอัด HTTP ในการตอบสนองที่ละเอียดอ่อน
• Heartbleed (เมษายน 2014) — จุดบกพร่องของ OpenSSL ไม่ใช่ปัญหาข้อมูลจำเพาะของ TLS หน่วยความจำเซิร์ฟเวอร์รั่วไหลรวมถึงคีย์ส่วนตัว เหตุการณ์การหมุนเวียนใบรับรองจำนวนมากทั่วทั้งเว็บ
• POODLE (ตุลาคม 2014) — ใช้ประโยชน์จาก SSL 3.0 ทางเลือก ทำลาย SSL 3.0 ในเบราว์เซอร์ภายในไม่กี่สัปดาห์
• Logjam (2015) — แสดงให้เห็นว่ากลุ่ม Diffie-Hellman กลุ่มเล็กๆ (โดยเฉพาะกลุ่ม 2 1024 บิตที่ใช้กันอย่างแพร่หลายใน IPsec/IKE) อยู่ไม่ไกลจากผู้โจมตีจากรัฐชาติ บังคับให้ย้ายทั่วทั้งอุตสาหกรรมไปยังกลุ่มที่ใหญ่ขึ้นและเส้นโค้งรูปไข่ DH.
• Lucky Thirteen (2013) — การโจมตีตามเวลาในโหมด CBC การแก้ไขระดับไลบรารีใน OpenSSL และอื่นๆ

การโจมตีแต่ละครั้งทำให้โปรโตคอลรัดกุมมากขึ้น ด้วย TLS 1.3 คลาสเหล่านี้ส่วนใหญ่เป็นไปไม่ได้โดยการออกแบบ

Certificate Authority และปัญหาความน่าเชื่อถือการตรวจสอบสิทธิ์

TLS ขึ้นอยู่กับ Certificate Authorities (CA) ที่เบราว์เซอร์เชื่อถือตามค่าเริ่มต้น สามอันดับแรกตามส่วนแบ่งตลาดตั้งแต่ปี 2019: IdenTrust, DigiCert และ Sectigo Let's Encrypt ซึ่งเป็น CA อัตโนมัติฟรีที่เปิดตัวในปี 2016 ผลักดันให้มีการใช้งาน HTTPS มากที่สุดในประวัติศาสตร์

จุดอ่อนทางโครงสร้าง: CA ที่เชื่อถือได้สามารถออกใบรับรองให้กับโดเมนใดก็ได้ CA ที่ถูกบุกรุกหรือถูกบังคับสามารถสร้างใบรับรองที่ถูกต้องให้กับธนาคารของคุณได้ บันทึก Certificate Transparency (CT) - บันทึกต่อท้ายสาธารณะเท่านั้นของใบรับรองทุกใบที่เคยออก - ถูกนำมาใช้เพื่อตรวจจับสิ่งนี้ ขณะนี้เบราว์เซอร์ต้องการให้ใบรับรองปรากฏในบันทึก CT ก่อนที่จะยอมรับ

CA/ฟอรัมเบราว์เซอร์อนุมัติให้ลดความถูกต้องของใบรับรองสูงสุดลงเหลือ 47 วันภายในปี 2029 ซึ่งจะทำให้หน้าต่างที่ CA ที่ถูกบุกรุกสามารถสร้างความเสียหายกระชับขึ้น

Encrypted Client Hello (ECH)

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

Encrypted Client Hello (ECH) — วิวัฒนาการของข้อเสนอ ESNI ก่อนหน้านี้ — เข้ารหัส SNI โดยใช้กุญแจสาธารณะที่ปลายทางเผยแพร่ผ่าน DNS Cloudflare และ Apple ได้จัดส่งการสนับสนุน ECH; Firefox และ Chrome เปิดตัวหลังแฟล็กจนถึงปี 2024 และกำลังมุ่งหน้าสู่ค่าเริ่มต้น สำหรับผู้ใช้บนเครือข่ายที่ไม่เป็นมิตร ECH คือการอัปเกรดความเป็นส่วนตัวครั้งต่อไปหลังจาก HTTPS สากล

DTLS — TLS สำหรับ UDP

DTLS (Datagram TLS) คือตัวแปร TLS ที่ทำงานบน UDP ขับเคลื่อน WebRTC (วิดีโอ/เสียงของเบราว์เซอร์) การรักษาความปลอดภัยพื้นฐานของ QUIC และโปรโตคอล VPN ต่างๆ DTLS 1.3 (RFC 9147, 2022) ตรงกับการจับมือกันและการปรับปรุงการเข้ารหัสของ TLS 1.3

Post-quantum TLS

Diffie-Hellman ซึ่งเป็นพื้นฐานของการส่งต่อความลับของ TLS สามารถทำลายได้โดยคอมพิวเตอร์ควอนตัมขนาดใหญ่เพียงพอ การแก้ไขคือการแลกเปลี่ยนคีย์แบบไฮบริดที่รวมอัลกอริธึมแบบคลาสสิก (X25519) กับตัวเลือกหลังควอนตัม (โดยทั่วไปคือ ML-KEM-768 ซึ่งเดิมเรียกว่า Kyber)

Chrome เปิดใช้งาน X25519MLKEM768 แบบไฮบริดตามค่าเริ่มต้นในปลายปี 2567 Cloudflare, Apple iCloud และผู้ให้บริการ VPN หลายรายจัดส่งจนถึงปี 2568 การเปิดตัวที่กว้างขึ้นช่วยปกป้องการรับส่งข้อมูลในปัจจุบันจาก การโจมตี "เก็บเกี่ยวตอนนี้ ถอดรหัสในภายหลัง" — ฝ่ายตรงข้ามบันทึกการรับส่งข้อมูลที่เข้ารหัสในปัจจุบัน รอคอมพิวเตอร์ควอนตัม จากนั้นถอดรหัสในอดีต

วิธีตรวจสอบ TLS ที่เบราว์เซอร์ของคุณใช้จริง

คลิกที่แม่กุญแจในแถบที่อยู่ของเบราว์เซอร์ของคุณ เบราว์เซอร์สมัยใหม่จะแสดงเวอร์ชันโปรโตคอล ชุดการเข้ารหัส และรายละเอียดใบรับรอง หากคุณเห็น TLS 1.0 หรือ 1.1 แสดงว่าไซต์กำลังใช้การกำหนดค่าที่เลิกใช้แล้ว หากคุณเห็น TLS 1.3 พร้อม AES-256-GCM หรือ ChaCha20-Poly1305 แสดงว่าคุณใช้ crypto สมัยใหม่

เทคโนโลยีสหาย HTTPS — ครอบคลุมอยู่ใน HTTPS Explainer ของเรา — คือสิ่งที่ล้อมรอบเว็บใน TLS คำทั้งสองนี้มักใช้สลับกันเรียกขานกัน แต่ TLS เป็นโปรโตคอลการเข้ารหัสที่สำคัญ HTTPS เป็นเพียง HTTP-over-TLS.