בדיקת אישור אתר דרך פרוקסי HTTP באמצעות OpenSSL

השתמשו ב־OpenSSL s_client מותקן שתומך ב־-proxy. עבור נקודת קצה HTTP CONNECT מורשית:

openssl s_client -proxy proxy.example:3128   -connect example.com:443 -servername example.com   -verify_hostname example.com -verify_return_error -showcerts

החליפו את כתובת הפרוקסי והשתמשו בעקביות בשם היעד המיועד. לבדיקת יעד ציבורי דרך פרוקסי שמותר לכם לבחור, בחרו מועמד HTTP מתוך רשימת פרוקסי HTTP. -connect בוחר את היעד, -servername שולח SNI עבור המארח הווירטואלי של TLS, ו־-verify_hostname בודק את הזהות. SNI לבדו אינו אימות שם מארח. בדקו את המדריך לגרסה המותקנת בעת התאמת האפשרויות.

-showcerts מציג את מה שהשרת שלח, אך אינו מצהיר שהשרשרת מהימנה. -verify_return_error גורם לשגיאות אימות לסיים את ה־handshake; אחרת לקוח האבחון יכול להמשיך לאחר שגיאות. עבור שירות פרטי השתמשו בחומר CA מאושר במקום לסמוך על אישור שהורד באקראי.

עם OpenSSL 3.x ופרוקסי HTTP המאמת באמצעות Basic, השתמשו ב־אפשרויות חשבון הפרוקסי של s_client תוך שמירת אימות היעד.

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