P12 قدیمی در OpenSSL 3 شکست می‌خورد: رمز عبور اشتباه یا رمزنگاری قدیمی؟
عبارت عبوری را که اشتباه تایپ شده از بسته RC2 قدیمی که OpenSSL 3 از بازکردنش سر باز می‌زند جدا کنید، سپس فایل را بدون برداشتن محافظت کلید دوباره مهر و موم کنید.
کادر گفتگوی ورود رمز عبور شما را می‌گیرد، لحظه‌ای می‌چرخد و بعد می‌گوید که نمی‌تواند بسته را بخواند. هیچ چیز در آن پیام نمی‌گوید که عبارت عبور را اشتباه تایپ کرده‌اید یا فایل با رمزنگاری مهر شده که کارخواه دیگر آن را ارائه نمی‌دهد. این‌ها خطاهای متفاوتی با راه‌حل‌های متفاوت هستند و انتخاب اشتباه به تنزل نسخه کارخواه می‌انجامد که فقط تصمیم را به تعویق می‌اندازد. تماشای مرحله‌ای که کارخواه در آن متوقف می‌شود آن‌ها را در حدود یک دقیقه از هم جدا می‌کند.
بین کادر گفتگو و فهرست گواهی‌ها چه رخ می‌دهد
فایل .p12 یک محفظه است، نه گواهی. درون آن یک یا چند کیسه گواهی و یک کیسه کلید خصوصی وجود دارد که با کلیدی برگرفته از رمز عبور شما رمزنگاری شده، به‌علاوه یک بررسی یکپارچگی به نام MAC روی کل فایل. بازکردن آن یعنی بررسی همان MAC، رمزگشایی کیسه کلید و تطبیق گواهی با کلیدی که از آن بیرون می‌آید.
مشکل رمز عبور در مرحله MAC پیش می‌آید. مشکل رمزنگاری دیرتر پیش می‌آید، هنگامی که کیسه کلید باید باز شود و نسخه‌ای که این کار را می‌کند هیچ پیاده‌سازی‌ای برای الگوریتم نام‌برده در فایل ندارد.
حالت دوم در سامانه‌های امروزی رایج است زیرا OpenSSL 3 گروهی از الگوریتم‌های قدیمی را به یک ارائه‌دهنده legacy اختیاری منتقل کرد. بسته‌هایی که OpenSSL 1.x صادر می‌کند معمولاً گواهی‌ها را با RC2 40 بیتی و کلید خصوصی را با Triple DES سه‌کلیدی مهر می‌کرد. نسخه پیش‌فرض OpenSSL 3 هنوز MAC را با رمز عبور درست شما بررسی می‌کند و سپس روی کیسه شکست می‌خورد، پس رمز عبور هرگز اشتباه نبوده و تایپ دوباره آن چیزی را تغییر نمی‌دهد.
محفظه را بدون نوشتن کلید به بیرون بخوانید
از نسخه OpenSSL روی رایانه خودتان بخواهید فایل را تجزیه کند و نقطه‌ای را که در آن تسلیم می‌شود بخواند. بررسی بدون فایل خروجی کلید را رمزنگاری‌شده روی دیسک باقی می‌گذارد و همین تنها دلیل ایمن بودن این مرحله روی میزبان اشتراکی است.
openssl pkcs12 -in vpn-identity.p12 -info -nooutروی یک بسته legacy با رمز عبور درست، این کار ویژگی‌های کیسه را چاپ می‌کند و سپس با digital envelope routines::unsupported متوقف می‌شود. با رمز عبور اشتباه پیش از خواندن هر کیسه‌ای Mac verify error: invalid password? می‌گیرید. دو پیام در جهت‌های مخالف اشاره می‌کنند و این دقیقاً همان اطلاعاتی است که کارخواه پنهان کرد.
اگر خطا مربوط به الگوریتم پشتیبانی‌نشده باشد، همان فرمان را دوباره با افزودن -legacy و بدون تغییر چیز دیگری اجرا کنید. این پرچم ارائه‌دهنده legacy را فقط برای همان فرایند بارگذاری می‌کند. کارخواه VPN را به تجزیه بسته‌های قدیمی وادار نمی‌کند، به سیاست رمزنگاری سامانه دست نمی‌زند و یک اندازه‌گیری است نه تعمیر، زیرا فایل هنوز باید جایگزین شود.
کدام خطا یعنی کدام مرحله
یک جدول کوتاه سه نتیجه را از هم جدا نگه می‌دارد و جمله‌بندی مهم‌تر از جایی است که کادر گفتگو ظاهر شد.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
متنی مانند not enough data یا header too long به هیچ‌یک از دو گروه اول تعلق ندارد. این یک مشکل قالب است: فایل DER که به .pem تغییر نام داده، نسخه‌ای که ویرایشگری با بازنویسی پایان خطوط خرابش کرده، یا دانلود ناقص. پیش از آنکه به رمزنگاری‌ها نگاه کنید، چک‌سام را با آنچه صادرکننده فرستاده مقایسه کنید.
Mac verify error را فقط شواهدی درباره رمز عبور بدانید. یعنی MAC محاسبه‌شده از آنچه تایپ کردید با مقدار ذخیره‌شده نمی‌خواند، که با یک غلط تایپی، با رمز عبوری که از ورود قبلی در حافظه پنهان مانده، یا با فایلی که با عبارت عبور دیگری دوباره صادر شده رخ می‌دهد. درباره قدیمی بودن الگوریتم‌های درون چیزی نمی‌گوید.
بسته‌ای بسازید که کارخواه واقعاً بتواند بازش کند
وقتی تجزیه‌گر legacy تأیید کرد که فایل سالم است، راه‌حل پایدار جایگزینی است که کارخواه هدف الگوریتم‌هایش را پشتیبانی می‌کند: AES-256-CBC برای کیسه‌های کلید و گواهی، PBKDF2 با SHA-256 برای اشتقاق و SHA-256 برای MAC. مدیر PKI شما می‌تواند آن را از همان مواد کلید صادر کند و گواهی درون آن همانی می‌ماند که سرورهایتان از پیش به آن اعتماد دارند.
وقتی باید به‌صورت محلی تبدیل کنید، از ابزار pkcs12 بخواهید کیسه‌ها را دوباره مهر و موم کند نه اینکه اول آن‌ها را خالی کند. هر دو عبارت عبور را با خواندن از یک فایل بیرون از تاریخچه پوسته نگه دارید.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passتبدیل موفق چیزی درباره انقضا، کاربرد کلید، تطبیق کلید خصوصی یا اعتماد سرور به زنجیره صادرکننده نمی‌گوید. بسته‌بندی دوباره یک تغییر حمل‌ونقل است نه تمدید، و هر یک از آن‌ها هنوز بررسی خودش را می‌خواهد.
از هر دستورالعملی که کلید میانی بدون محافظت می‌نویسد یا رمز عبور خروجی خالی می‌گذارد بگذرید، فقط به این دلیل که کارخواه بعداً فایل را پذیرفت. بسته خواندنی با محافظت برداشته‌شده نتیجه‌ای بدتر از همان خطای ورودی است که با آن شروع کردید.
تأیید کنید که کارخواه همان فایلی را وارد کرده که ساختید
تجزیه پاک در ترمینال ثابت می‌کند که محفظه معتبر است. ثابت نمی‌کند که کارخواه آن را انتخاب کرده، زیرا یک نمایه باقی‌مانده می‌تواند همچنان به فایل قدیمی اشاره کند و برخی کارخواه‌ها هویت واردشده را زیر نامی که شما انتخاب نکرده‌اید ذخیره می‌کنند.
هویتی را که می‌خواهید وارد کنید چاپ کنید و آن را با آنچه کارخواه در نمای گواهی‌هایش نشان می‌دهد مقایسه کنید.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256نخست ورودی نمایه کهنه را بردارید، سپس وارد کنید. اگر کارخواه موضوع یا اثر انگشتی را که بارگذاری کرده ثبت می‌کند، آن را با خط بالا تطبیق دهید؛ اگر فقط یک نام دوستانه نشان می‌دهد، به‌جای آن تاریخ انقضا را بررسی کنید، چون اشتباه گرفتنش با گواهی دیگری از همان صادرکننده سخت‌تر است.
مرجع PKCS12 گزینه‌های ارائه‌دهنده، عبارت عبور و خروجی استفاده‌شده در اینجا را فهرست می‌کند. نکته این است که ارائه‌دهنده legacy را بیرون از محیط کارخواه نگه دارید: با آن اندازه بگیرید، بدون آن تحویل دهید و کلید خصوصی را روی دیسک محافظت‌شده بگذارید.