WRONG_VERSION_NUMBER עם פרוקסי: בדקו HTTP מול HTTPS

השגיאה אומרת “גרסה שגויה”, ולכן מפתה להתחיל להחליף גרסאות TLS. עם פרוקסי, בדקו אפשרות מוקדמת יותר: האם הלקוח שלח לחיצת יד TLS לפורט שחיכה ל-HTTP פשוט?

יעד כמו https://example.com/ ופרוקסי כמו http://proxy.example:8080 הם זוג רגיל. שינוי הכתובת השנייה ל-HTTPS אומר ללקוח להצפין את השיחה שלו עם הפרוקסי עצמו. זו אינה הוראה לאפשר אתרי HTTPS.

אתרו את שיחת ה-TLS הראשונה

בפרוקסי HTTP, הלקוח יכול לשלוח תחילה CONNECT ולקבל תגובת HTTP. רק אחר כך הוא מתחיל את TLS היעד בתוך המנהרה. בפרוקסי HTTPS, קודם מגיע חיבור TLS נפרד לפרוקסי.

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

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

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

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