DM ที่เข้ารหัสแบบใหม่ของ Twitter ไม่ได้ดีกว่าของเดิม

 (mjg59.dreamwidth.org)
2 คะแนน โดย GN⁺ 2025-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DM เข้ารหัสแบบใหม่ของ Twitter(X) (XChat) อ้างว่าเป็น การเข้ารหัสแบบ end-to-end ในทางเทคนิค แต่ยังคงมี ช่องโหว่ด้านความปลอดภัยร้ายแรง เช่น การขโมย private key, MITM และการเปิดเผยเมตาดาต้า
  • มีการนำ Libsodium Box (การเข้ารหัสที่อิงกับ secret key) มาใช้ แต่ ไม่รองรับ forward secrecy และใช้การปกป้องกุญแจที่อ่อนแอด้วย PIN 4 หลัก ทำให้ การดึง private key ออกมาทำได้ค่อนข้างง่าย
  • ใช้ โปรโตคอล Juicebox สำหรับสำรอง/กู้คืนกุญแจ แต่ ความปลอดภัยที่แท้จริงขึ้นอยู่กับความน่าเชื่อถือของแบ็กเอนด์ทั้งหมด และ Twitter เป็นผู้ดูแลแบ็กเอนด์ทั้งหมดเอง ทำให้ แทบไม่มีประโยชน์จากการทำ sharding
  • ไม่มีขั้นตอน out-of-band สำหรับการรับรอง/ตรวจสอบ public key ทำให้ Twitter สามารถสลับเปลี่ยนกุญแจเพื่อทำ MITM (การโจมตีแบบคนกลาง) ได้ และ เมตาดาต้าของผู้ใช้ก็ยังคงถูกเปิดเผย
  • ต่างจาก Signal ตรงที่ขณะนี้ ยังขาดการคุ้มครองความเป็นส่วนตัวอย่างแท้จริง จึง แนะนำให้ใช้ Signal ซึ่งเป็นเมสเซนเจอร์เข้ารหัสที่เชื่อถือได้

วิเคราะห์ DM เข้ารหัสแบบใหม่ของ Twitter

พื้นหลังและสรุป

  • Twitter(X) เปิดตัว แพลตฟอร์มข้อความเข้ารหัส XChat ใหม่ โดยโปรโมตว่าพัฒนาด้วย Rust และใช้โครงสร้างการเข้ารหัสสไตล์ Bitcoin
  • แต่เมื่อดูการใช้งานจริง จะพบว่า Twitter ยังคงมีโครงสร้างที่เข้าถึง private key, ทำ MITM และเก็บเมตาดาต้าได้
  • บทสรุป: แนะนำให้ใช้ Signal ส่วน DM ของ Twitter(X) ไม่ปลอดภัยเพราะมีข้อจำกัดเชิงโครงสร้างตั้งแต่ต้น

โครงสร้างการเข้ารหัสและข้อจำกัด

1. วิธีการเข้ารหัส

  • ใช้ box ของ Libsodium (การเข้ารหัสแบบ public key)
  • ไม่รองรับ forward secrecy: หาก private key รั่ว ข้อความเก่าทั้งหมดจะถูกถอดรหัสได้ (กล่าวคือ อ่อนแอกว่าเมสเซนเจอร์สมัยใหม่อย่าง Signal)
  • การใช้งานจริงไม่ได้ใช้ Rust แต่ใช้ไลบรารี C (bind ผ่าน jni)

2. การเก็บและกู้คืนกุญแจ (โปรโตคอล Juicebox)

  • private key ที่สร้างบนอุปกรณ์ถูกเก็บด้วย โปรโตคอล Juicebox
  • กุญแจถูกเก็บหลังจาก เข้ารหัสด้วย PIN 4 หลัก และต้องใส่ PIN ตอนกู้คืน
  • เซิร์ฟเวอร์ไม่รู้ PIN แต่เพราะ PIN มีเพียง 4 หลัก (เป็นไปได้แค่ 10,000 แบบ) จึง ถูก crack ได้รวดเร็วด้วย brute force แบบขนาน
  • แม้จะใช้ Argon2id ด้วยหน่วยความจำ 16MB และทำซ้ำ 32 รอบ ก็ ไม่ใช่อุปสรรคใหญ่สำหรับผู้โจมตีจริง (แม้แต่โน้ตบุ๊กสเปกต่ำก็ใช้เวลาไม่ถึง 0.2 วินาที)

