Ricochet: عمليات نقل الملفات

واو ، هذه قضية قديمة. حان الوقت لإنجاز ذلك. لنتحدث عن عمليات نقل الملفات. هذا يتطلب ردود فعل جزئية ، وجزئيًا يحاول إقناع نفسي ، وجزئيًا عقليًا ، ولكن آمل أن يكون مفيدًا.

تجربة المستخدم

أرى نوعين عريضين من حالات الاستخدام لنقل الملفات. يقوم المستخدمون النشطون بإرسال واستقبال الملفات أثناء المحادثات ، ويتوقعون أن يكون الملف جزءًا من محادثتهم. قطرات الملفات مخصصة لأقلية مهمة من مستخدمي Ricochet الذين يرغبون في البقاء على الإنترنت والقدرة على تلقي الملفات في أي وقت ، حتى لو لم يكونوا نشطين على الفور.

مثل معظم تطبيقات المراسلة ، نريد إجراء عمليات نقل الملفات بشكل مضمّن كجزء من المحادثة ، ويجب ألا تتطلب استخدام أي تطبيق آخر (بما في ذلك المستعرض).

يعد سحب ملف في مربع العد التنازلي قبل الإرسال . يجب أن تكون هناك واجهة مستخدم مرئية أخرى لإرسال الملفات ، مثل زر في رأس المحادثة أو بالقرب من إدخال الرسالة.

يجب أن تنتهي صلاحية الملفات المعروضة بعد وقت كافٍ للافتراض بشكل معقول أن المستخدم قد نسيها.

يحظر نموذج التهديد الخاص بـ Ricochet تخزين بيانات المحادثة (بما في ذلك الملفات) تلقائيًا. يرى نموذج التهديد أيضًا جهات الاتصال على أنها خصوم محتملون للاستغلال ، لذلك نريد تقليل مجموعة الإجراءات التي يمكن لجهة اتصال إطلاقها دون موافقة المستخدم. تشير هذه إلى أننا يجب أن نطلب قبولًا صريحًا بشكل افتراضي لعمليات نقل الملفات. يتعين على المستخدم أن يختار صراحة مكان حفظ كل ملف ، ما لم يقم بتهيئة الموقع الافتراضي. هذا جيد مع حالة استخدام المستخدم النشط ، ولكن بالنسبة لعمليات إسقاط الملفات ، سنحتاج إلى خيار لحفظ الملفات تلقائيًا (والذي يمكن أن يكون أيضًا لكل جهة اتصال).

يجب أن تكون العروض أو التحويلات النشطة ملحوظة بسهولة لكلا الطرفين. بالإضافة إلى إظهار التقدم في النقل في المحادثة ، يجب أن يكون هناك تقدم في رأس المحادثة (علامة تبويب عمليات النقل؟) و / أو حالة النقل العام في مكان ما. هذا مهم بشكل خاص لأن المحادثة قد تستمر أثناء عمليات النقل جارية. عند انتهاء النقل ، يجب نقله إلى نهاية المحادثة.

يتم فتح عمليات النقل المكتملة

من المعروف أن Tor غير موثوق به ، لذا فإن القدرة على الاستئناف ستكون مهمة. يجب علينا إعادة الاتصال والاستئناف تلقائيًا كلما أمكن ذلك. إذا مر وقت طويل ، أو فقد أحد العملاء سجله ، فلا يزال من الممكن استئنافه عن طريق الحفظ على ملف موجود غير مكتمل .

تجربة المستخدم المستقبلية

يعد عرض الصور المضمنة مع المحادثات ميزة قياسية في المراسلة. من السهل القيام بذلك بمجرد أن يكون لدينا نقل الملفات في مكانه الصحيح ، باستثناء أنني لا أثق في أجهزة فك ترميز الصور . بمجرد أن نجد وحدة فك ترميز قوية وآمنة للذاكرة ، أو صندوق حماية على غرار seccomp عبر الأنظمة الأساسية ، فإن هذا يستحق القيام به.

أشار أحدهم إلى أنه يمكننا الجلب المسبق للملفات ، على الأقل عن طريق بناء اتصالات والتخزين المؤقت حتى حد معين من الذاكرة ، لجعل عملية النقل تبدو أسرع.

سيكون من الجيد السماح بنقل مجموعات من الملفات أو مجلدات كاملة حتى حد معقول.

سيكون وجود طريقة للتحقق تلقائيًا

بروتوكول

روابط

