วันนี้ SingLinkLabs ทีมผู้พัฒนา SingLinkVPN ได้เผยแพร่ซอร์สโค้ดทั้งหมดของ โปรโตคอล SingLink บน GitHub ภายใต้สัญญาอนุญาต Apache-2.0 ตั้งแต่นี้ไป ทุกคนสามารถอ่านข้อกำหนด รันโค้ด ตรวจสอบความปลอดภัย และนำไปต่อยอดได้

ตอนที่เราประกาศแผนโอเพนซอร์สของ SingLinkVPN เราบอกไว้ว่าจะทยอยเปิดเผยโปรโตคอล VPN และไคลเอนต์ VPN เป็นระยะ ๆ ครั้งนี้คือก้าวนั้น โปรโตคอลเปิดตัวพร้อมกับแอป SingLinkVPN ต้นแบบรุ่นแรกที่ทำงานบนโปรโตคอลนี้ อ่านเพิ่มเติมได้ที่ แอป SingLinkVPN ต้นแบบเปิดเป็นโอเพนซอร์สแล้ว

คลังโค้ด: SingLinkLabs / singlink-protocol · เวอร์ชัน: 1.0.0-draft (ชื่อบนสาย SingLink/1 ร่างข้อกำหนดฉบับที่ 2) · สัญญาอนุญาต: Apache-2.0 · ภาษา: Go ใช้เฉพาะไลบรารีมาตรฐาน

สิ่งที่เปิดเผยในครั้งนี้

  • ข้อกำหนด SPEC.md อธิบายรูปแบบข้อมูลบนสายแบบทีละไบต์ จึงสามารถนำโปรโตคอลไปพัฒนาใช้งานเองได้อย่างอิสระ

  • ไลบรารีโปรโตคอลที่เขียนด้วย Go ใช้เพียงการเข้ารหัสในไลบรารีมาตรฐานของ Go ไม่พึ่งพาไลบรารีของบุคคลที่สามเลย

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

  • พร็อกซีภายในเครื่องสำหรับแอป (SOCKS5 และ HTTP) และอินเทอร์เฟซไลบรารีภาษา C (libsinglink) เพื่อให้แอปบนทุกแพลตฟอร์มฝังโปรโตคอลนี้ได้

  • ตัวอย่างการติดตั้งใช้งาน: ไฟล์ตั้งค่าโหนดตัวอย่าง และไฟล์บริการ systemd ที่เสริมความปลอดภัยแล้ว

  • ผลการตรวจสอบความปลอดภัยภายใน พร้อมทุกข้อค้นพบและการแก้ไข: SECURITY-AUDIT.md

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

โปรโตคอล SingLink ที่เผยแพร่วันนี้ (เรียกว่าโปรโตคอลเปิด SingLink เมื่อต้องแยกให้ชัดจาก SingLink 2.0) เป็นโปรโตคอลแยกต่างหากที่ SingLinkLabs ออกแบบขึ้นใหม่ตั้งแต่ต้นเพื่อการพัฒนาแบบเปิด ปัจจุบันแอปอย่างเป็นทางการยังไม่ได้ใช้โปรโตคอลนี้ ผู้ใช้เดิมจึงไม่มีอะไรเปลี่ยนแปลง ทั้งแอป บัญชี และการเชื่อมต่อยังคงเหมือนเดิม

ทำไมเราจึงเปิดโอเพนซอร์ส

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

  • ยิ่งมีคนช่วยดู ยิ่งพบปัญหาเร็ว นักวิจัยและวิศวกรภายนอกจะเห็นปัญหาที่ทีมภายในมองข้ามไป

  • ผู้อื่นนำไปต่อยอดได้ นักพัฒนาสามารถทดสอบ ฝังไว้ในโปรเจกต์ของตนเอง และเสนอการปรับปรุงได้

  • เป็นไปตามแผนที่วางไว้ การเผยแพร่โปรโตคอลเป็นหนึ่งในขั้นตอนที่เราให้คำมั่นไว้

หลักการทำงานแบบเข้าใจง่าย

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

การออกแบบนี้ใช้คีย์สามชนิด ลองนึกภาพระบบรักษาความปลอดภัยของอาคารสำนักงาน:

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

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

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

เซิร์ฟเวอร์เพียงต้องรู้ว่าตราประทับหน้าตาเป็นอย่างไร ก็ตรวจบัตรผ่านได้ด้วยตัวเอง ด้วยเหตุนี้โหนดจึงไม่มีฐานข้อมูลผู้ใช้ และไม่เก็บข้อมูลผู้ใช้ใด ๆ

