אפשר לשתף מפתח ציבורי של VPN? בדקו את שלושת הדברים האלה

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

בדיקה ראשונה: איזה חצי מהזוג נמצא בלוח הגזירים שלכם

מפתחות א-סימטריים באים בזוגות, וכיוון הגזירה הוא כל העניין. ב-WireGuard המפתח הפרטי הוא 32 בתים אקראיים והמפתח הציבורי מחושב ממנו; בכיוון ההפוך אי אפשר. wg genkey כותב את הערך הפרטי, wg pubkey גוזר את הציבורי, ורק השני שייך להודעה לעמית.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

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

אם אינכם בטוחים איזה ערך אתם מחזיקים, חפשו את הסמן ולא את שם הקובץ. בלוק PEM שמתחיל ב------BEGIN PRIVATE KEY-----, או הצורה הישנה יותר BEGIN RSA PRIVATE KEY, הוא החצי הסודי. ערך שאפשר להדביק בלי הסמן הזה הוא מועמד לשיתוף, בכפוף לשתי הבדיקות הבאות.

בדיקה שנייה: למה הפריסה קושרת את הערך הציבורי הזה

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

תעודות מדליפות זהות מעצם התכנון. השדות Subject ו-subject alternative name קריאים, ובתעודות TLS מהימנות לציבור התעודה עצמה מתפרסמת ביומני Certificate Transparency, שניתנים לחיפוש. דבר מזה לא חושף מפתח פרטי, והכול חושף מערכת יחסים.

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

בדיקה שלישית: מה אפשר לבטל, וכמה מהר

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

ביטול הוא פעולת תצורה, לא פעולה קריפטוגרפית. WireGuard אינו מספק רשימת ביטול, ולכן מסירים את העמית:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN פריסות המבוססות על תעודות מבטלות את התעודה ומפרסמות CRL שהשרת באמת בודק דרך crl-verify. בלי ההנחיה הזו רשימת הביטול היא קישוט. כך או כך, הסדר זהה: הנפיקו תחליף, הפיצו אותו בערוץ הנתמך, ואז הוציאו את הזהות הישנה משימוש.

הטעויות שנובעות מאיחוד שלוש הבדיקות

רוב ההדלפות האמיתיות אינן אדם שמחליט לפרסם מפתח פרטי. אלה פרופיל שלם שהודבק בפורום: קובץ WireGuard .conf עם שורת PrivateKey, או חבילת .ovpn עם בלוק מפתח מוטמע, או צילום מסך של חלון לקוח שכלל במקרה את שדה המפתח. הערך הציבורי כנראה היה תקין; הוא נסע עם החלק שלא היה.

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

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

אחרי הדלפה של ערך פרטי, הוציאו את הזהות משימוש

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

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