معائنہ پراکسی کا کون سا رخ نے سرٹیفکیٹ مسترد کیا؟

کلائنٹ منظور شدہ معائنہ پراکسی پر بھروسہ کرتا ہے۔ پھر بھی درخواست سرٹیفکیٹ کی خرابی کی وجہ سے ناکام ہوتی ہے۔ دونوں حقائق درست ہو سکتے ہیں: اس پراکسی کا تصدیق کرنے کے لیے ایک اور TLS تعلق ہے۔

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

انٹرسیپشن کے انتظام میں ثالث کلائنٹ کا TLS ختم کرتا ہے اور آگے اپنا کنکشن بناتا ہے۔ کلائنٹ اپنی طرف پیش کردہ سرٹیفکیٹ قبول کر سکتا ہے جبکہ پراکسی ویب سائٹ سے موصول سرٹیفکیٹ مسترد کرتی ہے۔

تصدیق کنندہ کی خرابی پڑھیں

مقرر کریں کہ کس عمل نے ناکام زنجیر یا ہوسٹ نام کی اطلاع دی۔ پراکسی کا بنایا ہوا خرابی کا صفحہ کسی درست کنکشن کے ذریعے کلائنٹ تک کامیابی سے پہنچ سکتا ہے۔ کلائنٹ کی CA فائل دوبارہ بدلنے سے پراکسی کی اپ اسٹریم اعتماد کی ترتیب اپ ڈیٹ نہیں ہوتی۔

مثال کے طور پر Mitmproxy الگ اپ اسٹریم اعتماد کے اختیارات کی دستاویز کرتا ہے، جن میں ssl_verify_upstream_trusted_ca شامل ہے۔ موزوں منتظم تصدیق برقرار رکھتے ہوئے اپ اسٹریم سروس کے لیے منظور شدہ اعتماد ترتیب دے سکتا ہے۔ کسی دوسری پراکسی مصنوعات کو اپنا متعلقہ انٹرفیس درکار ہے۔

اصل منزل کا نام اور زنجیر بھی جانچیں۔ بغیر درمیانی سرٹیفکیٹ کے نجی سروس، میعاد ختم شدہ سرٹیفکیٹ اور نامعلوم نجی جاری کنندہ کو مختلف مرمت درکار ہے۔ ایک نجی سروس کے لیے ارادہ شدہ استثنا خاموشی سے ہر سرٹیفکیٹ کی عالمی قبولیت نہیں بننا چاہیے۔

سادہ CONNECT سرنگ مختلف ہے

غیر شفاف فارورڈ سرنگ منزل کے TLS کو اس طرح تقسیم نہیں کرتی۔ عام طور پر ایپلیکیشن خود اس اینڈ ٹو اینڈ TLS سیشن پر بات چیت اور تصدیق کرتی ہے۔ کسی بھی ثالث پر معائنہ پراکسی کی ترتیبات لاگو کرنے کے بجائے پہلے طے کریں کہ انٹرسیپشن واقعی راستے کا حصہ ہے یا نہیں۔

دونوں تصدیقی نتائج الگ الگ درج کریں۔ “پراکسی کا سرٹیفکیٹ قابل اعتماد ہے” کلائنٹ کی طرف کے سوال کا جواب دیتا ہے؛ یہ تصدیق نہیں کرتا کہ پراکسی نے اوپر جڑتے وقت کیا دیکھا۔