Ssl tls ยอมรับใบรับรองทั้งหมด ตรวจสอบให้แน่ใจว่าเปิดใช้งาน ssl และ tls แล้ว

โปรโตคอลเครือข่าย SSL และ TLS เป็นโปรโตคอลการเข้ารหัสที่ให้การรับรองความถูกต้องและการป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต การละเมิดความสมบูรณ์ของข้อมูลที่ส่ง โปรโตคอล SSL/TLS ได้รับการออกแบบมาเพื่อป้องกันการปลอมแปลงข้อมูลประจำตัวฝั่งไคลเอ็นต์หรือเซิร์ฟเวอร์ การเปิดเผยข้อมูลหรือการบิดเบือนข้อมูล เพื่อจุดประสงค์เหล่านี้ จะใช้วิธีการพิสูจน์ตัวตนที่เชื่อถือได้ การเข้ารหัสช่องทางการสื่อสาร และรหัสความสมบูรณ์ของข้อความ พอร์ตเริ่มต้นสำหรับ SSL/TLS คือพอร์ต 443 สำหรับ HTTPS, 465 สำหรับ SMTPS (อีเมล), 636 สำหรับ LDAPS, 563 สำหรับ NNTPS, 994 สำหรับ IRCS (แชท), 995 สำหรับ POP3S

โปรโตคอล SSL

โปรโตคอล SSL ได้รับการพัฒนาโดย Netscape เพื่อรักษาความปลอดภัยข้อมูลระหว่างบริการและโปรโตคอลการขนส่ง เวอร์ชันเผยแพร่ครั้งแรกเปิดตัวในปี 1995 ใช้กันอย่างแพร่หลายสำหรับแอปพลิเคชัน VoIP บริการส่งข้อความโต้ตอบแบบทันที SSL เป็นช่องทางที่ปลอดภัยซึ่งมีคุณสมบัติดังต่อไปนี้:

• ช่องส่วนตัว. ข้อความทั้งหมดจะถูกเข้ารหัสหลังจากบทสนทนาที่จำเป็นในการกำหนดคีย์การเข้ารหัส
• ช่องได้รับการรับรองความถูกต้อง การรับรองความถูกต้องเป็นทางเลือกสำหรับฝั่งไคลเอนต์ แต่จำเป็นสำหรับฝั่งเซิร์ฟเวอร์
• ความน่าเชื่อถือของช่อง เมื่อมีการส่งข้อความ การตรวจสอบความสมบูรณ์จะดำเนินการโดยใช้ MAC

โปรโตคอล SSL ใช้ทั้งคีย์สมมาตรและอสมมาตร

คุณสมบัติและวัตถุประสงค์ของโปรโตคอล SSL

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

โครงสร้างแบบเลเยอร์จะแสดงด้วยเลเยอร์โปรโตคอลการยืนยันการเชื่อมต่อและเลเยอร์โปรโตคอลการบันทึก เลเยอร์แรกคือโปรโตคอลการขนส่งเช่น TCP - ร่วมกับ SSL Record Protocol เลเยอร์เหล่านี้สร้างแกนหลักของ SSL ซึ่งต่อมามีส่วนร่วมในการก่อตัวของโครงสร้างพื้นฐานที่ซับซ้อน

ในคุณสมบัติหลักของโปรโตคอล SSL ควรสังเกตความเป็นอิสระของซอฟต์แวร์และแพลตฟอร์ม ปัจจุบัน โปรโตคอล SSL ไม่มีการป้องกันที่เพียงพอ - มันถูกแทนที่ด้วยโปรโตคอล TLS

โปรโตคอล TLS

โปรโตคอล TLS เป็นโปรโตคอลการเข้ารหัสที่ใช้เพื่อถ่ายโอนข้อมูลอย่างปลอดภัยระหว่างโหนดต่างๆ บนอินเทอร์เน็ต โปรโตคอลนี้พบแอปพลิเคชันในแอปพลิเคชัน VoIP, เว็บเบราว์เซอร์, แอปพลิเคชันการส่งข้อความโต้ตอบแบบทันที TLS ถูกนำมาใช้กับข้อกำหนด SSL 3.0 IETF มีส่วนร่วมในการคิดค้นและพัฒนาโปรโตคอล

มาตรการรักษาความปลอดภัยหลักที่มีให้โดยโปรโตคอล TLS ได้แก่:

• การใช้คีย์เพื่อตรวจสอบรหัสยืนยันตัวตนของข้อความ
• ขจัดความเป็นไปได้ในการดาวน์เกรด TLS หรือแทนที่ด้วยโปรโตคอลเครือข่ายที่ปลอดภัยน้อยกว่า
• ข้อความจับมือประกอบด้วยแฮชของข้อความทั้งหมดที่แลกเปลี่ยนระหว่างทั้งสองฝ่าย
• การใช้การบันทึกหมายเลขแอปพลิเคชันโดยใช้ MAC
• การใช้ฟังก์ชันสุ่มหลอกที่แยกข้อความเข้าออกเป็น 2 ส่วน ซึ่งแต่ละส่วนจะถูกประมวลผลด้วยฟังก์ชันแฮชที่แตกต่างกัน

คุณลักษณะและวัตถุประสงค์ของโปรโตคอล TLS

โปรโตคอล TLS ใช้อัลกอริทึมต่อไปนี้:

• RC4, Triple DES, SEED, IDEA เป็นต้น สำหรับการเข้ารหัสแบบสมมาตร
• RSA, DSA, Diffie-Hellman และ ECDSA สำหรับการตรวจสอบคีย์
• MD5, SHA และ SHA-256/384 สำหรับฟังก์ชันแฮช

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

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

การจับมือ TLS คืออะไรและทำงานอย่างไร

TLS เป็นหนึ่งในเครื่องมือรักษาความปลอดภัยที่ใช้บ่อยที่สุดบนอินเทอร์เน็ต โปรโตคอลทำงานอย่างแข็งขันกับกระบวนการเครือข่ายมากมาย: การถ่ายโอนไฟล์ การเชื่อมต่อ VPN (ในการใช้งานบางอย่างสำหรับการแลกเปลี่ยนคีย์) บริการส่งข้อความโต้ตอบแบบทันที หรือโทรศัพท์ IP

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

"การจับมือ SSL/TLS" คือชื่อของขั้นตอนการตั้งค่าการเชื่อมต่อ HTTPS งานส่วนใหญ่ที่เกี่ยวข้องกับโปรโตคอล SSL/TLS เสร็จสิ้นในขั้นตอนนี้ ปีที่แล้ว IETF ได้สรุป TLS 1.3 ด้วยการยกเครื่องกระบวนการจับมือใหม่ทั้งหมด
บทความนี้จะกล่าวถึงการจับมือกันสองประเภท - สำหรับโปรโตคอล TLS 1.2 และ TLS 1.3 ซึ่งเราจะพิจารณาโดยเริ่มจากระดับนามธรรมและค่อยๆ เจาะลึกคุณลักษณะต่างๆ:

• การประสานงานของโปรโตคอลการเข้ารหัส
• การรับรองความถูกต้องด้วยใบรับรอง SSL
• การสร้างคีย์เซสชัน

การจับมือ TLS ทำงานอย่างไร

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

การเจรจา Cipherset

