ପ୍ରକ୍ସି ସହିତ WRONG_VERSION_NUMBER: HTTP ଓ HTTPS ଯାଞ୍ଚ କରନ୍ତୁ

ତ୍ରୁଟି କହେ “ଭୁଲ ସଂସ୍କରଣ”, ତେଣୁ TLS ସଂସ୍କରଣ ବଦଳାଇବା ଆରମ୍ଭ କରିବାକୁ ଲୋଭ ହୁଏ। ପ୍ରକ୍ସି ସହିତ, ପୂର୍ବରୁ ଥିବା ଏକ ସମ୍ଭାବନା ଯାଞ୍ଚ କରନ୍ତୁ: କ୍ଲାଏଣ୍ଟ ସାଧାରଣ HTTP ଅପେକ୍ଷା କରୁଥିବା ପୋର୍ଟକୁ TLS ହ୍ୟାଣ୍ଡସେକ ପଠାଇଥିଲା କି?

https://example.com/ ପରି ଗନ୍ତବ୍ୟ ଏବଂ http://proxy.example:8080 ପରି ପ୍ରକ୍ସି ସାଧାରଣ ଯୋଡ଼ି। ଦ୍ୱିତୀୟ URL କୁ HTTPS କରିବା କ୍ଲାଏଣ୍ଟକୁ ପ୍ରକ୍ସି ସହିତ ନିଜର କଥାବାର୍ତ୍ତା ଏନକ୍ରିପ୍ଟ କରିବାକୁ କହେ। ଏହା HTTPS ସାଇଟ ଅନୁମତି ଦେବାର ନିର୍ଦ୍ଦେଶ ନୁହେଁ।

ପ୍ରଥମ TLS କଥାବାର୍ତ୍ତା ଖୋଜନ୍ତୁ

HTTP ପ୍ରକ୍ସିରେ, କ୍ଲାଏଣ୍ଟ ପ୍ରଥମେ CONNECT ପଠାଇ HTTP ଉତ୍ତର ପାଇପାରେ। ତା’ପରେ ହିଁ ସୁଡ଼ଙ୍ଗ ଭିତରେ ଗନ୍ତବ୍ୟର TLS ଆରମ୍ଭ କରେ। HTTPS ପ୍ରକ୍ସିରେ ପ୍ରଥମେ ପ୍ରକ୍ସିକୁ ଅଲଗା TLS ସଂଯୋଗ ଆସେ।

HTTP ତ୍ରୁଟି ପୃଷ୍ଠା କିମ୍ବା ଅନ୍ୟ ସାଧାରଣ ପାଠ୍ୟ ପାଇଥିବା TLS ପାର୍ସର ପ୍ରୋଟୋକଲ ତ୍ରୁଟି ରିପୋର୍ଟ କରିପାରେ। ସେ ଶବ୍ଦ ସାଇଟ କେଉଁ TLS ସଂସ୍କରଣ ସମର୍ଥନ କରେ, କିମ୍ବା ସାଇଟ ସହିତ ଯୋଗାଯୋଗ ହୋଇଥିଲା କି ନାହିଁ ତାହା ମଧ୍ୟ ସ୍ଥାପିତ କରେ ନାହିଁ।

1. ପ୍ରକ୍ସିର URL, ଏହାର ସ୍କିମ ସହିତ, ଏବଂ ଏଣ୍ଡପଏଣ୍ଟର ପ୍ରଲେଖିତ ପ୍ରୋଟୋକଲ ଲେଖନ୍ତୁ।
2. ବିଫଳତା CONNECT ଉତ୍ତର ପୂର୍ବରୁ, ଗନ୍ତବ୍ୟର TLS ସମୟରେ, ନା ପ୍ରକ୍ସିର ନିଜ ପ୍ରମାଣପତ୍ର ଯାଞ୍ଚ ସମୟରେ ଘଟିଛି ଖୋଜନ୍ତୁ।
3. ପୁରୁଣା ସମାଧାନ ସହିତ ତୁଳନା କରିବା ସମୟରେ ପ୍ରକୃତ କ୍ଲାଏଣ୍ଟ ଏବଂ ନିର୍ଭରତାର ସଂସ୍କରଣ ଯାଞ୍ଚ କରନ୍ତୁ। ପୂର୍ବ ପ୍ରକ୍ସି କାର୍ଯ୍ୟକାରୀକରଣ କେତେବେଳେ ସ୍କିମକୁ ଅଲଗା ଭାବରେ ନେଉଥିଲେ।

ଅନେକ ସଂଶୋଧନ ଅଲଗା କାରଣରୁ ଭୁଲ ହୋଇପାରେ। HTTP ପ୍ରକ୍ସି ତାଲିକା ସେ ପଥ ଦେଇ ଅନୁମୋଦିତ ସର୍ବସାଧାରଣ ଅନୁରୋଧ ପାଇଁ ସାଧାରଣ HTTP ଏଣ୍ଡପଏଣ୍ଟ ପ୍ରାର୍ଥୀ ଦିଏ। ସାଧାରଣ HTTP ଏଣ୍ଡପଏଣ୍ଟକୁ HTTP ପ୍ରକ୍ସି ସ୍କିମ ଦରକାର; ପ୍ରକୃତରେ TLS-ସକ୍ଷମ ଏଣ୍ଡପଏଣ୍ଟ HTTPS ଏବଂ ଏହାର ପ୍ରମାଣପତ୍ର ଯାଞ୍ଚ ରଖିବା ଉଚିତ। CONNECT ଅସ୍ୱୀକାର କରୁଥିବା ପ୍ରକ୍ସିକୁ ସମର୍ଥିତ ସେବା କିମ୍ବା ନୀତି ଦରକାର, ଲାଇବ୍ରେରୀର ମନଇଚ୍ଛା ଡାଉନଗ୍ରେଡ ନୁହେଁ।

ପ୍ରଥମ ଦୃଶ୍ୟମାନ ବିଫଳତା ରଖନ୍ତୁ। ପ୍ରମାଣପତ୍ର ଯାଞ୍ଚ ବନ୍ଦ କଲେ କେବଳ HTTP କୁହୁଥିବା ଶ୍ରୋତାକୁ TLS କହିବାକୁ ବାଧ୍ୟ କରାଯାଇପାରିବ ନାହିଁ, ଏବଂ ପୁରୁଣା ସାଇଫର ନୀତି ବାଛିଲେ ସାଇଟର ହ୍ୟାଣ୍ଡସେକ ପୂର୍ବରୁ ପଠାଯାଇଥିବା HTTP ଅସ୍ୱୀକାରର ବ୍ୟାଖ୍ୟା ହୋଇପାରିବ ନାହିଁ।