קובץ DH או מפתח tls-auth? איך להבדיל בין שני קבצי OpenVPN

שני קבצים, שתי הנחיות והרגל לקרוא לשניהם על שם הדבר שהם מגדירים. כך dh.pem מגיע לשורת tls-auth והלקוח נכשל בהודעה על תבנית מפתח לא צפויה. ההחלטה שלפניכם אינה איזה קובץ חזק יותר. היא איזה תפקיד הפריסה באמת זקוקה לו, ושלושה תנאים מכריעים אותה: איזה חילופי מפתחות תנהל שכבת ה-TLS שלכם, אם אתם רוצים אימות של ערוץ הבקרה בכלל, והאם החומר חייב להישאר סודי.

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

קראו את התווית לפני שם הקובץ

השורה הראשונה של הקובץ מאירת עיניים יותר משמו, כי שם הוא מוסכמה אנושית ואילו את התווית מייצר הכלי. פרמטרי Diffie-Hellman נושאים תווית PEM BEGIN DH PARAMETERS. מפתח סטטי של OpenVPN הוא מבנה שונה לחלוטין, עם כותרת משלו ומטען הקסדצימלי.

שינוי שם אינו ממיר דבר. קובץ פרמטרים בשם ta.key נשאר פרמטרים, ומפתח סטטי בשם dh.pem נשאר מפתח סטטי; המנתח קורא את התוכן ודוחה את אי-ההתאמה. בדקו לפני עריכת הפרופיל:

head -n 1 dh.pem
head -n 1 ta.key

שלושה תנאים שקובעים איזה קובץ דרוש לכם

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

התנאי השני הוא אימות ערוץ הבקרה, תכונה נפרדת עם חומר משלה. קובץ tls-auth הוא מפתח סטטי משותף ששני הצדדים מחזיקים, ומשמש לחתימה על מנות ערוץ הבקרה כדי שצד שאינו מאומת לא יוכל אפילו להשלים את לחיצת היד. הוא קיים בין אם אתם משתמשים ב-DH בשדה סופי ובין אם לאו, ואין לו שום קשר לפרמטרי הקבוצה.

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

צרו את החומר הנכון לכל תפקיד

השתמשו בכלי שמייצר את התבנית שההנחיה מצפה לה במקום להמיר ביניהם. עבור המפתח המשותף ב-OpenVPN 2.6, הצורה הטיפוסית של המחולל מציינת את המטרה במפורש.

openvpn --genkey tls-auth ta.key

הפקודה הזו יוצרת חומר סודי חדש; היא אינה מתקנת ואינה בודקת מפתח קיים, והרצה חוזרת נותנת לכם מפתח אחר שאין לצדדים האחרים. העתיקו את הקובץ שנוצר לצדדים שזקוקים לו דרך ערוץ שבו הייתם משתמשים לכל סוד משותף, ושמרו על מוסכמת הכיוון בעקביות: עם tls-auth צד אחד משתמש ב-key-direction 0 והשני ב-key-direction 1.

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

מה dh none עושה ומה לא

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

שתי טעויות נובעות מקריאה שגויה שלה. הראשונה היא להניח ש-dh none מסיר את הצורך ב-tls-auth, בעוד השניים שולטים בדברים שונים. השנייה היא להחזיק שורת dh מיושנת לצד תצורה של עקומה בלבד ואז לתהות איזה קובץ השרה באמת משתמשת בו; אם ההנחיה קיימת, הקובץ נקרא, ונתיב שבור שם מכשיל את האתחול מסיבה שאינה קשורה לחילוף שינוהל.

אם הקובץ השגוי כבר נפרס

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

אחר כך הפרידו בין שני האירועים שאנשים נוטים לאחד. פרסום קובץ פרמטרים של DH כמעט אינו מזיק, כי הפרמטרים היו ציבוריים מלכתחילה. חשיפת מפתח tls-auth היא אירוע אחר: המפתח מאמת מנות של ערוץ הבקרה עבור כל צד שמחזיק בו, ולכן יש לתאם את ההחלפה בכל הפריסה ולא להחיל אותה על מארח אחד.

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