แต่ละ ซอฟต์แวร์มีเอกลักษณ์. ดังนั้นแม้แต่เว็บเบราว์เซอร์ที่ได้รับความนิยมสูงสุดก็มีฟังก์ชันการทำงานที่แตกต่างกัน ในทำนองเดียวกันทางฝั่งเซิร์ฟเวอร์ - วินโดวส์เซิร์ฟเวอร์, Apache และ NGINX ก็แตกต่างกันเช่นกัน สิ่งต่าง ๆ จะซับซ้อนยิ่งขึ้นเมื่อคุณเพิ่มการกำหนดค่าแบบกำหนดเอง

นั่นคือเหตุผลที่ขั้นตอนแรกของ TLS handshake คือการแลกเปลี่ยนข้อมูลเกี่ยวกับความสามารถระหว่างไคลเอนต์และเซิร์ฟเวอร์สำหรับการเลือกฟังก์ชันการเข้ารหัสที่รองรับเพิ่มเติม

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

การรับรองความถูกต้อง

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

ใบรับรอง SSL ที่เชื่อถือได้ทั้งหมดออกโดย Certificate Authority (CA) CA ต้องปฏิบัติตามกฎที่เข้มงวดในการออกและตรวจสอบใบรับรองเพื่อให้เชื่อถือได้ คุณอาจคิดว่า CA เป็นเหมือนทนายความสาธารณะ ลายเซ็นของเขาหมายความว่าข้อมูลในใบรับรองนั้นเป็นของจริง

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

ในขั้นตอนนี้ ไคลเอนต์จะตรวจสอบทางอ้อมว่าเซิร์ฟเวอร์เป็นเจ้าของคีย์ส่วนตัวที่เกี่ยวข้องกับใบรับรองหรือไม่

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

หากใช้ระบบเข้ารหัสอื่น อัลกอริทึมอาจเปลี่ยนแปลง แต่การรับรองความถูกต้องของอีกฝ่ายจะยังคงอยู่

การแลกเปลี่ยนคีย์

ส่วนสุดท้ายของ TLS handshake เกี่ยวข้องกับการสร้าง "คีย์เซสชัน" ซึ่งจะใช้สำหรับการสื่อสารที่ปลอดภัย

คีย์เซสชันเป็นแบบ "สมมาตร" หมายความว่าคีย์เดียวกันใช้สำหรับทั้งการเข้ารหัสและถอดรหัส

การเข้ารหัสแบบสมมาตรเร็วกว่าการเข้ารหัสแบบไม่สมมาตร ทำให้เหมาะสำหรับการส่งข้อมูลผ่านการเชื่อมต่อ HTTPS วิธีการสร้างคีย์ที่แน่นอนนั้นขึ้นอยู่กับชุดการเข้ารหัสที่เลือก ซึ่งสองวิธีที่พบมากที่สุดคือ RSA และ Diffie-Hellman

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

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

จนถึง TLS 1.3 ทุกครั้งที่คุณเยี่ยมชมเว็บไซต์ การจับมือกันจะเกิดขึ้นอีกครั้ง Handshake TLS 1.3 รองรับ 0-RTT หรือเวลาดำเนินการต่อแบบไป-กลับเป็นศูนย์ ซึ่งช่วยเพิ่มความเร็วได้อย่างมากสำหรับผู้มาเยือนที่กลับมา

กระบวนการจับมือทีละขั้นตอนใน TLS 1.2

มาดูการจับมือ TLS โดยใช้ RSA ให้ละเอียดยิ่งขึ้น การใช้อัลกอริธึม Diffie-Hellman จะอธิบายไว้ด้านล่าง

1. ข้อความแรกเรียกว่า "ลูกค้าสวัสดี" ข้อความนี้แสดงรายการตัวเลือกของไคลเอ็นต์เพื่อให้เซิร์ฟเวอร์สามารถเลือกชุดการเข้ารหัสที่จะใช้สำหรับการสื่อสาร ข้อความนี้ยังมีหมายเลขเฉพาะขนาดใหญ่ที่สุ่มเลือก ซึ่งเรียกว่า "หมายเลขสุ่มของลูกค้า"
2. เซิร์ฟเวอร์ตอบกลับอย่างสุภาพด้วยข้อความ "สวัสดีเซิร์ฟเวอร์" ที่นั่นจะบอกลูกค้าว่าเลือกตัวเลือกการเชื่อมต่อใดและส่งคืนหมายเลขเฉพาะที่สุ่มเลือก ซึ่งเรียกว่า "หมายเลขสุ่มของเซิร์ฟเวอร์" หากไคลเอ็นต์และเซิร์ฟเวอร์ไม่ใช้ชุดการเข้ารหัสร่วมกัน การเชื่อมต่อจะล้มเหลว
3. ในข้อความ "ใบรับรอง" เซิร์ฟเวอร์จะส่งเชนใบรับรอง SSL ไปยังไคลเอนต์ ซึ่งรวมถึงใบรับรองระดับลีฟและระดับกลาง หลังจากได้รับแล้ว ลูกค้าจะทำการตรวจสอบหลายรายการเพื่อยืนยันใบรับรอง ลูกค้าต้องแน่ใจว่าเซิร์ฟเวอร์มี รหัสส่วนตัวใบรับรองซึ่งเกิดขึ้นระหว่างกระบวนการแลกเปลี่ยน/สร้างคีย์
4. ข้อความนี้เป็นข้อความเผื่อเลือก จำเป็นสำหรับวิธีการแลกเปลี่ยนคีย์บางอย่างเท่านั้น (เช่น Diffie-Hellman) ที่ต้องการข้อมูลเพิ่มเติมจากเซิร์ฟเวอร์
5. ข้อความ "สวัสดีเซิร์ฟเวอร์เสร็จสิ้น" แจ้งไคลเอ็นต์ว่าเซิร์ฟเวอร์ส่งข้อมูลเสร็จแล้ว
6. จากนั้นไคลเอ็นต์จะเข้าร่วมในการสร้างคีย์เซสชัน ความเฉพาะเจาะจงของขั้นตอนนี้ขึ้นอยู่กับวิธีการแลกเปลี่ยนคีย์ที่เลือกไว้ในข้อความ "สวัสดี" ดั้งเดิม เนื่องจากเรากำลังดูที่ RSA ไคลเอนต์จะสร้างสตริงสุ่มของไบต์ที่เรียกว่าความลับของพรีมาสเตอร์ เข้ารหัสด้วยคีย์สาธารณะของเซิร์ฟเวอร์ และส่งกลับ
7. ข้อความ "Change Cipher Spec" แจ้งให้อีกฝ่ายทราบว่ามีการสร้างคีย์เซสชันและสามารถสลับไปใช้การเชื่อมต่อที่เข้ารหัสได้
8. จากนั้นข้อความ "เสร็จสิ้น" จะถูกส่งไป เพื่อระบุว่าการจับมือเสร็จสิ้นในฝั่งไคลเอ็นต์ ตั้งแต่นั้นเป็นต้นมา การเชื่อมต่อจะได้รับการปกป้องโดยคีย์เซสชัน ข้อความประกอบด้วยข้อมูล (MAC) ที่สามารถใช้ในการตรวจสอบว่าการจับมือไม่ได้ถูกแก้ไข
9. ขณะนี้เซิร์ฟเวอร์ถอดรหัสลับพรีมาสเตอร์และคำนวณเซสชันคีย์ จากนั้นจะส่งข้อความ "Change Cipher Spec" เพื่อแจ้งว่ากำลังเปลี่ยนไปใช้การเชื่อมต่อที่เข้ารหัส
10. เซิร์ฟเวอร์ยังส่งข้อความ "เสร็จสิ้น" โดยใช้คีย์เซสชันสมมาตรที่สร้างขึ้นใหม่ และตรวจสอบผลรวมการตรวจสอบเพื่อยืนยันความสมบูรณ์ของการจับมือทั้งหมด

