האם תעודת RSA יכולה לעבוד עם dh none ב-OpenVPN?

הנה תצורת שרת שאומרת dh none לצד תעודה שאומרת RSA, יחד עם חשד מטריד שאחד מהם חייב להיות שגוי. שום דבר אינו שגוי. התעודה חותמת ומאמתת; החלפת המפתחות מקימה סוד משותף. אלה שתי משימות שונות באותה לחיצת יד, ו-TLS מאפשר לתעודת RSA לאמת לחיצת יד שמשתמשת בהסכם אפמרי על עקומה אליפטית.

הבלבול מגיע בדרך כלל עם מדריך הגירה. הוא אומר להחליף את קובץ פרמטרי ה-DH ב-dh none, הקורא מבחין שהתעודה אינה תעודת עקומה אליפטית, ושתי העובדות נתפסות כסתירה.

מדוע שתי ההגדרות נראות קשורות

תצורת OpenVPN הישנה יותר דרשה קובץ פרמטרי DH משום ש-Diffie-Hellman בשדה סופי זקוק לפרמטרי תחום ששני הצדדים מסכימים עליהם. ההוראה dh הצביעה על אותו קובץ. כאשר פריסה עוברת ל-ECDH, הפרמטרים מגיעים מעקומה בעלת שם במקום, והקובץ אינו נחוץ עוד, וזה מה ש-dh none מבטא.

תעודות הן ציר נפרד. הן נושאות מפתח ציבורי וחתימה שמוכיחים את זהות השרת, והמפתח הזה יכול להיות RSA או עקומה אליפטית ללא תלות באופן שבו מוסכם מפתח ההפעלה. לחיצת יד שמשתמשת ב-ECDHE להסכם מפתח וב-RSA לאימות היא רגילה ונפוצה ופרוסה באופן נרחב.

השמות מחמירים את החפיפה. עקומה אליפטית מופיעה הן בשמות חבילות ECDHE והן בשמות ECDSA, ולכן קל להניח שכל חיבור שמזכיר עקומה חייב לכלול תעודת עקומה. זה אינו המקרה.

איך לקרוא נכון שם חבילת TLS 1.2

קחו ECDHE-RSA-AES256-GCM-SHA384. האסימון הראשון הוא משפחת החלפת המפתחות: Diffie-Hellman אפמרי על עקומה אליפטית. השני הוא משפחת האימות: RSA. השאר מתאר את הגנת הרשומות ואת ה-hash שמשמש בלחיצת היד.

חבילת ECDHE-ECDSA משתמשת באותה משפחת החלפת מפתחות עם שיטת אימות אחרת, ולכן היא זקוקה לתעודת עקומה אליפטית. חבילת DHE-RSA משתמשת ב-Diffie-Hellman אפמרי בשדה סופי עם אימות RSA, וזו אכן זקוקה לפרמטרי DH.

קראו שם חבילה משמאל לימין והקצו כל חלק לתפקידו. לאחר הפרדת האסימונים, השאלה משתנה מ«האם התעודה שלי תואמת ל-dh none» ל«האם השרת שלי מתיר חבילה שהחלפת המפתחות שלה אינה זקוקה לקובץ DH».

מה dh none באמת משבית

dh none אומר לשרת לא לטעון קובץ פרמטרי DH של שדה סופי. הוא אינו משבית אימות, אימות תעודות או את TLS עצמו. הוא כן דורש שהחלפת המפתחות המוסכמת תהיה כזו שאינה זקוקה לפרמטרים האלה, שבפועל פירושה חבילת ECDHE או לחיצת יד TLS 1.3.

מהדרישה הזו מגיעה התקלה. אם מדיניות הצפנים של TLS בשרת מוגבלת לחבילות DHE, או שלקוח מציע רק אותן, הסרת קובץ הפרמטרים אינה מותירה שיטת החלפת מפתחות שמישה והלחיצה נכשלת. השגיאה מופיעה בדרך כלל במהלך לחיצת היד של ערוץ הבקרה, לפני אימות משתמש כלשהו. קראו את רשימת הצפנים לפני שאתם מאשימים את הקובץ החסר.

בצד העקומה האליפטית, העקומה נבחרת על ידי תצורת ה-TLS של השרת, ו-OpenVPN מציע אפשרות לבחור אותה בענפים ישנים יותר. TLS 1.3 מטפל במשא ומתן על הקבוצה בתוך הפרוטוקול ואינו מתייעץ עם קובץ ה-DH כלל.

dh none אינו הורדת אבטחה כשלעצמו. חוזק ההחלפה תלוי אז בעקומה ובחבילה שמתקבלות בפועל, ולכן הצעד הבא הוא להסתכל על מה שהצדדים בחרו ולא על הקובץ החסר.

לאשר את המשא ומתן לפני עריכה

הגבירו את רמת הפירוט של השרת והלקוח וקראו את שורת ערוץ הבקרה ש-OpenVPN מדפיס לאחר חיבור. היא מציינת את גרסת ה-TLS ואת הצופן המוסכם, ומדווחת על סוג המפתח של תעודת העמית. השורה האחת הזו עונה על השאלה שקובץ התצורה רק מרמז עליה.

אם היא מציגה TLS 1.2 עם חבילת ECDHE-RSA ותעודת RSA, השילוב הוא בדיוק מה ש-dh none מצפה לו, ואין מה לתקן. אם היא מציגה חבילת DHE או כשל לחיצת יד בלי צופן משותף, התיקון נמצא במדיניות הצפנים או ביכולות הלקוח, לא בתעודה.

בדקו את הלקוח הישן ביותר שאתם מתכוונים לתמוך בו, משום שלקוח עדכני עשוי להסכים על TLS 1.3 בעוד שישן יותר מוגבל לחבילות TLS 1.2. אם ללקוח הישן ביותר אין חפיפה, או שהרחיבו את החבילות המותרות או שדרגו את נקודת הקצה הזו.

אל תכבו את אימות התעודות כדי לעבור כשל לחיצת יד. הכשל אומר לכם שהצדדים לא הצליחו להסכים על החלפת מפתחות, וכיבוי הבדיקה מסיר את הבטחת הזהות בלי לטפל בהסכם.

רשימת בדיקה: האם התעודה היא RSA, האם חבילת ECDHE מותרת, האם היומן מציג את החבילה הזו, והאם גם הלקוח הנתמך הישן ביותר מסכים עליה? אם כל ארבעת התשובות כן, dh none עושה את עבודתו.