لا يمكن إرسال بيانات الملف عبر اتصال بروتوكول Ricochet الأساسي. على الرغم من أننا نجمع البيانات في حزم ، نظرًا لخصائص التخزين المؤقت لتدفقات Tor ، فإن كميات كبيرة جدًا من البيانات ستكون في قوائم الانتظار عند إغراق اتصال خدمة مخفي. يؤدي هذا إلى وقت استجابة شديد (غالبًا 30 ثانية أو أكثر) لهذا البث. أي شكل آخر من أشكال التحكم في الأسعار سيكون له تأثير كبير على سرعات النقل.

الجواب البسيط هو فتح اتصالات إضافية لخدمة الزميل. سيتم مضاعفة هذه الاتصالات بواسطة Tor على نفس الدائرة ، لكن سلوك التخزين المؤقت أفضل بكثير. في الاختبار العرضي ، يبدو أنه لا يوجد تأثير كبير على زمن انتقال الرسالة عند إغراق البيانات بتدفق آخر على نفس الدائرة.

يمكننا أيضًا استخدام خيارات عزل الدائرة لإجبار Tor على بناء دوائر جديدة لعمليات النقل. من غير الواضح ما إذا كان هذا سيكون مفيدًا للإنتاجية أو زمن الوصول ، وليس من الواضح ما إذا كان بناء دوائر إضافية متزامنة سيكون له تأثيرات كبيرة على إخفاء الهوية أو تحليل حركة المرور.

لا يسمح بروتوكول Ricochet بأكثر من اتصال مصدق واحد لكل جهة اتصال ، لأنه سيكون غامضًا بشأن الاتصال الذي يجب استخدامه ويمكن أن ينتهك التوقعات بشأن ترتيب الرسائل. إذا كانت الاتصالات الإضافية تستخدم بروتوكول Ricochet ، فستحتاج إلى المصادقة بشكل مختلف للإشارة إلى أن الاتصال يستخدم فقط لنقل البيانات.

نظرًا لأن نقل البيانات يحدث عبر اتصالات ثانوية ، فإننا لسنا مطالبين بحزم البيانات باستخدام بروتوكول Ricochet. يجدر التفكير في الخيارات هنا.

الخيار 1: تعديل بروتوكول Ricochet

كان تفكيري الأصلي هو استخدام بروتوكول Ricochet لنقل بيانات الملفات على اتصالات إضافية. هذا ليس واضحًا تمامًا.

فوائد:

• يمكن بسهولة إرسال ملفات صغيرة مضمنة عبر اتصال البروتوكول
• أكثر اتساقا مع البروتوكول الحالي
• لا توجد أسطح هجوم محلل / خادم جديد

سلبيات:

• يمكن أن يكون هناك اتصال أساسي واحد فقط ، لذلك ينتهي الأمر بالمصادقة إلى أن تكون غريبة
• ما لم نقم بإجراء تعديلات أعمق على البروتوكول ، يجب تقسيم البيانات إلى أجزاء بحد أقصى 65 كيلو بايت مع الرؤوس
• يصعب الحصول على تصميم البروتوكول وتنفيذه بالشكل الصحيح

هناك بعض الأعمال القديمة حول الشكل الذي يمكن أن يبدو عليه هذا من فرع ويب في FileTransferChannel.proto و FileTransferDataChannel.proto .

الخيار 2: HTTP (تفضيلي الحالي)

يمكن لعملاء Ricochet تقديم ملفات عبر HTTP ، باستخدام خادم داخلي بسيط وعناوين URL فريدة ، على غرار OnionShare . يمكن أن يكون هذا الخادم على منفذ مختلف (ربما عشوائيًا) للخدمة المخفية نفسها ، أو على خدمات مؤقتة جديدة ، أو حتى مشاركة نفس المنفذ باستخدام اكتشاف البروتوكول.

فوائد:

• تنفيذ أكثر قوة / قياسي / مقاوم للمستقبل
• توافق المستلم مع الإصدارات السابقة: يمكن أن يتراجع بشكل طبيعي إلى عرض عنوان URL
• يمكن للمستلمين التنزيل باستخدام المتصفحات والأدوات الأخرى
• يمكن استخدامها لتقديم الملفات لغير جهات الاتصال أيضًا

سلبيات:

• حتى الحد الأدنى من عميل وخادم HTTP يمثلان سطح هجوم بروتوكول جديد لجهات الاتصال
• من غير الواضح ما هو تنفيذ C ++ / Qt الذي سيكون آمنًا بدرجة كافية للاستخدام

تنفيذ الخادم / العميل