หลังจากขั้นตอนเหล่านี้ การจับมือ SSL จะเสร็จสมบูรณ์ ขณะนี้ทั้งสองฝ่ายมีคีย์เซสชันและสามารถสื่อสารผ่านการเชื่อมต่อที่เข้ารหัสและรับรองความถูกต้องได้

ณ จุดนี้ ไบต์แรกของเว็บแอปพลิเคชัน (ข้อมูลที่เกี่ยวข้องกับบริการจริง - HTML, Javascript ฯลฯ) สามารถส่งได้

กระบวนการจับมือทีละขั้นตอนใน TLS 1.3

การจับมือ TLS 1.3 นั้นสั้นกว่ารุ่นก่อนอย่างมาก

1. เช่นเดียวกับ TLS 1.2 ข้อความ "สวัสดีลูกค้า" จะเรียกการจับมือ แต่คราวนี้มีข้อมูลมากขึ้น TLS 1.3 ได้ลดจำนวนการเข้ารหัสที่รองรับจาก 37 เหลือ 5 ซึ่งหมายความว่าไคลเอนต์สามารถเดาได้ว่าจะใช้ข้อตกลงคีย์ใดหรือโปรโตคอลการแลกเปลี่ยน ดังนั้นควรส่งส่วนหนึ่งของคีย์สาธารณะจากโปรโตคอลที่ต้องการนอกเหนือจากข้อความ
2. เซิร์ฟเวอร์จะตอบกลับด้วยข้อความ "สวัสดีเซิร์ฟเวอร์" เช่นเดียวกับการจับมือกัน 1.2 ใบรับรองจะถูกส่งไปที่จุดนี้ หากไคลเอ็นต์เดาโปรโตคอลการเข้ารหัสด้วยข้อมูลที่แนบมาได้ถูกต้องและเซิร์ฟเวอร์ตกลงตามนั้น ไคลเอ็นต์จะส่งส่วนหนึ่งของคีย์สาธารณะ คำนวณคีย์เซสชัน และดำเนินการส่งให้เสร็จสมบูรณ์ด้วยข้อความ "เซิร์ฟเวอร์เสร็จสิ้น"
3. เมื่อไคลเอ็นต์มีข้อมูลทั้งหมดที่ต้องการแล้ว ก็จะตรวจสอบใบรับรอง SSL และใช้คีย์สาธารณะสองคีย์เพื่อคำนวณสำเนาของคีย์เซสชัน เมื่อเสร็จแล้ว จะส่งข้อความ "ไคลเอ็นต์เสร็จสิ้น"

การจับมือกันของ TLS เหนือศีรษะ

ในอดีต หนึ่งในข้อร้องเรียนเกี่ยวกับ SSL/TLS คือการโอเวอร์โหลดเซิร์ฟเวอร์โดยมีค่าใช้จ่ายเพิ่มเติม สิ่งนี้มีส่วนทำให้ความคิดที่ว่า HTTPS นั้นช้ากว่า HTTP

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

บนเว็บไซต์ขนาดเล็ก สิ่งนี้อาจจะไม่ทำให้สิ่งต่าง ๆ ช้าลงอย่างเห็นได้ชัด แต่สำหรับ ระบบองค์กรซึ่งมีผู้เข้าชมหลายแสนคนทุกวัน นี่อาจเป็นปัญหาใหญ่ แต่ละ รุ่นใหม่การจับมือทำให้กระบวนการง่ายขึ้นมาก: TLS 1.2 มีสองขั้นตอน ในขณะที่ TLS 1.3 ใช้งานได้เพียงขั้นตอนเดียวและรองรับ 0-RTT

TLS 1.3 ปรับปรุงการจับมือผ่าน TLS 1.2

ในคำอธิบายข้างต้น การจับมือแบ่งออกเป็นสิบขั้นตอนแยกกัน ในความเป็นจริง หลายสิ่งเหล่านี้เกิดขึ้นพร้อมๆ กัน ดังนั้นจึงมักถูกจัดกลุ่มเข้าด้วยกันและเรียกว่าเฟส

การจับมือ TLS 1.2 มีสองขั้นตอน บางครั้งอาจต้องเพิ่มเติม แต่เมื่อพูดถึงปริมาณ ค่าเริ่มต้นคือสถานการณ์ที่ดีที่สุด

ซึ่งแตกต่างจาก 1.2 ตรง TLS 1.3 handshake พอดีกับหนึ่งเฟส แม้ว่ามันจะแม่นยำกว่าหากพูดครึ่งเดียว แต่ก็ยังเร็วกว่า TLS 1.2 มาก

การลดรหัสลับ

ไม่มีใครจะใช้ชุดการเข้ารหัสข้อมูล 37 ชุด นั่นเป็นวิธีที่โปรโตคอลพัฒนาขึ้น ทุกครั้งที่มีการเพิ่มอัลกอริทึมใหม่ ชุดค่าผสมใหม่จะถูกเพิ่มเข้ามา และในไม่ช้า IANA ก็จัดการชุดการเข้ารหัสที่แตกต่างกัน 37 ชุด

สิ่งนี้ไม่ดีด้วยเหตุผลสองประการ:

1. ความแปรปรวนนี้นำไปสู่การกำหนดค่าที่ผิดพลาดซึ่งทำให้ผู้ใช้อินเทอร์เน็ตเสี่ยงต่อการถูกโจมตีที่รู้จัก
2. สิ่งนี้ทำให้การตั้งค่า SSL สับสนมากขึ้น

IETF ยกเลิกการสนับสนุนอัลกอริธึมทั้งหมดยกเว้นอัลกอริธึมที่ปลอดภัยที่สุดใน TLS 1.3 ขจัดความสับสนด้วยการจำกัดตัวเลือก โดยเฉพาะอย่างยิ่ง ทางเลือกของวิธีการแลกเปลี่ยนคีย์ได้ถูกลบออกไปแล้ว รูปแบบชั่วคราวของ Diffie-Hellman กลายเป็นวิธีเดียวที่ลูกค้าจะส่งข้อมูลสำคัญพร้อมกับ "สวัสดีลูกค้า" ในส่วนแรกของการจับมือกัน การเข้ารหัส RSA ถูกลบออกทั้งหมดพร้อมกับแผนการแลกเปลี่ยนคีย์แบบคงที่อื่นๆ ทั้งหมด

ดังที่ได้กล่าวไปแล้ว มีจุดอ่อนหนึ่งจุดที่เป็นไปได้ใน TLS 1.3

เวลาส่งสัญญาณซ้ำเป็นศูนย์ - 0-RTT