เกิดอะไรขึ้นในการเชื่อมต่อหนึ่งครั้ง

  1. แอปเปิดการเชื่อมต่อที่ดูเหมือนการเชื่อมต่อ HTTPS ธรรมดาไปยังเว็บไซต์แห่งหนึ่ง

  2. แพ็กเก็ตแรกบรรจุคีย์ใช้ครั้งเดียวสำหรับการเชื่อมต่อนี้ ข้อความเข้ารหัสแบบทนทานต่อควอนตัม และส่วนที่ปิดผนึกซึ่งมีปลายทาง บัตรผ่าน ข้อมูลจริงช่วงแรกสูงสุด 8 KB และลายเซ็นอุปกรณ์ที่ครอบคลุมคำขอทั้งหมด โดยไม่ต้องรับส่งข้อมูลไปกลับเพิ่ม

  3. เซิร์ฟเวอร์ตรวจสอบทุกอย่าง ทั้งการถอดรหัสคำขอได้ ตราประทับเป็นของจริง ลายเซ็นอุปกรณ์ตรงกัน เวลาถูกต้อง และคำขอไม่ใช่การส่งซ้ำ ไม่หมดอายุ และไม่ถูกเพิกถอน

  4. เซิร์ฟเวอร์จะตอบกลับและเริ่มส่งต่อข้อมูลก็ต่อเมื่อผ่านการตรวจสอบทุกข้อเท่านั้น หากข้อใดไม่ผ่าน การเชื่อมต่อจะถูกส่งต่อไปยังเว็บไซต์จริงโดยไม่มีการแตะต้อง ผู้ที่พยายามสอดแนมเซิร์ฟเวอร์จะเห็นเพียงเว็บไซต์ธรรมดา และไม่มีความแตกต่างด้านเวลาตอบสนอง

  5. ทั้งสองฝั่งนำคีย์ใช้ครั้งเดียวของตนมารวมกันเป็นคีย์เซสชันของการเชื่อมต่อนี้ ข้อมูลถูกเข้ารหัสเป็นชิ้น ๆ ชิ้นแรก ๆ จะมีการเติมข้อมูลเสริม และคีย์จะถูกเปลี่ยนใหม่โดยอัตโนมัติเมื่อใช้งานครบปริมาณที่กำหนด

คุณสมบัติด้านความปลอดภัย

  • การเข้ารหัสสองชั้น HTTPS ชั้นนอก บวกกับชั้น AES-256-GCM ของโปรโตคอลเองที่อยู่ด้านใน แม้แต่ CDN ที่ถอด HTTPS ก็มองไม่เห็นเนื้อหา

  • การป้องกันแบบทนทานต่อควอนตัม การแลกเปลี่ยนคีย์ใช้ X25519 แบบดั้งเดิมร่วมกับ ML-KEM-768 (FIPS 203) ผู้โจมตีต้องเจาะให้ได้ทั้งสองอย่าง

  • ความลับล่วงหน้า (Forward secrecy) ทุกการเชื่อมต่อใช้คีย์ใช้ครั้งเดียว แม้เซิร์ฟเวอร์จะถูกเจาะในภายหลัง ก็ไม่สามารถถอดรหัสทราฟฟิกในอดีตได้ ยกเว้นแพ็กเก็ตแรก (ดูข้อจำกัดด้านล่าง)

  • การผูกกับอุปกรณ์ บัตรผ่านที่ถูกคัดลอกไปจากที่ใดก็ตามจะใช้ไม่ได้ หากไม่มีคีย์ของอุปกรณ์ที่บัตรนั้นออกให้

  • การป้องกันการส่งซ้ำ การส่งแพ็กเก็ตที่ดักจับได้ซ้ำจะไม่ได้ผล แม้หลังจากรีสตาร์ตเซิร์ฟเวอร์แล้วก็ตาม

  • การต้านทานการสอดแนม คำขอที่หมดอายุ ถูกเพิกถอน ส่งซ้ำ หรือปลอมแปลง ล้วนได้รับการปฏิบัติเหมือนกัน คือถูกส่งต่อไปยังเว็บไซต์จริง

  • การควบคุมจากส่วนกลาง เมื่อบัญชีหรืออุปกรณ์ถูกเพิกถอน การเชื่อมต่อที่กำลังใช้งานอยู่บนทุกเซิร์ฟเวอร์จะถูกปิดภายในประมาณ 10 วินาที

  • เซิร์ฟเวอร์ที่เสริมความแข็งแกร่ง จำกัดจำนวนการเชื่อมต่อต่อเซิร์ฟเวอร์และต่อ IP กำหนดงบประมาณ CPU สำหรับการจับมือ และมีรายการบล็อกที่ครอบคลุมที่อยู่ส่วนตัวและที่อยู่สำหรับวัตถุประสงค์พิเศษทั้งหมด

