د پراکسي کارولو پر مهال د سند تېروتنې
د سند تنظیماتو له بدلولو مخکې معلومه کړئ چې تایید د پراکسي په خپل TLS اتصال کې ناکام شوی که د موخې وېبپاڼې په اتصال کې.
د CA ټولګې له بدلولو مخکې معلومه کړئ چې کوم TLS لاس ورکول ناکام شوي دي. د پراکسي سند او د وېبپاڼې سند ښايي په جلا اتصالونو وکتل شي.
| پراکسي او موخه | د TLS کتنې |
|---|---|
| د HTTPS موخې لپاره HTTP پراکسي | له CONNECT وروسته د تونل له لارې د موخې سند تایید کړئ. |
| د HTTPS موخې لپاره HTTPS پراکسي | لومړی پراکسي ته TLS تایید کړئ؛ د تونل له پرانیستل کېدو وروسته موخې ته جلا TLS ناسته تایید کړئ. |
په تفصیلي تعقیب کې غوښتل شوی کوربه نوم او وروستي بشپړ شوي لاس ورکول وپېژنئ. د HTTPS پراکسي د سند تېروتنه له وېبپاڼې سره تر اړیکې مخکې رامنځته کېدای شي. د هغه اتصال ټاکل شوی نوم، د سند د اعتبار موده، ځايي ساعت، تمه شوې لړۍ او منل شوی د باور زېرمتون وګورئ. قصداً تنظیم شوی TLS منځګړیتوب یا زیات شوی ریښه سند هم په څېړنه کې شامل کړئ.
curl د دواړو اتصالونو لپاره جلا CA انتخابونه لري:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert د پراکسي لپاره د باور بنسټ برابروي؛ --cacert د موخې لپاره. د بېلګې د نښلېدو ځای او فایلونه د خپل ټاکلي باور جوړښت په ارزښتونو بدل کړئ. که د سیستم باور کافي وي، ځانګړو ټولګو ته اړتیا نشته.
د کوربه نوم په یوه تصادفي IP بدلول د سند مطابقت بدلوي. د تایید پرېښودل تېروتنه پټولای شي، خو د بل لوري هویت نه ثابتوي. د نابلده پراکسي غوښتنه چې خپله ریښه CA یې نصب کړئ، پرې د باور لپاره کافي دلیل نه دی.
د پورټ اتصال رد کېدل یا د CONNECT رد کېدل په مخکیني پړاو پورې اړه لري؛ د سندونو بدلول یې نه شي سمولای. برعکس، د موخې د TLS تر تایید وروسته د وېبپاڼې HTTP تېروتنه په ترلاسه شوي ځواب پورې اړه لري، نه د CA په بل بدلون پورې.