0-RTT คือสิ่งที่โลกเทคโนโลยีทั้งโลกตั้งเป้าไว้ และนี่คือ TLS 1.3 ดังที่ได้กล่าวไปแล้ว การจับมือกันของ TLS มักจะช้า ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องเร่งความเร็วให้เร็วขึ้น 0-RTT ทำสิ่งนี้โดยการจัดเก็บข้อมูลลับบางอย่างเกี่ยวกับไคลเอ็นต์ โดยปกติจะเป็น ID เซสชันหรือตั๋วเซสชัน เพื่อใช้ในการเชื่อมต่อครั้งต่อไป

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

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

ความปลอดภัย

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

ในการจับมือ TLS 1.2 ขั้นตอนการเจรจาไม่ปลอดภัย แทนที่จะใช้ฟังก์ชัน MAC แบบธรรมดาเพื่อป้องกันไม่ให้ใครก็ตามรบกวนการส่งสัญญาณ ขั้นตอนการเจรจาประกอบด้วยข้อความ "Client Hello" และ "Server Hello"

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

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

ตอนนี้เรามาดูกันว่าการอัปเดต TLS 1.3 handshake เหล่านี้จะถูกนำไปใช้อย่างไรในฟีเจอร์หลักทั้งสามของ SSL/TLS handshake เอง

ชุดการเข้ารหัส TLS handshake

ชุดการเข้ารหัสคือชุดของอัลกอริทึมที่กำหนดพารามิเตอร์ของการเชื่อมต่อที่ปลอดภัย

ที่จุดเริ่มต้นของการเชื่อมต่อใดๆ การโต้ตอบแรก "ลูกค้าสวัสดี" คือรายการของชุดรหัสที่สนับสนุน เซิร์ฟเวอร์เลือกตัวเลือกที่ดีที่สุดและปลอดภัยที่สุดที่สนับสนุนและตรงตามข้อกำหนด คุณสามารถดูชุดรหัสและค้นหาการจับมือและพารามิเตอร์การเชื่อมต่อทั้งหมด

ชุดการเข้ารหัส TLS 1.2

• TLS เป็นโปรโตคอล
• ECDHE เป็นอัลกอริธึมการแลกเปลี่ยนคีย์
• ECDSA เป็นอัลกอริทึมการตรวจสอบสิทธิ์
• AES 128 GCM เป็นอัลกอริธึมการเข้ารหัสแบบสมมาตร
• SHA256 เป็นอัลกอริทึมการแฮช

ตัวอย่างข้างต้นใช้ระบบ Diffie-Hellman (DH) เส้นโค้งวงรีชั่วคราวสำหรับการแลกเปลี่ยนคีย์และอัลกอริทึมลายเซ็นดิจิทัลเส้นโค้งวงรีสำหรับการตรวจสอบสิทธิ์ DH ยังสามารถเชื่อมต่อกับ RSA (ทำหน้าที่เป็นอัลกอริทึมลายเซ็นดิจิทัล) เพื่อดำเนินการตรวจสอบความถูกต้อง

นี่คือรายการของชุดการเข้ารหัส TLS 1.2 ที่ได้รับการสนับสนุนอย่างกว้างขวางที่สุด:

ชุดการเข้ารหัส TLS 1.3

• TLS เป็นโปรโตคอล
• AES 256 GCM - การเข้ารหัสที่รับรองความถูกต้องด้วยข้อมูลที่แนบมา (AEAD)
• SHA384 เป็นอัลกอริทึมฟังก์ชันการสร้างคีย์แฮช (HKFD)

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

จากตัวอย่างข้างต้น คุณจะเห็นว่า AES (Advanced Encryption Standard) ใช้ในการเข้ารหัสข้อมูลจำนวนมาก มันทำงานในโหมดตัวนับ Galois โดยใช้คีย์ 256 บิต

ต่อไปนี้คือชุดรหัสห้าชุดที่รองรับใน TLS 1.3:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256

มีอะไรเปลี่ยนแปลงใน TLS 1.3 เมื่อเทียบกับ TLS 1.2

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

Handshake TLS 1.3 ยังปรับปรุงกระบวนการบางอย่าง เช่น การรับรองความถูกต้องของข้อความและลายเซ็นดิจิทัล

สุดท้าย นอกเหนือจากการเลิกใช้อัลกอริธึมการสร้างหรือแลกเปลี่ยนคีย์แบบเก่าแล้ว TLS 1.3 ยังกำจัดการเข้ารหัสแบบสมมาตรแบบเก่าอีกด้วย TLS 1.3 กำจัดบล็อกรหัสโดยสิ้นเชิง การเข้ารหัสแบบสมมาตรประเภทเดียวที่อนุญาตใน TLS 1.3 เรียกว่า Auxiliary Authenticated Encryption (AEAD) รวมการเข้ารหัสและการตรวจสอบข้อความ (MAC) ไว้ในฟังก์ชันเดียว

การรับรองความถูกต้องในการจับมือ TLS

ในอดีตการแลกเปลี่ยนหลักสองรายการคือ RSA และ Diffie-Hellman (DH) ปัจจุบัน DH มักเกี่ยวข้องกับเส้นโค้งวงรี (ECDH) แม้จะมีความคล้ายคลึงกันพื้นฐานอยู่บ้าง แต่ก็มีความแตกต่างพื้นฐานระหว่างแนวทางการแลกเปลี่ยนหลักทั้งสอง

กล่าวอีกนัยหนึ่ง การจับมือ RSA TLS แตกต่างจากการจับมือแบบ ECDH TLS

RSA ใช้การแยกตัวประกอบอย่างง่ายและเลขคณิตแบบแยกส่วน จำนวนเฉพาะจำนวนมากต้องใช้พลัง CPU จำนวนมากในการคำนวณและยากที่จะรับ

Diffie-Hellman บางครั้งเรียกว่า exponential key exchange ซึ่งบ่งชี้ถึงการยกกำลัง (นอกเหนือจาก modular arithmetic) แต่ DH เองไม่ได้เข้ารหัสหรือถอดรหัสอะไรเลย ดังนั้นการเรียกมันว่า "วิธีการเข้ารหัส" แทนที่จะเป็น "เหตุผลทางคณิตศาสตร์" อาจทำให้เข้าใจผิดเล็กน้อย

การพูดนอกเรื่องสั้น ๆ ในประวัติศาสตร์อาจชี้แจงประเด็นนี้

ในช่วงต้นปี 1976 Whitfield Diffie และ Martin Hellman ได้สร้างโปรโตคอลการแลกเปลี่ยนคีย์ตามผลงานของ Ralph Merkle ซึ่งชื่อตามทั้งสองควรจะปรากฏในชื่อของโปรโตคอลด้วย

พวกเขาพยายามแก้ปัญหาการแลกเปลี่ยนคีย์ที่ปลอดภัยผ่านช่องทางที่ไม่ปลอดภัย แม้ว่าผู้โจมตีจะแอบฟังอยู่ก็ตาม พวกเขาทำสำเร็จ แต่มีข้อเสียอย่างหนึ่ง: การแลกเปลี่ยนคีย์ DH ไม่รวมการรับรองความถูกต้อง ดังนั้นจึงเป็นไปไม่ได้ที่จะตรวจสอบฝ่ายที่ปลายอีกด้านของการเชื่อมต่อ

