9.7 - פתרון שמות וחיבור מוצפן - פתרון

פתרון הפרדת הכשלים

פתרון ראשון - כתובת אינה שם אימות

כאשר שרת המעבדה פועל, הפקודות הבאות משתמשות באותו יעד חיבור מקומי, אבל מבקשות לאמת שמות שונים.

cargo run -- localhost ca.crt
cargo run -- wrong.example ca.crt

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

פתרון שני - אמון מגיע מהלקוח

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

openssl req -x509 -newkey rsa:2048 -noenc -keyout other-ca.key -out other-ca.crt -days 1 -subj "/CN=Other Lab CA" -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign"
cargo run -- localhost other-ca.crt

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

פתרון שלישי - מדידה בלי שינוי משמעות

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

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

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