سرویس onion واقعاً چیست؟
سرویس onion سروری است که هیچوقت به کسی نمی‌گوید کجاست. به‌جای انتشار یک آدرس در DNS و انتظار برای اتصال، مدارهای خروجی‌ای از طریق شبکه Tor تا چند رله که به‌عنوان نقاط معرفی انتخاب میکند می‌سازد، و یک توصیف‌گر امضاشده منتشر میکند که می‌گوید «هرکس این کلید را داشته باشد، از طریق این رله‌ها قابل دسترسی است». کلاینتی که آدرس را می‌داند آن توصیف‌گر را واکشی میکند، یک رلهٔ سوم را به‌عنوان نقطه ملاقات انتخاب میکند، و از یک نقطه معرفی می‌خواهد درخواستی برای ملاقات در آنجا منتقل کند. هر دو طرف مدار خودشان را تا نقطه ملاقات می‌سازند، و هیچ‌کدام هرگز آدرس IP طرف مقابل را نمی‌فهمد، چون هیچوقت به آنها گفته نمی‌شود.
خودِ آدرس بخش جالب ماجراست. یک آدرس onion نسخه 3 شامل 56 کاراکتر base32 و به‌دنبال آن .onion است، و این یک نام نیست که به یک کلید اشاره کند — خودِ آن کلید است: یک کلید عمومی ed25519 به‌همراه چک‌سام و یک بایت نسخه، رمزگذاری‌شده. چیزی برای جست‌وجو کردن و چیزی برای اعتماد کردن وجود ندارد. وقتی کلاینت شما متصل میشود، توصیف‌گری که واکشی میکند دقیقاً با همان کلید امضا شده، پس آدرس بهطور ذاتی سرویس را احراز هویت میکند. هیچ مرجع صدور گواهی‌ای در کار نیست، هیچ‌کس نمی‌تواند برای آدرس شما گواهی صادر کند، و هیچ لاگ شفافیتی وجود ندارد که وجود سرویس را ثبت کند. اگر می‌خواهید دست‌دهیِ کامل را ببینید، خواندن مشخصات rendezvous ارزشش را دارد.
| یک سایت معمولی چه چیزی را منتشر میکند | چه کسی میتواند آن را ببیند | یک سرویس onion به‌جای آن چه چیزی منتشر میکند |
|---|---|---|
| یک رکورد DNS که نام را به IP نگاشت میکند | هرکسی، برای همیشه، و DNS غیرفعال هم تاریخچه‌اش را نگه می‌دارد | هیچ‌چیز — در هیچ مرحله‌ای DNS دخیل نیست |
| یک گواهی TLS که نام میزبان را دربردارد | هرکسی، از طریق لاگ‌های عمومی certificate transparency | هیچ‌چیز — خودِ آدرس همان کلید است، پس نیازی به CA نیست |
| آدرس IP که روی پورت 443 پاسخ میدهد | هرکسی که بهطور مداوم اینترنت را اسکن میکند | هیچ‌چیز — سرویس مدارهای خروجی باز میکند و روی هیچ پورت عمومی گوش نمیدهد |
| یک ارائه‌دهنده میزبانی و یک ASN | هرکسی، از روی آدرس | هیچ‌چیز قابل استخراج از خودِ آدرس نیست |
| سوابق WHOIS یا ریجیستراری | هرکسی؛ و ریجیستررها به احضاریه‌ها پاسخ می‌دهند | هیچ‌چیز — نه ثبتی وجود دارد و نه ریجیستراری |
این فهرست، کل ارزش پیشنهادیِ ماجراست و توضیح میدهد چرا طیف متنوعی از افراد این‌ها را اجرا میکنند. نمونه‌های SecureDrop در تحریریههای خبری سرویس onion هستند چون یک منبع خبری نباید مجبور باشد به DNS اعتماد کند. Debian آرشیو خودش را از طریق سرویس‌های onion آینه‌سازی میکند تا عمل به‌روزرسانی یک بسته به‌عنوان یک مقصد قابل‌مشاهده نباشد. چند پلتفرم مصرفی بسیار بزرگ هم یکی منتشر میکنند تا افرادی که در شبکه‌های تحت سانسور هستند بتوانند بدون آنکه یک IP مسدودشده وسط راه باشد به آنها برسند. هیچ‌کدام از این‌ها عجیب نیست؛ این فقط یک لایه انتقال با مجموعه‌ای متفاوت از تضمین‌هاست.
چه چیزی را محافظت میکند، و چه چیزی را نمی‌تواند
تضمین این پروتکل محدود اما قوی است: لایه شبکه فاش نمیکند سرویس کجا اجرا میشود. مهاجمی که میتواند بخش بزرگی از اینترنت را زیر نظر داشته باشد هم باز نمی‌تواند آدرس شما را به یک ماشین مشخص تبدیل کند، چون اصلاً مرحله‌ای برای این تبدیل وجود ندارد که رصد شود. نمی‌شود آدرس را دست یک ارائه‌دهنده میزبانی داد و پرسید مال کدام مشتری است، چون سمت ارائه‌دهنده چیزی از آن نمی‌داند. اسکنرها نمی‌توانند سرویس را پیدا کنند، چون روی هیچ پورت عمومی‌ای پاسخ نمیدهد. و حمله‌ای که قرار است یک سایت معمولی را از شبکه بیرون بیندازد، هدفی برای نشانه‌گیری ندارد؛ برای همین این الگو در بحث‌های DDoS به همان اندازه بحث‌های حریم خصوصی دیده میشود.
هر چیزی بالاتر از لایه شبکه هنوز به عهده خودِ شماست که خرابش نکنید، و تاریخچه واقعی همین‌جاست. سرویسها لو رفته‌اند چون برنامه یک stack trace حاوی نام میزبان واقعی چاپ کرده، چون همان وبسرور روی IP عمومی هم صفحه‌ای یکسان تحویل داده، چون گواهی دامنه دیگر همان اپراتور روی همان ماشین نصب بوده، چون یک تصویر مختصات GPS را در متادیتای خودش حمل می‌کرده، چون سرور ایمیلی فرستاده که از اینترنت باز عبور کرده، یا چون یک نقطه پایانی وضعیت که برای همه باز مانده آدرس خودِ سرور را فهرست کرده. Tor در تک‌تک این موارد کارش را درست انجام داده. آن کسی که رویش کار می‌کرده، نه.
پس دو ایده را هم‌زمان در ذهن نگه دارید. لایه انتقال سالم است و سال‌هاست که همین‌طور بوده؛ آن را حلقه ضعیف دانستن، برداشت اشتباهی از روند واقعی این تحقیقات است. و همین لایه انتقال، نیمه آسان کار هم هست — نیمه سخت، انضباطی است درباره هر چیزی که ماشین می‌گوید و انجام میدهد، و بقیه این راهنما عمدتاً درباره همین است. اگر دلیل حضور شما اینجا سؤالی گسترده‌تر درباره میزان قابل‌ردیابی بودن یک سرور اجاره‌ای است، نسخه صادقانه آن پاسخ همراه خوبی برای این صفحه است.
راهاندازی سرویس: دو دستور و یک ری‌استارت
پیکربندی واقعاً کوچک است، چیزی که کسانی را که انتظار یک تشریفات پیچیده دارند غافلگیر میکند. دیمن tor را نصب کنید، سپس دو دستور به torrc اضافه کنید: یک HiddenServiceDir که مسیر پوشه‌ای را نام می‌برد که Tor آن را می‌سازد و مالکش میشود، و یک HiddenServicePort که پورت مجازی مورد استفاده تماس‌گیرنده‌ها را به آدرس محلی‌ای که برنامه شما روی آن گوش میدهد نگاشت میکند. ری‌استارت کنید؛ Tor یک جفتکلید ed25519 تولید میکند و آدرس شما را در یک فایل hostname داخل همان پوشه می‌نویسد.
| خط | چه کاری انجام میدهد | اگر آن را حذف کنید چه اشکالی پیش می‌آید |
|---|---|---|
HiddenServiceDir /var/lib/tor/site/ | جایی که Tor کلیدها را نگه می‌دارد و آدرس را می‌نویسد؛ آن را با مُد 0700 می‌سازد | مالکیت اشتباه یا مُدی که برای همه قابل خواندن باشد، Tor را از اجرا شدن باز می‌دارد |
HiddenServicePort 80 127.0.0.1:8080 | درخواست‌کننده‌ها پورت 80 را روی آدرس onion می‌خواهند؛ Tor آن را به شنونده محلی شما هدایت میکند | اشاره کردن آن به یک آدرس عمومی، سرویس را دوباره روی اینترنت باز افشا میکند |
برنامه‌ای که به 127.0.0.1 متصل شده | فقط Tor میتواند به آن دسترسی داشته باشد | همان محتوا روی IP عمومی هم پاسخ میدهد و کل این تمرین بی‌فایده میشود |
HiddenServiceVersion 3 | صریح است، هرچند نسخه 3 تنها نسخه باقی‌مانده است | امروز هیچ اشکالی ندارد — نسخه 2 در سال 2021 از Tor حذف شد |
رایج‌ترین اشتباه، دقیقاً همان ردیف سوم است. یک نصب پیش‌فرض وبسرور روی 0.0.0.0 گوش میدهد، یعنی آدرس IPv4 عمومی و معمولاً آدرس IPv6 هم. اگر یک سرویس onion جلوی آن قرار دهید، حالا همان بایت‌ها را در دو جا سرو میکنید، که یکی از آنها توسط هر اسکنری در اینترنت ایندکس شده. هرکس که هش صفحه، فاوآیکون، ETag یا یک صفحه خطای متمایز را مقایسه کند، در چند ثانیه این دو را به هم پیوند می‌زند. فقط به 127.0.0.1 متصل شوید، و بعد به‌جای فرض کردن، آن را با ss -ltnp تأیید کنید — تأیید کردن پنج ثانیه طول میکشد، اما فرض کردن برای بعضی‌ها همه‌چیزشان را از بین برده.
پیش از هر کار دیگری، از hs_ed25519_secret_key در جایی رمزنگاری‌شده و خارج از خودِ ماشین نسخه پشتیبان بگیرید. این فایل مرتبط با آدرس نیست؛ خودِ آدرس است. اگر آن را از دست بدهید، آدرس برای همیشه از بین می‌رود، بدون امکان بازیابی و بدون هیچ راه چاره‌ای. اگر لو برود، فرد دیگری میتواند سرویسی راه بیندازد که به‌جای آدرس شما پاسخ میدهد و از نظر رمزنگاری از خودِ شما قابل تشخیص نیست. با آن مثل یک کلید امضا رفتار کنید، چون دقیقاً همین است — و اگر دیسکی که روی آن قرار دارد اجاره‌ای است، رمزنگاری آن دیسک گام همراه بدیهی است، البته با ملاحظاتی که همان راهنما توضیح میدهد.
بعد در ورودی را کاملاً ببندید. یک سرویس onion اصلاً به هیچ پورت ورودیای نیاز ندارد — هر اتصالی که استفاده میکند، خودش آن را بهصورت خروجی به داخل شبکه Tor باز کرده. میتوانید در فایروال همه ترافیک ورودی را رد کنید و سرویس همچنان کاملاً درست کار میکند. تقریباً هیچ چیز دیگری که بتوانید میزبانی کنید چنین چیزی ارائه نمیدهد، و این کل دسته‌ای از حملاتی را که با یک پورتاسکن شروع میشوند حذف میکند. دسترسی مدیریتی خودتان را هم از طریق Tor برقرار کنید تا ماشین کلاً به اینترنت پاسخ ندهد.
آدرسهای نسخه 3، پیشوندهای اختصاصی و مشکل فیشینگی که می‌سازند
اگر آموزشی که می‌خوانید از آدرسهای 16 کاراکتری حرف می‌زند، دارد پروتکلی را توصیف میکند که دیگر وجود ندارد. سرویس‌های onion نسخه 2 از هشهای 80 بیتی RSA-1024 استفاده می‌کردند که هم به‌اندازه کافی کوتاه بودند که جذاب باشند و هم به‌اندازه کافی ضعیف که مشکل‌ساز شوند؛ ضمن اینکه قابل شمارش هم بودند، چون هرکس یک رله دایرکتوری اجرا می‌کرد می‌توانست آدرس‌هایی را که از آن عبور می‌کردند جمعآوری کند. پروژه Tor برنامه زمانی کنارگذاری را در سال 2020 اعلام کرد، نسخه 2 را در سری 0.4.6 در ژوئیه 2021 غیرفعال کرد، و در اکتبر همان سال کد آن را کاملاً حذف کرد. آدرسهای نسخه 3، 56 کاراکتریاند، بر پایه ed25519 ساخته شده‌اند، و دیگر از طریق رلههای دایرکتوری نشت نمی‌کنند.
این طول، بهای همان امنیت است، و برای همین آدرسهای اختصاصی (vanity) وجود دارند. ابزارهایی مثل mkp224o بهصورت انبوه جفتکلید تولید میکنند و فقط آن‌هایی را نگه می‌دارند که آدرسشان با پیشوند انتخابی شما شروع شود. این کار هیچ چیزی را ضعیف نمیکند: شما کلید را محدود نمی‌کنید، بلکه گزینهها را کنار میگذارید تا یکی از آنها اتفاقی حروف مدنظرتان را رمزگذاری کند، و بازمانده دقیقاً به همان اندازه هر کلید دیگری قوی است. چیزی که هزینه می‌گیرد زمان است، و این هزینه نمایی است — هر کاراکتر اضافه، کار را 32 برابر میکند؛ پس یک پیشوند چهارکاراکتری روی یک لپ‌تاپ آنی است، شش یا هفت کاراکتر یعنی یک ماشین که ساعت‌ها کار کند، و ده کاراکتر یک پروژه جدی میشود. هیچ‌کس یک آدرس کامل 56 کاراکتری را brute-force نمیکند؛ کل نکته همین بزرگی فضای جست‌وجوست.
خطر واقعی، تصویر آینه‌ایِ همین ویژگی است. اگر یک پیشوند قابلتشخیص به کاربرانتان کمک کند شما را بشناسند، به فرد دیگری هم کمک میکند یک آدرس نزدیک به آن بسازد و روی یک صفحه فیشینگ بگذارد، چون آن هشت کاراکتری که یک انسان واقعاً می‌خواند تنها بخشی است که بررسی میکند. از آن همان‌طور دفاع کنید که همیشه از اثرانگشت کلیدها دفاع شده: آدرس کامل را در چند جای مستقل منتشر کنید، آن را با کلیدی که مردم از قبل دارند امضا کنید، اگر سایت کلیرنتی دارید آن را در هدر Onion-Location بگذارید، و صریحاً بگویید که هیچوقت آدرس جدیدی را فقط در شبکه‌های اجتماعی اعلام نخواهید کرد. یک پیشوند اختصاصی یک ویژگی کاربردپذیری است، نه یک ابزار احراز هویت.
سطح نشتی‌هایی که واقعاً هویت سرویسها را لو داده‌اند
این همان بخشی است که واقعاً اهمیت دارد. الگو در هر مورد مستندِ عمومی یکسان است: لایه شبکه دوام آورده، و چیزی بالاتر از آن به یک ماشین مشخص، یک فرد مشخص، یا یک دارایی مشخص دیگر اشاره کرده. بیشتر این موارد کسل‌کننده‌اند، همه‌شان را میشود در یک بعدازظهر بررسی کرد، و همین بررسی کردن است که کار اصلی است.
| نشتی | چطور پیدا میشود | راه‌حل |
|---|---|---|
| همان برنامه که روی IP عمومی هم پاسخ میدهد | هر دو را واکشی کنید و هش صفحه، فاوآیکون، ETag یا یک صفحه خطای متمایز را مقایسه کنید | فقط به 127.0.0.1 متصل شوید؛ با ss -ltnp تأیید کنید |
| یک هاست مجازی پیش‌فرض یا گواهی TLS روی آدرس عمومی | داده‌های اسکن سراسر اینترنت، قابل جست‌وجو و آرشیوشده بر اساس تاریخ | هیچ شنونده‌ای روی رابط عمومی نباشد؛ فایروالی که ترافیک ورودی را رد کند |
| بنرهای سرور و صفحات خطای فریم‌ورک | هدرهای پاسخ را بخوانید و عمداً یک خطای 500 ایجاد کنید | بنرهای نسخه را پنهان کنید، صفحات خطای دیباگ را با صفحات ایستا جایگزین کنید |
| URLهای مطلق که در قالب‌ها جاسازی شده‌اند | HTML را بخوانید: یک هاستِ کلیرنت هاردکد شده کافی است | همه‌جا از URL نسبی استفاده کنید، یا یک base URL آگاه به هاست |
| درخواست‌های شخص ثالث: آنالیتیکس، فونت، آواتار، CDN | صفحه را بارگذاری کنید و ببینید چه چیزی را واکشی میکند | هر دارایی را خودتان میزبانی کنید؛ اینجا هیچ درخواست شخص ثالثی قابل قبول نیست |
| متادیتای تصویر | بلوک EXIF را بخوانید: شماره سریال دوربین و مختصات GPS | در زمان آپلود، سمت سرور و بدون استثنا متادیتا را حذف کنید |
| نقاط پایانی وضعیت که باز مانده‌اند | /server-status را درخواست دهید و دیدگاه خودِ سرور از خودش را بخوانید | آنها را غیرفعال کنید، یا به رابط loopback محدودشان کنید |
| ترافیک خروجی که هاست را شناسایی میکند | ایمیلی که از سرور خارج میشود، عامل مانیتورینگی که به خانه زنگ می‌زند، کرون‌جابی با یک API key | ترافیک خروجی را ممیزی کنید، هرچه باید خارج شود را از مسیر Tor عبور دهید، و اصلاً ایمیلی نفرستید |
| یک کلید میزبان SSH که از ماشین دیگری دوباره استفاده شده | داده‌های اسکن بر اساس اثرانگشت کلید میزبان، دو ماشین را فوراً به هم پیوند می‌دهند | برای هر نمونه کلید تازه بسازید؛ به SSH فقط از طریق خودِ سرویس onion برسید |
| برچسب‌های زمانی و لوکِیل | برچسب‌های زمانی لاگ، سندهای تولیدشده، و یک روز کاری کاملاً مشخص | در UTC اجرا کنید؛ نگذارید برنامه یک منطقه زمانی محلی نمایش دهد |
دو مورد از آنها ارزش تأکید ویژه دارند چون حتی افراد دقیق را هم گیر می‌اندازند. اولی ترافیک خروجی است: ماشینی که هرگز اتصالی را نمی‌پذیرد، هنوز هم میتواند با برقرار کردن یک اتصال، خودش را لو بدهد. به‌روزرسانی بسته‌ها اشکالی ندارد و اجتناب‌ناپذیر است؛ اما عامل مانیتورینگی که به داشبوردی وابسته به نام شما گزارش میدهد اشکال دارد، و همین‌طور برنامه‌ای که ایمیل بازنشانی رمز عبور را از طریق اینترنت باز، از ماشینی که کل هدفش پیدا نشدن است، ارسال میکند. دومی کلید میزبان SSH است. استفاده مجدد از یک کلید در چند ماشین، عادتی است که مرتب به نظر می‌رسد اما پیوندی دائمی، قابل‌جست‌وجو و رمزنگاری‌شده بین دو سروری که قرار بود بی‌ربط باشند می‌سازد.
ممیزی را مثل یک فرد بیرونی انجام دهید، نه مثل خودِ اپراتور. سرویس را در Tor Browser روی ماشینی که هیچوقت با این پروژه سروکار نداشته باز کنید، هر هدر پاسخ را بخوانید، عمداً یک خطا ایجاد کنید، سورس صفحه‌ای را که خودتان ننوشته‌اید ببینید، و پنل شبکه را زیر نظر بگیرید تا ببینید صفحه از جای دیگری چه چیزی واکشی میکند. بعد یک روز کامل روی سرور بنشینید و ببینید چه چیزی از آن خارج میشود. چیزی که در آن روز پیدا میکنید، کل نکته این راهنماست.
احراز هویت کلاینت: سرویسی که فقط عده‌ای مشخص به آن دسترسی دارند
حالتی وجود دارد که اکثر مردم حتی نمی‌دانند هست، و شیک‌ترین بخش این پروتکل هم همین است. با احراز هویت کلاینت، توصیف‌گری که سرویس شما منتشر میکند برای مجموعه‌ای از کلیدهای عمومی x25519 که خودتان تعیین میکنید رمزنگاری میشود. کلاینتی که کلید خصوصی متناظر را نداشته باشد، حتی نمی‌تواند توصیف‌گر را رمزگشایی کند، یعنی نمی‌تواند نقاط معرفی را بفهمد، یعنی نمی‌تواند وصل شود — و حتی نمی‌تواند تأیید کند که اصلاً چیزی آنجا هست. کلیدهای عمومی کلاینت‌ها را در یک پوشه authorized_clients کنار کلیدهای سرویس میگذارید، یک فایل برای هر کلاینت، و ری‌استارت میکنید.
این را با روش‌های معمولِ محدود کردن دسترسی مقایسه کنید. یک allowlist مبتنی بر IP نیازمند دانستن اینکه کاربرانتان کجا هستند است و سرویس را برای همه‌ی دیگران آماده اسکن‌شدن و اثرانگشت‌گیری روی اینترنت باقی می‌گذارد. احراز هویت پایه HTTP یک پیام ورود آنجا باقی می‌گذارد که تبلیغ میکند چیزی وجود دارد. یک VPN یک سیستم دوم کامل برای اجرا اضافه میکند، با آدرس خودش که باید افشا شود. احراز هویت کلاینت سرویس را از دید هرکسی که در فهرست نیست کاملاً حذف میکند، که ویژگی‌ای اساساً متفاوت است: نه یک درِ قفل‌شده، بلکه نبودِ یک در.
جای طبیعی استفاده از این قابلیت، سطوح مدیریتی است. سایت عمومی را روی یک سرویس onion معمولی بگذارید و پنل مدیریت، داشبورد متریک‌ها، کنسول پایگاه‌داده و نقطه ورود SSH را پشت سرویس‌های onion جداگانه و دارای احراز هویت قرار دهید؛ آن‌وقت بخش‌هایی از استقرار شما که در غیر این صورت مدام پروب می‌شدند، اصلاً پیدا نمی‌شوند. هزینهاش توزیع کلید است — هر کلاینت باید کلید خصوصی خودش را در پیکربندی Tor نصب داشته باشد — که برای چند اپراتور محدود خوب است اما برای یک مخاطب عمومی عملی نیست. از آن جایی استفاده کنید که مخاطب قابل‌شمارش است.
تأخیر، افزونگی و مصالحه‌های صادقانه
یک اتصال onion از شش رله عبور میکند: سه‌تا که کلاینت انتخاب کرده و سه‌تا که سرویس انتخاب کرده، و در وسط به هم می‌رسند. این بهای ندانستن هیچ‌کدام از دو طرف درباره طرف دیگر است، و این بها بهصورت تأخیر بروز میکند نه پهنای باند — اولین بایت کند است، اما توان عملیاتی بعد از آن معمولاً خوب است. طراحی را متناسب با همین بسازید: رفت‌وبرگشت‌های کمتر، کش کردن تهاجمی، بدون زنجیره‌های پرحرفِ درخواست، بدون صفحه‌ای که پیش از رندر شدن به یازده زیرمنبع نیاز داشته باشد. سایتی که روی یک سرویس onion تجربه خوبی میدهد، معمولاً از اول هم خوب ساخته شده بوده.
اگر خودِ سرویس شما به ناشناسی مکانی نیازی ندارد — مثلاً یک پلتفرم عمومی بزرگ که صرفاً برای دسترسی کاربران تحت سانسور یک آدرس onion منتشر میکند — Tor حالتی به نام single onion service ارائه میدهد که در سمت سرویس فقط از یک گام مسیر استفاده میکند. این حالت تأخیر را تقریباً نصف میکند و صراحتاً از ناشناسیِ خودِ سرویس چشم‌پوشی میکند، و حتی نام دستور پیکربندی هم دقیقاً همین را می‌گوید. این پاسخ درست برای یک سازمان شناخته‌شده است و دقیقاً پاسخ اشتباه برای هرکسی که مکانش همان چیزی است که باید محافظت شود. آن را یا آگاهانه انتخاب کنید یا اصلاً انتخاب نکنید.
| دغدغه | گزینه | چه هزینه‌ای دارد | چه زمانی درست است |
|---|---|---|---|
| تأخیر | سرویس استاندارد شش‌گامی | اولین بایت کند، اما توان عملیاتی خوب | همیشه، مگر آنکه ناشناسیِ خودِ سرویس واقعاً لازم نباشد |
| تأخیر | سرویس onion تکی (یک گام در سمت سرویس) | ناشناسی مکانی خودِ سرویس، بهطور کامل | سازمانی شناخته‌شده که آدرسی برای کاربران تحت سانسور منتشر میکند |
| افزونگی | OnionBalance روی چند بک‌اند | یک دیمن مدیریتی و مدیریت کلید روی هر بک‌اند | هر چیزی که باید حتی حین بازسازی یک بک‌اند هم فعال بماند |
| قابل کشف بودن از سایت کلیرنت شما | هدر Onion-Location | این دو را عمداً و بهطور علنی به هم پیوند میدهد | وقتی پیوند دادن این دو مشکلی ندارد و ترافیک را می‌خواهید |
| مخاطب محدود | احراز هویت کلاینت | توزیع کلید به هر کلاینت | پنل‌های مدیریتی، ابزارهای داخلی، مخاطبی قابل‌شمارش |
افزونگی نیاز به یک توضیح دارد، چون روش ساده‌لوحانه شکست می‌خورد. نمی‌توانید فقط مواد کلید را روی یک ماشین دوم کپی کنید و هر دو را اجرا کنید — دو سرویس که برای یک آدرس یکسان توصیف‌گر منتشر میکنند بر سر دایرکتوری با هم رقابت میکنند و کلاینت‌ها بهطور غیرقابل‌پیش‌بینی به یکی از آنها می‌رسند. OnionBalance دقیقاً برای همین وجود دارد: یک نمونه front-end آدرس عمومی را نگه می‌دارد و توصیف‌گری منتشر میکند که به نقاط معرفیِ چند سرویس بک‌اند، هرکدام با کلید خودش، اشاره میکند. بک‌اندها را میشود یکی‌یکی بازسازی یا جابه‌جا کرد بدون آنکه آدرس هرگز تغییر کند.
اجرای یک سرویس onion در کنار یک سایت عادی
بسیاری از سرویس‌های onion فقط یک درِ ورودی دوم برای چیزی هستند که از قبل بهطور عمومی وجود دارد، و این پروژه‌ای کاملاً متفاوت از سرویسی است که مکانش باید مخفی بماند. پیش از نوشتن هر خط پیکربندی تصمیم بگیرید کدام‌یک را می‌سازید، چون این دو هدف کاملاً مخالف هم می‌خواهند. اگر هدف مقاومت در برابر سانسور برای سایتی است که همه از قبل می‌دانند شما اداره‌اش میکنید، پیوند دادن این دو دقیقاً همان ویژگی مطلوب است: یک هدر Onion-Location روی سایت کلیرنت منتشر کنید تا Tor Browser بهطور خودکار آدرس onion را به بازدیدکنندگان پیشنهاد دهد. اما اگر هدف این است که هیچ‌کس نداند سرویس کجا اجرا میشود، آن‌وقت هر پیوندی بین این دو یک نشتی است، و تعداد درستِ این پیوندها صفر است.
همین راه‌حل نصفه‌ونیمه است که به مردم آسیب می‌زند. اجرای هر دو از یک ماشین، با یک پایگاه‌داده، یک دامنه کوکی نشست و یک مجموعه فایل آپلودشده، درحالی‌که به خودتان می‌گویید این دو مخاطب از هم جدا هستند، یعنی یک پیکربندی اشتباه به‌تنهایی میتواند این تفکیک را فرو بریزد — و شما تا وقتی کس دیگری متوجه نشود، خودتان متوجه نمی‌شوید. اگر هر دو باید وجود داشته باشند و نباید به هم پیوند بخورند، پس باید دو استقرار روی دو ماشین با دو مجموعه اعتبارنامه جداگانه باشند، و هزینه عملیاتی همین است که بهای آن ویژگی‌ای است که می‌خواستید.
یک نکته کاربردی اگر تصمیم گرفتید این دو را پیوند بدهید: نشست‌ها و کوکی‌ها را به هر هاست محدود نگه دارید. کاربری که در سایت کلیرنت وارد شده و بعد از طریق آدرس onion می‌آید باید یک نشست تازه داشته باشد، نه یک نشست مشترک، وگرنه سازوکاری ساخته‌اید که این دو بازدید را برای هرکسی که یکی از آنها را ببیند به هم مرتبط میکند. و به آدرس onion لینک‌های canonical مخصوص خودش را بدهید، تا سایت به‌اصطلاح از سرِ کمک، کاربر Tor Browser را به همان هاست کلیرنتی که عمداً از آن دوری کرده برنگرداند.
چیزی که سمتِ میزبانی واقعاً باید درست انجام دهد
نیازمندی‌ها غیرمعمول‌اند، و برای همین یک میزبان عمومی اغلب گزینه بدی است. شما به یک مسیر خروجیِ بدون مانع به شبکه Tor نیاز دارید، چون این تنها نوع اتصالی است که سرویس شما برقرار میکند؛ برخی ارائه‌دهنده‌ها ترافیک دایرکتوری و رلهٔ Tor را کاملاً فیلتر میکنند، و شما این را وقتی می‌فهمید که سرویستان هرگز توصیف‌گری منتشر نمیکند. به ارائه‌دهنده‌ای نیاز دارید که سیاست کاربرد قابل‌قبولش صراحتاً و کتبی درباره Tor صحبت کرده باشد، نه با سکوت، چون همین سکوت است که اولین بار که کسی درباره یک موضوع کاملاً بی‌ربط شکایت کند، به یک ایمیل قطع سرویس تبدیل میشود. نیازی به IP ثابت، دامنه، گواهی یا هیچ پورت ورودیای ندارید — یعنی بیشتر آن چیزهایی که شرکت‌های میزبانی به‌عنوان مزیت رقابتی می‌فروشند، اینجا اصلاً بی‌ربط است.
پروفایل سوءاستفاده همان غافلگیری خوشایند ماجراست. یک نود خروجی (exit) از طرف غریبهها به اینترنت باز وصل میشود و به همین دلیل شکایت جمع میکند؛ این همان معامله‌ای است که هست، و برای همین اکزیت‌ها به ارائه‌دهنده‌ای با موضع مستند نیاز دارند. یک سرویس onion دقیقاً برعکس عمل میکند: هر اتصالی ورودی از شبکه Tor است، هرگز از طرف کسی با اینترنت باز تماس نمیگیرد، و در نتیجه اساساً هیچ ایمیل سوءاستفاده‌ای تولید نمیکند. این بار کاری آرامتر از رلهٔ کناری‌اش، و بسیار آرامتر از یک وبسرور عمومی است.
در BitVPS، اجرای Tor بهصورت کتبی مجاز است — رله، بریج، اکزیت و سرویس onion، همه به یک اندازه، با مستندسازی حالت اکزیت در صفحه abuse به‌جای واگذاشتن به شانس. صفحه میزبانی Tor اندازه‌گیری رله را پوشش میدهد؛ سرویس‌های onion سبک‌ترند. در عمل، یک پلن Growth با قیمت $13.50 با 4 vCPU، 8 گیگابایت RAM و آپلینک نامحدود، یک سرویس onion جدی را با جای کافی برای برنامه پشتش اجرا میکند، و یک پلن Starter با $8.50 برای یک سرویس کوچک کافی است. مکان را بر اساس موضع حقوقی‌اش انتخاب کنید نه تأخیرش: شش گام، تفاوت بین یک دیتاسنتر نزدیک و یک دیتاسنتر دور را تقریباً نامحسوس میکند.
صفحه شبکه ما ASN و پیرینگ را منتشر میکند، که اینجا به‌دلیلی غیرمستقیم اهمیت دارد. شما آدرسی را افشا نمی‌کنید، پس دلیل معمول اهمیت دادن به شبکه یک ارائه‌دهنده از بین می‌رود — اما میزبانی که زیرساخت خودش را علنی مستند میکند، همان میزبانی است که نوشته وقتی کسی درباره یک مشتری سؤال کند چه میکند، و واقعاً همین چیزی است که دارید می‌خرید.
مرز کجاست؟
ارزشش را دارد که درباره این موضوع صریح باشیم، چون این فناوری شهرتی دارد که با ترافیک واقعی‌اش هم‌خوانی ندارد. سرویس‌های onion یک لایه انتقال با یک ویژگی حریم خصوصی مشخص هستند، و کسانی که آنها را اجرا میکنند اکثریت قریب‌به‌اتفاق‌شان کاملاً معمولی‌اند: تحریریههای خبری که گزارش میگیرند، یک آرشیو بسته که نمی‌خواهد لاگ کند کدام ماشین کدام به‌روزرسانی را گرفته، پروژه‌های پیام‌رسانی و خودمیزبانی، مردمی در کشورهایی که اینترنت معمولی در آنها فیلتر است، و مدیرانی که فقط ترجیح می‌دهند رابط مدیریتی‌شان قابل‌اسکن نباشد. اجرای یک سرویس onion در اکثریت قریببهاتفاق حوزههای قضایی قانونی است، و این هیچ بیانیه‌ای درباره چیزی که میزبانی میکنید نیست.
چیزی که این فناوری نیست، تغییری در خودِ قوانین است. ارائه‌دهنده‌ای که اعلامیه‌های کپی‌رایت را نادیده می‌گیرد — و ما این کار را می‌کنیم، همان‌طور که آن راهنما توضیح میدهد — همچنان درباره محتوای سوءاستفاده جنسی از کودکان و تهدیدهای معتبر علیه افراد اقدام میکند، و سریع هم اقدام میکند: بازه زمانی اعلام‌شده ما برای این موارد چهار ساعت است، در برابر چهل‌وهشت ساعت برای همهچیز دیگر. این یک حفره در یک سیاست وگرنه بازِ ما نیست، خودِ سیاست همین است، و هیچ لایه انتقالی آن را تغییر نمیدهد. سیاست کاربرد قابلقبول کوتاه است و بهتر است پیش از ساختن بخوانیدش، نه بعدش.
نکته صادقانه دیگر این است که ناشناسی یک ویژگی سیستمی است، نه محصولی که بخرید. آدرس، ماشین را پنهان میکند؛ ولی رد پرداخت، رمز عبور تکراری، سبک نوشتار، دامنه‌ای که سال‌ها پیش با همان ایمیل ثبت کرده‌اید، یا اسکرین‌شاتی که مسیرهای فایل‌سیستم خودتان در آن است را پنهان نمیکند. اگر مدل تهدید جدی است، لایه انتقال آسان‌ترین بخش آن است و بخشی که کمترین زمان را رویش صرف خواهید کرد. راهنمای گسترده‌تر بقیه آن زنجیره را پوشش میدهد، و توضیح‌دهنده bulletproof hosting پادزهر مفیدی برای بازاریابی‌ای است که دور تا دور کل این موضوع را گرفته.