นี่ถือเป็นจุดกำเนิดของการเข้ารหัสคีย์สาธารณะและ PKI ไม่นานหลังจากที่ Diffie และ Hellman เปิดตัวโปรโตคอลการแลกเปลี่ยนคีย์ ระบบการเข้ารหัส RSA เวอร์ชันแรกสุดก็เสร็จสมบูรณ์ Diffie และ Hellman ได้สร้างแนวคิดของการเข้ารหัสคีย์สาธารณะ แต่ยังไม่ได้คิดฟังก์ชันที่แท้จริงของการเข้ารหัสแบบทางเดียว

Ron Rivest (R ใน RSA) เป็นผู้สร้างแนวคิดที่กลายมาเป็นระบบเข้ารหัส RSA ในที่สุด

ในหลาย ๆ ทาง RSA เป็นผู้สืบทอดทางจิตวิญญาณของ DH มันดำเนินการ:

• การสร้างคีย์
• การแลกเปลี่ยนคีย์
• การเข้ารหัส;
• ถอดรหัส

ดังนั้น RSA จึงเป็นอัลกอริทึมที่ทำงานได้มากกว่าที่สามารถจัดการทั้งการแลกเปลี่ยนคีย์และลายเซ็นดิจิทัล กล่าวคือ ทำการตรวจสอบความถูกต้องนอกเหนือจากการแลกเปลี่ยนคีย์ที่ปลอดภัย ดังนั้น RSA จึงมีคีย์ที่ใหญ่กว่า: ต้องมีการรักษาความปลอดภัยเพียงพอสำหรับลายเซ็นดิจิทัล

ในขณะที่ RSA จัดการการรับรองความถูกต้องและการแลกเปลี่ยนคีย์ Diffie-Hellman จะอำนวยความสะดวกในการแลกเปลี่ยนคีย์เท่านั้น มีสี่สายพันธุ์ทั่วไปของตระกูล DH:

• Diffie-Hellman (DH);
• ชั่วคราว (ระยะสั้น) Diffie-Hellman (DHE);
• เส้นโค้งวงรี Diffie-Hellman (ECDH);
• เส้นโค้งวงรีชั่วคราว Diffie-Hellman (ECDHE)

อีกครั้ง Diffie-Hellman ไม่ได้รับรองความถูกต้องอะไรเลย ต้องใช้ร่วมกับอัลกอริธึมลายเซ็นดิจิทัล ตัวอย่างเช่น หากคุณใช้ ECDH หรือ ECDHE ชุดการเข้ารหัสส่วนใหญ่จะจับคู่กับ Elliptic Curve Digital Signature Algorithm (ECDSA) หรือ RSA

การรับรองความถูกต้องของแฮนด์เชค TLS 1.2

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

ในทางกลับกัน หาก Diffie-Hellman ไม่รับรองความถูกต้อง จะทำอย่างไร ดังที่กล่าวไว้ข้างต้น DH มักจะใช้ร่วมกับการเข้ารหัสแบบโค้งวงรีเพื่อให้การรับรองความถูกต้องและการแลกเปลี่ยนคีย์

Elliptic cryptography (ECC) มีขนาดคีย์ที่เล็กกว่ามากซึ่งพอดีกับเส้นโค้งวงรีที่ใช้อ้างอิง มีห้าเส้นโค้งที่เหมาะสมสำหรับบริบทนี้:

• 192 บิต;
• 224 บิต;
• 256 บิต;
• 384 บิต;
• 521 บิต

แต่นั่นไม่ใช่ความแตกต่างเพียงอย่างเดียวระหว่างคีย์ ECC สาธารณะ/ส่วนตัว และคีย์ RSA พวกเขาใช้เพื่อวัตถุประสงค์ที่แตกต่างกันสองประการระหว่างการจับมือ TLS

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

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

การรับรองความถูกต้อง RSA

กระบวนการรับรองความถูกต้อง RSA เชื่อมโยงกับกระบวนการแลกเปลี่ยนคีย์ โดยเฉพาะอย่างยิ่งการแลกเปลี่ยนคีย์เป็นส่วนหนึ่งของกระบวนการตรวจสอบสิทธิ์

เมื่อไคลเอ็นต์ได้รับใบรับรอง SSL ของเซิร์ฟเวอร์ ไคลเอ็นต์จะตรวจสอบเมตริกต่างๆ ดังนี้

• ลายเซ็นดิจิทัลโดยใช้รหัสสาธารณะ
• สายใบรับรองเพื่อให้แน่ใจว่าใบรับรองมาจากหนึ่งในใบรับรองหลักในที่เก็บที่เชื่อถือได้
• วันหมดอายุเพื่อให้แน่ใจว่ายังไม่หมดอายุ
• สถานะการเพิกถอนใบรับรอง

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

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

การรับรองความถูกต้อง DH

เมื่อใช้ Diffie-Hellman และ ECDSA/RSA การพิสูจน์ตัวตนและการแลกเปลี่ยนคีย์จะถูกปรับใช้ควบคู่กันไป และนั่นนำเรากลับไปที่กุญแจและการใช้งาน คีย์สาธารณะ/ส่วนตัว RSA ใช้สำหรับทั้งการแลกเปลี่ยนคีย์และการรับรองความถูกต้อง ใน DH + ECDSA/RSA คู่คีย์แบบอสมมาตรจะใช้สำหรับลายเซ็นดิจิทัลหรือขั้นตอนการพิสูจน์ตัวตนเท่านั้น

เมื่อไคลเอนต์ได้รับใบรับรอง ไคลเอ็นต์ยังคงดำเนินการตรวจสอบมาตรฐาน:

• ตรวจสอบลายเซ็นบนใบรับรอง
• ห่วงโซ่ของใบรับรอง
• ความถูกต้อง
• สถานะข้อเสนอแนะ

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

การรับรองความถูกต้องของแฮนด์เชค TLS 1.3

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

• RSA (ลายเซ็นเท่านั้น)
• อัลกอริทึมลายเซ็นดิจิตอล Elliptic Curve (ECDSA)
• อัลกอริทึมลายเซ็นดิจิทัลของ Edwards (EdDSA)

ไม่เหมือนกับ Handshake TLS 1.2 ส่วนการรับรองความถูกต้องของ Handshake TLS 1.3 ไม่เกี่ยวข้องกับการแลกเปลี่ยนคีย์ แต่จะประมวลผลควบคู่ไปกับการแลกเปลี่ยนคีย์และการรับรองความถูกต้องของข้อความ

แทนที่จะเรียกใช้ MAC แบบสมมาตรเพื่อตรวจสอบความสมบูรณ์ของการจับมือกัน เซิร์ฟเวอร์จะลงนามแฮชการถอดรหัสทั้งหมดเมื่อส่งคืน "เซิร์ฟเวอร์สวัสดี" พร้อมกับรหัสสาธารณะส่วนหนึ่ง

ไคลเอ็นต์ได้รับข้อมูลทั้งหมดที่ส่งพร้อมกับ "Server Hello" และดำเนินการตรวจสอบชุดใบรับรอง SSL/TLS มาตรฐาน ซึ่งเกี่ยวข้องกับการตรวจสอบลายเซ็นบนใบรับรอง จากนั้นตรวจสอบว่าลายเซ็นที่เพิ่มไปยังแฮชการถอดรหัสนั้นตรงกันหรือไม่

