CLIENTSERVERClientHello + key shareServerHello + cert + FinishedFinished + first requestTLS 1.3: 1-RTT to first byte

การจับมือกันของ TLS

11 นาทีอ่านการเข้ารหัส

การเชื่อมต่อ HTTPS ทุกรายการเริ่มต้นด้วยการจับมือกัน: การแลกเปลี่ยนข้อความสั้นๆ โดยที่ไคลเอนต์และเซิร์ฟเวอร์เห็นด้วยกับอัลกอริธึมการเข้ารหัส ตรวจสอบตัวตน และรับคีย์การเข้ารหัสที่ใช้ร่วมกัน ทุกอย่างใช้เวลาไปกลับครั้งเดียวใน TLS 1.3 และเป็นรากฐานของการสื่อสารที่เข้ารหัสเกือบทั้งหมดบนเว็บ

เนื้อหาบทความฉบับเต็มมีให้เป็นภาษาอังกฤษด้านล่าง

TLS handshake คือการแลกเปลี่ยนโปรโตคอลที่สร้างการเชื่อมต่อที่เข้ารหัสและรับรองความถูกต้องระหว่างจุดปลายสองจุด โดยทำงานเมื่อเริ่มต้นทุกคำขอ HTTPS ทุกเซสชัน SMTP ที่ปลอดภัย ทุกการเข้าสู่ระบบ IMAP สมัยใหม่ ทุกการเชื่อมต่อ HTTP/2 และ HTTP/3 เวอร์ชันปัจจุบัน TLS 1.3 (RFC 8446, 2018) ง่ายกว่าและเร็วกว่า TLS 1.2 อย่างมาก

สิ่งที่การจับมือทำได้สำเร็จ

เมื่อสิ้นสุดการจับมือกัน ทั้งสองฝ่ายมี:

  • ยืนยันตัวตนของเซิร์ฟเวอร์ผ่านใบรับรอง
  • ตกลงกันใน เวอร์ชัน TLS และชุดการเข้ารหัส
  • Derived shared symmetric key for the session
  • ทางเลือกในการแลกเปลี่ยนการรับรองความถูกต้องสำหรับไคลเอ็นต์ (mTLS)
  • รายละเอียดเลเยอร์แอปพลิเคชันที่ส่งสัญญาณแบบเป็นทางเลือก (ALPN: เวอร์ชันของ HTTP เป็นต้น)

ข้อมูลที่ตามมาทั้งหมดจะใช้คีย์สมมาตร (โดยทั่วไปคือ AES-GCM หรือ ChaCha20-Poly1305) สำหรับการเข้ารหัสจำนวนมากอย่างรวดเร็ว

TLS 1.3 handshake ทีละขั้นตอน

การจับมือขั้นต่ำใน TLS 1.3 คือ 1 ไปกลับ:

  1. ClientHello. Client ส่ง:
    • รองรับเวอร์ชัน TLS
    • Cipher ชุดที่สามารถพูดได้
    • กลุ่มการแลกเปลี่ยนคีย์ที่รองรับ (X25519, secp256r1 ฯลฯ) การแชร์
    • Key — คีย์สาธารณะชั่วคราวสำหรับการแลกเปลี่ยนคีย์ นี่คือการเร่งความเร็ว TLS 1.3: ใน TLS 1.2 การแลกเปลี่ยนคีย์จะรอพารามิเตอร์ของเซิร์ฟเวอร์ TLS 1.3 เดาและส่งรหัสสาธารณะทันที
    • SNI (การระบุชื่อเซิร์ฟเวอร์) — ชื่อโฮสต์ที่ไคลเอนต์ต้องการพูดคุยด้วย ข้อความธรรมดาในอดีต Encrypted Client Hello (ECH) กำลังเปิดตัวเพื่อซ่อน
  2. ServerHello. เซิร์ฟเวอร์ส่ง:
    • Selected TLS version and cipher suite
    • its key share
    • จากข้อความนี้ ทุกสิ่งที่เซิร์ฟเวอร์ส่งคือ encrypted
    • its ห่วงโซ่ใบรับรอง (เข้ารหัสภายใต้คีย์จับมือ) ลายเซ็น
    • A พิสูจน์ว่ามันเก็บคีย์ส่วนตัวที่ตรงกับใบรับรอง
    • Finished ข้อความยืนยันว่าทั้งสองฝ่ายมีการถอดเสียงจับมือเดียวกัน
  3. Client ส่ง Finished รับทราบข้อความของเซิร์ฟเวอร์และสลับไปใช้คีย์แอปพลิเคชันที่ได้รับ
  4. Application data. คำขอ HTTP แรกไหล