ليست هناك حاجة إلى عميل HTTP كامل الميزات ومتوافق مع سلوك المواصفات في Ricochet ، لأن حالة الاستخدام هنا ضئيلة للغاية. للحفاظ على احتمالية حدوث أخطاء منخفضة قدر الإمكان ، سأقصر التنفيذ على الميزات التي نحتاجها ، ولا نستخدم (على سبيل المثال) ترميز النقل المقسم أو خيارات مقصورة على فئة معينة. يمكننا حتى فرض Connection: close إذا كان ذلك مفيدًا. ينتهي هذا الأمر بكونه مقدارًا صغيرًا جدًا من التعليمات البرمجية المكشوفة للشبكة ، ولا يزال متوافقًا بشكل عام مع العملاء والخوادم الأخرى.

سلوك الخادم وتنسيق URL

أنا أفضل وضع خادم HTTP على منفذ عشوائي تحت نفس الخدمة المخفية. أحيانًا يكون طرح خدمات جديدة بطيئًا أو غير موثوق به ، ويتضمن العديد من الدوائر الجديدة ونشاط الشبكة المميز. هذا يعني أيضًا أنه يمكننا طلب نفس اسم مضيف .onion ، مما يمنع الأقران من القدرة على فرض اتصال بـ .onion تعسفي.

إذا كان الخادم يعمل دائمًا ، فمن الممكن لجهات الاتصال وغير جهات الاتصال العثور عليها في أي وقت ، على الرغم من أن هذا لا ينبغي أن يكون ذا قيمة. إذا كان الخادم نشطًا فقط عندما تكون هناك عروض ملفات نشطة ، فقد تكون هذه الحالة قابلة للاكتشاف لجهات الاتصال أو غير جهات الاتصال الذين يمكنهم معرفة المنفذ.

ليست هناك فائدة أو حاجة لمحاولة التنكر في مثل أي شيء آخر غير عميل Ricochet. يجب رفض جميع الطلبات المنسقة جيدًا والتي لا تعد طلبات ملفات صالحة مع ظهور خطأ 404 عام.

أقترح ما يلي لتنزيل عناوين URL:

http://[address].onion:[port]/ricochet/fetch/[uniqid]/[filename]

[address] must be the contact's ricochet connection address
[uniqid] is a large (>=128bit) random identifier
[filename] is the URL-encoded original name of the file

Only HTTP is permitted, no HTTPS. We do not want to require a TLS
implementation, and .onion makes it unnecessary.

Clients may refuse transfer URLs without a /ricochet/fetch/ prefix.

ترتبط عناوين URL الخاصة بالملفات بنقل معين وهي مخصصة للاستخدام مرة واحدة. يجب دعم طلبات النطاق للسماح بالاستئناف ، وقد يُسمح لها بالتنزيل المتوازي. يجب أن تتوقف الخوادم عن تقديم عنوان URL بمجرد أن تعتقد أن المستلم لديه نسخة كاملة.

بروتوكول عرض الملف

يمكننا تجميع عرض ملف في رسالة محادثة موسعة:

message ChatMessage {
    required string message_text = 1;
    optional uint32 message_id = 2;
    optional int64 time_delta = 3;

    // Indicates a file transfer offer. message_text must begin with a valid
    // file transfer URL, terminated by the first whitespace or end of message.
    // The rest of message_text, if any, should be displayed as a user message
    // along with the file. 
    optional FileInfo file_info = 4;
}

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

message ChatAcknowledge {
    optional uint32 message_id = 1;
    optional bool accepted = 2 [default = true];
    optional bool file_received = 3;
    optional bool file_refused = 4;
}

يقر الإقرار بهذه الرسالة أيضًا بعرض الملف. يمكن الوصول إلى عنوان URL على الفور لتنزيل الملف. بالإضافة إلى الإقرار بالرسالة بشكل طبيعي ، يجب على المستلم إرسال مبلغ إضافي ChatAcknowledge عند اكتمال النقل أو في حالة رفضه ، مع مجموعة الحقول المناسبة. يجب أن يكون المرسلون مستعدين للنظر في عملية النقل المكتملة بناءً على البيانات المنقولة فقط وعدم الاعتماد على ChatAcknowledge ، لدعم العملاء الأكبر سنًا أو برامج التنزيل البديلة.

هذا له خاصية أنيقة لكونه متوافقًا تمامًا مع العملاء الذين لا ينفذون عمليات نقل الملفات ؛ سيرى المستخدم عنوان URL ويمكنه تنزيله في المتصفح. هذا ليس له معنى بشكل خاص.

XXX لا توجد طريقة محددة هنا للمرسل للإشارة إلى الإلغاء

