خطاهای TLS فقط روی VPN شرکتی: مخزن اعتماد درست را اصلاح کنید

ساخت Go، نصب Composer و کلاینت Python همه در خانه کار می‌کنند و همه داخل VPN شرکت شکست می‌خورند. این الگو درباره مسیر به شما می‌گوید، نه درباره برنامه. چیزی روی تونل زنجیره گواهی‌ای را که فرایند شما می‌بیند تغییر داده است، یا دست‌دادن را پیش از رسیدن هر زنجیره‌ای بازنشانی کرده است. این دو خطا در ترمینال شبیه هم به نظر می‌رسند و پاسخ‌های کاملاً متفاوتی می‌خواهند.

سه پیام، سه سازوکار

خطای x509 certificate signed by unknown authority یعنی زنجیره‌ای ساخته شده و ریشه آن در مخزن اعتمادی که آن فرایند استفاده می‌کند نیست. خطای self-signed certificate in certificate chain معمولاً یعنی یک پروکسی بازرسی با گواهی خودش پاسخ داده است، که زنجیره‌ای است که محیط اجرای شما آن را نمی‌شناسد. یک SSL EOF در هنگام دست‌دادن یعنی اتصال پیش از ارسال هر گواهی قابل استفاده‌ای بسته شده است، و این یک دستگاه میانی است که ClientHello را رد می‌کند، و اصلاً مسئله اعتماد نیست.

افزودن یک پرچم ناامن هر سه پیام را ناپدید می‌کند در حالی که شنود سر جایش می‌ماند، و بررسی‌ای را حذف می‌کند که یک مهاجم واقعی را می‌گرفت.

بسته‌ای را پیدا کنید که فرایند واقعاً می‌خواند

ریشه شرکتی که در مخزن Windows نصب شده، مرورگرها و برنامه‌های .NET را که به مخزن سیستم مراجعه می‌کنند اصلاح می‌کند. برای ساختی که داخل یک کانتینر اجرا می‌شود و بسته CA خودش را دارد کاری نمی‌کند، و نه برای فرایند Python که از certifi استفاده می‌کند یا فرایند Node که از فهرست همراه خودش استفاده می‌کند. Go مجموعه سیستمی محیطی را می‌خواند که باینری در آن اجرا می‌شود، یعنی کانتینر، نه لپ‌تاپ. بنابراین یک ماشین هم‌زمان هم مرورگر کارکننده و هم ابزار ساخت شکست‌خورده تولید می‌کند.

از ابزار بپرسید، نه اینکه فرض کنید. python3 -c "import ssl; print(ssl.get_default_verify_paths())" فایل‌هایی را چاپ می‌کند که Python به آن‌ها مراجعه خواهد کرد، و node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" نشان می‌دهد آیا از پیش بازنویسی‌ای تنظیم شده است. برای کانتینر، همان بررسی را داخل تصویر اجرا کنید، چون همان محیطی است که ساخت واقعاً استفاده می‌کند.

یک ریشه همان‌جا نصب کنید که ساخت اجرا می‌شود

ریشه بازرسی را به شکل فایل PEM از IT بگیرید و پیش از اعتماد، اثر انگشت آن را از کانالی جداگانه بررسی کنید. روی تصاویر مبتنی بر Debian آن را در /usr/local/share/ca-certificates/ کپی کنید و update-ca-certificates را اجرا کنید؛ تصاویر خانواده RHEL پس از گذاشتن فایل در /etc/pki/ca-trust/source/anchors/ از update-ca-trust استفاده می‌کنند. در ساخت کانتینر، این گام‌ها را پیش از فرمان شکست‌خورده اضافه کنید تا لایه بالای نصب وابستگی‌ها ذخیره شود.

برای یک devcontainer محلی، فایل PEM را سوار کنید و همان فرمان به‌روزرسانی را در آغاز اجرا کنید، به‌جای اینکه آن را در تصویری شخصی بپزید که هیچ‌کس دیگری نمی‌تواند بازتولید کند. ابزارهایی که بسته خودشان را می‌آورند به بازنویسی مستند خود نیاز دارند: pip تنظیم گواهی دارد، npm تنظیم cafile دارد، و بیشتر بقیه متغیرهای محیطی استاندارد را می‌پذیرند.

این همان پذیرفتن هر گواهی نیست. شما یک ریشه مشخص را که از طرف بازرسی‌کننده گرفته‌اید به یک محیط اضافه می‌کنید، و بررسی برای هر زنجیره دیگر روشن می‌ماند. ثبت کنید کدام فایل اضافه شد و چه زمانی منقضی می‌شود، چون ریشه بازرسی مانند هر CA دیگری تمدید می‌شود.

وقتی دست‌دادن پیش از یک گواهی می‌میرد

اگر چیزی ارائه نشود، هیچ تغییری در مخزن اعتماد کمکی نمی‌کند. همان درخواست را با تونل روشن و خاموش مقایسه کنید، سپس زنجیره را مستقیماً با openssl s_client -connect host:443 -servername host -showcerts بررسی کنید. اتصالی که بیرون از VPN کامل می‌شود و درون آن بازنشانی می‌شود، تصمیم سیاستی دستگاه میانی است، و درمان آن یک استثنا برای همان میزبان است نه گواهی دیگر. بخواهید که مخزن بسته یا نقطه پایانی API بدون تغییر عبور کند.

تقسیم تونل تا ابزار VPN را دور بزند، بازرسی آن ترافیک را دور می‌زند، که ممکن است سیاست را نقض کند و ابزار را قابل اعتماد نمی‌کند.

نتیجه را برای هر ابزار بنویسید

یادداشتی کوتاه که باینری، فایل اعتمادی که می‌خواند، متغیر محیطی در بازی و استثنای تأییدشده را فهرست کند، تمام تشخیص را از نفر بعدی دریغ می‌کند. یادداشت را برای هر ابزار نگه دارید نه هر لپ‌تاپ، چون لپ‌تاپ به‌ندرت همان چیزی است که تغییر کرده.

و دو جمله را در تیکت جدا نگه دارید: ما یک ریشه شرکتی مشخص نصب کردیم، و بررسی را خاموش کردیم. فقط یکی از آن دو یک اقدام پشتیبانی است.