มาตรการบรรเทาเหตุการณ์ดัก MitM ของ Hetzner/Linode XMPP.ru

 (devever.net)
1 คะแนน โดย GN⁺ 2023-10-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • jabber.ru และ xmpp.ru ประสบการโจมตีแบบ MitM ที่ผสานการดักทราฟฟิกในเส้นทางของผู้ให้บริการโฮสติ้งกับการออก ใบรับรอง Domain Validation โดยไม่ได้รับอนุญาต ทำให้เห็นช่องว่างในการป้องกันของบริการ TLS ที่ไม่ใช่เว็บ
  • การเฝ้าระวัง Certificate Transparency logs และการ probe กุญแจสาธารณะ TLS ช่วยค้นหาสัญญาณผิดปกติได้ แต่ยังตรวจจับได้ไม่สมบูรณ์เมื่อเจอใบรับรองที่ไม่ได้บันทึกใน CT และ MitM แบบเลือกเป้าหมาย
  • หาก deploy ACME-CAA(RFC 8657) ร่วมกับ DNSSEC จะสามารถอนุญาตให้เฉพาะบัญชีที่กำหนดของ CA ที่กำหนดออกใบรับรองได้ ทำให้ผู้โจมตีใช้เพียง CA เดียวกันอย่างเดียวไม่พอ
  • ต่างจากเว็บเบราว์เซอร์ ไคลเอนต์ที่ไม่ใช่เว็บจำนวนมากไม่ได้บังคับใช้ หลักฐาน CT (SCT) และ CA/Browser Forum Baseline Requirements ก็ไม่ได้บังคับให้ใบรับรองทั้งหมดต้องถูก log ใน CT
  • ผู้ดูแลระบบควรพิจารณา ACME-CAA, DNSSEC, การมอนิเตอร์ CT, Tor onion service และการกระจายเขตอำนาจศาล ส่วนผู้ใช้ควรถือการเข้ารหัสแบบ end-to-end และการตรวจสอบลายนิ้วมือเป็นแนวป้องกันพื้นฐาน

โครงสร้างหลักของเหตุการณ์

  • ผู้ดูแล jabber.ru และ xmpp.ru ระบุว่าบริการถูกโจมตีแบบ man-in-the-middle
  • การโจมตีเป็นรูปแบบที่สององค์ประกอบทำงานร่วมกัน
    • Hetzner และ Linode ดักทราฟฟิกที่มุ่งหน้าไปยังเครื่องของบริการ
    • ผู้โจมตีออก ใบรับรอง Domain Validation สำหรับบริการดังกล่าวโดยไม่ได้รับอนุญาต
  • ประเมินว่ามีความเป็นไปได้สูงที่รัฐเยอรมนีเป็นผู้ประสานงาน หรือเยอรมนีประสานงานร่วมกับรัฐอื่นอย่างน้อยหนึ่งรัฐ
  • ยังมีความเป็นไปได้อื่นอยู่
    • Hetzner และ Linode อาจตอบรับคำขอดักฟังจากอำนาจต่างชาติโดยสมัครใจ โดยไม่มีการบังคับทางกฎหมาย
    • อย่างไรก็ตาม ในกรณีนี้จะส่งผลเสียต่อชื่อเสียงของทั้งสองบริษัทอย่างมากและอาจผิดกฎหมาย จึงมองว่ามีความเป็นไปได้ต่ำ

วิธีตรวจจับและข้อจำกัด

  • วิธีแรกคือเฝ้าระวัง Certificate Transparency(CT) logs เพื่อค้นหาการออกใบรับรองที่ผู้ดูแลไม่ได้ร้องขอ
    • มีบริการบางส่วนที่ทำสิ่งนี้แทนให้
    • เครื่องมือที่คัดเฉพาะใบรับรองที่ไม่ได้ร้องขอแล้วแจ้งเตือนได้อย่างแม่นยำยังมีพื้นที่ให้ปรับปรุงอีก
  • วิธีที่สองคือเชื่อมต่อกับบริการเป็นระยะ ๆ เพื่อตรวจว่า กุญแจสาธารณะ ของ TLS server ตรงกับค่าที่คาดไว้หรือไม่

  • พื้นที่ที่การเฝ้าระวัง CT อาจพลาดได้

    • แม้เป็นใบรับรองที่ออกโดย CA ที่ถูกต้องตามกฎหมาย ก็ไม่จำเป็นต้องถูกบันทึกใน CT logs เสมอไป
    • CA/Browser Forum Baseline Requirements ยังไม่ได้กำหนดให้การ log ใน CT เป็นข้อกำหนดบังคับของ CA
    • เว็บเบราว์เซอร์ปฏิเสธใบรับรองที่ไม่มีหลักฐานเชิงเข้ารหัสว่าถูกบันทึกใน CT log ดังนั้นการ log ใน CT จึงถูกบังคับใช้โดยพฤตินัย
    • แอปพลิเคชันไคลเอนต์ที่ไม่ใช่เว็บส่วนใหญ่ไม่ได้ตรวจสอบหรือกำหนดให้ใบรับรองต้องมีหลักฐานการบันทึก CT
    • ในทางทฤษฎี ผู้โจมตีสามารถจัดหา ใบรับรองที่ไม่ได้ถูกบันทึกใน CT ได้

  • ความเป็นไปได้ในการหลบเลี่ยงของ MitM แบบเลือกเป้าหมาย

    • แม้พยายามตรวจจับ MitM ด้วยการ probe บริการ ผู้โจมตีอาจระบุการเชื่อมต่อที่ใช้ตรวจจับ แล้วไม่ใช้ MitM กับการเชื่อมต่อนั้นได้
    • อย่างน้อยควรทำ probe ผ่าน Tor เพื่อหลีกเลี่ยงสถานการณ์ที่ถูกระบุได้ง่าย
    • TLS stack สามารถถูก fingerprint ได้จากสัญญาณอย่างลำดับการเรียง TLV ทำให้มีความเป็นไปได้ที่จะแยกไคลเอนต์ XMPP จริงออกจาก probe agent
    • แทนที่จะขึ้นบัญชีดำ probe ที่รู้จัก ผู้โจมตีอาจขึ้นบัญชีขาวเพื่อทำ MitM เฉพาะทราฟฟิกของบุคคลที่สนใจได้
    • วิธีตรวจจับทั้งสองอย่างไม่สามารถให้ ความน่าเชื่อถือสมบูรณ์ ได้