3. ข้อจำกัดของโครงสร้างกระจายกุญแจ (Sharding)

  • Juicebox รองรับการกระจายไปยังหลายแบ็กเอนด์ (sharding) แต่ Twitter เป็นผู้ดูแลแบ็กเอนด์ทั้ง 3 ตัวเองทั้งหมด
  • สุดท้ายแล้ว ผู้ใช้ต้องพึ่งพาความน่าเชื่อถือของ Twitter อย่างสมบูรณ์ในกระบวนการกู้คืนกุญแจ และไม่ได้ประโยชน์ด้านความปลอดภัยหลักของ sharding
  • อีกทั้งยัง ไม่มีขั้นตอนตรวจสอบฮาร์ดแวร์ เช่น HSM หรือ SGX สำหรับการสื่อสารกับแบ็กเอนด์อย่างปลอดภัย

4. จุดอ่อนของการรับรอง/แลกเปลี่ยน public key

  • public key ของคู่สนทนาได้รับผ่านเซิร์ฟเวอร์ของ Twitter เท่านั้น และไม่มีวิธีตรวจสอบแยกต่างหาก (out-of-band)
  • Twitter สามารถ ส่ง public key ปลอมตามต้องการเพื่อทำการโจมตีแบบคนกลาง (MITM) ได้
  • แม้หน้า support อย่างเป็นทางการจะยอมรับจุดอ่อนนี้ และบอกเพียงว่าจะปรับปรุงในอนาคต แต่ก็ ยังไม่มีมาตรการที่เป็นรูปธรรมในตอนนี้

5. เมตาดาต้าและปัญหาอื่น ๆ

  • Twitter สามารถทราบเมตาดาต้าได้ทั้งหมด เช่น ใครส่งข้อความหาใคร และส่งเมื่อใด
  • ต่อให้ private key ไม่รั่ว รูปแบบการสื่อสารของผู้ใช้ก็ยังคงถูกเปิดเผยต่อบริษัท

