TLS 1.3 อยู่ที่นี่

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

ขนส่งเลเยอร์ความปลอดภัย

Transport Layer Security หรือ TLSเป็นโปรโตคอลการเข้ารหัสที่ปกป้องข้อมูลที่แลกเปลี่ยนผ่านเครือข่ายคอมพิวเตอร์ TLS มีชื่อเสียงในฐานะ S in HTTPS. โดยเฉพาะอย่างยิ่ง, TLS ใช้เพื่อปกป้องข้อมูลผู้ใช้เว็บจากการโจมตีเครือข่าย

TLS ได้รับการออกแบบมาเพื่อเป็นทางเลือกที่ปลอดภัยกว่ารุ่นก่อน Sockets Layer ความปลอดภัย (เอสเอสแอล). ในช่วงหลายปีที่ผ่านมานักวิจัยด้านความปลอดภัยได้ค้นพบช่องโหว่มากมายที่ส่งผลกระทบต่อ SSL ซึ่งกระตุ้นให้ IETF ออกแบบ TLS ในความพยายามที่จะบรรเทาพวกเขา

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

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

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

TLS เวอร์ชันและเอกสาร RFC ตามลำดับสามารถพบได้ในรายการด้านล่าง:

  • TLS 1.0 ถูกเผยแพร่เป็น RFC 2246 ใน 1996
  • TLS 1.1 ถูกเผยแพร่เป็น RFC 4346 ใน 2006
  • TLS 1.2 ถูกเผยแพร่เป็น RFC 5246 ใน 2008
  • TLS 1.3 ได้รับการเผยแพร่ตามมาตรฐานที่เสนอใน RFC 8446 ใน 2018

แก่ได้อย่างไร TLS รุ่นทำงาน?

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

TLS คือ ไฮบริด cryptosystem ซึ่งหมายความว่ามันใช้ทั้งสองอย่าง ไม่สมมาตร (กุญแจสาธารณะ) และ สมมาตร (ตามรหัสผ่าน / วลี) การเข้ารหัส เนื่องจาก การเข้ารหัสแบบอสมมาตร เป็นคำสั่งของขนาดที่ช้ากว่าการเทียบเท่าแบบสมมาตร

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

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

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

มีอะไรผิดปกติ TLS ? 1.2

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

นอกเหนือจากข้อพิจารณาด้านความปลอดภัยแล้ว TLS 1.2 ยังกำหนดประสิทธิภาพและค่าใช้จ่ายเครือข่ายที่ไม่จำเป็น

TLS ปัญหาด้านความปลอดภัย 1.2

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

แม้ว่าการใช้งานส่วนใหญ่และข้อบกพร่องอื่น ๆ จะได้รับการแก้ไขใน TLS 1.2 น่าเสียดายที่ช่องโหว่ในการออกแบบโปรโตคอลไม่สามารถแก้ไขได้โดยใช้เพียงแค่โปรแกรมแก้ไขซอฟต์แวร์ ปรากฎว่าในการทำเช่นนั้น IETF ต้องออกแบบโปรโตคอลการจับมือใหม่ทั้งหมดใน TLS 1.3.

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

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

TLS 1.2 ปัญหาด้านประสิทธิภาพ

นอกเหนือจากข้อพิจารณาด้านความปลอดภัยเหล่านี้แล้ว TLS 1.2 ต้องเจรจามากมาย TLS พารามิเตอร์สามารถกำหนดค่าใช้จ่ายด้านประสิทธิภาพบน HTTPS (หรืออื่น ๆ TLS ป้องกัน) การสื่อสาร

TLS การจับมือ 1.2 ขั้นตอนของ 4 ต้องมีการแลกเปลี่ยนแบบไปกลับสองครั้งโดยอันดับแรกต้องเลือกชุดการเข้ารหัสจากนั้นจึงแลกเปลี่ยนใบรับรองและคีย์สมมาตร (หรือคีย์แชร์)

ซึ่งหมายความว่าสำหรับทุกๆ TLS การเชื่อมต่อที่จะสร้างขึ้น ธุรกรรมเพิ่มเติมสองรายการ กับเซิร์ฟเวอร์เป็นสิ่งจำเป็น ผลที่ตามมา, TLS การเชื่อมต่อต้องการแบนด์วิดท์และพลังงานมากกว่า HTTP (ไม่เข้ารหัส) ซึ่งอาจมีราคาแพงโดยเฉพาะสำหรับแอปพลิเคชัน Internet-of-Things (IoT) ซึ่งการใช้พลังงานและแบนด์วิดท์ต่ำเป็นข้อ จำกัด อย่างหนัก

