OpenVPN EC מול ED: למה השמות האלה אינם סולם עוצמה
EC, ED, ECDHE ו-auth עונים על שאלות שונות. מיינו פרופיל OpenVPN לפי העבודה שכל שם עושה לפני שאתם משווים או עורכים משהו.
שימו ec, ed, ecdh, ecdsa, auth ורשימת צפנים של TLS זה לצד זה בפרופיל אחד, והקובץ מתחיל להיראות כמו חוגת עוצמה עם שישה מצבים. אבל הוא לא. כל שם עונה על שאלה אחרת, ושני פרופילים שנבדלים באחד מהם אינם בהכרח חזקים או חלשים יותר זה מזה. מיון השמות לפי העבודה שהם עושים לוקח כחמש דקות ומונע את רוב השינויים הגרועים שאנשים עושים בקונפיגורציה שעובדת.
המיון שלהלן מתחיל מהבלבול עצמו, ואז מתרחב החוצה אל החלקים בפרופיל שבאמת קובעים מה מגן על התעבורה שלכם. כל סעיף לוקח בתורו קריאה מוטעית אחת ומראה למה השם באמת מחובר.
שתי אותיות, שתי שאלות שונות
הזוג שיוצר את הוויכוח הגדול ביותר הוא EC ו-ED, והוויכוח מניח בדרך כלל שהם תשובות מתחרות לשאלה אחת. הם אפילו לא על אותו ציר. EC מתאר משפחה של מתמטיקה: קריפטוגרפיה של עקומות אליפטיות, שבה הביטחון מגיע מקושי של לוגריתם דיסקרטי על עקומה ולא בשדה סופי גדול.
ED מתאר צורת עקומה בתוך אותה משפחה. עקומות Twisted Edwards הן ייצוג שנבחר בגלל מהירות ובגלל עמידות בפני כמה שגיאות מימוש, ו-Ed25519 הוא השם שהאנשים בדרך כלל מתכוונים אליו. העקומה אינה מתחרה בקריפטוגרפיה של עקומות אליפטיות; היא אחת הדרכים לכתוב עקומה אליפטית. קריאה של ED כ"ה-EC החדש והחזק יותר" היא הפנייה השגויה הראשונה, וכל מה שאחריה נוטה להיות שגוי באותו כיוון.
חתימה והחלפה הן משימות נפרדות
לאחר שנפתרה שאלת המשפחה, השמות הנותרים מתחלקים לשתי עמודות שלעולם אינן מחליפות זו את זו. עמודה אחת חותמת, השנייה מסכימה על סוד משותף.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
גם EdDSA וגם ECDSA חותמים, אבל אלה סכמות שונות עם פורמטים שונים של מפתחות, ולכן תעודה שהונפקה לאחת אינה שמישה כשנייה. EdDSA מוגדרת לקבוצה קטנה של עקומות; P-256 אינה אחת מהן, ולכן תעודת P-256 מאומתת ב-ECDSA ואף פעם לא ב-Ed25519.
לעמודת ההחלפה אין מקבילה בשם EdDH. הסכמה אפמרלית על מפתח Curve25519 היא X25519, וזו ECDH עם עקומה מסוימת, בדיוק כמו עם P-256. Ed25519 פירושו באופן קפדני סכמת החתימה, אם כי השם משמש בחופשיות להחלפה מפני ששתי העקומות קשורות: צורת Edwards שמשמשת לחתימה וצורת Montgomery שמשמשת ל-X25519 מתארות את אותה קבוצה בסיסית.
למה אין קובץ dh בפרופיל EC
קובץ dh מכיל פרמטרים שנוצרו מראש עבור Diffie-Hellman בשדה סופי, והפרמטרים האלה קיימים מפני שמספר ראשוני גדול ויוצר חייבים לבוא מאיפשהו. החלפה על עקומה אליפטית אינה זקוקה להם: העקומה הנקובה היא מערך הפרמטרים, ושני הצדדים כבר מכירים אותו. זו כל הסיבה לכך שפרופיל EC יכול להשמיט את ההוראה.
שני מצבים עדיין מייצרים שורת dh בפרופיל שנראה מודרני אחרת. הראשון הוא מאזין שני או עמית ישן יותר שבאמת מנהל משא ומתן על קבוצות בשדה סופי. השני הוא טקסט שנותר, שהועתק מתבנית מתקופת RSA ומעולם לא הוסר. פרופיל שמנקב עקומה להחלפה ועדיין טוען קובץ dh של 2048 סיביות אינו בטוח יותר מפני שעשה זאת; הוא נושא פריט שאינו בשימוש.
TLS 1.3 הסיר את החלפת המפתחות מהשם
השוו בין TLS_AES_256_GCM_SHA384 ל-TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 והשם הקצר נראה כמו ירידה בדרגה. זהו שינוי שם, והסיבה מבנית: TLS 1.3 הסיר את RSA הסטטי ואת החלפת המפתחות Diffie-Hellman בשדה סופי, ולכן החלפה אפמרלית על עקומה אליפטית היא האפשרות היחידה שנותרה ללא PSK. ציון שלה בכל חבילה היה חוזר על אותה עובדה תריסר פעמים.
סוג התעודה נעלם מהשם מסיבה קשורה. בגרסה 1.3 התעודה מאמתת את חתימת לחיצת היד, לא את הסכם המפתחות, ולכן היא אינה בוחרת יותר את החבילה. זו גם הסיבה לכך שקיימת רשימת צפנים נפרדת ל-1.3 בקונפיגורציה: החבילות שונו ואורגנו מחדש, לא נחלשו.
תוצאה אחת ראויה להיאמר בבירור. ECDHE הוא אלגוריתם להחלפת מפתחות ולעולם לא צופן. חבילה שמתוארת כ"אליפטית" אומרת משהו על האופן שבו שני הצדדים הגיעו למפתח משותף, ושום דבר על מה שמצפין אחר כך את המטען.
auth מאמת מנות, לא מטענים
ההוראה auth בוחרת את תמצית ה-HMAC שמאמתת מנות, וברירת המחדל ההיסטורית שלה היא SHA1. עם צופן נתונים שאינו AEAD, OpenVPN מחשב את התמצית על הטקסט המוצפן ומוסיף אותה, סידור של הצפן-ואז-MAC שהופך מניפולציה בריפוד לבלתי מעשית.
המיתוס כאן הוא שהעלאת auth ל-SHA512 מחזקת את המנהרה. היא אינה מעלה את חוזק ההצפנה, ואם צופן הנתונים שנקבע הוא מצב AEAD כמו AES-256-GCM, התמצית כלל אינה מוחלת על מנות נתונים. תגית GCM כבר מאמתת אותן, וערך auth נשאר ל-HMAC של ערוץ הבקרה ולכל צופן שאינו AEAD שעדיין בשימוש.
אז ההוראה חשובה, אבל היא חשובה במקום צר יותר ממה שמיקומה בקובץ מרמז. בדיקה איזה צופן באמת נקבע אומרת לכם אם היא חלה בכלל.
קראו את הפרופיל לפי עמודה, לא לפי דירוג
שלוש שאלות מפרידות בין השכבות באופן נקי, וכל אחת מהן נענית על ידי חלק אחר של הסשן שנקבע. איזה צופן מגן על המטען? איזו תגית או תמצית ערבה לכל מנה, והאם הצופן שבשימוש בכלל זקוק לאחת? של מי התעודה שסגרה את לחיצת היד, והאם ערוץ הבקרה מוגן בנוסף על ידי tls-auth או tls-crypt?
שום דבר בתווית EC או ED לא מכריע אף אחת משלוש השאלות האלה, וגם שם חבילה לבדו לא מכריע אף אחת מהן. התוצאה שנקבעה היא הראיה היחידה, אז קראו אותה במקום להסיק חוזק מאוצר המילים:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logהפקודה הראשונה אומרת לכם איזו סכמת חתימה התעודה שלכם באמת משתמשת בה, וזו הדרך האמינה היחידה לדעת אם אתם מריצים ECDSA או Ed25519. השנייה מציגה את שורת ערוץ הבקרה שהלקוח תיעד עבור הסשן, כולל גרסת TLS והחבילה שעליה נעצר. אם לא ניתן להצדיק שינוי בפרופיל באחת משתי הפלטים האלה, סביר שזה שינוי בשם ולא בתכונה.