การจับคู่ยืนยันว่าเซิร์ฟเวอร์เป็นเจ้าของคีย์ส่วนตัว

การแลกเปลี่ยนคีย์ในการจับมือ TLS

หากคุณเน้นแนวคิดหลักของส่วนนี้จะมีลักษณะดังนี้:

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

หากตอนนี้ฟังดูเป็นนามธรรมเล็กน้อย ในตอนท้ายของส่วนนี้ ทุกอย่างควรจะชัดเจน

การแลกเปลี่ยนคีย์ RSA

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

นี่คือวิธีการ:

1. xและ ย
2. ลูกค้าสร้าง ความลับก่อนมาสเตอร์(a) จากนั้นใช้รหัสสาธารณะของเซิร์ฟเวอร์เพื่อเข้ารหัสและส่งไปยังเซิร์ฟเวอร์
3. เซิร์ฟเวอร์ถอดรหัส ความลับก่อนมาสเตอร์ด้วยคีย์ส่วนตัวที่เกี่ยวข้อง ตอนนี้ทั้งสองฝ่ายมีตัวแปรอินพุตทั้งสามตัวและผสมเข้ากับฟังก์ชันสุ่มหลอก (PRF) เพื่อสร้างคีย์หลัก
4. ทั้งสองฝ่ายผสมมาสเตอร์คีย์กับ PRF มากขึ้นและลงเอยด้วยคีย์เซสชันที่ตรงกัน

การแลกเปลี่ยนคีย์ DH

นี่คือวิธีการทำงานของ ECDH:

1. ไคลเอนต์และเซิร์ฟเวอร์แลกเปลี่ยนหมายเลขเฉพาะสองตัว ( xและ ย) ซึ่งเรียกว่าตัวเลขสุ่ม
2. ฝ่ายหนึ่งเลือกหมายเลขลับที่โทรออก ความลับก่อนมาสเตอร์(a) และคำนวณ: x a mod y. จากนั้นส่งผลลัพธ์ (A) ไปยังผู้เข้าร่วมรายอื่น
3. อีกฝ่ายก็ทำเช่นเดียวกัน คือเลือกเอง ความลับก่อนมาสเตอร์(b) และคำนวณ x b สมัย yแล้วส่งค่ากลับ (B)
4. ทั้งสองฝ่ายจบส่วนนี้ด้วยการยอมรับค่าที่กำหนดและดำเนินการซ้ำ หนึ่งคำนวณ b a mod yคอมพิวเตอร์อื่นๆ a b mod y.

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

การจับมือ TLS 1.2 สำหรับ DH

ตอนนี้เราได้เห็นแล้วว่า DH แตกต่างจาก RSA อย่างไร มาดูกันว่าการจับมือกันแบบ TLS 1.2 ที่ใช้ DH นั้นเป็นอย่างไร

อีกครั้ง มีความคล้ายคลึงกันมากระหว่างสองวิธี เราจะใช้ ECDHE สำหรับการแลกเปลี่ยนคีย์และ ECDSA สำหรับการรับรองความถูกต้อง

1. เช่นเดียวกับ RSA ไคลเอนต์จะเริ่มต้นด้วยข้อความ "สวัสดีไคลเอ็นต์" ซึ่งรวมถึงรายการของชุดการเข้ารหัส เช่นเดียวกับหมายเลขสุ่มไคลเอ็นต์
2. เซิร์ฟเวอร์ตอบกลับด้วยข้อความ "เซิร์ฟเวอร์สวัสดี" ซึ่งรวมถึงชุดการเข้ารหัสที่เลือกและหมายเลขสุ่มของเซิร์ฟเวอร์
3. เซิร์ฟเวอร์ส่งใบรับรอง SSL เช่นเดียวกับการจับมือ RSA TLS ไคลเอนต์จะทำการตรวจสอบการรับรองความถูกต้องของใบรับรองหลายชุด แต่เนื่องจาก DH เองไม่สามารถตรวจสอบความถูกต้องของเซิร์ฟเวอร์ได้ จึงจำเป็นต้องมีกลไกเพิ่มเติม
4. ในการรับรองความถูกต้อง เซิร์ฟเวอร์จะใช้หมายเลขสุ่มของไคลเอนต์และเซิร์ฟเวอร์ รวมถึงพารามิเตอร์ DH ที่จะใช้ในการคำนวณคีย์เซสชัน และเข้ารหัสด้วยคีย์ส่วนตัว ผลลัพธ์จะทำหน้าที่เป็นลายเซ็นดิจิทัล: ไคลเอ็นต์ใช้คีย์สาธารณะเพื่อตรวจสอบลายเซ็นและเซิร์ฟเวอร์เป็นเจ้าของคู่คีย์โดยชอบธรรม และจะตอบกลับด้วยตัวเลือก DH ของตนเอง
5. เซิร์ฟเวอร์สิ้นสุดขั้นตอนนี้ด้วยข้อความ "สวัสดีเซิร์ฟเวอร์เสร็จสิ้น"
6. ซึ่งแตกต่างจาก RSA ตรงที่ไคลเอนต์ไม่จำเป็นต้องส่งความลับของพรีมาสเตอร์ไปยังเซิร์ฟเวอร์โดยใช้การเข้ารหัสแบบอสมมาตร แต่ไคลเอนต์และเซิร์ฟเวอร์ใช้พารามิเตอร์ DH ที่แลกเปลี่ยนก่อนหน้านี้เพื่อรับความลับของพรีมาสเตอร์ จากนั้นทุกคนจะใช้ข้อมูลลับพรีมาสเตอร์ที่เพิ่งคำนวณเพื่อให้ได้คีย์เซสชันเดียวกัน
7. ไคลเอ็นต์ส่งข้อความ "Change Cipher Spec" เพื่อแจ้งให้อีกฝ่ายทราบว่าได้เปลี่ยนไปใช้การเข้ารหัส
8. ลูกค้าส่งข้อความสุดท้าย "เสร็จสิ้น" เพื่อระบุว่าได้เสร็จสิ้นส่วนหนึ่งของการจับมือแล้ว
9. เซิร์ฟเวอร์ส่งข้อความ "Change Cipher Spec" ในทำนองเดียวกัน
10. การจับมือจบลงด้วยข้อความ "เสร็จสิ้น" จากเซิร์ฟเวอร์

ข้อดีของ DHE เหนือ RSA

มีเหตุผลหลักสองประการที่ทำให้ชุมชนการเข้ารหัสลับชอบใช้ DHE มากกว่า RSA: ความลับในการส่งต่อที่สมบูรณ์แบบและช่องโหว่ที่รู้จัก

ส่งต่อความลับที่สมบูรณ์แบบ

