มีข่าวออกมาว่า Apple, Cloudflare, Fastly และ Mozilla ได้ร่วมมือกันในการปรับปรุงการเข้ารหัสของกลไกการระบุชื่อเซิร์ฟเวอร์ของ HTTPS ที่ IETF 102 Hackathon ตามที่ระบุโดยทวีตจาก Nick Sullivan ของ Cloudflare ทวีตแสดงความยินดีกับทีมมิกซ์จาก บริษัท ยักษ์ใหญ่ด้านเทคโนโลยีทั้งสี่โดยกล่าวว่า“ สุดยอดงาน” และแบ่งปันที่นั่นภายใต้ลิงก์ไปยังเซิร์ฟเวอร์ที่ใช้งานได้ที่ esni.examp1e.net และ cloudflare-esni.com .
ผลงานที่ยอดเยี่ยมที่ IETF 102 hackathon โดยทีม SNI ที่เข้ารหัสซึ่งประกอบด้วยคนจาก @Cloudflare @ รวดเร็ว @mozilla และ @แอปเปิ้ล . ขณะนี้มีการใช้งานใน BoringSSL, NSS และ picotls
เซิร์ฟเวอร์ที่ทำงานอยู่ที่ https://t.co/sLI9xLRjlK และ https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 กรกฎาคม 2561
IETF Hackathon เป็นแพลตฟอร์มที่เชิญนักพัฒนารุ่นใหม่และผู้ที่ชื่นชอบเทคโนโลยีมาร่วมเป็นส่วนหนึ่งในการร่างโซลูชันสำหรับปัญหาที่เกี่ยวข้องกับเทคโนโลยีที่ผู้ใช้ทั่วไปต้องเผชิญในปัจจุบัน กิจกรรมนี้สามารถเข้าร่วมได้ฟรีเปิดให้ทุกคนเข้าร่วมและส่งเสริมการทำงานเป็นทีมเมื่อเทียบกับการแข่งขัน IETF Hackathon ในปีนี้จัดขึ้นที่มอนทรีออลในวันที่ 14ธและ 15ธของเดือนกรกฎาคม ความสำเร็จที่โดดเด่นที่สุดที่จะเกิดขึ้นคือการเข้ารหัสของ Transport Layer Security (TLS) Server Name Indication (SNI) ซึ่งเป็นปัญหาที่รบกวนนักพัฒนาในช่วงทศวรรษที่ผ่านมาซึ่งเป็นสมาชิกของ Apple, Cloudflare, Fastly และขณะนี้ Mozilla ได้เสนอวิธีแก้ปัญหา
กิจกรรม IETF Hackathon IETF
มีการเปลี่ยนแปลงทั่วโลกอย่างชัดเจนจาก Hyper Text Transfer Protocol (HTTP) ไปเป็น Transport Layer Security Server Name Indication Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) ในช่วงทศวรรษครึ่งที่ผ่านมา ปัญหา สิ่งที่เกิดขึ้นจากการเพิ่มประสิทธิภาพระบบ TLS SNI HTTPS คือความสามารถของแฮ็กเกอร์ในการใช้ SNI โดยไม่คำนึงถึงวัตถุประสงค์เพื่อจับคู่การถ่ายโอนข้อมูลสำหรับการถอดรหัสในภายหลัง
ก่อนการพัฒนา SNI เป็นการยากที่จะสร้างการเชื่อมต่อที่ปลอดภัยกับเซิร์ฟเวอร์เสมือนหลายเครื่องโดยใช้การจับมือกับไคลเอ็นต์แรกเดียวกัน เมื่อที่อยู่ IP หนึ่งโต้ตอบกับเซิร์ฟเวอร์หนึ่งเซิร์ฟเวอร์ทั้งสองแลกเปลี่ยน“ hellos” เซิร์ฟเวอร์ส่งใบรับรองคอมพิวเตอร์ส่งคีย์ไคลเอ็นต์ทั้งสองแลกเปลี่ยนคำสั่ง“ ChangeCipherSpec” จากนั้นการโต้ตอบก็เสร็จสิ้นเมื่อมีการสร้างการเชื่อมต่อ สิ่งนี้อาจฟังดูง่ายอย่างที่เพิ่งพูดไป แต่กระบวนการนี้เกี่ยวข้องกับการแลกเปลี่ยนและการตอบสนองหลายรายการซึ่งจัดการได้ง่ายจนมีปัญหาเนื่องจากจำนวนเซิร์ฟเวอร์ที่สื่อสารด้วยเพิ่มขึ้น หากไซต์ทั้งหมดใช้ใบรับรองเดียวกันก็ไม่เป็นปัญหามากนัก แต่น่าเสียดายที่ไม่ค่อยเกิดขึ้น เมื่อไซต์หลายแห่งส่งใบรับรองต่างๆไปมาเป็นเรื่องยากที่เซิร์ฟเวอร์จะระบุได้ว่าคอมพิวเตอร์กำลังมองหาใบรับรองใดและในเว็บการแลกเปลี่ยนที่ซับซ้อนจึงยากที่จะระบุว่าใครส่งอะไรและเมื่อใดจึงยุติกิจกรรมทั้งหมด พร้อมข้อความเตือนทั้งหมด
TLS SNI ได้รับการแนะนำในเดือนมิถุนายนปี 2546 ผ่านการประชุมสุดยอด IETF และจุดประสงค์ในการให้บริการในแง่หนึ่งคือการสร้างแท็กชื่อสำหรับคอมพิวเตอร์และบริการที่เกี่ยวข้องกับเว็บแลกเปลี่ยน สิ่งนี้ทำให้กระบวนการแลกเปลี่ยนสวัสดีไคลเอนต์เซิร์ฟเวอร์ตรงไปตรงมามากขึ้นเนื่องจากเซิร์ฟเวอร์ถูกสร้างขึ้นให้สามารถให้ใบรับรองที่แน่นอนที่จำเป็นและทั้งสองถูกทำให้สามารถแลกเปลี่ยนการสนทนาของตัวเองได้โดยไม่ต้องสับสนว่าใครพูดอะไร เหมือนกับการมีชื่อผู้ติดต่อสำหรับการแชทและไม่สับสนว่าข้อความนั้นมาจากไหนและยังสามารถตอบกลับคำถามแต่ละข้อได้อย่างเหมาะสมโดยให้เอกสารที่เหมาะสมกับคอมพิวเตอร์เครื่องใดก็ตามที่ต้องการ คำจำกัดความ SNI นี้เป็นสิ่งที่ทำให้เกิดปัญหาสูงสุดกับวิธีการเพิ่มประสิทธิภาพกระบวนการแลกเปลี่ยนนี้
การต่อสู้ที่หลาย บริษัท ต้องเผชิญในการเปลี่ยนมาใช้ HTTPS คือการปรับเปลี่ยนใบรับรองจำนวนมากให้เป็นรูปแบบ SNI โดยมีที่อยู่ IP แต่ละรายการเพื่อดำเนินการขอใบรับรองแต่ละรายการ สิ่งที่ TLS ทำเพื่อพวกเขาทำให้ง่ายขึ้นในการสร้างใบรับรองเพื่อตอบสนองต่อคำขอดังกล่าวและสิ่งที่ SNI ทำเพิ่มเติมก็คือการขจัดความต้องการที่อยู่ IP ของใบรับรองเฉพาะรายบุคคลโดยการโยนระบบการระบุตัวตนทั้งหมดในเครือข่ายอินเทอร์เน็ต สิ่งที่มาพร้อมกับการอัพเกรดแห่งศตวรรษคือความจริงที่ว่ามันอนุญาตให้แฮกเกอร์ใช้ 'ชื่อผู้ติดต่อ' ที่กำหนดขึ้นเพื่อตรวจสอบและควบคุมการถ่ายโอนข้อมูลและดึงข้อมูลที่ต้องการถอดรหัสในภายหลัง
แม้ว่า TLS จะอนุญาตให้ส่งข้อมูลกลับไปกลับมาในช่องทางที่เข้ารหัส แต่ SNI จะทำให้มั่นใจได้ว่าข้อมูลนั้นไปถึงปลายทางที่ถูกต้อง แต่อย่างหลังนี้ยังให้วิธีการสำหรับแฮกเกอร์ในการตรวจสอบกิจกรรมออนไลน์และจับคู่กับแหล่งที่มาโดยทำตามคำขอ DNS ที่อยู่ IP และสตรีมข้อมูล แม้ว่าจะมีการใช้นโยบายการเข้ารหัส SNI ที่เข้มงวดขึ้นโดยการส่งข้อมูล DNS ผ่านช่องทาง TLS เช่นกัน แต่ยังคงมีหน้าต่างเล็ก ๆ สำหรับแฮกเกอร์ที่สามารถใช้สิ่งนี้เป็นวิธีการระบุตัวตนเพื่อติดตามข้อมูลที่พวกเขาต้องการแยกและแยกออก การถอดรหัส เซิร์ฟเวอร์ที่ซับซ้อนซึ่งจัดการกับการรับส่งข้อมูลที่เข้ารหัส TLS มากขึ้นใช้ SNI ข้อความธรรมดาเพื่อส่งการสื่อสารไปรอบ ๆ ในเซิร์ฟเวอร์ของตนและนี่คือสิ่งที่ทำให้แฮกเกอร์ระบุช่องทางและสตรีมข้อมูลที่ต้องการติดตามได้ง่ายขึ้น เมื่อแฮ็กเกอร์สามารถดึงข้อมูล SNI ของข้อมูลที่สนใจได้เขา / เขาสามารถตั้งค่าการเล่นคำสั่งซ้ำของคำสั่งในการเชื่อมต่อ TLS แยกกับเซิร์ฟเวอร์โดยส่งข้อมูล SNI ที่ขโมยมาและดึงข้อมูลที่ เกี่ยวข้องกับมัน มีความพยายามหลายครั้งในการแก้ไขปัญหา SNI นี้ในอดีต แต่ส่วนใหญ่ขัดต่อหลักการเรียบง่ายที่ SNI ดำเนินการเพื่อให้เป็นวิธีการระบุตัวตนที่สะดวกสำหรับเซิร์ฟเวอร์
ย้อนกลับไปที่การประชุมสุดยอดครั้งแรกเพื่อสร้างวิธีการนี้ผู้เข้าร่วมจากยักษ์ใหญ่ด้านเทคโนโลยีสี่รายได้กลับไปที่การประชุมในมอนทรีออลเพื่อพัฒนาการเข้ารหัสสำหรับ TLS SNI เนื่องจากแม้จะมีประสิทธิภาพที่ดีกว่าในระบบที่เชื่อมต่อกับ HTTPS แบบหลายระบบ แต่ความปลอดภัยก็ยังคงเป็นปัญหา เท่าที่เคยทำมาก่อน
ในการปกปิด SNI ใน TLS จะต้องเก็บ“ บริการที่ซ่อนอยู่” ไว้ภายใต้การแสดง“ Fronting Service” ที่แฮ็กเกอร์อาจเห็น หากไม่สามารถสังเกตเห็นบริการที่ซ่อนอยู่ได้โดยตรงแฮ็กเกอร์จะเข้าใจผิดโดยการปลอมตัวบังหน้าซึ่งซ่อนอยู่ภายใต้ข้อความธรรมดาโดยไม่สามารถระบุพารามิเตอร์ของบริการลับที่ใช้ในการถ่ายทอดข้อมูลที่เข้ารหัสได้ ในขณะที่ผู้สังเกตการณ์ติดตามเส้นทางของบริการบังหน้าข้อมูลจะถูกลบออกจากช่องสัญญาณที่สังเกตได้เนื่องจากข้อมูลจะถูกเปลี่ยนเส้นทางไปยังบริการที่ซ่อนไว้ซึ่งตั้งใจไว้ซึ่งจุดนั้นแฮกเกอร์จะสูญเสียเส้นทาง เนื่องจากเซิร์ฟเวอร์จะถูกเปิดเผยต่อบริการ fronting เมื่อข้อมูลไปถึงที่นั่นสัญญาณ SNI แบบขนานที่สองจะถูกส่งไปยังบริการ fronting เพื่อเปลี่ยนเส้นทางข้อมูลไปยังบริการที่ซ่อนอยู่และในกระบวนการเปลี่ยนทิศทางนี้แฮ็กเกอร์จะ หายไปในเว็บของเซิร์ฟเวอร์ กลไกของตั๋วสองใบนี้ได้รับการพัฒนาต่อไปเป็นตั๋วรวมภายใต้ SNI เดียวกัน เนื่องจากข้อมูลชิ้นเดียวถูกส่งไปยังเซิร์ฟเวอร์ข้อมูลจะสร้างผู้อำนวยการใหม่ SNI ที่ทำงานร่วมกันและทั้งสองทำงานร่วมกันเพื่อรับข้อมูลที่เข้ารหัส TLS ไปยังที่ที่ต้องการ หากไม่สามารถถอดรหัสบริการบังหน้าแบบสุ่มที่ครอบคลุมทั้งแทร็ก SNI แฮ็กเกอร์จะไม่สามารถติดตามข้อมูลได้ แต่เซิร์ฟเวอร์จะยังคงสามารถเชื่อมต่อทั้งสองและถอดรหัสบริการที่ซ่อนอยู่เป็นตำแหน่งสูงสุดของข้อมูล สิ่งนี้ช่วยให้เซิร์ฟเวอร์ใช้ SNI ต่อไปเพื่อเพิ่มประสิทธิภาพการถ่ายโอนข้อมูลในการเข้ารหัส TLS ในขณะที่มั่นใจว่าแฮกเกอร์ไม่สามารถใช้ประโยชน์จากกลไก SNI ได้