ความเสี่ยงที่ลดได้ด้วย ACME-CAA

  • ใบรับรอง TLS เป็นกลไกเพื่อป้องกันการโจมตีแบบ MitM แต่ตัว โมเดล Domain Validation ที่ CA ใช้ยืนยันสิทธิ์ควบคุมโดเมนนั้นเองมีช่องโหว่ต่อ MitM
  • หากผู้โจมตีสามารถดักทราฟฟิกทั้งหมดที่มุ่งหน้าไปยังไซต์เหยื่อ ไม่ใช่แค่บางส่วน ความเสี่ยงจะสูงขึ้น
  • ACME-CAA(RFC 8657) สามารถบรรเทาปัญหานี้ได้ในบางสถานการณ์
  • แนวคิดหลักคือใช้ DNS record เพื่อระบุให้ เฉพาะบัญชีที่กำหนดของ CA ที่กำหนด เท่านั้นที่ออกใบรับรองโดเมนได้
    • แค่ใช้ CA เดียวกันยังไม่เพียงพอ
    • ต้องมีสิทธิ์เข้าถึงบัญชีเดียวกันของ CA นั้น
    • ใน Let's Encrypt ต้องมีสิทธิ์เข้าถึง ACME private key ที่ใช้ในการร้องขอใบรับรอง
  • เมื่อเทียบกับรูปแบบการโจมตีที่ทราบ ประเมินว่าหาก deploy ส่วนขยายนี้ไว้ก็น่าจะป้องกันการโจมตีได้

  • ข้อควรระวังเมื่อ deploy

    • เพื่อให้ ACME-CAA ทำงานได้ถูกต้อง จำเป็นต้อง deploy DNSSEC
    • หากไม่มี DNSSEC คำขอ DNS ของ CA ก็อาจถูกดักได้เช่นกัน
    • ผู้ที่ยึดครอง signing key ของ DNSSEC ได้สามารถข้ามกำแพงนี้ได้
    • DNS zone ที่ป้องกันด้วย DNSSEC สามารถดำเนินการได้โดยไม่ต้องมอบ signing key ให้บุคคลที่สาม
    • ในกรณีนี้ ผู้ให้บริการ DNS hosting ไม่มีอำนาจทำให้ zone เสียหาย
    • วิธีนี้ถูกประเมินว่าเป็นกลยุทธ์การ deploy ที่ดีที่สุด
    • ผู้โจมตีอาจพยายามกดดันนายทะเบียนโดเมนหรือ TLD registry ให้เปลี่ยน DNSSEC signing key ที่ลงทะเบียนไว้กับโดเมน
    • การกระทำนี้มีแนวโน้มที่จะสะดุดตา
    • ด้วยคุณสมบัติของ DNS caching อาจทำให้ยากที่จะป้องกันไม่ให้ repeated probes ตรวจพบการเปลี่ยน key
    • ยังมีความเป็นไปได้ที่ผู้โจมตีจะกดดัน CA เองให้ misissue ใบรับรอง
    • หาก CA บุคคลที่สามฝ่าฝืนกฎหรือทำผิดพลาด ก็ยังคงเปราะบางอยู่
    • CA/Browser Forum Baseline Requirements กำหนดให้ CA ตรวจสอบ DNSSEC
    • อย่างไรก็ตาม CA บุคคลที่สามยังอาจออกใบรับรองได้แม้ไม่ได้รับอนุญาตใน CAA record
    • เนื่องจากการ log ใน CT ไม่ใช่ข้อบังคับ ใบรับรองแบบนั้นจึงอาจไม่ถูกตรวจพบ

