عبارت عبور روی کلید خصوصی VPN در واقع از چه چیزی محافظت میکند
فایل روی دیسک را قفل میکند، نه تونل در حال اجرا یا ورود به حساب شما را. بیاموزید این درخواست چه چیزی را پوشش میدهد، چه چیزی را نه، و اگر افشا شد چه باید کرد.
درخواستی که هنگام شروع کلاینت VPN ظاهر میشود بهراحتی اشتباه خوانده میشود. این رمز عبور حساب VPN نیست، رمز عبور تونل نیست، و وارد کردن آن ثابت نمیکند که اتصال امن است. این یک نمایش ذخیرهشده از کلید خصوصی را باز میکند تا کلاینت بتواند ماده کلید را بخواند و از آن برای احراز هویت استفاده کند. هر اتفاقی که بعد از آن بیفتد مسئله دیگری است.
در عمل پاسخ در لبهها خراب میشود: مردم فرض میکنند عبارت عبور از تونل در حال اجرا محافظت میکند، یا تغییر آن نسخهای از کلید را که قبلاً افشا شده باطل میکند. هر دو فرض شکست میخورند، و هر دو بهگونهای شکست میخورند که یک اعتبارنامه در معرض دید میماند در حالی که اپراتور فکر میکند رسیدگی شده است.
یک گفتوگو، چند راز متفاوت
عبارت عبور کلید خصوصی یک فایل را رمزگشایی میکند. رمز عبور حساب شما را در یک سرویس احراز هویت میکند. رمز عبور واردات PKCS#12 بستهای را رمزگشایی میکند که یک کلید و گواهی آن را در بر دارد، و ممکن است همان رشته عبارت عبور خود کلید نباشد. این درخواستها میتوانند تقریباً یکسان به نظر برسند، و حدس زدن اینکه کدام راز کجا میرود همان راهی است که کلیدها در فیلد اشتباه چسبانده میشوند.
رمزنگاری خود تونل چیز چهارم است. کانال داده از کلیدهای نشستی استفاده میکند که در طول دستدادن مذاکره میشوند؛ عبارت عبور کلید خصوصی هیچ نقشی در محافظت از بستههای منفرد ندارد. اگر کسی بتواند فایل کلید را بخواند، میتواند عبارت عبور را خارج از شبکه حدس بزند، اما اگر بتواند بستهها را بخواند، عبارت عبور بیاهمیت است.
رمزنگاری روی دیسک چه چیزی را پوشش میدهد
کلید PEM رمزنگاریشده دو شکل دارد و سرآیند به شما میگوید کدام را دارید. شکل مدرن PKCS#8 با -----BEGIN ENCRYPTED PRIVATE KEY----- شروع میشود؛ شکل قدیمی PEM که هنوز در تنظیمات قدیمیتر OpenVPN رایج است با -----BEGIN RSA PRIVATE KEY----- شروع میشود و Proc-Type: 4,ENCRYPTED و خط DEK-Info را دقیقاً زیر آن دارد. فایل کلید خصوصی را زیر کلیدی رمزنگاریشده نگه میدارد که از عبارت عبور شما مشتق شده است، معمولاً از طریق KDF مبتنی بر رمز عبور با تعداد تکرار یا ضریب کار مشخص. مستندات OpenSSL pkey قالبها و گزینههای عبارت عبور را که هنگام خواندن اعمال میشوند پوشش میدهد.
دو پیامد دارد. عبارت عبور ضعیف با سرعتی که KDF اجازه میدهد بهصورت خارج از شبکه قابل حمله است، بنابراین مجوزهای فایل و دسترسی به نسخههای پشتیبان حتی وقتی فایل رمزنگاریشده است همچنان مهماند. و مهاجمی که فقط فایل را بدون عبارت عبور به دست میآورد باید حدس بزند؛ کسی که فایل و عبارت عبور را با هم به دست میآورد کلید را دارد، درست مثل اینکه هرگز رمزنگاری نشده بود.
head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout
head -3 سرآیند و در یک فایل قدیمی خطوط Proc-Type و DEK-Info را که رمزنگاری را ثابت میکنند نشان میدهد؛ یک خط بهتنهایی در هیچ جهتی مدرک نیست. خط pkey عبارت عبور را میپرسد و فقط نیمه عمومی را چاپ میکند، که ثابت میکند فایل و عبارت عبور کار میکنند بدون افشای کلید خصوصی. برای این بررسی از -text استفاده نکنید: اجزای خصوصی، privateExponent، prime1، prime2 و بقیه را چاپ میکند و آن خروجی هرگز نباید جایی چسبانده شود، نه در تیکت، نه در گفتوگو و نه در گزارش. فرمان PKCS#12 همچنین میگوید آیا بسته رمز عبور MAC یا رمزنگاری جداگانه دارد، که دانستن آن پیش از دادن بسته به همکار ارزش دارد.
وقتی کلید بارگذاری شد، چه چیزی را دیگر محافظت نمیکند
باز کردن برای آن فرایند رویدادی یکطرفه است. کلاینت کلید را از KDF میخواهد، فایل را رمزگشایی میکند و کلید خصوصی را تا زمانی که لازم دارد در حافظه نگه میدارد. از آن لحظه عبارت عبور هیچ چیز از نشست در حال اجرا را محافظت نمیکند: نه حافظه فرایند، نه دامپ هسته، نه نشست اشکالزدایی متصل به کلاینت، و نه نسخه پشتیبان ماشینی که هنگام استفاده از کلید گرفته شده است.
این همان مرزی است که یک کلید SSH با عبارت عبور یا گاوصندوق بازشده مدیر رمز عبور دارد. هزینه دزدیدن فایل در حالت سکون را بالا میبرد و در برابر بدافزاری که با کاربر شما اجرا میشود، برنامه مجازی که از کلاینت میخواهد امضا کند، یا مدیر سیستمی که میتواند حافظه را بخواند کاری نمیکند. آن را یک لایه بدانید، نه کنترلی که کلید را برای رها کردن اطراف امن میکند.
چرا درخواست مدام برمیگردد
کلاینتی که در هر اتصال مجدد دوباره میپرسد لزوماً خراب نیست. برخی کلاینتها عبارت عبور را برای نشست کش میکنند، برخی آن را در زنجیره کلید سیستمعامل ذخیره میکنند، و برخی را میتوان به کمککنندهای ارجاع داد که آن را تأمین میکند، بنابراین رفتار شما به کلاینت و پیکربندی آن بستگی دارد، نه به فایل کلید.
اگر درخواست تکراری شکایت واقعی است، پیش از حذف رمزنگاری از کلید، گزینههای کش و احراز هویت کلاینت را بررسی کنید. حذف عبارت عبور یک فایل محافظتشده را به کلید متن ساده تبدیل میکند و اتصال مجدد ساکت میشود به قیمت تنها کنترل سکون که داشتید. پاسخ بهتر معمولاً یک انبار اعتبارنامه پشتیبانیشده با همان مجوزهای فایلی است که به هر حال استفاده میکردید.
از دست رفتن و افشا شدن یک تعمیر نیستند
عبارت عبور گمشده از گواهی بازیابی نمیشود. گواهی ماده عمومی است که یک نام را به یک کلید پیوند میدهد؛ هیچ مسیری به کلید خصوصی و هیچ سرنخی درباره عبارت عبور در آن نیست. گزینههای عملی نسخه پشتیبان مجاز کلید یا هویت جدیدی است که از طریق فرایند عادی اپراتور صادر میشود. هر کس پیشنهاد 'بازیابی' عبارت عبور را بدهد پیشنهاد حدس زدن آن را داده است.
افشا شدن پاسخ متفاوتی میخواهد. رمزنگاری مجدد همان کلید با عبارت عبور جدید ماده کلید را بیتغییر میگذارد، بنابراین نسخهای که قبلاً جای دیگری باز شده هنوز کار میکند. تعمیر واقعی ابطال یا جایگزینی اعتبارنامه است: کلید و گواهی جدید صادر کنید، توزیع کنید و قدیمی را در همتا بازنشسته کنید. تا آن زمان، تغییر رمز عبور فایل خانهداری است، نه مهار. فایل قدیمی را تنها پس از تأیید کارکرد هویت جدید از نسخههای پشتیبان بیرون نگه دارید و ثبت کنید کدام شماره سریال یا اثر انگشت جایگزین آن شد.