اپل اعتماد به گواهی‌های ناامن eMudhra را از راه دور پس گرفت؛ یک درز اما روی مک باز مانده
اوایل اکتبر، یک پژوهشگر امنیتی کشف کرد کلیدهای خصوصی هشت گواهی میانی از eMudhra — یک مرجع صدور گواهی هندی — ضعیف‌اند؛ کلیدهایی که می‌شد با آن‌ها خود را جای وب‌سایت‌های معتبر جا زد. اپل از ۱۹ اکتبر این گواهی‌ها را مسدود کرده و برای بیشتر کاربران هیچ اقدامی لازم نیست. اما یک استثنا هنوز چشم‌به‌راه آپدیت macOS است و همین، داستان را جالب‌تر می‌کند.
برای اینکه بفهمیم ماجرا چرا مهم است، برگردیم به اینکه وقتی آدرس سایتی را باز می‌کنید چه می‌شود. پیش از بارگذاری صفحه، مرورگر گواهی دیجیتال آن سایت را می‌خواند تا مطمئن شود همان است که ادعا می‌کند و بعد ارتباط رمزنگاری‌شده برقرار شود. این گواهی‌ها را نهادهایی به نام «مرجع صدور گواهی» صادر می‌کنند و مرورگرها فهرستشان را از پیش در خود نگه می‌دارند. مراجع بزرگ‌تر می‌توانند به نهادهای دیگر اجازه صدور گواهی بدهند؛ به این‌ها گواهی میانی می‌گویند و زنجیره اعتماد از همین‌جا ساخته می‌شود. اگر یک حلقه از این زنجیره سست شود، سستی‌اش به همه کسانی می‌رسد که به آن تکیه کرده‌اند.
eMudhra شرکتی هندی است در همین حوزه و گواهی‌هایی صادر می‌کند که هویت یک سایت را برای مرورگر تأیید می‌کنند. گواهی‌های میانی این شرکت در Safari، کروم، اج و فایرفاکس پذیرفته شده بود؛ یعنی عملاً هر مرورگر بزرگی به آن‌ها اعتماد می‌کرد. همان پژوهشگرِ اوایل اکتبر متوجه شد کلیدهای خصوصی مرتبط با هشت گواهی میانی این شرکت ضعیف‌اند و می‌توان از آن‌ها برای جعل هویت سایت‌های دیگر استفاده کرد.
واکنش اپل سریع و بی‌سروصدا بود. در سند پشتیبانی خود نوشته که از ۱۹ اکتبر جلوی این گواهی‌های آسیب‌دیده را در Safari، Mail و هر برنامه‌ای که از چارچوب‌های شبکه و امنیت اپل استفاده می‌کند گرفته است. این مسدودسازی خودکار انجام می‌شود و به‌روزرسانی نرم‌افزاری نمی‌خواهد؛ صاحب iPhone، iPad یا مک لازم نیست تنظیمی را عوض کند یا بسته‌ای نصب کند. تا این لحظه هم هیچ گزارشی از سوءاستفاده واقعی از این کلیدها منتشر نشده — ضعف کلیدها تأیید شده، اما بهره‌برداری از آن‌ها نه. این تمایز را باید دقیق نگه داشت.
استثنا اما جایی است که کمتر به چشم می‌آید: ابزارهای خط فرمان مک. بخشی از این ابزارها فهرست مراجع مورد اعتماد را از فایلی محلی به نام /etc/ssl/cert.pem می‌خوانند و این فایل تنها با آپدیت سیستم‌عامل بازنویسی می‌شود. اپل می‌گوید بعضی از این ابزارها تا انتشار آپدیت macOS، گواهی‌های آسیب‌دیده را می‌پذیرند؛ تاریخی هم برای آن آپدیت اعلام نشده است.
این استثنا تقریباً همه کاربران عادی را بیرون می‌گذارد. کسانی که سروکارشان به آن می‌افتد مدیران سیستم و توسعه‌دهندگانی هستند که در ترمینال اتصال‌های TLS می‌سازند یا بررسی می‌کنند، یا اسکریپت‌هایی دارند که همین کار را خودکار انجام می‌دهند. برای آن‌ها مهم‌ترین پرسش این است: ابزار خط فرمان در این فاصله به کدام فهرست اعتماد تکیه می‌کند؟
اپل در همان سند راه‌حل موقت را هم نوشته است: حذف گواهی‌های مرجع ریشه از فایل /etc/ssl/cert.pem. این کار در سطح مدیر سیستم است و پیش از دست زدن به آن باید متن سند را خواند؛ ویرایش نادرست این فایل می‌تواند ابزارهای وابسته به TLS را از کار بیندازد. برای بقیه، مسیر کوتاه‌تر است و هیچ کاری در آن نیست.
اپل هم تنها بازیگری نبود که واکنش نشان داد؛ شرکت‌های پشت کروم، اج و فایرفاکس نیز برای محافظت از کاربرانشان اقدام کرده‌اند. نکته آموزنده‌تر — و این برداشت خودم است، نه بخشی از خبر — جای دیگری است: اعتماد به یک مرجع گواهی، بدون آپدیت سیستم‌عامل و از راه دور پس گرفته شد. همین ویژگی باعث شد بیشتر دستگاه‌ها از همان روز اول پوشش بگیرند، بی‌آنکه صاحبانشان خبردار شوند؛ و دقیقاً همین است که ارزش گفتن دارد.
با این حال، پرونده eMudhra با یک بیانیه بسته نمی‌شود. معلوم نیست آپدیت macOS کِی منتشر می‌شود، معلوم نیست کدام نسخه‌های مک آن را دریافت می‌کنند و معلوم نیست در این فاصله کسی سراغ سوءاستفاده از این کلیدها می‌رود یا نه. چیزی که معلوم است دوگانگی مسیر ترمیم است: بخش بزرگی از کاربران از ۱۹ اکتبر محافظت شده‌اند و عملاً کاری هم از دستشان برنمی‌آید، و گروه کوچک‌تری که با ترمینال کار می‌کند باید یا منتظر بماند یا طبق سند اپل دستی اقدام کند. تشخیص اینکه در کدام دسته‌اید ساده‌تر از آن است که به نظر می‌رسد؛ اگر همین حالا از خودتان می‌پرسید /etc/ssl/cert.pem چیست، احتمالاً در گروه اول هستید.