Net ต้นทุน: 1 รอบก่อนไบต์แอปพลิเคชันแรก ด้วย 0-RTT (คุณลักษณะ TLS 1.3 ที่ใช้คีย์เซสชันที่แคชไว้จากการเชื่อมต่อก่อนหน้า) คำขอแรกสามารถดำเนินการใน ClientHello เองได้ — ไม่ต้องเดินทางไปกลับสำหรับเซสชันที่กลับมาทำงานต่อ

TLS 1.2 ช้ากว่าการจับมือของ

TLS 1.2 ใช้เวลา 2 วินาที ไป-กลับ:

  1. ClientHello (ยังไม่มีการแบ่งปันคีย์)
  2. ServerHello + ใบรับรอง + ServerKeyExchange + ServerHelloDone
  3. ClientKeyExchange + ChangeCipherSpec + Finished
  4. ChangeCipherSpec + เสร็จสิ้น
  5. ข้อมูลแอปพลิเคชัน

ค่าใช้จ่ายแบบไปกลับมีความสำคัญมากที่สุดบนเครือข่ายที่มีความหน่วงสูง การจับมือกันแบบ 1-RTT (หรือ 0-RTT) ของ TLS 1.3 เป็นหนึ่งในการปรับปรุงประสิทธิภาพเว็บที่ผู้ใช้รับรู้ได้มากขึ้นในทศวรรษที่ผ่านมา

อะไรที่ได้รับการเจรจา

สาขาหลัก:

  • TLS เวอร์ชัน 1.2 หรือ 1.3 ในทางปฏิบัติ SSL 3.0, TLS 1.0, 1.1 เลิกใช้แล้ว
  • Cipher suite. ระบุรหัสสมมาตร (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305), ฟังก์ชันแฮช (SHA-256, SHA-384) และ (ใน TLS 1.2) กลไกการแลกเปลี่ยนคีย์ TLS 1.3 แยกสิ่งเหล่านี้
  • Key-exchange group. X25519, secp256r1, secp384r1 ฯลฯ ECC เป็นค่าเริ่มต้น การแลกเปลี่ยนคีย์ RSA จะถูกลบออกใน 1.3.
  • Signature Algorithm. RSA-PSS, ECDSA, Ed25519 ลายเซ็นใบรับรองของเซิร์ฟเวอร์ใช้หนึ่งในนั้น
  • Extensions. SNI, ALPN, Early Data, รองรับ_รุ่น, key_share, padding และอื่นๆ อีกมากมาย

Forward secrecy

TLS 1.3 mandates การแลกเปลี่ยนคีย์ชั่วคราว — ทุกเซสชันจะได้รับคีย์จากคีย์ชั่วคราวใหม่ที่ถูกละทิ้งทันทีหลังจากนั้น หากคีย์ส่วนตัวระยะยาวของเซิร์ฟเวอร์รั่วไหลในวันพรุ่งนี้ การรับส่งข้อมูลที่บันทึกไว้ในวันนี้จะยังคงได้รับการปกป้อง (สมมติว่าการรั่วไหลนั้นไม่รวมคีย์ชั่วคราว ซึ่งโดยทั่วไปจะไม่คงอยู่)

TLS 1.2 ทำให้สิ่งนี้เป็นทางเลือกผ่านการเข้ารหัส DHE/ECDHE เซิร์ฟเวอร์จำนวนมากเปิดใช้งาน แต่บางเซิร์ฟเวอร์ไม่ได้เปิดใช้งาน TLS 1.3 ทำให้ไม่สามารถต่อรองได้

การตรวจสอบใบรับรอง

เซิร์ฟเวอร์พิสูจน์ตัวตนโดยการส่งห่วงโซ่ใบรับรอง ไคลเอ็นต์ตรวจสอบ:

  • ชื่อของใบรับรองลีฟตรงกับโฮสต์ที่เชื่อมต่อกับ
  • ใบรับรองอยู่ในวันที่
  • ใบรับรองแต่ละใบในห่วงโซ่ได้รับการลงนามโดยถัดไป
  • รากอยู่ในร้านค้าที่เชื่อถือได้ในพื้นที่
  • Certificate บันทึกความโปร่งใสรวมถึงใบรับรอง (เบราว์เซอร์สมัยใหม่)
  • ใบรับรองจะไม่ถูกเพิกถอน (CRL, OCSP หรือเทียบเท่าสมัยใหม่เช่น CRLite)

