131 lines
21 KiB
Typst
131 lines
21 KiB
Typst
#import "../PageTemplate.typ": *
|
|
#set list(marker: ([•], [○], [■]))
|
|
|
|
= เกณฑ์วิธีความมั่นคงของชั้นขนส่ง (Transport Layer Security; TLS)
|
|
|
|
#i
|
|
เกณฑ์วิธีความมั่นคงของชั้นขนส่ง (Transport Layer Security; TLS)
|
|
เป็นโปรโตคอลการเข้ารหัสที่ออกแบบมาเพื่อรักษาความปลอดภัยการสื่อสารบนเครือข่ายคอมพิวเตอร์เช่นอินเทอร์เน็ตโปรโตคอลนี้ถูกใช้อย่างแพร่หลายในแอปพลิเคชันต่างๆเช่นอีเมลการส่งข้อความโต้ตอบแบบทันทีและบริการเสียงผ่าน
|
|
IP แต่การใช้งานเพื่อรักษาความปลอดภัย HTTPS ยังคงเป็นที่เปิดเผยต่อสาธารณะมากที่สุด
|
|
|
|
#i โปรโตคอล TLS มีวัตถุประสงค์หลักเพื่อรักษาความปลอดภัย รวมถึงความเป็นส่วนตัว (ความลับ)
|
|
ความสมบูรณ์ และความถูกต้อง ผ่านการใช้การเข้ารหัสเช่น
|
|
การใช้ใบรับรองระหว่างแอปพลิเคชันคอมพิวเตอร์ที่สื่อสารกันตั้งแต่สองแอปพลิเคชันขึ้นไป
|
|
โปรโตคอลนี้ทำงานในเลเยอร์การนำเสนอและประกอบด้วยสองชั้น ได้แก่ ระเบียน TLS และโปรโตคอล TLS
|
|
handshake
|
|
|
|
#i Datagram Transport Layer Security (DTLS)
|
|
ซึ่งเป็นโปรโตคอลการสื่อสารที่เกี่ยวข้องอย่างใกล้ชิดมอบความปลอดภัยให้กับ แอปพลิเคชันที่ใช้
|
|
ดาต้าแกรมในงานเขียนทางเทคนิค มักพบการอ้างอิงถึง "(D)TLS" เมื่อใช้กับทั้งสองเวอร์ชัน
|
|
|
|
#i TLS เป็นมาตรฐานที่ได้รับการเสนอโดย Internet Engineering Task Force (IETF)
|
|
ซึ่งกำหนดขึ้นครั้งแรกในปี 1999 และเวอร์ชันปัจจุบันคือ TLS 1.3 ซึ่งกำหนดขึ้นในเดือนสิงหาคม 2018 TLS
|
|
สร้างขึ้นจาก ข้อกำหนด SSL (Secure Sockets Layer) ที่ไม่รองรับอีกต่อไป (1994, 1995, 1996)
|
|
ซึ่งพัฒนาโดย Netscape Communications เพื่อเพิ่มโปรโตคอล HTTPS ลงในเว็บเบราว์เซอร์ Netscape
|
|
Navigator
|
|
|
|
== คำอธิบาย
|
|
#iii
|
|
เนื่องจากแอปพลิเคชันสามารถสื่อสารได้ทั้งแบบมีหรือไม่มี TLS (หรือ SSL)
|
|
จึงจำเป็นที่ไคลเอนต์จะต้องร้องขอให้เซิร์ฟเวอร์ตั้งค่าการเชื่อมต่อ TLS
|
|
หนึ่งในวิธีหลักในการทำเช่นนี้คือการใช้หมายเลขพอร์ต อื่น สำหรับการเชื่อมต่อ TLS โดยทั่วไปแล้ว พอร์ต 80
|
|
จะใช้สำหรับ การรับส่งข้อมูล HTTP ที่ไม่ได้เข้ารหัส ในขณะที่พอร์ต 443 เป็นพอร์ตทั่วไปที่ใช้สำหรับ
|
|
การรับส่งข้อมูล HTTPS ที่เข้ารหัส อีกกลไกหนึ่งคือการสร้างคำขอ STARTTLS
|
|
เฉพาะโปรโตคอลไปยังเซิร์ฟเวอร์เพื่อสลับการเชื่อมต่อกับ TLS ตัวอย่างเช่น
|
|
เมื่อใช้โปรโตคอลอีเมลและข่าวสารบางอย่าง
|
|
|
|
#iii เมื่อไคลเอนต์และเซิร์ฟเวอร์ตกลงที่จะใช้ TLS แล้ว พวกเขาจะเจรจา การเชื่อมต่อ
|
|
แบบมีสถานะโดยใช้ขั้นตอนการจับมือ (ดูการจับมือ TLS)
|
|
โปรโตคอลใช้การจับมือกับรหัสแบบอสมมาตรเพื่อกำหนดค่าการเข้ารหัสไม่เพียงเท่านั้น
|
|
แต่ยังรวมถึงคีย์ที่ใช้ร่วมกันเฉพาะเซสชัน
|
|
ซึ่งการสื่อสารต่อไปจะถูกเข้ารหัสโดยใช้รหัสแบบสมมาตรในระหว่างการจับมือนี้
|
|
ไคลเอนต์และเซิร์ฟเวอร์จะตกลงกันเกี่ยวกับพารามิเตอร์ต่างๆ ที่ใช้สร้างความปลอดภัยของการเชื่อมต่อ:
|
|
|
|
- การจับมือเริ่มต้นเมื่อไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ที่เปิดใช้งาน TLS
|
|
เพื่อขอการเชื่อมต่อที่ปลอดภัยและไคลเอนต์แสดงรายการชุดรหัสที่รองรับ (รหัสและฟังก์ชันแฮช)
|
|
- จากรายการนี้ เซิร์ฟเวอร์จะเลือกฟังก์ชันรหัสและแฮชที่รองรับ และแจ้งให้ไคลเอนต์ทราบถึงการตัดสินใจ
|
|
- โดยปกติแล้วเซิร์ฟเวอร์จะระบุตัวตนในรูปแบบของใบรับรองดิจิทัลใบรับรองประกอบด้วยชื่อเซิร์ฟเวอร์ผู้ให้บริการออกใบรับรอง
|
|
(CA) ที่เชื่อถือได้ซึ่งรับรองความถูกต้องของใบรับรอง และคีย์การเข้ารหัสสาธารณะของเซิร์ฟเวอร์
|
|
- ลูกค้าต้องยืนยันความถูกต้องของใบรับรองก่อนดำเนินการต่อ
|
|
- ในการสร้างคีย์เซสชันที่ใช้สำหรับการเชื่อมต่อที่ปลอดภัย ไคลเอนต์จะต้องทำดังนี้:
|
|
- เข้ารหัสตัวเลขสุ่ม (PreMasterSecret)
|
|
ด้วยคีย์สาธารณะของเซิร์ฟเวอร์และส่งผลลัพธ์ไปยังเซิร์ฟเวอร์
|
|
(ซึ่งเฉพาะเซิร์ฟเวอร์เท่านั้นที่จะสามารถถอดรหัสด้วยคีย์ส่วนตัว)
|
|
จากนั้นทั้งสองฝ่ายใช้ตัวเลขสุ่มเพื่อสร้างคีย์เซสชันเฉพาะสำหรับการเข้ารหัสและถอดรหัสข้อมูลในระหว่างเซสชันในภายหลังหรือ
|
|
- ใช้การแลกเปลี่ยนคีย์ Diffie--Hellman (หรือรูปแบบ DH ที่เป็นเส้นโค้งวงรี)
|
|
เพื่อสร้างคีย์เซสชันแบบสุ่มและไม่ซ้ำกันอย่างปลอดภัยสำหรับการเข้ารหัสและถอดรหัส
|
|
ซึ่งมีคุณสมบัติเพิ่มเติมของการปกปิดแบบส่งต่อ : หากคีย์ส่วนตัวของเซิร์ฟเวอร์ถูกเปิดเผยในอนาคต
|
|
จะไม่สามารถใช้คีย์นั้นเพื่อถอดรหัสเซสชันปัจจุบันได้
|
|
แม้ว่าเซสชันนั้นจะถูกดักจับและบันทึกโดยบุคคลที่สามก็ตาม
|
|
|
|
#iii
|
|
การดำเนินการนี้จะสิ้นสุดการจับมือและเริ่มการเชื่อมต่อที่ปลอดภัยซึ่งจะถูกเข้ารหัสและถอดรหัสด้วยคีย์เซสชันจนกว่าการเชื่อมต่อจะสิ้นสุดลงหากขั้นตอนใดขั้นตอนหนึ่งข้างต้นล้มเหลวการจับมือ
|
|
TLS จะล้มเหลวและการเชื่อมต่อจะไม่ถูกสร้างขึ้น
|
|
|
|
#iii TLS และ SSL ไม่สามารถจัดวางได้อย่างลงตัวในเลเยอร์ใดเลเยอร์หนึ่งของแบบจำลอง OSI
|
|
หรือแบบจำลอง TCP/IP TLS ทำงาน "บนโปรโตคอลการขนส่งที่เชื่อถือได้ (เช่น TCP)"
|
|
ซึ่งหมายความว่ามันอยู่เหนือเลเยอร์การขนส่งมันทำหน้าที่เข้ารหัสให้กับเลเยอร์ที่สูงกว่า
|
|
ซึ่งโดยปกติแล้วเป็นหน้าที่ของเลเยอร์การนำเสนออย่างไรก็ตาม โดยทั่วไปแอปพลิเคชันจะใช้ TLS
|
|
เหมือนกับเป็นเลเยอร์การขนส่งแม้ว่าแอปพลิเคชันที่ใช้ TLS จะต้องควบคุมการเริ่มต้นการจับมือ TLS
|
|
และการจัดการใบรับรองการตรวจสอบสิทธิ์ที่แลกเปลี่ยนกัน
|
|
|
|
#iii เมื่อได้รับการรักษาความปลอดภัยโดย TLS การเชื่อมต่อระหว่างไคลเอนต์ (เช่น เว็บเบราว์เซอร์)
|
|
และเซิร์ฟเวอร์ (เช่น wikipedia.org) จะมีคุณสมบัติทั้งหมดดังต่อไปนี้
|
|
|
|
- การเชื่อมต่อเป็นแบบส่วนตัว (หรือมีความลับ) เนื่องจาก มีการใช้
|
|
อัลกอริทึมคีย์แบบสมมาตรในการเข้ารหัสข้อมูลที่ส่ง
|
|
คีย์สำหรับการเข้ารหัสแบบสมมาตรนี้จะถูกสร้างขึ้นอย่างเฉพาะเจาะจงสำหรับแต่ละการเชื่อมต่อ
|
|
และอิงจากความลับร่วมที่เจรจากันไว้เมื่อเริ่มต้นเซสชัน
|
|
เซิร์ฟเวอร์และไคลเอ็นต์จะเจรจารายละเอียดเกี่ยวกับอัลกอริทึมการเข้ารหัสและคีย์การเข้ารหัสที่จะใช้ก่อนที่จะส่งข้อมูลไบต์แรก
|
|
(ดูด้านล่าง) การเจรจาความลับร่วมนั้นทั้งปลอดภัย
|
|
(ความลับที่เจรจากันไว้จะไม่สามารถเข้าถึงได้โดยผู้ดักฟังและไม่สามารถได้รับ
|
|
แม้แต่โดยผู้โจมตีที่วางตัวเองอยู่ตรงกลางการเชื่อมต่อ) และเชื่อถือได้
|
|
(ไม่มีผู้โจมตีคนใดสามารถแก้ไขการสื่อสารระหว่างการเจรจาโดยไม่ถูกตรวจพบ)
|
|
- การยืนยันตัวตนของฝ่ายที่สื่อสารสามารถยืนยันได้โดยใช้การเข้ารหัสด้วยคีย์สาธารณะการยืนยันตัวตนนี้จำเป็นสำหรับเซิร์ฟเวอร์และเป็นทางเลือกสำหรับไคลเอนต์
|
|
- การเชื่อมต่อมีความน่าเชื่อถือ (หรือมีความสมบูรณ์)
|
|
เนื่องจากข้อความแต่ละข้อความที่ส่งออกจะมีการตรวจสอบความสมบูรณ์ของข้อความโดยใช้รหัสยืนยันข้อความเพื่อป้องกันการสูญหายหรือการเปลี่ยนแปลงข้อมูลที่ไม่ถูกตรวจพบระหว่างการส่งข้อมูล
|
|
|
|
#iii TLS รองรับวิธีการที่หลากหลายสำหรับการแลกเปลี่ยนคีย์ การเข้ารหัสข้อมูล
|
|
และการตรวจสอบความถูกต้องของข้อความ ดังนั้น การกำหนดค่า TLS
|
|
อย่างปลอดภัยจึงเกี่ยวข้องกับพารามิเตอร์ที่กำหนดค่าได้มากมาย
|
|
และตัวเลือกทั้งหมดไม่ได้มีคุณสมบัติที่เกี่ยวข้องกับความเป็นส่วนตัวทั้งหมดที่อธิบายไว้ในรายการด้านบน
|
|
(ดูตารางด้านล่าง การแลกเปลี่ยนคีย์ ความปลอดภัยของการเข้ารหัสและความสมบูรณ์ของข้อมูล)
|
|
|
|
#iii มีการพยายามบ่อนทำลายแง่มุมด้านความปลอดภัยในการสื่อสารที่ TLS มุ่งหวังจะมอบให้
|
|
และโปรโตคอลนี้ได้รับการแก้ไขหลายครั้งเพื่อจัดการกับภัยคุกคามด้านความปลอดภัยเหล่านี้
|
|
นักพัฒนาเว็บเบราว์เซอร์ได้ปรับปรุงผลิตภัณฑ์ของตนซ้ำแล้วซ้ำเล่าเพื่อป้องกันจุดอ่อนด้านความปลอดภัยที่อาจเกิดขึ้นหลังจากค้นพบจุดอ่อนเหล่านี้
|
|
(ดูประวัติการสนับสนุน TLS/SSL ของเว็บเบราว์เซอร์) ความปลอดภัยของเลเยอร์การขนส่งดาต้าแกรม
|
|
|
|
#iii Datagram Transport Layer Security หรือเรียกย่อๆ ว่า DTLS เป็นโปรโตคอลการสื่อสาร
|
|
ที่เกี่ยวข้องซึ่งให้ความปลอดภัยแก่ แอปพลิเคชันที่ใช้ Datagram
|
|
โดยอนุญาตให้แอปพลิเคชันสื่อสารในลักษณะที่ออกแบบมาเพื่อป้องกันการดักฟัง
|
|
การปลอมแปลงหรือการปลอมแปลงข้อความโปรโตคอล DTLS ใช้ โปรโตคอล Transport Layer
|
|
Security (TLS) ที่เน้น การสตรีมและมีจุดประสงค์เพื่อให้การรับประกันความปลอดภัยที่คล้ายคลึงกัน
|
|
อย่างไรก็ตาม โปรโตคอลนี้แตกต่างจาก TLS ตรงที่สามารถใช้งานร่วมกับโปรโตคอลที่เน้น Datagram
|
|
ส่วนใหญ่ ได้แก่ User Datagram Protocol (UDP), Datagram Congestion Control Protocol
|
|
(DCCP), Control And Provisioning of Wireless Access Points (CAPWAP), Stream
|
|
Control Transmission Protocol (SCTP) encapsulation และ Secure Real-time
|
|
Transport Protocol (SRTP)
|
|
|
|
#iii เนื่องจากเดตาแกรมของโปรโตคอล DTLS รักษาความหมายของการขนส่งพื้นฐานไว้
|
|
แอปพลิเคชันจึงไม่ประสบปัญหาความล่าช้าที่เกี่ยวข้องกับโปรโตคอลสตรีม อย่างไรก็ตาม
|
|
แอปพลิเคชันต้องจัดการกับการเรียงลำดับแพ็กเก็ตใหม่ การสูญหายของเดตาแกรม
|
|
และข้อมูลที่มีขนาดใหญ่กว่าขนาดของแพ็กเก็ตเครือข่าย เดตาแกรม เนื่องจาก DTLS ใช้ UDP หรือ SCTP
|
|
แทน TCP จึงหลีกเลี่ยงปัญหา TCP ล่มเมื่อนำไปใช้สร้างอุโมงค์ VPN
|
|
|
|
#iii DTLS เวอร์ชัน 1.0 ฉบับดั้งเดิมในปี 2006 ไม่ใช่เอกสารแบบสแตนด์อโลน
|
|
แต่ได้รับการกำหนดให้เป็นชุดเดลต้าของ TLS 1.1 ทำนองเดียวกัน DTLS เวอร์ชัน 2012
|
|
ที่ตามมาก็ถูกกำหนดให้เป็นเดลต้าของ TLS 1.2 โดยได้รับหมายเลขเวอร์ชันของ DTLS 1.2
|
|
เพื่อให้ตรงกับเวอร์ชัน TLS สุดท้าย DTLS 1.3 ปี 2022 ก็ถูกกำหนดให้เป็นเดลต้าของ TLS 1.3
|
|
เช่นเดียวกับสองเวอร์ชันก่อนหน้า DTLS 1.3 มีวัตถุประสงค์เพื่อให้ "การรับประกันความปลอดภัยที่เทียบเท่า
|
|
[กับ TLS 1.3] ยกเว้นการป้องกันคำสั่ง/การไม่สามารถเล่นซ้ำได้"
|
|
|
|
#iii ไคลเอนต์ VPN จำนวนมากรวมถึง Cisco AnyConnect & InterCloud Fabric,
|
|
OpenConnect, อุโมงค์ ZScaler, F5 Networks Edge VPN Client และ Citrix Systems
|
|
NetScaler ใช้ DTLS เพื่อรักษาความปลอดภัยการรับส่งข้อมูล UDP นอกจากนี้
|
|
เว็บเบราว์เซอร์สมัยใหม่ทั้งหมดยังรองรับ DTLS-SRTP สำหรับ WebRTC
|
|
|
|
#include "X509.typ"
|
|
#include "x690.typ"
|
|
#include "OpenSSL.typ"
|