ತಪಾಸಣಾ ಪ್ರಾಕ್ಸಿಯ ಯಾವ ಬದಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತಿರಸ್ಕರಿಸಿತು?

ಕ್ಲೈಂಟ್ ಅನುಮೋದಿತ ತಪಾಸಣಾ ಪ್ರಾಕ್ಸಿಯನ್ನು ನಂಬುತ್ತದೆ. ಆದರೂ ಪ್ರಮಾಣಪತ್ರ ದೋಷದಿಂದ ವಿನಂತಿ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡೂ ಸತ್ಯವಾಗಿರಬಹುದು: ಆ ಪ್ರಾಕ್ಸಿಗೆ ಪರಿಶೀಲಿಸಲು ಇನ್ನೊಂದು TLS ಸಂಬಂಧವಿದೆ.

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

ಪ್ರತಿಬಂಧದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಮಧ್ಯವರ್ತಿ ಕ್ಲೈಂಟ್‌ನ TLS ಅನ್ನು ಕೊನೆಗೊಳಿಸಿ ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ಮುಂದೆ ರಚಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ತನ್ನ ಬದಿಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಿದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಆದರೆ ಪ್ರಾಕ್ಸಿ ವೆಬ್‌ಸೈಟ್‌ನಿಂದ ಪಡೆದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ಪರಿಶೀಲಕನ ದೋಷವನ್ನು ಓದಿ

ವಿಫಲವಾದ ಸರಪಳಿ ಅಥವಾ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಯಾವ ಪ್ರಕ್ರಿಯೆ ವರದಿ ಮಾಡಿತು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ಪ್ರಾಕ್ಸಿ ರಚಿಸಿದ ದೋಷ ಪುಟವು ಮಾನ್ಯ ಸಂಪರ್ಕದ ಮೂಲಕ ಕ್ಲೈಂಟ್‌ಗೆ ಯಶಸ್ವಿಯಾಗಿ ತಲುಪಬಹುದು. ಕ್ಲೈಂಟ್‌ನ CA ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಬದಲಿಸುವುದು ಪ್ರಾಕ್ಸಿಯ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ವಿಶ್ವಾಸ ಸಂರಚನೆಯನ್ನು ನವೀಕರಿಸುವುದಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ Mitmproxy ಪ್ರತ್ಯೇಕ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ವಿಶ್ವಾಸ ಆಯ್ಕೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ssl_verify_upstream_trusted_ca ಸೇರಿದೆ. ಸೂಕ್ತವಾದ ನಿರ್ವಾಹಕರು ಪರಿಶೀಲನೆಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಗೆ ಅನುಮೋದಿತ ವಿಶ್ವಾಸವನ್ನು ಸಂರಚಿಸಬಹುದು. ಇನ್ನೊಂದು ಪ್ರಾಕ್ಸಿ ಉತ್ಪನ್ನಕ್ಕೆ ಅದರ ಸಂಬಂಧಿತ ಇಂಟರ್ಫೇಸ್ ಬೇಕು.

ನಿಜವಾದ ಗಮ್ಯಸ್ಥಾನದ ಹೆಸರು ಮತ್ತು ಸರಪಳಿಯನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಮಧ್ಯಂತರವಿಲ್ಲದ ಖಾಸಗಿ ಸೇವೆ, ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಗುರುತಿಸಲಾಗದ ಖಾಸಗಿ ನೀಡುಗರು ಬೇರೆ ಬೇರೆ ದುರಸ್ತಿ ಬೇಕಾಗುತ್ತದೆ. ಒಂದು ಖಾಸಗಿ ಸೇವೆಗಾಗಿ ಉದ್ದೇಶಿಸಿದ ವಿನಾಯಿತಿ ಮೌನವಾಗಿ ಪ್ರತಿ ಪ್ರಮಾಣಪತ್ರದ ಜಾಗತಿಕ ಸ್ವೀಕಾರವಾಗಬಾರದು.

ಸಾಮಾನ್ಯ CONNECT ಸುರಂಗ ಬೇರೆ

ಅಪಾರದರ್ಶಕ ಫಾರ್ವರ್ಡ್ ಸುರಂಗ ಗಮ್ಯಸ್ಥಾನದ TLS ಅನ್ನು ಈ ರೀತಿ ವಿಭಜಿಸುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಆ ಎಂಡ್-ಟು-ಎಂಡ್ TLS ಸೆಷನ್ ಅನ್ನು ತಾನೇ ಸಂಧಾನ ಮಾಡಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಯಾವುದೇ ಮಧ್ಯವರ್ತಿಗೆ ತಪಾಸಣಾ-ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅನ್ವಯಿಸುವ ಬದಲು ಪ್ರತಿಬಂಧವು ನಿಜವಾಗಿಯೂ ಮಾರ್ಗದ ಭಾಗವೇ ಎಂದು ಮೊದಲು ನಿರ್ಧರಿಸಿ.

ಎರಡು ಪರಿಶೀಲನಾ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸಿ. “ಪ್ರಾಕ್ಸಿಯ ಪ್ರಮಾಣಪತ್ರವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ” ಎಂಬುದು ಕ್ಲೈಂಟ್ ಬದಿಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ; ಪ್ರಾಕ್ಸಿ ಮೇಲಕ್ಕೆ ಸಂಪರ್ಕಿಸಿದಾಗ ಏನನ್ನು ನೋಡಿತು ಎಂಬುದನ್ನು ಅದು ಪ್ರಮಾಣೀಕರಿಸುವುದಿಲ್ಲ.