แนวคิดมาจากไหน

โปรโตคอล SingLink เรียนรู้จากการออกแบบที่ได้รับการพิสูจน์มาแล้ว ได้แก่ การเชื่อมต่อด้วยคำขอเดียวจาก VLESS และ Trojan การส่งต่อการเชื่อมต่อที่ล้มเหลวไปยังเว็บไซต์จริงจาก Trojan และ obfs4 รูปแบบการจับมือ Noise NK การสร้างคีย์และการจัดการ 0-RTT จาก TLS 1.3 การแลกเปลี่ยนคีย์แบบไฮบริดที่ทนทานต่อควอนตัมจากร่างมาตรฐาน X-Wing การเข้ารหัสเป็นชิ้นจาก Shadowsocks AEAD โทเคนที่มีลายเซ็นจาก JWT และ PASETO โทเคนที่ผูกกับอุปกรณ์จาก OAuth DPoP, HAProxy PROXY protocol รวมถึงการป้องกันการส่งซ้ำและการรับมือภาระงานจาก WireGuard

ทั้งหมดนี้เป็นเพียงแนวคิดด้านการออกแบบ โค้ดทั้งหมดเขียนขึ้นใหม่ตั้งแต่ต้น ไม่มีโค้ดจาก Xray, V2Ray, sing-box หรือ WireGuard อยู่เลย

สถานะปัจจุบันและข้อจำกัดที่ทราบ

  • ยังเป็นฉบับร่าง เวอร์ชันคือ 1.0.0-draft และรูปแบบข้อมูลบนสายยังอาจเปลี่ยนแปลงได้

  • ผ่านเพียงการตรวจสอบความปลอดภัยภายในเท่านั้น ผู้ตรวจสอบสองคนตรวจการออกแบบด้านการเข้ารหัสและการพัฒนาโค้ดแยกกัน และบันทึกข้อค้นพบไว้ 31 รายการ: ระดับ High 2 รายการ ระดับ Medium 14 รายการ ที่เหลือเป็นระดับ Low หรือเชิงข้อมูล ไม่มีรายการใดที่ทำลายความลับหรือการยืนยันตัวตนของทราฟฟิกผู้ใช้ได้ ข้อค้นพบระดับ High และ Medium ทั้งหมดได้รับการแก้ไขหรือบรรเทาแล้ว แต่ละรายการมีการทดสอบถดถอยรองรับ และตัวแยกวิเคราะห์ทุกตัวผ่านการทดสอบแบบ fuzz

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

  • แพ็กเก็ตแรกไม่มีความลับล่วงหน้า แพ็กเก็ตนี้ได้รับการปกป้องด้วยคีย์ระยะยาวของเซิร์ฟเวอร์ จึงควรหมุนเวียนคีย์เซิร์ฟเวอร์อย่างสม่ำเสมอ ซึ่งโปรโตคอลรองรับการหมุนเวียนคีย์

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

  • เซิร์ฟเวอร์ต้องมีโดเมนของตัวเอง ใบรับรองที่เบราว์เซอร์ยอมรับ และเว็บไซต์จริงที่อยู่เบื้องหลัง

ลองใช้และร่วมพัฒนา

เมื่อมี Go 1.24 ขึ้นไป make test จะรันชุดทดสอบ make cli จะสร้างเครื่องมือบรรทัดคำสั่ง และ singlink demo จะเริ่มเซิร์ฟเวอร์และไคลเอนต์ภายในบนเครื่องเดียว ไฟล์ README ในคลังโค้ดอธิบายวิธีรันเซิร์ฟเวอร์

เรายินดีรับคำถาม รายงานข้อบกพร่อง และ Pull Request บน GitHub โปรดรายงานช่องโหว่ด้านความปลอดภัยแบบส่วนตัว ไม่ใช่ใน Issue สาธารณะ ขั้นตอนอยู่ใน SECURITY.md

สัญญาอนุญาตและเครื่องหมายการค้า

โค้ดใช้สัญญาอนุญาต Apache-2.0: คุณสามารถใช้ แก้ไข และแจกจ่ายต่อได้ รวมถึงเพื่อการค้า ภายใต้เงื่อนไขของสัญญาอนุญาต ชื่อ "SingLink" และ "SingLinkVPN" รวมถึงโลโก้ เป็นเครื่องหมายการค้าของ SingLinkLabs และสัญญาอนุญาตไม่ได้ให้สิทธิ์ใช้สิ่งเหล่านี้เกินกว่าการระบุที่มาของงาน เวอร์ชันที่แก้ไขและ fork ควรเผยแพร่ภายใต้ชื่อและไอคอนของตนเอง

อ่านเพิ่มเติม