TLS 1.2 ปัญหาความเป็นส่วนตัว

สุดท้าย TLS 1.2 ถูกวิพากษ์วิจารณ์ว่าละเมิดความเป็นส่วนตัวของผู้ใช้เว็บ

โดยเฉพาะอย่างยิ่ง, TLS เสนอส่วนขยายที่เรียกว่า บ่งชี้ชื่อเซิร์ฟเวอร์ หรือ SNI SNI อนุญาตให้ชื่อโฮสต์ของเซิร์ฟเวอร์รวมอยู่ใน SSL handshake เริ่มต้น ส่วนขยายนี้ใช้สำหรับการโฮสต์เสมือนที่เซิร์ฟเวอร์อาจให้บริการหลายโดเมนบนที่อยู่ IP และพอร์ตเดียวกันในขณะที่แสดงใบรับรองที่แตกต่างกันสำหรับแต่ละโดเมน

In TLS 1.2, SNI จะถูกส่งไป ที่ไม่ได้เข้ารหัสดังนั้นแม้จะมีการใช้ HTTPS ผู้โจมตีเครือข่ายสามารถรั่วไหลข้อมูลนี้และติดตามเว็บเพจที่ผู้ใช้เยี่ยมชม

อย่างไร TLS 1.3 แก้ไขทั้งหมดที่?

TLS 1.2 (และเวอร์ชันก่อนหน้า) มุ่งเน้นไปที่การรักษาความเข้ากันได้แบบย้อนกลับ แต่ละเวอร์ชันสร้างขึ้นจากเวอร์ชันก่อนหน้าโดยมีการแก้ไขเล็กน้อยที่พยายามกำจัดช่องโหว่ที่เผยแพร่ระหว่าง TLS รุ่นที่

น่าเสียดายที่นี่ยังหมายความว่าการตัดสินใจออกแบบโปรโตคอลที่ไม่ดี (เช่น handshake ที่ไม่มีการป้องกัน) นั้นได้รับการสืบทอดในเวอร์ชันที่ใหม่กว่า

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

TLS ความปลอดภัย 1.3

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

มีอะไรอีก, TLS 1.3 ไม่รองรับการเข้ารหัสที่ไม่จำเป็นหรือมีช่องโหว่อีกต่อไปเช่นโหมด CBC และการเข้ารหัส RC4 การเข้ารหัสเหล่านี้เป็นที่ทราบกันดีว่ามีความอ่อนไหวต่อการโจมตี แต่ส่วนใหญ่ยังได้รับการสนับสนุน TLS การใช้งานสำหรับความเข้ากันได้แบบดั้งเดิม โชคดีที่การโจมตีลดระดับเมื่อเร็ว ๆ นี้ส่งผลกระทบในช่วงต้น TLS เวอร์ชันกระตุ้นให้ IETF ลบรหัสดังกล่าวออกทั้งหมด TLS 1.3.

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

ในที่สุดลายเซ็นตัวเองก็ยังได้รับการปรับปรุงโดยใช้มาตรฐานใหม่ที่เรียกว่า อาร์เอส-PSS. ลายเซ็น RSA-PSS ไม่สามารถป้องกันการโจมตีด้วยการเข้ารหัสที่มีผลต่อรูปแบบลายเซ็นที่ใช้ในช่วงก่อนหน้านี้ TLS รุ่นที่

TLS ไม่มีประสิทธิภาพ

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

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

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

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

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

ควรสังเกตว่ามีความปลอดภัย ความกังวล เกี่ยวกับโหมด 0-RTT ในอดีต

TLS ความเป็นส่วนตัว 1.3

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

สรุป

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

ขอขอบคุณที่เลือก SSL.com ซึ่งเราเชื่อว่า ปลอดภัยมากขึ้น อินเทอร์เน็ตคือ ดีกว่า อินเตอร์เน็ต

สมัครสมาชิกจดหมายข่าวของ SSL.com

อย่าพลาดบทความและการปรับปรุงใหม่จาก SSL.com

รับทราบข้อมูลและปลอดภัย

SSL.com เป็นผู้นำระดับโลกในด้านความปลอดภัยทางไซเบอร์ PKI และใบรับรองดิจิทัล ลงทะเบียนเพื่อรับข่าวสารอุตสาหกรรม เคล็ดลับ และประกาศผลิตภัณฑ์ล่าสุดจาก SSL.com.

เราชอบความคิดเห็นของคุณ

ทำแบบสำรวจของเราและแจ้งให้เราทราบความคิดเห็นของคุณเกี่ยวกับการซื้อครั้งล่าสุดของคุณ