เราได้เปิดใช้งาน TLS 1.3 แล้ว ทำไมคุณควรทำเช่นเดียวกัน

เราได้เปิดใช้งาน TLS 1.3 แล้ว ทำไมคุณควรทำเช่นเดียวกัน

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

ประธานคณะทำงาน IETF TLS เขียน:
“โดยสรุป TLS 1.3 ควรเป็นรากฐานสำหรับอินเทอร์เน็ตที่ปลอดภัยและมีประสิทธิภาพยิ่งขึ้นไปอีก 20 ปีข้างหน้า”

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

อ้างอิงจาก Eric Rescorla (Firefox CTO และผู้เขียน TLS 1.3 แต่เพียงผู้เดียว) ในการให้สัมภาษณ์กับ The Register:

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


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

รายการการใช้งาน TLS 1.3 ปัจจุบันมีอยู่บน Github สำหรับใครก็ตามที่กำลังมองหาไลบรารี่ที่เหมาะสมที่สุด: https://github.com/tlswg/tls13-spec/wiki/Implementations. เป็นที่ชัดเจนว่าการยอมรับและการสนับสนุนโปรโตคอลที่ได้รับการอัปเดตจะก้าวหน้าไปอย่างรวดเร็วและกำลังดำเนินไปอย่างรวดเร็ว การทำความเข้าใจว่าการเข้ารหัสขั้นพื้นฐานเกิดขึ้นได้อย่างไรในโลกสมัยใหม่ได้แพร่กระจายไปอย่างกว้างขวาง

มีอะไรเปลี่ยนแปลงไปตั้งแต่ TLS 1.2?

ของ บันทึกของสมาคมอินเทอร์เน็ต:
“TLS 1.3 ทำให้โลกน่าอยู่ขึ้นได้อย่างไร?

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

ที่สำคัญไม่แพ้กันคือจะลบการสนับสนุนสำหรับการเข้ารหัสและอัลกอริธึมการแฮชแบบเดิมและไม่ปลอดภัยหลายอย่างที่ยังคงได้รับอนุญาต (แต่ไม่แนะนำ) เพื่อใช้กับ TLS เวอร์ชันก่อนหน้า รวมถึง SHA-1, MD5, DES, 3DES และ AES-CBC เพิ่มการรองรับชุดรหัสใหม่ การปรับปรุงอื่นๆ ได้แก่ องค์ประกอบการจับมือที่เข้ารหัสมากขึ้น (เช่น ขณะนี้การแลกเปลี่ยนข้อมูลใบรับรองได้รับการเข้ารหัสแล้ว) เพื่อลดจำนวนคำแนะนำแก่ผู้ดักฟังการรับส่งข้อมูลที่อาจเกิดขึ้น รวมถึงการปรับปรุงการส่งต่อความลับเมื่อใช้โหมดการแลกเปลี่ยนคีย์บางโหมดเพื่อให้การสื่อสารนั้น จะต้องคงความปลอดภัยไว้ตลอดเวลาแม้ว่าอัลกอริธึมที่ใช้ในการเข้ารหัสจะถูกบุกรุกในอนาคตก็ตาม”

การพัฒนาโปรโตคอลสมัยใหม่และ DDoS

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

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

เราได้เปิดใช้งาน TLS 1.3 แล้ว ทำไมคุณควรทำเช่นเดียวกัน

แม้ว่าเราจะไม่พร้อมที่จะคาดเดาข้อกำหนดด้านกฎระเบียบอย่างแน่นอน แต่ผลิตภัณฑ์ลดผลกระทบ DDoS ที่เป็นกรรมสิทธิ์ของเรา (รวมถึงโซลูชัน ไม่ต้องการการเปิดเผย ข้อมูลที่ละเอียดอ่อนและ/หรือเป็นความลับ) ถูกสร้างขึ้นในปี 2012 โดยคำนึงถึง PFS ดังนั้นลูกค้าและคู่ค้าของเราจึงไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ กับโครงสร้างพื้นฐานของตนหลังจากอัปเดตเวอร์ชัน TLS บนฝั่งเซิร์ฟเวอร์

นอกจากนี้ นับตั้งแต่มีการนำไปใช้ ยังไม่พบปัญหาที่เกี่ยวข้องกับการเข้ารหัสการขนส่งอีกด้วย เป็นทางการ: TLS 1.3 พร้อมสำหรับการผลิตแล้ว

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

ดังนั้นจึงควรเป็นตัวอย่างที่ดี ส่วนที่ 4.4 ร่าง IETF “ความสามารถในการจัดการ QUIC” ซึ่งเป็นส่วนหนึ่งของชุดโปรโตคอล QUIC ที่กำลังจะมีขึ้น ระบุว่า “วิธีการที่ทันสมัยในการตรวจจับและบรรเทา [การโจมตี DDoS] โดยทั่วไปแล้วจะเกี่ยวข้องกับการวัดแบบพาสซีฟโดยใช้ข้อมูลโฟลว์เครือข่าย”

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

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

การตั้งเป้าหมายที่เหมาะสมเพื่อเป็นแนวทางในการวิจัยถือเป็นความท้าทายที่สำคัญสำหรับผู้ให้บริการบรรเทาผลกระทบจาก DDoS พื้นที่หนึ่งที่สามารถเริ่มต้นการพัฒนาได้คือ กลุ่มวิจัยสมาร์ท ที่ IRTF ซึ่งนักวิจัยสามารถทำงานร่วมกับภาคอุตสาหกรรมเพื่อขัดเกลาความรู้ของตนเองเกี่ยวกับอุตสาหกรรมที่ท้าทายและสำรวจแนวทางการวิจัยใหม่ๆ นอกจากนี้เรายังยินดีต้อนรับนักวิจัยทุกคนอย่างอบอุ่น หากมี - สามารถติดต่อหากมีคำถามหรือข้อเสนอแนะที่เกี่ยวข้องกับการวิจัย DDoS หรือกลุ่มวิจัย SMART ได้ที่ [ป้องกันอีเมล]

ที่มา: will.com

เพิ่มความคิดเห็น