หากการตรวจสอบล้มเหลว เบราว์เซอร์จะแสดงคำเตือน ดูบทความ CA ของเรา สำหรับภาพที่กว้างขึ้น

0-RTT และโหมด 0-RTT ของ Risk

TLS 1.3 ช่วยให้ไคลเอ็นต์ที่กลับมาส่งข้อมูลแอปพลิเคชันในแพ็กเก็ตแรก โดยใช้คีย์ที่ได้รับจากเซสชันก่อนหน้า ข้อเสียเปรียบ: ผู้โจมตีที่จับข้อมูล 0-RTT สามารถเล่นซ้ำได้ในภายหลัง สำหรับการดำเนินการ idempotent (คำขอ GET สำหรับเนื้อหาที่แคชได้) ก็ถือว่าใช้ได้ สำหรับการดำเนินการที่ไม่ใช่ idempotent (POST ที่เปลี่ยนสถานะ) 0-RTT จะไม่ปลอดภัย เบราว์เซอร์และ CDN ส่วนใหญ่จัดการเรื่องนี้ด้วยความระมัดระวัง เซิร์ฟเวอร์สามารถปฏิเสธ 0-RTT สำหรับการดำเนินการเฉพาะ

คำถามที่พบบ่อย

จริงๆ แล้วการจับมือ TLS ใช้เวลานานเท่าใด
ในการเชื่อมต่อทั่วไป: TLS 1.3 จะเพิ่มประมาณ 100 ms (ไปกลับหนึ่งครั้ง) นอกเหนือจากการจับมือ TCP TLS 1.2 เพิ่มประมาณ 200 ms (ไปกลับสองครั้ง) 0-RTT เพิ่ม 0 ms เมื่อทำได้ คำขอครั้งต่อไปในการเชื่อมต่อเดียวกันจะไม่จับมือกันซ้ำ
เหตุใดบางครั้ง TLS จึงใช้ ChaCha20 แทน AES
ChaCha20-Poly1305 เร็วกว่า AES บนฮาร์ดแวร์ที่ไม่มีการเร่งความเร็ว AES-NI (CPU มือถือรุ่นเก่า, แกน ARM แบบธรรมดา, อุปกรณ์ IoT) เมื่อไคลเอนต์ส่งสัญญาณว่าไม่รองรับการเร่งความเร็ว AES อย่างมีประสิทธิภาพ เซิร์ฟเวอร์จะเลือกใช้ ChaCha20 ใน x86 สมัยใหม่และ ARM พร้อม AES-NI โดยปกติแล้ว AES จะเร็วกว่าเล็กน้อย
TLS ร่วมกัน (mTLS) คืออะไร
การจับมือ TLS มาตรฐานจะตรวจสอบสิทธิ์เฉพาะเซิร์ฟเวอร์เท่านั้น ใน mTLS ไคลเอนต์ยังแสดงใบรับรองด้วย และเซิร์ฟเวอร์จะตรวจสอบใบรับรองนั้น ใช้สำหรับการรักษาความปลอดภัย API การตรวจสอบสิทธิ์แบบบริการต่อบริการ สถาปัตยกรรม Zero Trust เพิ่มความซับซ้อนในการดำเนินงานแต่ให้ข้อมูลประจำตัวไคลเอ็นต์ที่เข้ารหัส
TLS เข้ารหัสชื่อโฮสต์ปลายทางหรือไม่
จนกระทั่งเมื่อไม่นานมานี้ — สนาม SNI เป็นแบบข้อความธรรมดา ซึ่งผู้สังเกตการณ์บนเส้นทางทุกคนมองเห็นได้ Encrypted Client Hello (ECH) ซ่อน SNI โดยการเข้ารหัส ClientHello ไปยังคีย์ที่เผยแพร่ใน DNS ECH รองรับ Chrome, Firefox และ Cloudflare การนำไปใช้ในวงกว้างกำลังเปิดตัวจนถึงปี 2025–2026
จะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ไม่รองรับ TLS 1.3
การจับมือกันกลับเป็น TLS 1.2 เบราว์เซอร์สมัยใหม่ปฏิเสธ TLS 1.0 และ 1.1 ทั้งหมดในปี 2020–2021 TLS 1.2 ยอมรับได้แต่ช้ากว่า แนะนำให้ใช้ 1.3 และตอนนี้เป็นการจับมือกันใหม่ส่วนใหญ่
อธิบาย TLS Handshake: จะเกิดอะไรขึ้นก่อนที่ HTTPS จะส่งข้อมูลใดๆ