บทสรุปและคำแนะนำ

  • ด้วย ข้อจำกัดด้านการออกแบบของ DM เข้ารหัส ระบบนี้จึงยังด้อยกว่าเมสเซนเจอร์ที่ผ่านการพิสูจน์แล้วอย่าง Signal ในแง่ความปลอดภัยและความเป็นส่วนตัวจริง
  • ตราบใดที่ Twitter ยังควบคุมทั้ง public key, keystore และเส้นทางการสื่อสาร ก็ ไม่อาจถือเป็น end-to-end encryption ที่แท้จริงได้
  • ขอแนะนำอย่างยิ่งให้ใช้เมสเซนเจอร์ที่ใช้โปรโตคอลเปิดเผยและโปร่งใสอย่าง Signal

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

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

 
GN⁺ 2025-06-07
ความคิดเห็นจาก Hacker News

  • ฉันเป็นแฟนที่ชอบทุกบทความของ Matthew Garrett แต่ก็อยากย้ำแบบจุกจิกว่า Signal รองรับฟีเจอร์ forward secrecy มาตลอดตั้งแต่ก่อนหน้านี้แล้ว แนวคิดของแอปส่งข้อความที่ปลอดภัยสมัยใหม่ถือกำเนิดขึ้นเมื่อ OTR (Borisov และ Goldberg) เป็นกลุ่มแรก ๆ ที่เสนอแนวคิดเรื่อง "perfect forward secrecy" และ deniability Signal คือผลลัพธ์ของการต่อยอดทั้งไอเดียเหล่านี้และด้านวิศวกรรมของมันทั้งหมด (การเข้ารหัสที่ดีขึ้น โค้ดที่ดีขึ้น การแพ็กเกจที่ดีขึ้น) สิ่งที่น่าหงุดหงิดคือแอปส่งข้อความใหม่ ๆ ไม่ได้ถอยกลับไปแค่ระดับ "ก่อน Signal" แต่ถอยไปถึงระดับความปลอดภัยก่อนปี 2001 หรือก่อนยุคสมัยใหม่เสียอีก

    • มีสามเรื่องที่ควรจำจากข้อมูลรั่วไหลหลายครั้งในอดีต (1) FBI เคย "บังคับ" บริษัทต่าง ๆ อย่างลับ ๆ ให้ใส่ backdoor มีการกล่าวถึงด้วยว่าศาล FISA สามารถปรับบริษัทด้วยค่าปรับรุนแรงได้ (2) มีการจ่ายเงินให้บริษัทยักษ์ใหญ่หลักสิบล้านถึงหลักร้อยล้านเป็นค่าทำ backdoor และยังใช้แรงกดดันผ่านสัญญาภาครัฐหรือใบอนุญาตส่งออกด้วย ตีความได้ว่าเป็นนโยบายแบบ "เงินหรือปืน" ในที่สุด (3) ในคดี Lavabit นั้น FBI เรียกขอกุญแจและในทางปฏิบัติก็บีบให้โกหกลูกค้าด้วย เมื่อนึกถึงกรณีเหล่านี้ ก็เลยอดสงสัยไม่ได้ว่าการเข้ารหัสในแพลตฟอร์มขนาดใหญ่คงถูกทำให้อ่อนแอลงโดยเจตนาตามคำสั่งรัฐอยู่บ่อย ๆ หรือไม่ก็ทำแบบขอไปทีจนหละหลวม จนกว่ากฎหมายและแนวปฏิบัติที่เกี่ยวข้องอย่าง Patriot Act, FISC, การตีความลับ ฯลฯ จะถูกยกเลิก และผู้ฝ่าฝืนจะถูกลงโทษ ผมถือว่าการเข้ารหัสในรัฐตำรวจนั้นถูก Five Eyes ทำลายไปแล้ว

    • ตราบใดที่ผู้คนยังติดตั้งแอปบนพีซีผ่าน App Store สภาพล้าหลังแบบนี้ก็คงจะดำเนินต่อไป

  • ถ้าใช้ ephemeral key แต่ไม่มี forward secrecy หรือแม้แต่บันทึกการโต้ตอบ ก็สงสัยว่าตรงไหนกันแน่ที่เป็น "สไตล์ Bitcoin" จริง ๆ

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

    • หมายถึงแทบไม่มีคุณค่าในการใช้งานจริง

    • และตัว Bitcoin เองก็ไม่ใช่ช่องทางสื่อสารที่ปลอดภัยด้วย

    • มีจุดที่ใช้การอนุมานกุญแจจาก PIN แต่ดูจะใกล้เคียงกับวิธีทำแบ็กอัปมากกว่าจะเป็นเรื่องของระบบส่งข้อความเอง จึงยากจะนับว่าเป็นคุณลักษณะสำคัญโดยเนื้อแท้

    • มีการพูดถึงการใช้ฟังก์ชันแฮช

  • แชร์ลิงก์การถกเถียงก่อนหน้า:
    XChat "เข้ารหัส" ใหม่ของ X ก็ไม่ได้ปลอดภัยขึ้นเท่าไร

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

  • ถ้าจะเข้ารหัส น่าจะดีกว่าถ้าใช้ซอฟต์แวร์แยกต่างหากและแลก public key กันแบบเจอหน้ากันโดยตรง

  • คำถาม: กำลังจะไปปักกิ่งในเร็ว ๆ นี้ อยากรู้ว่าสามารถใช้ Twitter ได้โดยไม่ต้องมี VPN หรือไม่

    • ซิมโรมมิ่งบางประเภทอาจไม่ถูกบังคับใช้ตาม Great Firewall แต่โดยมากแล้วก็ยังต้องใช้ VPN

  • สงสัยกับคำว่า "Bitcoin style encryption" เพราะในความเข้าใจจริง ๆ แล้ว Bitcoin พึ่งพาเทคโนโลยีลายเซ็นเข้ารหัสมากกว่าสิ่งที่เรามักเรียกว่า "encryption"

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

    • ควรจำไว้ด้วยว่าต้นทางของคำพูดนี้เองก็ไม่ใช่คนที่ลงลึกทางเทคนิคมากนัก

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

    • แชร์ลิงก์วิดีโออธิบาย
      https://www.youtube.com/watch?v=sJNK4VKeoBM

    • เป็นแค่คำฮิตประมาณว่าเอาไว้ทำให้มันดูเท่และรู้สึกเหมือนเป็น “ของมีค่า” เท่านั้น

  • สงสัยว่า XChat ตัวจริง (IRC client) จะฟ้อง X-Twitter เรื่องละเมิดเครื่องหมายการค้าได้ไหม
    http://xchat.org/

    • มีความทรงจำว่าเคยเป็นผู้ใช้ IRC ในช่วงที่ย้ายจาก XChat ไป HexChat แต่ก็ตกใจเหมือนกันที่ได้ยินข่าวว่า HexChat เลิกพัฒนาแล้ว
      ข่าวการยุติ HexChat

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

  • สิ่งที่น่าสนใจเกี่ยวกับไลบรารีที่ Twitter ใช้ (ตามบทความต้นทาง) คือผู้พัฒนาเขียนไว้ในคำอธิบายไลบรารีเองเลยว่า
    "คำเตือน: ไลบรารีทดลอง! อย่านำสิ่งนี้ไปใช้ในโปรดักชันจนกว่าจะผ่านการตรวจสอบ มีความเสี่ยงและอาจมีบั๊กสูง"
    https://github.com/ionspin/kotlin-multiplatform-libsodium

    • ทำให้นึกถึงไม่ใช่นวัตกรรมทำลายล้าง แต่เป็นการเข้ารหัสแบบทำลายล้าง

  • อดทึ่งไม่ได้ว่าอำนาจของแบรนด์ Twitter แข็งแรงมากจนหลังรีแบรนด์แล้วก็ยังไม่หมดพลังชีวิต

    • ผู้เขียนอธิบายไว้ละเอียดในเชิงอรรถว่าทำไมถึงยังใช้ชื่อเดิม