โครงการ Tor กำลังเปลี่ยนผ่านไปสู่ Rust

 (itsfoss.com)
4 คะแนน โดย GN⁺ 2025-12-14 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • โค้ดแกนหลักของเครือข่าย Tor กำลังเปลี่ยนจากภาษา C เดิมไปเป็น Arti ที่พัฒนาบน Rust
  • โค้ด C เดิมมีช่องโหว่ เช่น buffer overflow, use-after-free และ memory corruption
  • เวอร์ชันใหม่ Arti 1.8.0 ได้ ออกแบบ circuit timeout ใหม่ เพื่อลบรูปแบบที่คาดเดาได้และลดความเสี่ยงจากการติดตาม
  • มีการเพิ่มคำสั่งใหม่ที่ช่วยให้ ผู้ดูแล onion service สามารถ ย้ายคีย์โดยอัตโนมัติ จาก Tor ที่พัฒนาด้วย C ไปยัง Arti ได้
  • การเปลี่ยนผ่านครั้งนี้ถือเป็นความก้าวหน้าทางเทคนิคสำคัญของโครงการ Tor เพื่อ ยกระดับความปลอดภัยและความเสถียร

การเปลี่ยนแปลงสำคัญใน Arti 1.8.0

  • หัวใจสำคัญของรีลีสนี้คือการนำ การปรับปรุง circuit timeout ใหม่ (circuit timeout rework) มาใช้

    • Circuit Dirty Timeout (CDT) ของ Tor เดิมควบคุมช่วงเวลาปิดวงจรด้วยตัวจับเวลาเพียงตัวเดียว
    • วิธีนี้คาดเดาได้ ทำให้ผู้สังเกตการณ์ทราฟฟิกสามารถระบุรูปแบบได้
    • Arti 1.8.0 ได้นำ timeout ตามการใช้งานและตัวจับเวลาแยกเป็นรายวงจร มาใช้ ทำให้วงจรถูกปิด ในช่วงเวลาสุ่ม เมื่อรับการเชื่อมต่อใหม่หรืออยู่ในสถานะ idle
    • ช่วยลดความเสี่ยงจาก การทำ fingerprinting

  • เพิ่ม คำสั่งทดลอง arti hsc ctor-migrate ใหม่

    • ผู้ดูแล onion service สามารถย้าย restricted discovery keys จาก Tor ที่พัฒนาด้วย C ไปยัง keystore ของ Arti ได้
    • คีย์เหล่านี้ใช้สำหรับ การยืนยันตัวตนของไคลเอนต์ และคำสั่งใหม่นี้รองรับการย้ายอัตโนมัติโดยไม่ต้องทำงานด้วยตนเอง

  • การปรับปรุงเพิ่มเติม

    • มีการปรับปรุงองค์ประกอบภายในหลายส่วน เช่น สถาปัตยกรรมการกำหนดเส้นทาง, การอิมพลีเมนต์โปรโตคอล, การรองรับ directory cache และ การตั้งค่า OR port listener
    • รายละเอียดการเปลี่ยนแปลงเพิ่มเติมดูได้จาก บันทึกการเปลี่ยนแปลงอย่างเป็นทางการ ของ Arti 1.8.0

เบื้องหลังของการเปลี่ยนผ่านสู่ Rust

  • เครือข่าย Tor ดำเนินงานบนพื้นฐานของ ภาษา C มาตั้งแต่ช่วงต้นทศวรรษ 2000
  • อย่างไรก็ตาม โค้ดเบสภาษา C มี ปัญหาด้าน memory safety ทำให้เกิดช่องโหว่ด้านความปลอดภัยอย่างต่อเนื่อง
  • ด้วยเหตุนี้ โครงการ Tor จึงกำลังผลักดัน โครงการเขียนใหม่ Arti โดยใช้ memory safety ของ Rust
  • Arti คือการนำความสามารถของ Tor มาเขียนใหม่ด้วย Rust โดยมีเป้าหมายเพื่อเสริม ความปลอดภัย ความเสถียร และการบำรุงรักษา