الخطوات التالية

أرغب في المضي قدمًا في هذا بسرعة كبيرة ، لذلك سأهدف إلى توضيح البروتوكول وقرارات تجربة المستخدم الرئيسية قريبًا جدًا.

يوجد بالفعل جزء كبير من التعليمات البرمجية المكتوبة ، ولكنها تحتاج إلى بعض الإصلاح وستحتاج إلى تغييرات بناءً على القرارات هنا.

أي أفكار؟

هذا يبدو جيدا بالنسبة لي. أوافق على أن اتجاه خادم HTTP يبدو أنه الاتجاه الصحيح.

زوجان من الأفكار - بدون ترتيب معين أو أولوية:

• بدون مصادقة العميل على التنزيل ، هل هناك أي موجهات هجوم جديرة بالملاحظة؟ لا يمكنني التفكير في أي شيء قد يكون حاسمًا لنموذج التهديد ... ولكن للتسجيل ، إليك بعض الأشياء التي خطرت في بالي:
  
  
  
  • هل هناك احتمال لوقوع هجوم من نوع DoS / slowloris حيث يحصل المهاجم على ضحية لتقديم ملف ثم المهاجم نفسه ، أو مع عدة أشخاص يفتحون جميعًا ويملئون مجموعة الاتصال؟
  
  
  • هل هناك هجوم إسناد حيث يحصل المهاجم على شخص ما لتقديم ملف ويمكنه بعد ذلك إثبات قيام شخص آخر بذلك؟
  
  
• من المحتمل أن يكون اسم الملف ونوع المحتوى عرضة لنفس مشكلات unicode المحددة في # 338
• يجب على العملاء رفض عمليات إعادة توجيه HTTP والمحاولات الأخرى لاختطاف تدفق HTTP.
• أعتقد أنني سأجادل بأن عناوين URL غير الصالحة يجب أن تؤدي فقط إلى إغلاق الاتصال ، بدلاً من 404.

هذا له خاصية أنيقة لكونه متوافقًا تمامًا مع العملاء الذين لا ينفذون عمليات نقل الملفات ؛ سيرى المستخدم عنوان URL ويمكنه تنزيله في المتصفح.

• يفتح هذا عددًا قليلاً من متجهات الهجوم المذكورة أعلاه والتي يمكن لعميل http المرتد أن يتجنبها ، لكن المستعرض لا يمكنه ذلك. توجد بالفعل تحذيرات حول فتح الروابط ، لكنني أتساءل عما إذا كانت الرسائل وحالة الميزة المدعومة لعمليات نقل الملفات قد تفتح صدعًا للتصيد الاحتيالي.

• بدون مصادقة العميل على التنزيل ، هل هناك أي موجهات هجوم جديرة بالملاحظة؟ لا يمكنني التفكير في أي شيء قد يكون حاسمًا لنموذج التهديد ... ولكن للتسجيل ، إليك بعض الأشياء التي خطرت في بالي:

حسنًا ، هناك مصادقة باستخدام عنوان URL فريد للمستلم والملف. القلق هو أنه قابل للتحويل: لا تحدد هذه المصادقة المستلم لأي شخص آخر غير المرسل (وهذا غير مشفر) ، ولا يحتوي على أي سر قد يرغب المستلم في حمايته.

• هل هناك احتمال لوقوع هجوم من نوع DoS / slowloris حيث يحصل المهاجم على ضحية لتقديم ملف ثم المهاجم نفسه ، أو مع عدة أشخاص يفتحون جميعًا ويملئون مجموعة الاتصال؟

أعتقد أنه لا يوجد خيار DoS ، طالما أننا نحد من عدد الاتصالات لكل ملف معروض. نظرًا لأن القصد هو مشاركة ملف واحد مع شخص واحد مرة واحدة (السماح بالاستئناف والمشكلات الأخرى) ، فيمكننا أن نكون صارمين بشأن ذلك. قد يكون من الجيد أيضًا تعيين حد أدنى لمعدل النقل ، من أجل سهولة الاستخدام أيضًا.

• هل هناك هجوم إسناد حيث يحصل المهاجم على شخص ما لتقديم ملف ويمكنه بعد ذلك إثبات قيام شخص آخر بذلك؟

مثير للإعجاب! أنا أحب هذا الهجوم. هناك دفاعات ضعيفة من خلال تغيير مصادقة العميل ، لكنها في الحقيقة لا تشجع على مشاركة عناوين URL. أود أيضًا ألا تحدد عناوين URL هذه المستلم المقصود بخلاف المرسل الذي أنشأها.

