ଯାଞ୍ଚ ପ୍ରକ୍ସିର କେଉଁ ପାର୍ଶ୍ୱ ପ୍ରମାଣପତ୍ରକୁ ଅସ୍ୱୀକାର କଲା?

କ୍ଲାୟେଣ୍ଟ ଅନୁମୋଦିତ ଯାଞ୍ଚ ପ୍ରକ୍ସିକୁ ବିଶ୍ୱାସ କରେ। ତଥାପି ପ୍ରମାଣପତ୍ର ତ୍ରୁଟି ହେତୁ ଅନୁରୋଧ ବିଫଳ ହୁଏ। ଉଭୟ ତଥ୍ୟ ସତ୍ୟ ହୋଇପାରେ: ସେହି ପ୍ରକ୍ସିର ଯାଞ୍ଚ କରିବାକୁ ଆଉ ଏକ TLS ସମ୍ପର୍କ ଅଛି।

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

ଇଣ୍ଟରସେପ୍ସନ ବ୍ୟବସ୍ଥାରେ ମଧ୍ୟସ୍ଥ କ୍ଲାୟେଣ୍ଟର TLS ସମାପ୍ତ କରି ଆଗକୁ ନିଜର ସଂଯୋଗ ସୃଷ୍ଟି କରେ। କ୍ଲାୟେଣ୍ଟ ନିଜ ପାର୍ଶ୍ୱରେ ଉପସ୍ଥାପିତ ପ୍ରମାଣପତ୍ର ଗ୍ରହଣ କରିପାରେ, ମାତ୍ର ପ୍ରକ୍ସି ୱେବସାଇଟରୁ ମିଳିଥିବା ପ୍ରମାଣପତ୍ରକୁ ଅସ୍ୱୀକାର କରେ।

ଯାଞ୍ଚକର୍ତ୍ତାର ତ୍ରୁଟି ପଢ଼ନ୍ତୁ

କେଉଁ ପ୍ରକ୍ରିୟା ବିଫଳ ଶୃଙ୍ଖଳା କିମ୍ବା ହୋଷ୍ଟନାମ ରିପୋର୍ଟ କଲା ନିର୍ଣ୍ଣୟ କରନ୍ତୁ। ପ୍ରକ୍ସି ଦ୍ୱାରା ଉତ୍ପନ୍ନ ତ୍ରୁଟି ପୃଷ୍ଠା ଏକ ବୈଧ ସଂଯୋଗ ମାଧ୍ୟମରେ କ୍ଲାୟେଣ୍ଟ ପାଖରେ ସଫଳତାର ସହ ପହଞ୍ଚିପାରେ। କ୍ଲାୟେଣ୍ଟର CA ଫାଇଲ ପୁଣି ବଦଳାଇବା ପ୍ରକ୍ସିର ଅପଷ୍ଟ୍ରିମ ବିଶ୍ୱାସ କନଫିଗୁରେସନ ଅପଡେଟ କରେ ନାହିଁ।

ଉଦାହରଣ ସ୍ୱରୂପ Mitmproxy ଅଲଗା ଅପଷ୍ଟ୍ରିମ ବିଶ୍ୱାସ ବିକଳ୍ପ ଦଲିଲଭୁକ୍ତ କରେ, ସେଥିରେ ssl_verify_upstream_trusted_ca ଅନ୍ତର୍ଭୁକ୍ତ। ଉପଯୁକ୍ତ ପ୍ରଶାସକ ଯାଞ୍ଚ ବଜାୟ ରଖି ଅପଷ୍ଟ୍ରିମ ସେବା ପାଇଁ ଅନୁମୋଦିତ ବିଶ୍ୱାସ କନଫିଗର କରିପାରିବେ। ଅନ୍ୟ ଏକ ପ୍ରକ୍ସି ଉତ୍ପାଦ ପାଇଁ ଏହାର ସମ୍ପୃକ୍ତ ଇଣ୍ଟରଫେସ ଆବଶ୍ୟକ।

ପ୍ରକୃତ ଗନ୍ତବ୍ୟ ନାମ ଏବଂ ଶୃଙ୍ଖଳା ମଧ୍ୟ ଯାଞ୍ଚ କରନ୍ତୁ। ମଧ୍ୟବର୍ତ୍ତୀ ବିନା ବ୍ୟକ୍ତିଗତ ସେବା, ମିଆଦ ଶେଷ ହୋଇଥିବା ପ୍ରମାଣପତ୍ର ଏବଂ ଅଜଣା ବ୍ୟକ୍ତିଗତ ପ୍ରଦାନକାରୀ ପାଇଁ ଭିନ୍ନ ମରାମତି ଆବଶ୍ୟକ। ଗୋଟିଏ ବ୍ୟକ୍ତିଗତ ସେବା ପାଇଁ ଉଦ୍ଦିଷ୍ଟ ବ୍ୟତିକ୍ରମ ଚୁପଚାପ ପ୍ରତ୍ୟେକ ପ୍ରମାଣପତ୍ରର ବୈଶ୍ୱିକ ଗ୍ରହଣୀୟତା ହେବା ଉଚିତ ନୁହେଁ।

ସାଧାରଣ CONNECT ଟନେଲ ଅଲଗା

ଅସ୍ପଷ୍ଟ ଫରୱାର୍ଡ ଟନେଲ ଗନ୍ତବ୍ୟ TLS କୁ ଏହିପରି ବିଭକ୍ତ କରେ ନାହିଁ। ସାଧାରଣତଃ ଆପ୍ଲିକେସନ ନିଜେ ସେହି ଏଣ୍ଡ-ଟୁ-ଏଣ୍ଡ TLS ସେସନ ବୁଝାମଣା ଏବଂ ଯାଞ୍ଚ କରେ। ଯେକୌଣସି ମଧ୍ୟସ୍ଥ ଉପରେ ଯାଞ୍ଚ-ପ୍ରକ୍ସି ସେଟିଂ ଲାଗୁ କରିବା ପରିବର୍ତ୍ତେ ପ୍ରଥମେ ଇଣ୍ଟରସେପ୍ସନ ପ୍ରକୃତରେ ପଥର ଅଂଶ କି ନାହିଁ ନିର୍ଣ୍ଣୟ କରନ୍ତୁ।

ଉଭୟ ଯାଞ୍ଚ ଫଳାଫଳ ଅଲଗା ଭାବରେ ରେକର୍ଡ କରନ୍ତୁ। “ପ୍ରକ୍ସିର ପ୍ରମାଣପତ୍ର ବିଶ୍ୱାସଯୋଗ୍ୟ” କ୍ଲାୟେଣ୍ଟ ପାର୍ଶ୍ୱର ପ୍ରଶ୍ନର ଉତ୍ତର ଦିଏ; ପ୍ରକ୍ସି ଉପରକୁ ସଂଯୋଗ କରିବା ସମୟରେ କଣ ଦେଖିଲା ତାହା ଏହା ପ୍ରମାଣିତ କରେ ନାହିଁ।