אילו חבילות OpenVPN מגן עליהן digest של auth?
אפשרות auth מכסה פחות ממה שפרופיל מרמז. עברו על הערוץ, מקרה ה-AEAD וההגנה על ערוץ הבקרה לפני שתקבעו מדיניות digest.
רוב הדיונים על digests של OpenVPN מתחילים בחבילה הלא נכונה. לקרוא auth SHA256 כ״קבל רק עמיתים שמציעים SHA256״ הוא הדבר הראשון שצריך לשכוח. האפשרות נוקבת ב-digest עבור חבילות מסוימות, ואילו חבילות אלו תלוי בערוץ ובשאלה אם אותו ערוץ הוא AEAD. עברו על ארבע השאלות שלמטה לפי הסדר; כל אחת מצמצמת את מה שההגדרה עשויה לומר בפריסה שלכם.
נקבו בשם הערוץ שההגדרה אמורה להגן עליו
OpenVPN יש ערוץ בקרה שנושא תעבורת לחיצת יד של TLS וערוץ נתונים שנושא את המטען של המנהרה. ל-digest של auth יש תפקיד בשניהם, אך לא אותו תפקיד, והפרופיל רק לעיתים נדירות הופך את ההבדל לגלוי. רשמו איזה מהשניים אתם מנסים להגביל לפני שאתם נוגעים בקובץ תצורה.
הטבלה שלמטה היא הגרסה הקצרה של איך אותה אפשרות נוחתת בכל הקשר.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
בדקו אם ערוץ הנתונים הוא AEAD לפני שאתם סומכים עליו
אם צופן הנתונים שנקבע במשא ומתן הוא AES-GCM או CHACHA20-POLY1305, ערוץ הנתונים מאמת את עצמו וה-digest הנפרד אינו עושה את העבודה שאולי אתם מדמיינים. שניהם מבני AEAD, ולכן השלמות נוצרת על ידי אותה פעולה שמצפינה את המטען. זו אינה הורדת דרגה, אך פירושה שמדיניות המוצדקת כ״כל חבילת נתונים היא HMAC-SHA256״ שגויה עובדתית במנהרה הזו. אשרו את הערך שנקבע ביומן השרת או בפלט המצב של הלקוח לפני שתכתבו את המדיניות.
בחנו את הצופן שנקבע בפועל ולא את הרשימה בפרופיל, כי המשא ומתן עשוי לנחות על חבר אחר בקבוצה. data-ciphers AES-256-GCM:AES-128-GCM היא רשימת משא ומתן, ושתי הרשומות הן AEAD, ולכן אף אחת מהן אינה צורכת את digest של auth להגנת המטען.
התייחסו להגנה על ערוץ הבקרה כהחלטה נפרדת
tls-auth מוסיף HMAC לחבילות ערוץ הבקרה ולוקח את ה-digest שלו מהגדרת auth, ולכן מנהרת AEAD יכולה עדיין לקבל digest משמעותי מוגדר. tls-crypt הוא סידור אחר עם הגנה קבועה משלו, אז אל תניחו שהוא יורש כל תכונה של tls-auth. קראו את התיעוד של המנגנון שבחרתם במקום להעביר הנחות ביניהם.
שני העמיתים חייבים להסכים גם על הסידור וגם על כיוון המפתח. digest שמתאים אך קובץ מפתח ששימש בכיוון הלא נכון יוצר לחיצת יד שנכשלת מסיבות שהגדרת ה-digest אינה יכולה להסביר.
הפרידו את auth ממשא ומתן של צפנים ומתעודות
שלוש הגדרות מתבלבלות כל הזמן: digest של auth, רשימת צפני הנתונים ואלגוריתם החתימה של התעודה. שינוי הראשון אינו מנפיק תעודה מחדש, אינו בוחר את digest החתימה שלה ואינו יוצר שיטת שם משתמש-סיסמה. הגדרות אפשרויות הפרוטוקול מופיעות ב מקורות OpenVPN 2.6 ומתארות כל אחת בסעיף משלה, וזו תזכורת שימושית לכך שאלו כפתורים בלתי תלויים.
כשעמית מסרב להתחבר לאחר שינוי digest, הסיבה היא בדרך כלל אי-התאמה באחת משתי ההגדרות האחרות. קראו את שני הקצוות לפני שתשנו כל אחת מהן.
רשמו את המדיניות והשוו אותה לתצורות פועלות
הצהרה ברמת הצי צריכה לנקוב במפורש במצבי ערוץ הנתונים המותרים ובהגנה שנבחרה לערוץ הבקרה, באותו משפט. המשפט הזה ניתן לבדיקה; ״אנחנו משתמשים ב-SHA256״ אינו. לאחר מכן השוו אותה לפרופילי שרת ולקוח אפקטיביים ולא לתבנית במאגר.
סיימו בתיעוד מה כל מנהרה קבעה בפועל ואיזה מנגנון אימת את החבילות שלה. שורת auth גלויה בפרופיל היא הוכחה לכוונת תצורה בלבד, והכוונה היא החלק הזול ביותר בבדיקה.