لإزالة الإحالة المشفرة فعليًا ، سيتعين علينا تقديم الملفات على الخدمات المؤقتة. لست متأكدًا مما إذا كان يتطلب أيضًا خدمة واحدة سريعة الزوال لكل _ اتصال_. من الناحية الفنية ، يمكن أن يقنع بوب أليس بإرسال ملف خطير ، ويشارك بوب العنوان مع كارول ، وبعد ذلك يمكن لكارول بشكل منفصل أن تجعل أليس ترسل ملفًا غير ضار ، حتى تتمكن كارول من تأكيد أن عنوان URL الخطير جاء من أليس.

ستكون الإجابة الأكثر أمانًا من حيث الإسناد هي استخدام خدمة فريدة سريعة الزوال لكل جهة اتصال في كل جلسة. اهتماماتي بهذا هي 1) زمن انتقال نشر الخدمة ؛ 2) مطلوب العديد من الدوائر ؛ 3) يظهر بشكل أكثر وضوحا لتحليل حركة المرور.

أعتقد أنني قد أكون موافقًا على استخدام خدمة واحدة سريعة الزوال لجميع عمليات نقل الملفات في الجلسة. إنه على الأقل لا يزال متميزًا من الناحية المشفرة ، ويقلل من كل تلك التأثيرات ، ويتم اختراع الحالة التي يفشل فيها.

• من المحتمل أن يكون اسم الملف ونوع المحتوى عرضة لنفس مشكلات unicode المحددة في # 338

نوع المحتوى هو نوع MIME ، لذلك لا توجد مشاكل يونيكود هناك. لتعقيم أسماء الملفات ، توصلت إلى بعض القواعد منذ فترة طويلة ، والتي ستحتاج إلى مزيد من التفكير. يجب أن تكون حذرا للغاية هناك.

• يجب على العملاء رفض عمليات إعادة توجيه HTTP والمحاولات الأخرى لاختطاف تدفق HTTP.

يوافق على.

• أعتقد أنني سأجادل بأن عناوين URL غير الصالحة يجب أن تؤدي فقط إلى إغلاق الاتصال ، بدلاً من 404.

بدون أي رد؟ همم. هذا يجعل الأمر أكثر غموضًا إلى حد ما بالنسبة للعميل المرتد لمعرفة ما إذا كان هناك فشل في الشبكة أو إذا كان عنوان URL لم يعد صالحًا. وإلا فليس لدي مشكلة في ذلك ، وأرغب في عدم إرسال أي شيء مرة أخرى إلى العملاء غير المصرح لهم.

هذا له خاصية أنيقة لكونه متوافقًا تمامًا مع العملاء الذين لا ينفذون عمليات نقل الملفات ؛ سيرى المستخدم عنوان URL ويمكنه تنزيله في المتصفح.

• يفتح هذا عددًا قليلاً من متجهات الهجوم المذكورة أعلاه والتي يمكن لعميل http المرتد أن يتجنبها ، لكن المستعرض لا يمكنه ذلك. توجد بالفعل تحذيرات حول فتح الروابط ، لكنني أتساءل عما إذا كانت الرسائل وحالة الميزة المدعومة لعمليات نقل الملفات قد تفتح صدعًا للتصيد الاحتيالي.

يجب أن تكون الاحتياطات هنا هي نفسها المستخدمة في فتح أي عنوان URL. لا أعتقد أن هذه بالضرورة حالة استخدام تستحق التصميم من أجلها - لست متأكدًا من أنها ستنتهي بالبقاء فيها.

من غير الواضح ما هو تنفيذ C ++ / Qt الذي سيكون آمنًا بدرجة كافية للاستخدام

من المحتمل أن تكون كبيرة جدًا بالفعل بالنسبة لحالة الاستخدام هذه ، ولكنها مكتوبة مع مراعاة الأمان: https://github.com/reyk/httpd

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

أتساءل لماذا تريد حفظ نوع محتوى إضافي بصرف النظر عن ملحق اسم الملف المرئي للمستخدم؟ هل يمكن أن يؤدي ذلك إلى حدوث ارتباك في جانب المستقبِل إما تقنيًا في أي برنامج يبدأ تشغيله ، أو غير تقني فيما يتوقعه المستخدم؟

XXX لا توجد طريقة محددة هنا للمرسل للإشارة إلى الإلغاء

أليست علامة bool file_refused في رسالة ChatAcknowledge وسيلة للقيام بذلك؟ أم تقصد بعد قبول ملف وأثناء منتصف عملية التحويل؟