นัยสำคัญทางเทคนิค

  • การเปลี่ยนผ่านสู่ Rust เป็นทิศทางที่ช่วย เสริมโครงสร้างการรักษาความไม่ระบุตัวตนของ Tor ให้แข็งแกร่งยิ่งขึ้นในระดับพื้นฐาน
  • การลบพฤติกรรมของวงจรที่คาดเดาได้และการทำให้การจัดการคีย์เป็นอัตโนมัติ ช่วย ยกระดับการปกป้องความเป็นส่วนตัวของผู้ใช้
  • การอัปเดตอย่างต่อเนื่องของ Arti ถูกมองว่าเป็นสัญญาณที่เร่ง การแทนที่ Tor ที่พัฒนาด้วย C แบบค่อยเป็นค่อยไป

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

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

 
GN⁺ 2025-12-14
ความคิดเห็นบน Hacker News

  • เมื่อเร็ว ๆ นี้ลองทดสอบ EFF's Cover Your Tracks แล้วพบว่า มีเพียง Tor Browser ที่ปิด JS เท่านั้นที่ต้านทานการทำฟิงเกอร์พรินต์ได้อย่างสมบูรณ์
    แม้แต่ Tor ที่เปิด JS ก็ยังถูกประเมินว่าต้านทานได้แค่ ‘บางส่วน’ ส่วน Firefox นั้นถึงจะปิด JS ก็ยังได้ผลลัพธ์ที่ไม่ดีนัก เป็นผลที่ค่อนข้างน่ากลัวเลยอยากรู้ว่าคนอื่นทดลองแล้วได้ผลอย่างไรบ้าง

    • เครื่องมือนี้มี ข้อบกพร่องในวิธีวัดการป้องกันฟิงเกอร์พรินต์ มันให้คะแนนการป้องกันแบบสุ่มต่ำเกินไป และให้คะแนนสูงเฉพาะวิธีแบบ binning เท่านั้น
      ในทางกลับกัน เครื่องมือที่ทดสอบแค่ความคงอยู่ของฟิงเกอร์พรินต์อย่าง fingerprinting.com/demo ก็มีปัญหาเช่นกัน
      สัญญาณอันตรายที่แท้จริงคือกรณีที่ไม่ผ่านทั้งสองการทดสอบ
    • ตอนทดสอบด้วย Safari บน macOS ได้ผลว่า “มีการป้องกันการติดตามบนเว็บที่แข็งแกร่ง”
      แต่ถึงแม้ Tor Browser จะสังเกตเห็นได้ชัดเจน ก็ยังยากจะสรุปจากการทดสอบนี้เพียงอย่างเดียวว่า การแยกแยะฟิงเกอร์พรินต์ ระหว่างผู้ใช้ Tor ทำได้ง่าย
    • Tor Browser พยายามขยาย bucket ของฟิงเกอร์พรินต์ด้วยวิธีอย่าง การปัดขนาด canvas สุดท้าย bucket ที่กว้างที่สุดและหลีกเลี่ยงไม่ได้ก็คือ “ผู้ใช้ Tor” เอง
    • เมื่อทดสอบบน Debian ด้วย Tor Browser ค่าเริ่มต้น พบข้อมูลระบุตัวตน 8.24 บิต
      ยิ่งเพิ่มระดับความปลอดภัย จำนวนบิตที่ใช้ระบุตัวตนกลับยิ่งเพิ่มขึ้น แต่พอปิด JS ทั้งหมดแล้วจึงลดลงอีกครั้ง
      กล่าวคือ การปิด JS ให้ความไม่ระบุตัวตนสูงสุด

  • น่าเสียดายที่ Mozilla ไม่ได้เดินหน้าการ เปลี่ยนผ่านสู่ Rust (oxidizing) ของ Firefox ต่อให้มากกว่านี้ เพราะน่าจะส่งผลดีต่อ ecosystem ของ Rust ด้วย

    • อย่างน้อยทีม Chrome ก็ยังคงเดินหน้าการนำ Rust มาใช้ต่อไป
    • แม้ว่า Mozilla จะปลดนักพัฒนา Rust ออกเป็นจำนวนมาก แต่สัดส่วน โค้ด Rust ใน Firefox ก็เพิ่มขึ้นเป็นมากกว่า 12% แล้ว ขณะที่ Chromium ยังต่ำกว่า 4% จึงถือว่าน้อยกว่าอย่างชัดเจน
      ถ้า Rust ยังคงเป็น ‘อาวุธลับ’ ของ Mozilla ต่อไป บางทีการแพร่หลายของ Rust อาจกลับยิ่งช้าลงก็ได้
    • ความล้มเหลวของโครงการ Servo ไม่น่าใช่ปัญหาของ Rust แต่เป็นข้อจำกัดภายในของ Mozilla เองมากกว่า

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

    • หลายครั้งเรื่องอย่าง การปรับ dependency ให้เหมาะสมหรือการปรับปรุงประสิทธิภาพ น่าสนใจกว่า “การเปลี่ยนภาษา” แบบนี้
    • บล็อกต้นฉบับไม่ได้โจมตี C ดังนั้นจึงไม่คิดว่าจำเป็นต้องยกเรื่องนั้นขึ้นมา
    • การที่ภาษาแบบ memory-safe เหนือกว่าทางเทคนิคในด้านความปลอดภัย เป็นเรื่องชัดเจนอยู่แล้ว
      นี่ไม่ใช่คำอวยของแฟนบอย Rust แต่คล้ายกับแรงต้านในยุคที่แพทย์หรือนักบินไม่ยอมรับ checklist มากกว่า
    • Rust เหมาะกับกรณีนี้ แต่ไม่เหมาะกับ โปรเจกต์ UI ส่วนใหญ่
      งาน UI ต้องการการวนซ้ำที่รวดเร็วและ GC สำคัญกว่า ขณะที่ประสิทธิภาพไม่ใช่เรื่องหลัก หากเขียน UI ด้วย Rust ก็อาจกลายเป็นนรกของการดูแลรักษาได้
    • ฉันไม่ชอบแนวคิดแบบ “เขียนทุกอย่างใหม่ด้วย Rust” แต่ในกรณีของ Tor นั้น Rust คือเครื่องมือที่เหมาะสม
      เพราะ Tor เป็น สภาพแวดล้อมมัลติเธรดที่ทั้งความปลอดภัยและประสิทธิภาพสำคัญพอ ๆ กัน
      Zig อาจเป็นทางเลือกได้เช่นกัน แต่ยังไม่ mature พอ แนวทางที่ให้ความสำคัญกับ determinism แบบ Tigerbeetle ก็น่าสนใจ

  • ข้อบ่นใหญ่ที่สุดเกี่ยวกับ Tor คือ ความช้า การย้ายไป Rust ไม่น่าจะทำให้มันเร็วขึ้น

    • Onion routing มี trade-off ระหว่างความเป็นส่วนตัวกับประสิทธิภาพ อยู่แล้ว ต้นเหตุหลักมาจาก network latency
    • ความช้าของ Tor เกิดจาก จำนวนโหนดที่ไม่เพียงพอ มากกว่าตัวโค้ด เวอร์ชันใหม่จะปลอดภัยขึ้น แต่ไม่ได้เร็วขึ้น
    • โครงสร้างของมันทำให้ทราฟฟิกวิ่งรอบโลกสองรอบ จึงเกิดความหน่วงทางกายภาพอย่างหลีกเลี่ยงไม่ได้ สุดท้ายก็ชนกับ ขีดจำกัดความเร็วแสง
    • Tor มีไว้ เพื่อรับประกันความไม่ระบุตัวตน ไม่ได้มีไว้สำหรับสตรีมวิดีโอ
    • การสร้างเครือข่ายไม่ระบุตัวตนที่ทั้งเร็วและดีนั้นยากมาก ถึงอย่างนั้น Tor ในช่วงหลังก็เร็วขึ้นกว่าแต่ก่อนมาก และถ้าใช้งาน ภายใน onion เท่านั้น ก็จะยิ่งได้ความไม่ระบุตัวตนสูงขึ้น

  • การเปลี่ยนผ่านสู่ Rust ครั้งนี้เกิดขึ้นได้ด้วยการสนับสนุนจาก Zcash Community Grants แสดงให้เห็นว่าแม้แต่งาน R&D ในวงการคริปโตก็อาจให้ผลลัพธ์ที่ดีได้

    • จึงนึกถึงวลี “Pecunia non olet (เงินไม่มีกลิ่น)” ในความหมายที่ว่าเงินก็คือเงิน
      แม้จะมีการแซวต่อว่าคริปโตอาจแย่กว่าปัสสาวะเสียอีก

  • เวลารัน exit node ของ Tor ก็อดกังวลเรื่องความเสี่ยงทางกฎหมายไม่ได้ เลยสงสัยว่ามีวิธีจำกัดให้อนุญาตเฉพาะแบบ whitelist ได้หรือไม่

    • ลองดู คู่มือการรัน exit node จากบล็อกทางการของ Tor
      หากเป็นไปได้ แนะนำให้ จดทะเบียนในนามองค์กร และถ้าอยากช่วยแบบปลอดภัยกว่า การรัน relay จะดีกว่า
    • ถ้าอยากหลีกเลี่ยงการถูกจับตาทางกฎหมาย การรัน bridge ก็เป็นอีกทางเลือก
      หรือจะรัน guard/middle relay ก็ช่วยเครือข่ายได้มากเช่นกัน
    • แม้ exit node จะจัดการยาก แต่ก็ยังช่วยบริจาคแบนด์วิดท์ได้ด้วยการโฮสต์ Linux ISO torrent หรือเซิร์ฟเวอร์ tile ของ OpenMap
      เพียงแต่ต้องบล็อก ASN บางส่วนของจีน เพราะมีทราฟฟิกดาวน์โหลดปลอมจำนวนมาก

  • การนำ Rust มาใช้ก็เหมือน การเปลี่ยนเสาไม้ของป้อมปราการเก่าเป็นเหล็กทีละต้น
    โค้ด C ของ Tor สะสมทั้งร่องรอยของการประนีประนอมด้านความปลอดภัยและการปรับแต่งประสิทธิภาพมานานหลายสิบปี ดังนั้นการค่อย ๆ เปลี่ยนเป็น Rust จึงเป็นวิธีที่สมจริงที่สุดในการเพิ่มความปลอดภัย
    แก่นสำคัญไม่ใช่ “เขียนใหม่ทั้งหมด” แต่คือ การลดพื้นที่ที่ยังไม่ memory-safe
    หากย้ายเฉพาะส่วน parsing, cryptography และขอบเขตของโปรโตคอลที่มีความเสี่ยงสูงไปเป็น Rust ได้ Tor ก็จะแข็งแกร่งขึ้นมาก
    อีกจุดที่น่าสนใจคืออนาคตอาจพัฒนาไปสู่ plugin transport ที่เขียนด้วย Rust หรือ hybrid runtime

  • จริง ๆ แล้วการตัดสินใจนี้ไม่ใช่เรื่องใหม่ Tor เริ่มโครงการ Arti ที่ใช้ Rust มาตั้งแต่ปี 2020 และประกาศ Arti 1.0 ในปี 2022
    พวกเขามองว่าการรีแฟกเตอร์ codebase ฝั่ง C แบบค่อยเป็นค่อยไปทำได้ยาก และพอใจกับ ความเร็วในการพัฒนา ความสามารถในการพกพาข้ามแพลตฟอร์ม และการดึงดูดผู้ร่วมพัฒนา ของ Rust
    แม้แต่ตอนนี้ จาก Arti changelog ก็ยังเห็นได้ว่ามีการพัฒนาอย่างต่อเนื่อง

    • Arti ถูกออกแบบมาให้ ฝังเป็นไลบรารีในแอปอื่นได้
      ตัวอย่างเช่น แอปส่งข้อความสามารถใช้งานเครือข่ายนี้ได้โดยไม่ต้องมี Tor daemon แยกต่างหาก ซึ่งอาจเป็นการเปลี่ยนแปลงที่ใหญ่กว่าด้วยซ้ำ
    • ก็มีความเห็นว่าพาดหัวนี้ค่อนข้างเกินจริง เพราะทีม Tor ดำเนินการเรื่องนี้อย่างระมัดระวังมานานแล้ว
    • ลิงก์นี้เป็นข้อมูลอ้างอิงที่ดีกว่าต้นฉบับมาก และแสดงกลยุทธ์ได้ชัดเจนพอจะตัดบทถกเถียงแนว “ทำไมต้อง Rust” ได้ล่วงหน้า
    • มีคนตั้งคำถามด้วยว่า Rust มี ความสามารถในการพกพาข้ามระบบปฏิบัติการ ดีกว่า C จริงหรือไม่

  • Tor ไม่ได้เป็นแค่แนวคิด แต่เป็นชื่อที่ครอบคลุมทั้ง โปรโตคอล (onion routing), เครือข่าย และ reference implementation

    • Onion routing คือโปรโตคอล ส่วน Tor คือเครือข่ายและ implementation บนโปรโตคอลนั้น
    • Tor เป็น ผลิตภัณฑ์ ที่ดาวน์โหลดมาใช้งานได้จริง และประกอบด้วยหลายส่วน
    • ดังนั้นคำว่า “เขียน Tor ใหม่ด้วย Rust” ก็ไม่ได้ถือว่าผิดนัก

  • มีข้อเสนอเชิงขำ ๆ ว่า ถ้า คอมไพล์ Tor ด้วย Fil-C ก็น่าจะได้ความปลอดภัยของหน่วยความจำมาแบบฟรี ๆ

    • แต่การเปลี่ยนผ่านนี้เป็นโครงการที่เริ่ม ก่อน Fil-C จะปรากฏตัว เสียอีก