ขั้นตอนที่ผู้โจมตีที่ชำนาญกว่าอาจเลือกใช้

  • ผู้โจมตีในเหตุการณ์นี้ไม่ใช่ผู้โจมตีที่สมบูรณ์แบบ เพราะปล่อยให้ใบรับรองผิดกฎหมายหมดอายุ
  • เมื่อการเข้ารหัสราคาถูกและใช้ง่ายแพร่หลายขึ้น คาดว่าการโจมตีระดับรัฐจะซับซ้อนขึ้นและเกิดบ่อยขึ้น
  • หากเป็นผู้โจมตีระดับรัฐที่ชำนาญกว่า อาจเลือกขั้นตอนดังนี้
    • ใช้ประโยชน์จากการที่ CA ไม่ได้ถูกบังคับให้บันทึกใน CT log เพื่อขอ ใบรับรองที่ไม่ได้ถูกบันทึก
    • กดดันผู้ให้บริการโฮสติ้งให้ทำ MitM กับทราฟฟิกทั้งหมดที่มุ่งหน้าไปยังเครื่องของเหยื่อ
    • ใช้ TLS stack fingerprint และ IP ต้นทางเพื่อแยกทราฟฟิกที่สนใจออกจากทราฟฟิกสำหรับตรวจจับแบบ heuristic
    • ใช้ MitM ทำให้ CA เชื่อว่าผู้โจมตีเป็นผู้ควบคุมโดเมนเหยื่อโดยชอบธรรม
    • หากโดเมนใช้ ACME-CAA และ DNSSEC ก็อาจพยายามกดดันผู้ให้บริการ DNS hosting, นายทะเบียนโดเมน, TLD registry และ CA

ช่องโหว่ในโครงสร้างพื้นฐาน TLS ปัจจุบัน

  • การบังคับใช้ CT ของ TLS client ที่ไม่ใช่เว็บยังไม่เพียงพอ

    • เว็บเบราว์เซอร์กำหนดให้ใบรับรอง CA มีหลักฐานเชิงเข้ารหัสของการบันทึก CT log
    • TLS client ส่วนใหญ่อื่น ๆ ไม่บังคับใช้ หลักฐาน CT จึงอาจยอมรับใบรับรองที่ไม่ได้ถูกบันทึกได้
    • ไคลเอนต์ XMPP จำนวนมากก็อาจอยู่ในกลุ่มนี้ด้วย
    • การตรวจสอบ CT ไม่ใช่ฟีเจอร์ที่เปิดใช้เองโดยอัตโนมัติจากการ link กับ OpenSSL แต่ต้อง implement แยกต่างหาก
    • ซอฟต์แวร์ที่ใช้กับการสื่อสารอ่อนไหวควรพิจารณารองรับการบังคับใช้ CT

  • ไม่มีข้อบังคับให้ log ใบรับรองใน CT

    • CA/Browser Forum Baseline Requirements ซึ่งเป็นกฎอุตสาหกรรมที่ CA ต้องปฏิบัติตาม ไม่ได้กำหนดให้ต้องบันทึกใบรับรองใน CT log
    • มองว่าควรมุ่งไปสู่การกำหนดให้ใบรับรองทั้งหมดต้องถูกบันทึกใน CT log
    • หากการบังคับใช้ CT ถูก deploy อย่างแพร่หลาย ปัญหานี้อาจหมดความหมายในเชิงเทคนิค

  • ขาดบริการมอนิเตอร์ CT

    • จำเป็นต้องมี บริการมอนิเตอร์ CT มากขึ้น
    • ปัจจุบันบริการแจ้งเตือน CT หลักมี SSLMate's Cert Spotter
    • ราคาอาจเป็นภาระสำหรับบริการที่ดำเนินงานบนฐานอาสาสมัคร เป็นต้น
    • การมอนิเตอร์ CT ควรออกแบบให้ลด false positives และแจ้งเตือนเฉพาะการออกใบรับรองที่ดูผิดปกติหรือไม่ได้รับอนุญาต

  • ขาดความโปร่งใสของ DNSSEC

    • ปัจจุบันยังไม่มีโครงสร้างพื้นฐานเชิงเข้ารหัสที่ถูก deploy แล้วสำหรับตรวจจับการเปลี่ยน DNSSEC key ที่ตั้งค่าไว้กับโดเมน
    • หากนายทะเบียนโดเมนและ TLD registry ถูกกดดันหรือถูกเจาะจนเปลี่ยน DNSSEC key ของโดเมน การป้องกันของ ACME-CAA อาจอ่อนลง
    • ควรมี โซลูชันความโปร่งใส ที่ทำให้การเปลี่ยน zone key ของ DNSSEC มองเห็นได้ต่อสาธารณะ
    • โซลูชันนี้อาจบันทึกเฉพาะการเปลี่ยน zone key อย่าง DS record ก็ได้ ไม่จำเป็นต้องบันทึก record ทั้งหมดของ zone