أعتقد أنني سأجادل بأن عناوين URL غير الصالحة يجب أن تؤدي فقط إلى إغلاق الاتصال ، بدلاً من 404.

👍

مثير للإعجاب! أنا أحب هذا الهجوم. هناك دفاعات ضعيفة من خلال تغيير مصادقة العميل ، لكنها في الحقيقة لا تشجع على مشاركة عناوين URL. أود أيضًا ألا تحدد عناوين URL هذه المستلم المقصود بخلاف المرسل الذي أنشأها.

على حساب توافق العميل ، هل سيكون من الممكن تشفير محتويات الملف بالمفتاح العام للمستلمين أو شيء من معرف الجلسة؟

أتساءل لماذا تريد حفظ نوع محتوى إضافي بصرف النظر عن ملحق اسم الملف المرئي للمستخدم؟ هل يمكن أن يؤدي ذلك إلى حدوث ارتباك في جانب المستقبِل إما تقنيًا في أي برنامج يبدأ تشغيله ، أو غير تقني فيما يتوقعه المستخدم؟

همم. لدي استخدامان في الاعتبار:

1. عندما نطبق الصور المضمنة ، سنحتاج إلى طريقة لمعرفة الملفات التي هي صور
2. قد يكون من الجيد أن تكون قادرًا على إظهار رمز مختلف لبعض أنواع الملفات (صورة / ، فيديو / ، إلخ)

إن اكتشاف هذه استنادًا إلى الامتداد لا يمكن الاعتماد عليه على الأقل مثل وجود نوع محتوى (ربما يكون خاطئًا). أنت محق في أنك ستحتاج إلى الاهتمام بالرقم 2 للتأكد من أننا لا نظهر شيئًا ما على أنه صورة عندما يتم فتحه في الواقع كملف تنفيذي. لهذا السبب وحده ، ربما يكون من الأفضل إزالة نوع المحتوى والكشف عن طريق الامتداد فقط. همم..

XXX لا توجد طريقة محددة هنا للمرسل للإشارة إلى الإلغاء

أليست علامة file_refused المنطقية في رسالة ChatAcknowledge وسيلة للقيام بذلك؟ أم تقصد بعد قبول ملف وأثناء منتصف عملية التحويل؟

يكون صالحًا فقط لإرسال ChatAcknowledge للرسائل التي تلقيتها - ليس من المنطقي الاعتراف برسائلك الخاصة. لذلك يوفر file_refused طريقة للمستلم للإلغاء ، لكنني لم أحدد ما يعادله للمرسل ليقول "لم أعد أعرض هذا الملف بعد الآن".

على حساب توافق العميل ، هل سيكون من الممكن تشفير محتويات الملف بالمفتاح العام للمستلمين أو شيء من معرف الجلسة؟

لا يحل تشفير الملف هجوم الإسناد @ s-rah: فهذا يعني فقط أنك بحاجة إلى توفير مفتاح فك التشفير مع عنوان URL. تواجه الطرق الشائعة للتشفير بالمفتاح العام للمستلم نفس المشكلة ، لأنك عمومًا تقوم فقط بلف مفتاح التشفير المتماثل المستخدم لبيانات الملف.

قد يكون من المفيد أكثر أن تطلب من المستلم التخلي عن مفتاح هويته الخاص لإثبات أن المرسل يقدم ملفًا. لذلك ، نحتاج فقط إلى مصادقة الاتصال بالمفتاح العام للمستلم قبل تقديم الملفات - لكن هذا لا يتوافق جيدًا مع HTTP (لا ، لا TLS). ستكون هذه نقطة لصالح استخدام بروتوكول آخر.

هناك طريقة مختلفة تمامًا تتمثل في جعل المستلم يستضيف الخادم ، بحيث يعمل المرسل كعميل لتحميل البيانات. يمكن أن يعمل هذا مع HTTP أو أي شيء آخر ، ولكن له بعض الجوانب السلبية في المرونة. لن تكون هناك مشكلة الإسناد في هذه الحالة.

عندما نطبق الصور المضمنة ، سنحتاج إلى طريقة لمعرفة الملفات التي هي صور

أود أن أعبر عن أنني أتفق تمامًا مع بيانك السابق: I don't trust image decoders .

ليس من المنطقي الاعتراف برسائلك الخاصة.

سيئًا ، لقد قرأت كلمة "المتلقي" بينما تشير بالفعل إلى "المرسل" :)

