بروتوكول SingLink أصبح مفتوح المصدر

نشرت 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.

SingLink 2.0 وبروتوكول SingLink المفتوح بروتوكولان مختلفان

تعمل تطبيقات 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). وعلى المهاجم أن يكسر الاثنين معًا.
• السرية الأمامية. يستخدم كل اتصال مفاتيح لمرة واحدة، فلا يستطيع خادم يُخترق لاحقًا فك تشفير الحركة السابقة. والاستثناء هو الحزمة الأولى (راجع القيود أدناه).
• ربط الجهاز. تصريح الوصول المنسوخ من أي مكان عديم الفائدة دون مفتاح الجهاز الذي صدر له.
• الحماية من إعادة الإرسال. إعادة إرسال حزمة ملتقطة لا تنجح، حتى بعد إعادة تشغيل الخادم.
• مقاومة الاستطلاع. الطلبات المنتهية الصلاحية أو المُلغاة أو المُعاد إرسالها أو المزوّرة تُعامَل جميعها بالطريقة نفسها: تُسلَّم إلى الموقع الحقيقي.
• تحكم مركزي. عند إلغاء حساب أو جهاز، تُغلق اتصالاته النشطة على كل الخوادم خلال 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 ملاحظة: 2 عالية الخطورة، و14 متوسطة، والباقي منخفضة أو إعلامية. لم تكسر أي منها سرية حركة المستخدمين أو المصادقة عليها. أُصلحت جميع الملاحظات العالية والمتوسطة أو خُففت، ولكل منها اختبار انحدار، وكل محلّل مغطّى باختبارات 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، ولا تمنح الرخصة إذنًا باستخدامها لأكثر من بيان مصدر العمل. ويجب نشر النسخ المعدّلة والنسخ المشتقة (forks) باسمها وأيقونتها الخاصين.

قراءات إضافية

• النموذج الأولي لتطبيق SingLinkVPN أصبح مفتوح المصدر — وشيفرته على GitHub
• مشاريع SingLinkLabs مفتوحة المصدر
• الورقة البيضاء التقنية لـ SingLink 2.0، البروتوكول الإنتاجي للتطبيقات الرسمية