ก่อนหน้านี้ คุณอาจสงสัยว่าคำว่า "ชั่วคราว" ที่ต่อท้าย DHE และ ECDHE หมายความว่าอย่างไร Ephemeral แปลว่า "อายุสั้น" และช่วยให้เข้าใจ Perfect Forward Secrecy (PFS) ซึ่งเป็นคุณสมบัติของโปรโตคอลการแลกเปลี่ยนคีย์บางตัวได้ PFS รับรองว่าคีย์เซสชันที่แลกเปลี่ยนระหว่างฝ่ายต่างๆ จะไม่ถูกบุกรุก แม้ว่าคีย์ส่วนตัวของใบรับรองจะถูกบุกรุกก็ตาม กล่าวอีกนัยหนึ่งคือปกป้องเซสชันก่อนหน้าจากการถูกแยกและถอดรหัส PFS ได้รับความสำคัญสูงสุดหลังจากการค้นพบบั๊ก Heartbleed นี่คือองค์ประกอบหลักของ TLS 1.3

ช่องโหว่การแลกเปลี่ยนคีย์ RSA

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

นี่คือสาเหตุที่ RSA ถูกนำออกเนื่องจาก DHE ใน TLS 1.3

การแลกเปลี่ยนกุญแจในการจับมือ TLS 1.3

ในการจับมือ TLS 1.3 เนื่องจากตัวเลือกที่จำกัดของรูปแบบการแลกเปลี่ยนคีย์ ลูกค้าสามารถเดารูปแบบได้สำเร็จ และส่งส่วนหนึ่งของรหัสที่ใช้ร่วมกันในช่วงเริ่มต้น (สวัสดีลูกค้า) ของการจับมือกัน

RSA ไม่ใช่รูปแบบการแลกเปลี่ยนคีย์เดียวที่ถูกลบออกใน TLS 1.3 แผนการ Diffie-Hellman ที่ไม่ชั่วคราวก็ถูกกำจัดเช่นกัน เช่นเดียวกับรายการพารามิเตอร์ Diffie-Hellman ที่ปลอดภัยไม่เพียงพอ

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

1. เมื่อเริ่มต้น TLS 1.3 handshake เมื่อทราบว่าจะใช้รูปแบบข้อตกลงคีย์ DHE ลูกค้าจะรวมส่วนหนึ่งของคีย์สาธารณะตามรูปแบบการแลกเปลี่ยนคีย์ที่ตั้งใจไว้ในข้อความ Hello ของลูกค้า
2. เซิร์ฟเวอร์ได้รับข้อมูลนี้และหากไคลเอนต์ถูกต้อง จะส่งคืนรหัสสาธารณะบางส่วนใน "เซิร์ฟเวอร์สวัสดี"
3. ไคลเอ็นต์และเซิร์ฟเวอร์จะคำนวณเซสชันคีย์

สิ่งนี้คล้ายกับสิ่งที่เกิดขึ้นกับ DH ในการจับมือ TLS 1.2 ยกเว้นว่าการแลกเปลี่ยนคีย์เกิดขึ้นก่อนหน้าใน TLS 1.3

แทนที่จะเป็นข้อสรุป

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

อย่างน้อยก็จนกว่าจะมีบางอย่างผิดพลาด

ตามข้อกำหนดของกฎหมายรัสเซีย เฉพาะการใช้การเชื่อมต่อ TLS ที่จัดตั้งขึ้นโดยรัสเซีย อัลกอริทึมการเข้ารหัส GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 และ GOST R 34.10-2001 ดังนั้นหากคุณต้องการใช้ไซต์ที่ใช้การเข้ารหัสตามอัลกอริทึม GOST คุณต้องติดตั้งโปรแกรม " CryptoPro CSP» .

ในห้องผ่าตัด ระบบวินโดวส์ใช้โปรแกรม CryptoPro CSP - ชุดยูทิลิตี้การเข้ารหัสสำหรับการสร้าง ลายเซนต์อิเล็กทรอนิกส์, ทำงานกับใบรับรอง

ในการติดตั้ง CryptoPro CSP ให้ใช้วัสดุจากเว็บไซต์อย่างเป็นทางการ:

หลังจากติดตั้ง CryptoPro เบราว์เซอร์ CSPตรวจสอบการมีอยู่และการทำงานของโปรแกรมนี้

ไซต์ที่ร้องขอการเข้ารหัส GOST TLS

หากไซต์ร้องขอการเข้ารหัส GOST TLS เบราว์เซอร์จะตรวจสอบว่าติดตั้ง CryptoPro CSP หรือไม่ หากมีการติดตั้งโปรแกรม การควบคุมจะถูกถ่ายโอนไปยังโปรแกรมนั้น

ตัวอย่างของไซต์ที่ขอการเข้ารหัส: www.gosuslugi.ru , ไซต์บนโดเมน .gov.ru, .kamgov.ru , .nalog.ru

หากไซต์ไม่อยู่ในรายการ จะมีการร้องขอการยืนยันเพิ่มเติม หากคุณเชื่อถือไซต์และต้องทำการเชื่อมต่อโดยใช้การเข้ารหัส GOST TLS ให้คลิกปุ่มดำเนินการต่อ

เหตุผลทั้งหมดของเราขึ้นอยู่กับความจริงที่ว่าคุณใช้ Windows XP หรือใหม่กว่า (Vista, 7 หรือ 8) ซึ่งมีการติดตั้งการอัปเดตและแพตช์ที่เหมาะสมทั้งหมด ตอนนี้อีกหนึ่งเงื่อนไข: เรากำลังพูดถึงเบราว์เซอร์เวอร์ชันล่าสุดในปัจจุบัน ไม่ใช่ "Ognelis ทรงกลมในสุญญากาศ"

ดังนั้นเราจึงกำหนดค่าเบราว์เซอร์ให้ใช้โปรโตคอล TLS เวอร์ชันปัจจุบัน และไม่ใช้เวอร์ชันที่ล้าสมัยและ SSL เลย ไม่ว่าในกรณีใด ๆ เท่าที่เป็นไปได้ในทางทฤษฎี

และทฤษฎีบอกเราว่าแม้ว่า อินเทอร์เน็ต เอ็กซ์พลอเรอร์เนื่องจากเวอร์ชัน 8 รองรับ TLS 1.1 และ 1.2 ภายใต้ Windows XP และ Vista เราจะไม่บังคับให้ทำเช่นนั้น คลิก: เครื่องมือ / ตัวเลือกอินเทอร์เน็ต / ขั้นสูง และในส่วน "ความปลอดภัย" เราพบ: SSL 2.0, SSL 3.0, TLS 1.0 ... พบอะไรอีกบ้าง ขอแสดงความยินดี คุณจะมี TLS 1.1/1.2! ไม่พบ - คุณมี Windows XP หรือ Vista และใน Redmond ถือว่าคุณล้าหลัง

ดังนั้นเราจึงลบเครื่องหมายถูกออกจาก SSL ทั้งหมด เราวางไว้บน TLS ที่มีอยู่ทั้งหมด หากมีเฉพาะ TLS 1.0 เท่านั้น หากมีเวอร์ชันล่าสุดให้เลือกเฉพาะเวอร์ชันที่ดีกว่าและยกเลิกการเลือก TLS 1.0 (และไม่ต้องแปลกใจในภายหลังว่าบางไซต์ไม่เปิดผ่าน HTTPS) . จากนั้นคลิกปุ่ม "สมัคร", "ตกลง"

