git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
c18f0dd52
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
branches
original_web
ar
hidden-services.wml
Added 19 FAQ entries
Matt Pagan
commited
c18f0dd52
at 2013-08-26 04:06:05
hidden-services.wml
Blame
History
Raw
## translation metadata # Revision: $Revision: 22995 $ # Translation-Priority: 3-low #include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8" <div class="main-column"> <h2>تور: بروتوكول الخدمات المخفية</h2> <hr /> <p> يُمكّن تور المستخدمين من إخفاء أماكنهم عند تقديم عدد من الخدمات كخدمة للنشر على الوب أو خادوم للمحادث الفورية. يمكن باستخدام "نقاط تجمع" تور للمستخدمين الآخرين الاتصال بتلك الخدمات المخفية بدون أن يعرف كل طرف هوية الآخر على الشبكة. تشرح هذه الصفحة التفاصيل التقنية لكيفية عمل بروتوكول التجمع هذا. لمزيد من المعلومات التي تشرح القيام بذلك مباشرة، راجع صفحة <a href="<page docs/tor-hidden-service>">ضبط الخدمات المخفية</a>. </p> <p> يجب أن تعلن الخدمة المخفية عن وجودها في شبكة تور قبل أن يتمكن العملاء من الاتصال بها. تقوم الخدمات باختيار تحويلات عشوائية وبناء حلقات معها وتطلب منها أن تكون <em>نقاط تعريف</em> بأن تعطيها الخدمة مفتاحها العلني. لاحظ أن الخط الأخضر في الرسومات التالية يمثل حقلة وليس اتصالا مباشرًا. يصعب على أي أحد ربط نقطة التعريف بالخادوم المخفي عند استخدام حلقة تور كاملة. تُعطى النقاط التعريفية وغيرها من الجهات هوية الشبكة المخفية (المفتاح العلني) لكن موقع الخادوم (عنوان IP) مخفي. </p> # maybe add a speech bubble containing "PK" to Bob, because that's what # Bob tells to his introduction points <img alt="الخطوة الأولى لخدمات تور المخفية" src="$(IMGROOT)/THS-1.png" /> <p> الخطوة الثانية: تجمع الخدمة المخفية <em>مُعرّف الخدمة المخفية</em> الذي يتكون من مفتاحها العلني وملخص عن كل نقطة تعريف وتُوقع المُعرّف بمفتاحها الخاص وترفع المُعرّف إلى جدول تلبيد مُوزّع (distributed hash table). يمكن أن يعثر العملاء على المُعرّف بطلب سصع.onion حيث أن سصع اسم فريد يتكون من 16 حرفًا مشتق من مفتاح الخدمة العلني. ستكون الخدمة المخفية جاهزة بعد هذه الخطوة. </p> <p> وعلى الرغم من أن استخدام اسم مولد تلقائيًا، إلا أن ذلك يهدف غرضًا هامًا وهو أن يتمكن الجميع (ومن ذلك نقاط التعريف وأدلة جدول التوليد المُوزّع و-طبعًا- العملاء) من التأكد أنهم يتصلون بالخدمة الصحيحة. راجع أيضًا <a href="https://zooko.com/distnames.html">توقع زوكو</a> عن إمكانية إحراز اثنين على الأكثر من بين التوزيع والأمن والاسم المفهوم. ربما يُنفذ أحد ما تصميمًا <a href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">للأسماء المستعارة</a> للخدمات المخفية! </p> # maybe replace "database" with "DHT"; further: how incorrect # is it to *not* add DB to the Tor cloud, now that begin dir cells are in # use? <img alt="الخطوة الثانية لخدمات تور المخفية" src="$(IMGROOT)/THS-2.png" /> <p> الخطوة الثالثة: يجب أن يعرف العميل الذي يريد الاتصال بخدمة مخفية عنوانها البصلي (onion) أولا. يمكن بعد ذلك أن يبدأ العميل تشييد الاتصال بتنزيل المُعرّف من جدول التبليد الموزع. إذا عثر العميل على عنوان سصع.onion فسيعرف نقاط التعريف والمفتاح العلني الصحيح الذي ينبغي استخدامه (يمكن أيضًا ألا تتوفر الخدمة في ذلك الوقت ويمكن أن تكون ألغيت منذ فترة طويلة ويمكن أن يوجد خطأ مطبعي في العنوان البصلي. ينشئ العميل بعد ذلك حلقة مع تحويلة أخرى عشوائية ويطلب منها أن تكون <em>نقطة التقاء</em> بأن يخبرها كلمة سر تستخدم لمرة واحدة. </p> # maybe add "cookie" to speech bubble, separated from the surrounded # "IP1-3" and "PK" <img alt="الخطوة الثالثة لخدمات تور المخفية" src="$(IMGROOT)/THS-2.png" /> <p> الخطوة الرابعة: عندما يتوفر المُعرّف وتجهز نقطة الالتقاء يرسل العميل رسالة <em>تعريفية</em> (مُعمّاة بمفتاح الخدمة المخفية العلني) تحتوي عنوان نقطة الالتقاء وكلمة السر التي ستستخدم مرة واحدة. يرسل العميل تلك الرسالة إلى إحدى نقاط التعريف ويطلب أن توصلها إلى الخدمة المخفية؛ ومرة أخرى، تتم الاتصالات عبر حلقة تور ولذا لا يمكن أن يربط أحد الرسالة التعريفية بعنوان IP العميل ليظل العميل مجهولا. </p> <img alt="الخطوة الرابعة لخدمات تور المخفية" src="$(IMGROOT)/THS-4.png" /> <p> الخطوة الخامسة: تفك الخدمة المخفية تعمية رسالة العميل التعريفية لتستخرج عنوان نقطة الالتقاء وكلمة السر التي ستستخدم مرة واحدة. تنشئ الخدمة حلقة مع نقطة الالتقاء وترسل كلمة السر التي ستستخدم لمرة واحدة. </p> <p> من الضروري عند هذه المرحلة التي تلتزم الخدمة المخفية بنفس <a href="<wiki>TorFAQ#Whatsthisaboutentryguardformerlyknownashelpernodes">المداخل</a> لإنشاء الحلقات وإلا فيمكن لمهاجم أن يُشغّل تحويلة وأن يجبر الخدمة المخفية على إجراء عدد كبير من الحلقات إلى أن ينجح من إجبارها على الاتصال بتحويلته الفاسدة ليعرف عنوان IP الخدمة المخفية بالتحليل الزمني. تناول Øverlier و Syverson هذا الهجوم في بحثهما المعنون <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden Servers</a>. </p> # it should say "Bob connects to Alice's ..." <img alt="الخطوة الخامسة لخدمات تور المخفية" src="$(IMGROOT)/THS-5.png" /> <p> الخطوة الأخيرة أن تشعر نقطة الالتقاء العميل بنجاح تأسيس الاتصال. بعد ذلك يمكن أن يستخدم العميل والخدمة المخفية نفس الحلقات التي كانا يستخدمانها للاتصال بنقطة الالتقاء للاتصال ببعضهما. تنقل نقطة الالتقاء رسائل (مُعمّاة من الطرفين) من العميل إلى الخدمة والعكس. </p> <p> أحد أسباب عدم الاعتماد على حلقة التعريف للاتصالات الفعلية هي أنه لا ينبغي أن تكون أي تحويلة بذاتها مسؤولة عن خدمة مخفية معينة؛ ولهذا فإن نقطة الالتقاء لا تعرف أبدًا هوية الخدمة المخفية. </p> <p> يتم الاتصال بين العميل والخدمة المخفية عادة بربط 6 تحويلات: 3 منها من اختيار العميل على أن تكون الثالثة نقطة التقاء و3 أخرى من اختيار الخدمة المخفية. </p> <img alt="الخطوة السادسة لخدمات تور المخفية" src="$(IMGROOT)/THS-6.png" /> <p> يوجد تفصيل أكثر من هذا عن بروتوكول الخدمات المخفية. راجع <a href="<svnprojects>design-paper/tor-design.pdf">مستند تصميم تور</a> لمعلومات أعمق عن التصميم و<a href="<gitblob>doc/spec/rend-spec.txt">معيار الالتقاء</a> لمعلومات عن أنساق الرسائل. </p> </div> #include <foot.wmi>