คำแนะนำสำหรับผู้ให้บริการ

  • หากเป็นบริการที่อาจตกเป็นเป้าหมายการโจมตีระดับรัฐ แนะนำให้ใช้แนวทางป้องกันตามลำดับที่คุ้มค่าต่อค่าใช้จ่าย

  • ACME-CAA และ DNSSEC

    • การ deploy ACME-CAA อาจทำให้ผู้โจมตีหลอก CA ให้ออกใบรับรองโดเมนได้ยากขึ้น
    • ดูคู่มือการ deploy ได้จาก บทความการ deploy ACME-CAA
    • Security Considerations ของ RFC ก็มีข้อควรระวังสำคัญด้วย
    • หาก deploy ACME-CAA ควร deploy DNSSEC ร่วมด้วย
    • หากเป็นไปได้ ควรเลือกผู้ให้บริการ DNSSEC ที่ไม่ต้องฝาก signing key ไว้กับผู้ให้บริการ

  • บริการพร็อกซีและการเฝ้าระวัง CT

    • การใช้บริการอย่าง Cloudflare ถูกประเมินว่าอยู่ในสภาพคล้ายกับการทำ MitM กับตัวเองอยู่แล้ว
    • ควรสมัครบริการมอนิเตอร์ CT log หรือค้นหา log ด้วยตนเองเป็นประจำ
    • SSLMate's Cert Spotter ให้บริการมอนิเตอร์อัตโนมัติแบบเสียเงิน
    • Cert Spotter เป็นโอเพนซอร์ส จึง self-host ได้
    • crt.sh ให้บริการค้นหา CT log ด้วยตนเอง

  • การกระจายเขตอำนาจศาลและ Tor onion service

    • อาจพิจารณา การกระจายเขตอำนาจศาล โดยให้นายทะเบียนโดเมน, TLD registry, DNS hosting, CA และผู้ให้บริการโฮสติ้งอยู่คนละประเทศ
    • สามารถเลือกโดยคำนึงถึงประเทศหรือกลุ่มภูมิรัฐศาสตร์ที่มีแนวโน้มร่วมมือกันต่ำ
    • การให้บริการ Tor onion service สามารถหลีกเลี่ยงโครงสร้างพื้นฐานรวมศูนย์อย่าง TLS และ CA ได้
    • ใน Tor onion service กุญแจสาธารณะของบริการคือที่อยู่นั้นเอง
    • ผู้ใช้ต้องได้รับ onion address ที่ถูกต้องผ่านช่องทางที่เชื่อถือได้
    • บุคคลที่สามอาจชักนำไปยัง onion address ที่ผิดได้

  • การ probe อัตโนมัติผ่าน Tor

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

  • เวกเตอร์โจมตีอื่นและสมมติฐานกรณีเลวร้ายที่สุด

    • หากทำให้ MitM ยากขึ้น ผู้โจมตีอาจมีแนวโน้มใช้เส้นทางอื่น เช่น เจาะเครื่องโดยตรง ขโมย private key หรือขโมยข้อมูลอ่อนไหว
    • ผู้โจมตีระดับรัฐอาจกดดันผู้ให้บริการ VM ให้ทำ memory dump ในระดับ hypervisor
    • Dedicated server ก็อาจถูกเจาะได้หากผู้โจมตีเข้าถึงทางกายภาพ
    • ผู้ดูแลควรแนะนำให้ผู้ใช้ใช้ การเข้ารหัสแบบ end-to-end และควรสมมติว่าบริการถูกเจาะได้แม้พยายามอย่างดีที่สุดแล้ว
    • ประเมินว่าการเข้ารหัส “end-to-end” ที่ส่งผ่านเว็บแอปพลิเคชันไม่ใช่การป้องกันที่มีความหมาย

สิ่งที่ CA, นักพัฒนาไคลเอนต์ และผู้ใช้ควรทำ

  • CA/Browser Forum

    • ควรกำหนดให้ใบรับรองทั้งหมดถูกบันทึกใน CT log หรือเสนอข้อกำหนดดังกล่าว

  • นักพัฒนาแอปพลิเคชันไคลเอนต์

    • ควรเพิ่มฟีเจอร์บังคับว่าใบรับรอง TLS ต้องมี Signed Certificate Timestamps(SCTs) และเปิดใช้เป็นค่าเริ่มต้น
    • ควรทำให้ผู้ใช้รับรู้ได้ว่ากำลังได้รับการป้องกันนี้
    • เนื่องจากการบังคับใช้หลักฐาน CT มีความผันแปรบางประการ จึงควรพิจารณาการอภิปรายที่เกี่ยวข้องด้วย
    • ซอฟต์แวร์ควรเป็นโอเพนซอร์สเพื่อให้ audit โดยสาธารณะได้
    • ควรพิจารณาความเสี่ยงของ supply chain และความเป็นไปได้ที่ผู้พัฒนาจะถูกบังคับทางกฎหมายให้ทำให้ซอฟต์แวร์เสียหาย
    • ช่องทางจัดจำหน่ายที่นักพัฒนาไม่ได้ควบคุมโดยตรง เช่น package repository ของ Linux distribution อาจช่วยลดความเสียหายได้

  • ผู้ใช้ปลายทาง

    • แม้ผู้ให้บริการจะดำเนินงานด้วยเจตนาดี ก็ควรสมมติว่าบริการอาจถูกเจาะได้แม้พยายามอย่างดีที่สุดแล้ว
    • หากชีวิตขึ้นอยู่กับการที่บริการไม่ถูกเจาะ ก็ไม่ควรเชื่อถือบริการนั้น
    • ใน XMPP ควรใช้เทคโนโลยีเข้ารหัสแบบ end-to-end เช่น OMEMO หรือ OTR
    • ควรตรวจสอบลายนิ้วมือของคู่สนทนาเสมอ
    • ไม่ควรทำการเข้ารหัสแบบ end-to-end ผ่านซอฟต์แวร์บนเว็บ หรืออย่างน้อยควรสมมติว่าถูกเจาะแล้ว
    • หากผู้ให้บริการมี Tor onion service ให้พิจารณาใช้งาน แต่ต้องรับ onion address จากแหล่งที่เชื่อถือได้

  • CA และผู้เขียนมาตรฐาน

    • หาก CA ยังไม่รองรับ ACME-CAA(RFC 8657) ควรพิจารณา implement
    • แม้ไม่ใช่ CA ที่ใช้ ACME ก็สามารถ implement ACME-CAA ได้
    • แม้กฎของ CA/Browser Forum จะอนุญาตไม่ให้บันทึกใน CT แต่ CA สามารถใช้นโยบายบันทึกใบรับรองทั้งหมดใน CT ได้
    • ผู้เขียนมาตรฐานอาจพิจารณาความเป็นไปได้ของ ความโปร่งใสของ DNSSEC อีกครั้ง อย่างน้อยสำหรับ DS record

