رمزنگاری سرتاسری لایه‌ای اضافه است، نه مجوز نادیده‌گرفتن هشدار TLS یا اعتماد به کد دستکاری‌شده.
TLS و رمزنگاری سرتاسری دو مرز متفاوت می‌سازند. این مرزها در ارزیابی VPN و پروکسی نیز اهمیت دارند. TLS معمولاً ارتباط دستگاه شما با سرویس را محافظت می‌کند؛ رمزنگاری سرتاسریِ درست و احرازشده، محتوای گفتگو را تا دستگاه گیرنده محافظت می‌کند. خواندن لایهٔ TLS الزاماً به معنی خواندن محتوای سرتاسری نیست، اما نباید از این واقعیت نتیجه گرفت که امنیت TLS دیگر اهمیتی ندارد.
اگر یک واسط بتواند اتصال امن را خاتمه دهد، ممکن است علاوه بر مشاهدهٔ دادهٔ انتقالی، پاسخ‌ها یا کد برنامهٔ وب را هم تغییر دهد. به همین دلیل عبارت «دورزدن TLS با LVR1» توصیف مناسبی برای امنیت یک پیام‌رسان نیست.
یک گواهی ریشه چگونه امکان بازرسی را ایجاد می‌کند؟
در اتصال HTTPS، دستگاه زنجیرهٔ گواهی سرور و نام میزبان را بررسی می‌کند. اگر واسط گواهی‌ای ارائه کند که برنامه آن را معتبر بداند، ممکن است دو اتصال جدا بسازد: یکی با کاربر و دیگری با سرور واقعی. در این حالت واسط پایان یکی از اتصال‌های TLS است، نه شنونده‌ای که صرفاً با نگاه‌کردن به بسته‌ها رمز را شکسته باشد.
نصب یک گواهی دلخواه به‌تنهایی کافی نیست؛ برنامه باید به آن اعتماد کند و بررسی‌های اتصال هم باید پذیرفته شوند. مستندات پیکربندی امنیت شبکهٔ اندروید توضیح می‌دهد که سیاست اعتماد می‌تواند برای هر برنامه متفاوت باشد. برنامه‌هایی که Android 7.0 و بالاتر را هدف می‌گیرند، به‌طور پیش‌فرض به گواهی‌های افزوده‌شده توسط کاربر اعتماد نمی‌کنند، مگر پیکربندی دیگری داشته باشند.
این یک سازوکار فنی عمومی است. از آن نمی‌توان بدون مدرک دربارهٔ یک اپراتور، کشور یا رخداد مشخص حکم داد. اختلال یا فیلترینگ به‌تنهایی اثبات بازرسی موفق TLS نیست.
اگر TLS باز شود، چه چیزی دیده می‌شود؟
| نوع داده یا وضعیت | پیامد احتمالی بازرسی TLS |
|---|---|
| محتوایی که فقط با HTTPS محافظت شده | واسطِ مورداعتماد ممکن است متن را ببیند |
| پیام از قبل رمزنگاری‌شده با کلید معتبر گیرنده | واسط معمولاً با متن رمز مواجه است، نه متن پیام |
| دادهٔ مسیریابی، نشست یا درخواست‌های جانبی | میزان افشا به قالب و طراحی سرویس بستگی دارد |
| کد نسخهٔ وب که از همان مسیر می‌رسد | تغییر کد می‌تواند امنیت نقطهٔ پایانی را تهدید کند |
| سرویس از دسترس خارج یا ترافیک مسدود شود | رمزنگاری به‌تنهایی اتصال را برقرار نمی‌کند |
محافظت محتواییِ E2EE به اصالت کلید گیرنده و سلامت نرم‌افزار دو طرف هم وابسته است. اگر مهاجم کلید اولیه را جایگزین کند یا برنامه‌ای که پیام را پیش از رمزنگاری می‌بیند دستکاری شود، صرف وجود AES یا ML-KEM کافی نیست.
چرا نسخهٔ وب به TLS سالم نیاز دارد؟
برنامهٔ وب معمولاً کد اجرایی را از سرور دریافت می‌کند. اگر آن کد مخرب باشد، می‌تواند پیش از رمزنگاری یا پس از رمزگشایی به محتوا دسترسی داشته باشد. رمزنگاری سرتاسری را نمی‌توان مستقل از نحوهٔ تحویل و اجرای کد ارزیابی کرد.
در نسخهٔ نصب‌شده نیز اصالت بسته، به‌روزرسانی‌ها و سلامت سیستم‌عامل مهم‌اند. امضای بسته و بررسی هش مفیدند، اما آزمون کامل امنیت برنامه نیستند. مدل تهدید لیوارا نیز می‌گوید اگر مهاجم هم فایل و هم هشِ نمایش‌داده‌شده را عوض کند، تطابق هش به‌تنهایی اصالت را ثابت نمی‌کند.
لیوارا چه ادعایی دارد؟
طبق مستندات امنیت لیوارا، پیام‌های مستقیم از LVR1 و گروه‌های خصوصیِ سازگار از LGS1 استفاده می‌کنند. مستندات، ترکیب P-256 و ML-KEM-768 و رمزنگاری محتوای پیام را شرح می‌دهد. این توضیحات ادعای محصول است، نه نتیجهٔ یک ممیزی مستقل در این مقاله.
همان صفحه حفظ فرادادهٔ مسیریابی و عمومی‌بودن کانال‌های انتشار را هم بیان می‌کند. بنابراین نتیجهٔ صحیح این نیست که «همهٔ اطلاعات پنهان می‌شود» یا «هیچ اعتماد شبکه‌ای لازم نیست». نتیجه این است که حفاظت محتوای خصوصی باید جدا از اتصال، تحویل کلید، کد برنامه و فراداده بررسی شود.
با هشدار گواهی چه کنیم؟
- هشدار مرورگر یا برنامه را برای ادامهٔ چت حساس نادیده نگیرید.
- تاریخ دستگاه و نشانی دقیق سرویس را بررسی کنید؛ هر خطای گواهی لزوماً حمله نیست.
- اگر دستگاه سازمانی است، سیاست مدیریت و گواهی‌های نصب‌شده را از مسئول مجاز بپرسید؛ تنظیمات مدیریت‌شده را خودسرانه تغییر ندهید.
- گواهی یا پروفایلی را صرفاً به درخواست یک پیام ناشناس نصب نکنید.
- در گفتگوهای حساس، اثرانگشت کلید را از مسیری مستقل با مخاطب تطبیق دهید؛ تطبیق کلید جایگزین رفع هشدار TLS نیست.
پرسش‌های رایج
آیا VPN همهٔ این مشکلات را حل می‌کند؟
خیر. VPN می‌تواند مسیر مشاهدهٔ ترافیک را عوض کند، اما دستگاه آلوده، گواهی مورداعتماد مخرب یا کد وب دستکاری‌شده را خودکار اصلاح نمی‌کند.
آیا احراز هویت بدون ارسال رمز عبور کافی است؟
خیر. پروتکل احراز هویت، مدیریت نشست و رمزنگاری پیام کارکردهای متفاوتی دارند. یک صفحهٔ ورود جعلی یا کد مخرب می‌تواند خودِ ورودی کاربر را پیش از اجرای پروتکل دریافت کند.
اصل کاربردی: E2EE لایهٔ ارزشمندی است؛ آن را مجوز نادیده‌گرفتن گواهی‌ها، اصالت برنامه یا تأیید کلیدها ندانید.
