האם נגמרת האנטרופיה ל־VPN? מה באמת מראה entropy_avail

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

למה המיתוס שורד

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

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

מה גנרטור עושה לכל מנה

ב־OpenSSL 3 היררכיית הגנרטורים המוגדרת כברירת מחדל בנויה ממופעי DRBG שזורים ומזריעים מחדש לפי תצורה ומצב. ב־OpenVPN 2.6 נתיב הנתונים AEAD גוזר את ה־nonce ממספר הרצף של המנה יחד עם ערך מרומז לכל הפעלה, בעוד נתיב CBC הישן יותר שואב IV פסאודו־אקראי לכל מנה. אף אחד מהדפוסים לא תומך בכלל שמעבר של גיגה־בייט צורך גיגה־בייט של רעש גרעין טרי. שניהם תומכים ברעיון שיצירת מפתחות ולחיצות יד הן המקום שבו הזריעה חשובה.

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

איפה ההמתנה באמת נראית

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

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

cat /proc/sys/kernel/random/entropy_avail
uname -r

התאימו את התיקון לקריאה

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

ss -tin dst 203.0.113.7
sar -n DEV 1 5

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