قد يكون من المفيد أكثر أن تطلب من المستلم التخلي عن مفتاح هويته الخاص لإثبات أن المرسل يقدم ملفًا. لذلك ، نحتاج فقط إلى مصادقة الاتصال بالمفتاح العام للمستلم قبل تقديم الملفات - لكن هذا لا يتوافق جيدًا مع HTTP (لا ، لا TLS).

تبدو مثيرة للاهتمام ، هل لديك أمثلة على بروتوكولات أخرى تفعل هذا؟ أو كيف يمكن إعداده؟ أعتقد أن إطار عمل الضوضاء يمكن أن يساعد هنا كما هو مذكور في https://github.com/ricochet-im/ricochet/issues/72#issuecomment -258894126.

إذا كان أي شخص يحتاج إلى هذا في أسرع وقت ممكن ، فيجب عليك استخدام onionshare مع الإرتداد.

----- بدء رسالة توقيع PGP -----
الهاش: SHA512

جون بروكس:

يسمح فقط بـ HTTP ، ولا يسمح ببروتوكول HTTPS. لا نريد أن نطلب TLS
التنفيذ ، و .onion يجعله غير ضروري.

ليس من الواضح بالنسبة لي ما إذا كان هذا جزءًا من نموذج تهديد ريكوشيت ،
ولكن في بيئات مثل Whonix ، يمكن لعميل Tor قراءة المحتويات
من حركة مرور بيانات .onion وليس حركة مرور TLS (حيث يتم فك تشفير TLS في ملف
مختلف VM).
----- بدء توقيع PGP -----

iQIcBAEBCgAGBQJYKlGYAAoJELPy0WV4bWVwu / gQAI / 7bmPTKwbcsjEntuEjc03j
nQFKDvSMg05FXR9rljFym5E ++ pr1FEteKb2qAu0Gub9CbkxCWhibBYNQHi1aFgy5
wgO07yom0oJI4JxBXA185TNSJKE7 + LnDAqUCT0H1d0yCy5t4TZfFQHJFLdhOjdk +
GD + Lbuv3pH0GIInsK7iAFQlps0bQmI8aNrNAgoiuk3iWI9MqGFZ8BoXZlabMeGnF
O0OeaibMjtvtuvX4mRsgTFZdNzzUmSfmkoYsABHDK / He4rcnUg6LUetVz16YKzuo
i5Oxy + dQZ6FHHICsQq2Ajg35LfW95I27jcm0QBGFZ08tu3Igt7DFqw9Sq1Ydg5Hl
ي / HckRIA5pIJJUcOUa4ynFyk2t / hA0fQEjSoy9C66GnH4Fzt6X / Izs0CDkPkZOQ /
+ Vo7wYkqyKcInn2uu7sb62lopX7L6QKHMORRiO / 5echUMCNCs5fVx7pDenIKvXew
88QcZ / UkR48N9RdKaNC + UdCt3a / vJzQhbzB65cgGuPtvJLhUPFay2IK / szP0 ​​/ Drw
gPXT + kwbCcBKqbmzkniPysn0Z62wXOlZAfiI / BJ5TqbqILNlhyR9HFSb9MIImiNL
Es + Q3vteUEm6pGVGPnqMZMm2dxVYmP5xx3pHhqq7GjaeGplNEi0ZwTsmSpfCztPB
Y6ksrSAXNDadT0ijrXfu
= تيتغ
----- نهاية توقيع PGP -----

الحل المحتمل : على الأقل في نظامي التشغيل Windows و Linux يوجد gpg4usb (gpg4usb.org) ، وهو برنامج GPG قائم بذاته يحفظ جميع الملفات المشفرة كملفات نصية:

واجهه المستخدم:

الإخراج (open _data.docx.asc_ في المفكرة):

المزالق:

• قطع؟ لقد أرسلت بعض أجزاء النصوص الطويلة جدًا فوق Ricochet ولكن يمكنني أن أتخيل أنها تقطعها في مرحلة ما. قد تحتاج إلى إرسال الملفات في مجموعات.
• الملفات أكبر قليلاً من الملفات الثنائية)
• قلة من الناس يستخدمون GPG (باستثناء JeremyRand أعلاه) لذلك بعض الوقت سوف يذهب لشرح كيفية عمله ، وتبادل المفاتيح ، وما إلى ذلك.

تحديث: يستخدم هذا البرنامج إصدارًا قديمًا من GPG ، لذا في حين أنه من المحتمل أن يظل يعمل كحل بديل ، فقد لا يعمل مع أدوات أخرى متوافقة مع GPG تم تحديثها مؤخرًا.