การประเมิน confidential computing

  • หากกังวลถึงขั้นที่ผู้ให้บริการโฮสติ้งอาจเจาะเครื่อง เทคโนโลยี confidential computing ปัจจุบันยังไม่ถือว่าเป็นทางออกที่เพียงพอ
  • การ deploy เองอาจดีกว่าไม่ทำอะไรเลย แต่ไม่ควรเชื่อว่าปลอดภัย
  • ประเมินว่าเทคโนโลยีปัจจุบันรวมถึง AMD, Intel และอื่น ๆ พึ่งพา vendor golden key ที่สามารถ backdoor ระบบได้
  • ผู้โจมตีระดับรัฐสามารถกดดัน vendor ให้ส่งมอบ key และเมื่อเป็นเช่นนั้น วิธีนี้ก็พังทลาย
  • แนวทาง confidential computing ที่ไม่พึ่งพา golden key อาจเป็นไปได้ แต่แนวทางปัจจุบันยังไม่ถึงมาตรฐานนั้น

เอกสารที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-22
ความคิดเห็นใน Hacker News

  • สรุปการโจมตีที่ https://notes.valdikss.org.ru/jabber.ru-mitm/ น่าสนใจ
    ผู้โจมตีออกใบรับรอง SSL/TLS หลายใบสำหรับ jabber.ru และ xmpp.ru ผ่าน Let’s Encrypt ตั้งแต่วันที่ 18 เมษายน 2023 และได้รับการยืนยันว่า ตั้งแต่วันที่ 21 กรกฎาคมถึง 19 ตุลาคม ทราฟฟิกไคลเอนต์อย่างน้อย 100% บน พอร์ต XMPP STARTTLS 5222 ถูกโจมตีแบบคนกลาง
    หลังจากนั้น เมื่อออกใบรับรองใหม่ไม่สำเร็จ จึงมีการส่งใบรับรองที่หมดอายุออกมาจากพอร์ต 5222 ของ jabber.ru และทันทีหลังจากเริ่มการตรวจสอบและสอบถาม Hetzner/Linode การโจมตีก็หยุดลง แต่บนเซิร์ฟเวอร์ Linode บางส่วนยังคงมีการดักฟังแบบพาสซีฟผ่านฮอปการกำหนดเส้นทางเพิ่มเติมอยู่
    ดูเหมือนว่าตัวเซิร์ฟเวอร์เองไม่ได้ถูกแฮ็ก แต่เครือข่ายของ Hetzner และ Linode น่าจะถูกปรับตั้งค่าใหม่โดยเล็งไปที่ IP ของบริการ XMPP
    ทั้งหน้านั้นและหน้าที่ลิงก์จากที่นี่ไม่ได้กล่าวถึง certificate pinning เลย ไม่แน่ใจว่าเป็นเพราะ XMPP ไม่รองรับหรือไม่ แต่ถ้ารองรับ ก็น่าจะช่วยป้องกันการโจมตีแบบนี้ได้

    • XMPP รองรับ channel binding และมันสามารถป้องกันการโจมตีนี้ได้ แต่บทความไม่ได้กล่าวถึง
      น่าเสียดายที่ jabber.ru ใช้ซอฟต์แวร์เซิร์ฟเวอร์รุ่นปี 2016 จึงไม่รองรับในเวอร์ชันเก่านั้น
      ทุกวันนี้ certificate pinning มีปัญหามาก เพราะใบรับรองมีอายุสั้นและต้องต่ออายุบ่อย หากถามผู้ใช้ทุกเดือนว่าจะอนุญาตใบรับรองใหม่หรือไม่ ผู้ใช้ก็จะกด “Accept” ให้ใบรับรองของผู้โจมตีโดยไม่คิดมากเช่นกัน
      Channel binding ทำงานโดยไม่ขึ้นกับใบรับรอง และรับประกันว่า TLS stream สิ้นสุดที่ตัวตนที่คาดไว้
      การไปเน้นที่การไม่รองรับ CT/SCT ของไคลเอนต์ XMPP นั้นดูน่าสงสัย การโจมตีนี้ใช้ใบรับรองที่ถูกต้องซึ่ง Let’s Encrypt ออกให้และถูกบันทึกใน CT log แล้ว ดังนั้น CT/SCT ก็คงตรวจจับไม่ได้
      หากมีระเบียน CAA ที่เข้มงวด ก็อาจใช้การตรวจสอบ SCT จับกรณีเชิงทฤษฎีที่ออกใบรับรองจาก CA อื่นได้ แต่ในความเป็นจริงก็ไม่มี CAA และ channel binding ก็เป็นมิตรต่อความเป็นส่วนตัวมากกว่า อีกทั้งพึ่งพาบุคคลที่สามน้อยกว่า
    • สงสัยว่าทำไมถึงเล็งเฉพาะ พอร์ต STARTTLS ถ้ารู้ว่าเซิร์ฟเวอร์มีพอร์ต TLS ปกติอยู่ด้วย ในกรณีนี้ผมคงไม่มีวันใช้พอร์ต STARTTLS ซึ่งเป็นการเข้ารหัสแบบ opportunistic encryption แน่
    • การที่ผู้โจมตีออกใบรับรอง SSL/TLS หลายใบผ่าน Let’s Encrypt ได้ หมายความว่าพวกเขาผ่านการตรวจสอบความเป็นเจ้าของโดเมนของ jabber.ru และ xmpp.ru
      กล่าวคือสามารถตอบสนอง โปรโตคอล ACME บน HTTP ที่โฮสต์อยู่ได้ หรือสามารถเขียนระเบียน DNS TXT ได้ จึงดูเหมือนว่าผู้เสียหายสูญเสียการควบคุมเซิร์ฟเวอร์กระบวนการหรือเนมเซิร์ฟเวอร์ไปแล้ว
    • ถ้าควบคุมไคลเอนต์ไม่ได้ ก็ไม่รู้ว่าจะทำ certificate pinning ได้อย่างไร
      ผมเข้าใจว่า certificate pinning ทำได้เฉพาะเมื่อควบคุมไคลเอนต์ได้ และเป็นวิธีใส่ใบรับรองที่จะอนุญาตลงในไคลเอนต์โดยตรง เพื่อเลี่ยงโครงสร้างพื้นฐานกุญแจสาธารณะของเว็บทั้งหมด
      ในสถานการณ์ที่ไคลเอนต์ทั่วไปเชื่อมต่อเข้ามา ไม่มีทางรู้ได้ว่าใบรับรองใดควรถูกอนุญาต และนั่นคือเหตุผลที่ใช้โครงสร้างพื้นฐานกุญแจสาธารณะของเว็บนั่นเอง
      แน่นอนว่าแม้จะมีไคลเอนต์ของตัวเอง ปัญหาก็แค่ย้ายขึ้นไปอีกชั้นหนึ่ง เพราะตำแหน่งที่ลูกค้าดาวน์โหลดไคลเอนต์แบบกำหนดเองอาจถูกเจาะและถูกใช้แจกจ่ายไคลเอนต์อันตรายได้

  • ในรายการนี้ขาดมาตรการป้องกันที่ obvious ที่สุดไป ควรเปิดใช้ SCRAM-xxxxx-PLUS เป็นวิธีพิสูจน์ตัวตน และถ้าเป็นไปได้ก็ควรบังคับใช้
    แนวคิดของรูปแบบ PLUS นั้นเรียบง่ายแต่ได้ผล แทนที่จะตรวจสอบด้วย salt เพียงอย่างเดียว มันจะผูกการตรวจสอบเข้ากับการเชื่อมต่อ TLS เฉพาะ ทำให้การพิสูจน์ตัวตนใช้ได้เฉพาะกับการเชื่อมต่อ TLS เดียวเท่านั้น
    สิ่งนี้เรียกอีกอย่างว่า channel binding

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

    • นึกภาพสถานการณ์ที่เกี่ยวข้องกับสงครามโดยตรง แบบดักทหารหรือสายลับตามตัวอักษรไม่ค่อยออก
      ที่ดูเป็นไปได้มากกว่าคือสถานการณ์ที่พยายามจับ ผู้ปฏิบัติการคาร์เดอร์หรือบอตเน็ต Jabber/XMPP ยังได้รับความนิยมพอสมควรในวงการฝั่งรัสเซียแบบนั้น และในบทความอย่าง Krebs on Security ก็มักเห็นภาพหน้าจอหรือล็อกที่มีหลายเซิร์ฟเวอร์อย่าง @exploit.in, @jabber.ru อยู่บ่อย ๆ
      แต่ไม่ว่าเจตนาจะเป็นอะไร การสอดส่องเป็นวงกว้างโดยทั่วไปก็น่ารังเกียจอยู่ดี
      ไม่รู้ว่าสัดส่วนการใช้งานเพื่ออาชญากรรมกับที่ไม่ใช่อาชญากรรมบนสองเซิร์ฟเวอร์นั้นเป็นเท่าไรแน่ แต่เหมือนกับ Tor ที่มีทั้งเนื้อหาผิดกฎหมายชัดเจนและการใช้งานที่ถูกกฎหมายปะปนกัน ที่นี่ก็น่าจะมีบทสนทนาธรรมดา ๆ อยู่ไม่น้อย
      ดังนั้นโดยหลักแล้วจึงไม่ค่อยเห็นด้วยกับการละเมิดความเป็นส่วนตัวเพื่อเฝ้าดูอาชญากรไซเบอร์แบบสุ่ม ๆ ในประเทศนอกเขตอำนาจที่แม้แต่ส่งผู้ร้ายข้ามแดนก็ทำได้ยาก
      เข้าใจว่า Hetzner คงไม่มีทางเลือกนอกจากให้ความร่วมมือถ้าไม่อยากลงเอยเหมือน Lavabit แต่ในฐานะที่เคยแนะนำบ่อย ๆ ถ้า Hetzner รู้เรื่องการโจมตีแบบคนกลางแล้วยังอนุญาตหรือช่วยเหลือ ก็ถือว่าน่าผิดหวังพอสมควร นอกเหนือจากเรื่องนี้ ผมยังมองว่าเป็นหนึ่งในบริษัทโฮสติ้งที่ดีที่สุด
      ความโปร่งใสดี uptime·ความน่าเชื่อถือ·การซัพพอร์ตดีกว่าผู้ให้บริการคลาวด์ส่วนใหญ่ และค่าใช้จ่ายก็ไม่เกินเหตุ ความพยายามในการทำให้การออกแบบที่เป็นมิตรต่อสิ่งแวดล้อมเป็นทางเลือกที่ฉลาดในเชิงเศรษฐกิจก็น่าชื่นชม
      ในหลัก “ลด > ใช้ซ้ำ > รีไซเคิล” ส่วน “ลด” เห็นได้จากการออกแบบแบบ KISS เช่น หลังคาสูงเอียงที่ช่วยระบายความร้อนตามธรรมชาติ[2], แชสซีเซิร์ฟเวอร์ที่ใกล้เคียงกับโครงค้ำยันขั้นต่ำและฝาครอบทางลมมากกว่าแชสซีจริง ๆ, และการออกแบบเมนบอร์ดมาตรฐานที่หมุนซ็อกเก็ต 90 องศาเพื่อให้พัดลมตัวเดียวระบายความร้อน VRM·CPU·หน่วยความจำได้[3]
      “ใช้ซ้ำ” เห็นได้จากการประมูลเซิร์ฟเวอร์ โดยไม่ทิ้งฮาร์ดแวร์รุ่นเก่า แต่ปล่อยเช่าด้วยวิธีประมูลแบบดัตช์ จึงหลีกเลี่ยงทั้งต้นทุนฮาร์ดแวร์ใหม่และต้นทุนสิ่งแวดล้อมจากการผลิตใหม่ทุกรุ่น
      ถ้ามีเซิร์ฟเวอร์เฉพาะนอกยุโรปด้วย ก็คงอยากใช้มากกว่านี้
      [1]: คำว่า “ถูกกฎหมาย” เองก็นิยามได้ยาก นักข่าวของประเทศหนึ่งคือ “ตัวแทนต่างชาติ” ของอีกประเทศหนึ่ง และ “นักต่อสู้เพื่อเสรีภาพ” ของประเทศหนึ่งคือ “ผู้ก่อการร้าย” ของอีกประเทศหนึ่ง
      [2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
      [3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk

  • ในบทความบอกว่า “CT เป็นตัวเลือก” แต่สุดท้ายแล้วนี่ไม่ใช่เรื่องที่ ไคลเอนต์ XMPP ต้องตัดสินใจหรือ? ตอนนี้เบราว์เซอร์แทบจะบังคับใช้แล้ว เลยสงสัยว่าอะไรที่ทำให้ไคลเอนต์ XMPP เรียกใช้ CT ไม่ได้
    ก็ไม่เข้าใจด้วยว่าหมายถึงการพึ่งพา trust store แบบไหนที่ออกใบรับรองซึ่งใช้กับเบราว์เซอร์ไม่ได้

    • ใช่แล้ว ทำแบบนั้นได้ และดูเป็นไอเดียที่ดี
      ปัญหาคือ พฤติกรรมการบังคับใช้ CT แทบไม่มีไลบรารี TLS ไหนเปิดไว้เป็นค่าเริ่มต้น ดังนั้นนักพัฒนาไคลเอนต์ XMPP ต้องตั้งใจเปิดเอง และตอนนี้คิดว่าส่วนใหญ่หรือทั้งหมดไม่ได้ทำแบบนั้น แน่นอนว่าอาจเปลี่ยนได้

  • บทความนี้แนะนำให้ใช้ OTR ใน XMPP แต่น่าเสียดายที่ OTRv3 ใช้การเข้ารหัสที่เก่าแล้ว และ OTRv4 ก็ยังไม่สรุปเป็นมาตรฐาน
    https://dustri.org/b/time-to-sunset-otr.html

  • สำหรับคำถามว่า “ถ้าเป็นผู้โจมตีที่สมบูรณ์แบบจะทำอะไร?” หากเข้าถึงคอมพิวเตอร์ทางกายภาพได้ ก็น่าจะมีวิธีดึงข้อมูลออกจากอุปกรณ์ด้วยการ ดักบัส บางรูปแบบ

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

  • ลองดู CAA แล้ว แต่ผู้ให้บริการ DNS ที่ใช้อยู่ไม่รองรับเรคคอร์ดนั้น มีเหตุผลไหมว่าทำไมต้องเป็นชนิดใหม่ แทนที่จะใช้ TXT record ที่พบได้ทั่วไปกว่า?

    • ลองดูได้ว่าผู้ให้บริการรองรับชนิดแบบ “opaque” หรือไม่ เป็นวิธีที่ส่ง encoding แบบไบนารีได้แม้ผู้ให้บริการจะไม่รู้ว่าเรคคอร์ดนั้นคืออะไร
      ถ้าไม่ได้ ก็ต้องขอให้รองรับ CAA record เป็นชนิดที่ถูกใช้งานมากขึ้นเรื่อย ๆ ดังนั้นถ้าทุกวันนี้ยังไม่รองรับ ก็ไม่ใช่บริการที่ดีนัก
      ไม่รู้รายละเอียดการถกเถียงตอนออกแบบ CAA แต่มีโอกาสสูงว่าน่าจะเคยคุยกันใน mailing list ของ IETF ที่เกี่ยวข้อง
    • ดู RFC5507 ส่วน “Why Adding a New Resource Record Type Is the Preferred Solution” ได้
      ผู้ให้บริการ DNS ควรรองรับ RR type ที่หลากหลาย และเจ้าของโดเมนควรโหวตด้วย NS record
      รายชื่อผู้ให้บริการ DNS ที่รองรับ CAA อยู่ที่ https://github.com/StackExchange/dnscontrol/blob/master/docu...
    • ผู้ให้บริการบางรายบอกว่าไม่รองรับ แต่จริง ๆ แล้วบางครั้งหมายถึงทำผ่าน เว็บอินเทอร์เฟซ ไม่ได้เท่านั้น
      คุ้มที่จะทดสอบว่าสามารถตั้ง primary server แบบซ่อน แล้วให้ผู้ให้บริการเป็นแค่ secondary server ได้ไหม ผมเคยเลี่ยงข้อจำกัดนั้นที่ Linode ด้วยวิธีนี้

  • ตัวเลือกในการรัน หน่วยงานออกใบรับรอง เองและเลือกใบรับรองรากอย่างระมัดระวังยังขาดไป

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

  • ผู้ให้บริการสามารถเข้าถึงโฮสต์ได้ จึงตรวจสอบการทำงานจากภายนอกได้โดยที่ผู้ใช้ไม่รู้ตัว

    • ฝั่ง Hetzner เป็น เซิร์ฟเวอร์จริง ต้องจัดฉากสถานการณ์อย่าง “ไฟดับ” แล้วฝังแบ็กดอร์ ซึ่งคงไม่ง่าย
      เช่น ต้องฝังเคอร์เนลโมดูลที่ยังคงอยู่ได้แม้หลังอัปเกรดเคอร์เนล และซ่อนตัวเองได้อย่างแนบเนียนมาก ในบทความก็พูดถึงการวิเคราะห์ดัมพ์หน่วยความจำดิบด้วย
    • Secure Boot และการเข้ารหัสหน่วยความจำแบบเวอร์ชวลไลซ์ถูกออกแบบมาเพื่อป้องกันการโจมตีแบบนั้น แต่ก็ต้องเชื่อใจ Intel/AMD
    • แต่ในกรณีนี้ ไม่รู้ด้วยเหตุผลใด ผู้โจมตีไม่ได้ใช้การเข้าถึงแบ็กดอร์ของเซิร์ฟเวอร์

  • แล้วคำตอบทางเทคนิคขั้นพื้นฐานต่อการโจมตีแบบนี้จากรัฐหรือผู้กระทำที่ทรงอำนาจระดับใกล้เคียงกันคืออะไร? มีวิธีใดที่จะตอบสนองความฝันแบบเพี้ยน ๆ เรื่องซอฟต์แวร์ที่เผยแพร่ได้อย่างเสรี แต่ไม่มีใครนอกจากผู้เขียนสามารถเซ็นเซอร์ แทรกแซง หรือดัดแปลงแก้ไขได้หรือไม่?
    ระบบ P2P ที่สร้างมาอย่างดีบนโครงสร้างพื้นฐานอินเทอร์เน็ตปัจจุบันเพียงพอเป็นคำตอบไหม หรือควรต้องวางอินเทอร์เน็ตเมชระดับโลกแบนด์วิดท์ต่ำที่ทำงานแบบไร้สายเพิ่มอีกชั้นหนึ่ง?
    หวังว่า Freenet 2023 จะพัฒนาไปสู่ประสบการณ์นักพัฒนาที่ไร้แรงเสียดทานสำหรับแอปพลิเคชัน P2P