گروه مشترک DH، رازهای تازه: چرا هزینهٔ حمله کمتر می‌شود
رازهای تازهٔ نشست یک گروه ضعیف در میدان متناهی را درست نمی‌کنند. استفادهٔ دوباره از یک گروه، گران‌ترین مرحلهٔ حمله را میان همهٔ تبادل‌هایی که با آن مذاکره می‌کنند تقسیم می‌کند.
پارامترهای گروه بنا به طراحی عمومی‌اند، و همین عمومی بودن است که نادیده گرفتنشان را آسان می‌کند. در Diffie-Hellman میدان متناهی، پیمانه و مولد مشترک‌اند، اما توان‌های خصوصی و کلیدهای نشست حاصل این‌گونه نیستند. مرحلهٔ گران حملهٔ غربال میدان اعداد به گروه وابسته است نه به یک تبادل، پس یک گروه ضعیف که همه‌جا استفاده شود به بدهی مشترک تبدیل می‌شود. عمومی خواندن پارامترها درست است و به موضوع ربطی ندارد، چون هزینه‌ای که دوباره استفاده می‌شود همان هزینهٔ حمله به همین گروه است.
نیمهٔ عمومی نیمهٔ آسیب‌پذیر نیست، و تله همین‌جاست
استدلال نیمه‌بندی معمول می‌گوید پارامترها در یک استاندارد منتشر شده‌اند، پس مهاجم از قبل آن‌ها را می‌داند و پنهان کردنشان چیزی را عوض نمی‌کرد. هر دو بند درست‌اند و هیچ‌کدام از دیگری نتیجه نمی‌شود. گروه پیش‌فرضی که ارسال می‌شود عمومی است، و گروه خصوصی‌ای که هفتهٔ گذشته ساختید هم برای هر کسی که دست‌دهی را کامل کند دیدنی است. پنهان‌کاری هرگز کنترل نبود؛ قدرت و اعتبارسنجی کنترل‌اند.
آنچه تغییر می‌کند تعداد جاهایی است که یک ضعف را شریک‌اند. سازمانی که گروه 2048 بیتی خودش را می‌سازد هزینهٔ حملهٔ خودش را می‌پردازد، در حالی که پیش‌فرض پروتکلی که میلیون‌ها نفر برمی‌گزینند یک هزینه را میان همه‌شان سرشکن می‌کند. به این معنا گروه نامتعارف خودبه‌خود بهتر نیست. گروه نامتعارفی که بیش از اندازه کوچک است فقط راز مشترک کوچک‌تری است که چشم‌های کمتری روی آن است.
اعتبارسنجی به اندازهٔ اندازه اهمیت دارد. همتایی که پیمانه‌ای با عامل‌های کوچک می‌فرستد، یا پیمانه‌ای که شکل مورد انتظار پروتکل را ندارد، می‌تواند حتی وقتی طول بیتی محترم به نظر می‌رسد اطلاعاتی دربارهٔ توان خصوصی نشت دهد. کتابخانه‌هایی که پارامترهای بدشکل را همان‌جا در ورودی رد می‌کنند کار واقعی انجام می‌دهند، و همین دلیل بدی است برای اینکه تجزیهٔ دست‌ساز پارامترها جای صرفه‌جویی در تلاش باشد.
پیش‌محاسبه واقعاً چه چیزی به مهاجم می‌دهد
غربال میدان اعداد مرحله‌ای دارد که فقط به عدد اول وابسته است، و خروجی آن در برابر هر تبادلی که از آن عدد اول استفاده می‌کند دوباره به کار می‌رود. تمام سازوکار پشت نگرانی تاریخی همین است: بخش گران یک بار پرداخت می‌شود و هزینهٔ حاشیه‌ای هر نشست بعدی کاهش می‌یابد. توان‌های تازه هنوز هر تبادل جداگانه را از یک ناظر منفعل محافظت می‌کنند، تا زمانی که گروه آن‌قدر بزرگ باشد که غربال را ناممکن کند. این دو گزاره با هم سازگارند، و بیشتر بحث‌های این موضوع از برداشتن یکی و رها کردن دیگری می‌آید.
مقالهٔ Logjam در سال 2015 تنزل به Diffie-Hellman 512 بیتی درجهٔ صادراتی را نشان داد و برآورد کرد حمله به گروه‌های بزرگ‌تر و پرکاربرد با منابع چشمگیر چه هزینه‌ای دارد. نمایش عینی بود، برآوردها برآورد بودند، و هیچ‌کدام شاهدی بر رمزگشایی یک نشست مشخص VPN نبود.
مقاله را برای سازوکار و برای تنزل نشان‌داده‌شده ارجاع دهید، نه به عنوان اندازه‌گیری استقرار خودتان. آمارهای قدیمی دربارهٔ اینکه چند سرور یک گروه پیش‌فرض را شریک بودند اینترنت آن سال را توصیف می‌کنند، نه شبکه‌ای که امروز می‌توانید بررسی کنید. آنچه ارزش انتقال دارد پرسش است: آیا دستگاه‌های شما هنوز گروهی را مذاکره می‌کنند که کوچک یا ضعیف اعتبارسنجی شده است؟
استانداردشده با ضعیف یکی نیست
RFC 7919 گروه‌های نام‌دار میدان متناهی را تعریف می‌کند تا دو سر با شناسه بر یک گروه توافق کنند و سیاستی یکدست اعمال کنند. استانداردشده بودن یک مزیت است، چون ابهام مذاکره را برمی‌دارد و به پیاده‌سازی اجازه می‌دهد اندازه‌های پشتیبانی‌نشده را رد کند. گروه نام‌دار تنها وقتی ضعیف است که اندازه‌اش زیر سیاستی باشد که ادعا می‌کنید پیروی می‌کنید، نه به این دلیل که در سندی آمده است. همین منطق برای گروه‌های خم بیضوی هم صادق است، که ساختار و شیوه‌های شکست متفاوتی دارند.
هنگام استدلال دربارهٔ آن‌ها سازه‌ها را جدا نگه دارید. نتیجه‌ای دربارهٔ Diffie-Hellman میدان متناهی چیزی دربارهٔ X25519 نمی‌گوید، و نتیجه‌ای دربارهٔ گروه MODP 1024 بیتی چیزی دربارهٔ گروه 3072 بیتی نمی‌گوید. سیاست قدرت به ازای هر سازوکار، هر اندازه و هر نسخهٔ پروتکل است، و به همین دلیل عبارت رمزنگاری قوی یک گزارهٔ قابل بازبینی نیست.
احراز هویت نیمهٔ دیگر است و جایگزین نمی‌شود. گروه قوی بدون بررسی همتا مهاجم را در میان می‌گذارد، و گواهی معتبر نمی‌تواند یک تبادل 768 بیتی را نجات دهد. آن‌ها را دو خط مستقل ببینید، سپس تأیید کنید که هر دو واقعاً مذاکره می‌شوند.
گروه مذاکره‌شده را روی یک اتصال واقعی بخوانید
گروه مذاکره‌شده را از دستگاه بخوانید نه از قالب پیکربندی. قالب‌ها قصد را توصیف می‌کنند، و مقدار جالب همان است که دو طرف در آخرین دست‌دهی بر آن توافق کردند. در نقطهٔ پایانی IPsec خروجی وضعیت معمولاً پیشنهاد انتخاب‌شده را چاپ می‌کند، از جمله گروه MODP.
آن خط را پیش و پس از تغییر سیاست ثبت کنید و هر دو را در سابقهٔ تغییر نگه دارید. مقایسه همان شاهد است.
ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -nooutاگر پس از تغییر، وضعیت هنوز گروه قدیمی را نشان می‌دهد، اتصال دوباره مذاکره نکرده و ویرایش پیکربندی چیزی را ثابت نکرده است. همتا را دوباره راه‌اندازی کنید یا انجمن امنیتی را پاک کنید، سپس وضعیت را دوباره بخوانید. سیاستی که فقط بر اتصال‌های تازه اعمال شود، تونل‌های دیرپا را تا وقتی برپا بمانند روی پارامترهای قدیمی نگه می‌دارد.
گروه و هویت همتا را جداگانه بررسی کنید
آنچه را گروه محافظت می‌کند از اینکه چه کسی آن سوی دیگر است جدا کنید. روش تبادل کلید، اندازهٔ گروه و روش احراز هویت را سه فیلد ثبت کنید، چون مستقل از هم شکست می‌خورند. تونلی که گروه 3072 بیتی را مذاکره کرده اما هر گواهی‌ای را می‌پذیرد همان خطر تونلی نیست که همتا را سنجاق می‌کند و از گروه 2048 بیتی استفاده می‌کند.
معیارهای پذیرش را پیش از شروع بازبینی بنویسید تا نتیجه مقایسه باشد نه نظر. حداقل اندازهٔ گروه برای هر نسخهٔ پروتکل، فهرست مجاز گروه‌های نام‌دار و بررسی اجباری همتا کافی است تا تصمیم مکانیکی شود. ابهام در آن فهرست است که بازبینی را به بحث تبدیل می‌کند، و بحث‌ها جبران نمی‌شوند. آن‌گاه خروجی فهرستی از نقاط پایانی است که قاعدهٔ اعلام‌شده را نقض می‌کنند.
ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'حلقه را با بازخوانی مقادیر مذاکره‌شده پس از رفع ببندید. یک فایل پیکربندی منطبق شاهدی بر این نیست که تونلی آن را پذیرفته است. خروجی وضعیت و یک دست‌دهی تازه شاهدند، و جمع‌آوری‌شان از جلسه دربارهٔ اینکه لازم‌اند کمتر وقت می‌گیرد.