ด้วย Opera มันง่ายกว่า - มันจัดงานเลี้ยงจริงให้เราจาก รุ่นต่างๆโปรโตคอล: เครื่องมือ/การตั้งค่าทั่วไป/ขั้นสูง/ความปลอดภัย/โปรโตคอลความปลอดภัย เราเห็นอะไร? ทั้งชุดซึ่งเราออกจากช่องทำเครื่องหมายสำหรับ TLS 1.1 และ TLS 1.2 เท่านั้นหลังจากนั้นเราคลิกปุ่ม "รายละเอียด" และยกเลิกการทำเครื่องหมายทุกบรรทัดยกเว้นบรรทัดที่ขึ้นต้นด้วย "256 บิต AES" - พวกมันอยู่ที่ จบ. ที่จุดเริ่มต้นของรายการมีบรรทัด "256 บิต AES ( ไม่ระบุชื่อ DH/SHA-256) ให้ยกเลิกการเลือกด้วย คลิก "ตกลง" และเพลิดเพลินกับการรักษาความปลอดภัย

อย่างไรก็ตาม Opera มีคุณสมบัติที่แปลกอย่างหนึ่ง: หากเปิดใช้งาน TLS 1.0 หากจำเป็นต้องสร้างการเชื่อมต่อที่ปลอดภัย จะใช้โปรโตคอลเวอร์ชันเฉพาะนี้ทันที โดยไม่คำนึงว่าไซต์นั้นจะรองรับโปรโตคอลที่ใหม่กว่าหรือไม่ ชอบทำไมต้องเครียด - และทุกอย่างเรียบร้อยดีทุกอย่างได้รับการปกป้อง เมื่อคุณเปิดใช้งานเฉพาะ TLS 1.1 และ 1.2 อันดับแรกจะพยายามใช้เวอร์ชันขั้นสูงกว่า และหากไซต์ไม่รองรับ เบราว์เซอร์จะเปลี่ยนเป็นเวอร์ชัน 1.1

แต่ Ognelis Firefox ทรงกลมจะไม่ทำให้เราพอใจเลย: เครื่องมือ / การตั้งค่า / ขั้นสูง / การเข้ารหัส: สิ่งที่เราทำได้คือปิด SSL, TLS ใช้ได้เฉพาะในเวอร์ชัน 1.0 ไม่มีอะไรให้ทำ - เราปล่อยให้มีเครื่องหมายถูก

อย่างไรก็ตาม สิ่งที่ไม่ดีได้เรียนรู้เมื่อเปรียบเทียบ: Chrome และ Safari ไม่มีการตั้งค่าใดๆ เลย โปรโตคอลการเข้ารหัสที่จะใช้ เท่าที่เราทราบ Safari ไม่รองรับ TLS เวอร์ชันล่าสุดกว่า 1.0 ในเวอร์ชันภายใต้ Windows และเนื่องจากการเปิดตัวเวอร์ชันใหม่สำหรับระบบปฏิบัติการนี้ได้ถูกยุติลง จึงไม่รองรับ

เท่าที่เราทราบ Chrome รองรับ TLS 1.1 แต่ในกรณีของ Safari เราไม่สามารถปฏิเสธการใช้ SSL ได้ การปิดใช้งาน TLS 1.0 ใน Chrome ก็ไม่มีทางเช่นกัน แต่ด้วยการใช้งาน TLS 1.1 จริง - คำถามใหญ่: เปิดใช้งานครั้งแรกจากนั้นปิดเนื่องจากปัญหาในการทำงาน และเท่าที่ใครสามารถบอกได้ก็คือยังไม่ได้เปิดใช้งานอีกครั้ง นั่นคือดูเหมือนว่าการสนับสนุนจะอยู่ที่นั่น แต่ก็ปิดอยู่เหมือนเดิมและไม่มีทางที่จะเปิดใช้งานอีกครั้งกับผู้ใช้เอง เรื่องเดียวกันกับ Firefox - TLS 1.1 รองรับในความเป็นจริงคือ แต่ยังไม่พร้อมใช้งานสำหรับผู้ใช้

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

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

มิฉะนั้น จะไม่มีทางเลือก: เฉพาะ Opera และ TLS 1.2 เท่านั้น (TLS 1.1 เป็นเพียงการปรับปรุงของ TLS 1.0 โดยสืบทอดปัญหาด้านความปลอดภัยบางส่วน) อย่างไรก็ตาม เว็บไซต์โปรดของเราอาจไม่รองรับ TLS 1.2 :(

TLS เป็นตัวตายตัวแทนของ SSL ซึ่งเป็นโปรโตคอลที่ให้ความปลอดภัยและ การเชื่อมต่อที่ปลอดภัยระหว่างโหนดบนอินเทอร์เน็ต ใช้ในการพัฒนาไคลเอ็นต์ต่างๆ รวมถึงเบราว์เซอร์และแอปพลิเคชันไคลเอนต์-เซิร์ฟเวอร์ TLS ใน Internet Explorer คืออะไร

เล็กน้อยเกี่ยวกับเทคโนโลยี

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

โดยทั่วไปในองค์กรจะใช้เบราว์เซอร์ในตัว ในบางกรณี - มอซิลลา ไฟร์ฟอกซ์.

เปิดหรือปิดโปรโตคอล

บางครั้งเว็บไซต์บางแห่งไม่สามารถเข้าถึงได้เนื่องจากการรองรับเทคโนโลยี SSL และ TLS ถูกปิดใช้งาน การแจ้งเตือนปรากฏขึ้นในเบราว์เซอร์ คุณจะเปิดใช้งานโปรโตคอลเพื่อใช้การสื่อสารที่ปลอดภัยต่อไปได้อย่างไร
1. เปิดแผงควบคุมผ่าน Start อีกวิธีหนึ่ง: เปิด Explorer แล้วคลิกไอคอนรูปเฟืองที่มุมขวาบน

2. ไปที่ส่วน "ตัวเลือกอินเทอร์เน็ต" และเปิดบล็อก "ขั้นสูง"

3. ทำเครื่องหมายที่ช่องถัดจาก "ใช้ TLS 1.1 และ TLS 1.2"

4. คลิกตกลงเพื่อบันทึก การเปลี่ยนแปลง. หากคุณต้องการปิดใช้งานโปรโตคอล ซึ่งไม่สนับสนุนอย่างยิ่ง โดยเฉพาะอย่างยิ่งหากคุณใช้บริการธนาคารทางอินเทอร์เน็ต ให้ยกเลิกการเลือกรายการเดียวกัน

อะไรคือความแตกต่างระหว่าง 1.0 และ 1.1 และ 1.2? 1.1 เป็นเพียงเวอร์ชันปรับปรุงเล็กน้อยของ TLS 1.0 ซึ่งสืบทอดข้อบกพร่องบางส่วนมา 1.2 เป็นโปรโตคอลเวอร์ชันที่ปลอดภัยที่สุด ในทางกลับกัน ไม่ใช่ทุกไซต์ที่สามารถเปิดได้เมื่อเปิดใช้งานเวอร์ชันโปรโตคอลนี้

ดังที่คุณทราบ Skype messenger เกี่ยวข้องโดยตรงกับ Internet Explorer ในฐานะส่วนประกอบของ Windows หากคุณไม่ได้ตรวจสอบโปรโตคอล TLS ในการตั้งค่า แสดงว่าอาจมีปัญหากับ Skype โปรแกรมจะไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ได้

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