1) ميزة نقل الملفات ضرورية في بيئة العمل الحقيقية. لأسباب تتعلق بالعمل ، غالبًا ما أكون متحركًا وأضطر إلى تبادل الرسائل والملفات مع الزملاء (نادرًا ما تكون الصور ، ومعظم ملفات docx و xls وأنواع الملفات الأخرى). بالطبع نحن بحاجة للتأكد من أن هذه تتحرك في قناة آمنة ومحفوظة.
من الضروري تمامًا (طلب رقم 1) ألا يتم اعتراض الملف أو الاستيلاء عليه من قبل أي شخص آخر غير المستلم المقصود.
لذلك أنا بالتأكيد وأعارض أي استخدام لعنوان URL العام (حتى لو كان مختلطًا أو أي شيء من هذا القبيل) يكون مرئيًا بأي شكل من الأشكال ، أو يمكن اشتقاقه بسهولة (وقابل للتحويل للآخرين). يجب أن يظل محتوى المحادثة والملف خاصًا تمامًا بين المرسل والمستقبل (P2P خالص وليس مشاركًا على الإطلاق).
نوع من "الهجوم" عليك التفكير فيه إذا كان استخدام عناوين URL "العامة" يأتي من المستلم نفسه.

فكر في موظف غير مخلص يعرف هذه الآلية ويمرر عبر قناة مختلفة (ربما حتى دردشة Ricochet IM ثانية دون ترك أي أثر ...) عنوان URL لطرف ثالث بمجرد استلامه ... يقوم الطرف الثالث بتنزيل الملف ، ويقوم الموظف بتنزيله أيضًا ويتظاهر بأنه لم يرتكب أي خطأ ... في نظام بدون أي روابط عامة / مرئية / قابلة للنسخ ، حيث يكون الخيار الوحيد الذي يتلقاه في نافذة الدردشة هو تنزيل الملف إلى جهاز الكمبيوتر الخاص به أو يرفضه ، فهو الشخص الآخر الوحيد (بخلاف المرسل) الذي يمكنه الوصول إلى هذا الملف وإذا تسرب ، فلا عذر لكونه يرجع إلى أي عنوان URL لـ http عام ...

2) هل نظرت في حلول الدردشة الأخرى التي توفر نقل ملفات P2P للحصول على أفكار حول شيء يعمل بالفعل؟
أثناء انتظار ظهور هذا الخيار ، نستخدم في الحقل QTox ولديه خيار نقل ملفات عملي ورائع مضمن بالكامل في الدردشة.
(في الماضي ، استخدمت أيضًا uVNC ونفذت عمليات نقل سهلة للملفات عبر أنفاق آمنة من نوع p2p)

3) سيكون شعوري الداخلي القديم هو تفريغ أي فكرة عن بروتوكول http والبدء في العمل على حزم فعالة للملفات في بروتوكول الارتداد المدقق والآمن والموثوق به (مع التعديلات الصغيرة الضرورية وربما طبقة إضافية اختيارية من التشفير البسيط) ، كما هو موضح في خيارك الأول.
حتى مجرد التفاف الملف باستخدام Mime64 + عملية التدافع الخفيف (والقيام بالعكس عند الاستقبال) سيكون كافيًا كغلاف.
أنا أفضل الأمان واليقين ، فلا توجد مخاطر من وصول ملفاتي إلى أيدي المنافسين بدلاً من آلية نقل مربي الحيوانات و / أو أسرع.

4) لا تنس أن معظم الأشخاص ما زالوا يستخدمون البريد الإلكتروني (تشفير غير مشفر لملفات المرفقات MIME-64) لإرسال الملفات ... بطيئة وغير فعالة وغير آمنة بالتأكيد.
السرعة القصوى ليست جزءًا مهمًا من النقل في بيئة الهاتف المحمول في العالم الحقيقي (وبعض اتصالات الهاتف المحمول المستخدمة عن بُعد ليست قادرة على أي حال حتى على دعم سرعات هائلة ...).
بالنسبة لي ، من الأهمية بمكان أن يكون لدي مؤشر لحالة النقل إلى زملائي ، لإمكانية `` إيقاف مؤقت / استئناف '' إرسال الملفات الطويلة ولديك آلية للتعامل مع الاتصالات المفقودة (وهو ما يحدث كثيرًا في الميدان) مع عمليات النقل الجارية.

يوجد تطبيق مشاركة ملفات صغير وخفيف الوزن يعتمد على خدمة Tor Hidden Service يسمى Onionize بواسطة nogoest (مكتوب بلغة Golang).

أشعر بالفضول إذا كانت هناك إمكانية لإنشاء نسل لطيف لمشاركة ملفات IM + ؛)