TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಪರಿಚಯ

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ
ಸಿಸ್ಕೋ, ಬ್ಲೂಕೋಟ್, ಫೈರ್‌ಐನಂತಹ ಪ್ರಸಿದ್ಧ ತಯಾರಕರ ಆಧುನಿಕ ಕಾರ್ಪೊರೇಟ್ ವಿಷಯ ಫಿಲ್ಟರಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳು ತಮ್ಮ ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಕೌಂಟರ್‌ಪಾರ್ಟ್‌ಗಳು - ಡಿಪಿಐ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ ಸಾಕಷ್ಟು ಸಾಮ್ಯತೆಯನ್ನು ಹೊಂದಿವೆ, ಇವುಗಳನ್ನು ರಾಷ್ಟ್ರೀಯ ಮಟ್ಟದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಇಂಟರ್ನೆಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಕಪ್ಪು/ಬಿಳಿ ಪಟ್ಟಿಗಳ ಆಧಾರದ ಮೇಲೆ ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕವನ್ನು ನಿಷೇಧಿಸುವ ನಿರ್ಧಾರವನ್ನು ಮಾಡುವುದು ಇಬ್ಬರ ಕೆಲಸದ ಮೂಲತತ್ವವಾಗಿದೆ. ಮತ್ತು ಇಬ್ಬರೂ ತಮ್ಮ ಕೆಲಸದ ಮೂಲಭೂತತೆಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ತತ್ವಗಳನ್ನು ಅವಲಂಬಿಸಿರುವುದರಿಂದ, ಅವುಗಳನ್ನು ತಪ್ಪಿಸುವ ವಿಧಾನಗಳು ಸಹ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿರುತ್ತವೆ.

ಡಿಪಿಐ ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ವ್ಯವಸ್ಥೆಗಳೆರಡನ್ನೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬೈಪಾಸ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ ಒಂದು ಡೊಮೇನ್-ಫ್ರಂಟ್ ತಂತ್ರಜ್ಞಾನವಾಗಿದೆ. ಇದರ ಮೂಲತತ್ವವೆಂದರೆ ನಾವು ನಿರ್ಬಂಧಿಸಿದ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಹೋಗುತ್ತೇವೆ, ಇನ್ನೊಂದು, ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್‌ನ ಹಿಂದೆ ಅಡಗಿಕೊಳ್ಳುತ್ತೇವೆ, ಇದು ಯಾವುದೇ ಸಿಸ್ಟಮ್‌ನಿಂದ ನಿಸ್ಸಂಶಯವಾಗಿ ನಿರ್ಬಂಧಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ google.com.

ಈ ತಂತ್ರಜ್ಞಾನದ ಬಗ್ಗೆ ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಲೇಖನಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಅನೇಕ ಉದಾಹರಣೆಗಳನ್ನು ನೀಡಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಜನಪ್ರಿಯ ಮತ್ತು ಇತ್ತೀಚೆಗೆ ಚರ್ಚಿಸಲಾದ DNS-ಓವರ್-HTTPS ಮತ್ತು ಎನ್‌ಕ್ರಿಪ್ಟೆಡ್-SNI ತಂತ್ರಜ್ಞಾನಗಳು, ಹಾಗೆಯೇ TLS 1.3 ಪ್ರೋಟೋಕಾಲ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯು ಡೊಮೇನ್ ಮುಂಭಾಗಕ್ಕೆ ಮತ್ತೊಂದು ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ತಂತ್ರಜ್ಞಾನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಮೊದಲಿಗೆ, ನಾವು ಸ್ವಲ್ಪ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ ಇದರಿಂದ ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾರು ಮತ್ತು ಏಕೆ ಇವೆಲ್ಲವೂ ಬೇಕು ಎಂಬ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ನಾವು eSNI ಕಾರ್ಯವಿಧಾನವನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದೇವೆ, ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು. eSNI (ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸರ್ವರ್ ಹೆಸರು ಸೂಚನೆ) ಯಾಂತ್ರಿಕತೆಯು SNI ನ ಸುರಕ್ಷಿತ ಆವೃತ್ತಿಯಾಗಿದೆ, ಇದು TLS 1.3 ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಮಾತ್ರ ಲಭ್ಯವಿದೆ. ವಿನಂತಿಯನ್ನು ಯಾವ ಡೊಮೇನ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ ಮಾಹಿತಿಯನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಮುಖ್ಯ ಆಲೋಚನೆಯಾಗಿದೆ.

ಈಗ eSNI ಕಾರ್ಯವಿಧಾನವು ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ನಾವು ಆಧುನಿಕ DPI ಪರಿಹಾರದಿಂದ ನಿರ್ಬಂಧಿಸಲಾದ ಇಂಟರ್ನೆಟ್ ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ (ಉದಾಹರಣೆಗೆ, ಪ್ರಸಿದ್ಧ ಟೊರೆಂಟ್ ಟ್ರ್ಯಾಕರ್ rutracker.nl ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ). ನಾವು ಟೊರೆಂಟ್ ಟ್ರ್ಯಾಕರ್‌ನ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಸಂಪನ್ಮೂಲವನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುವ ಪೂರೈಕೆದಾರರ ಪ್ರಮಾಣಿತ ಸ್ಟಬ್ ಅನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ:

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

RKN ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಈ ಡೊಮೇನ್ ವಾಸ್ತವವಾಗಿ ಸ್ಟಾಪ್ ಪಟ್ಟಿಗಳಲ್ಲಿ ಪಟ್ಟಿಮಾಡಲಾಗಿದೆ:

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ನೀವು whois ಅನ್ನು ಪ್ರಶ್ನಿಸಿದಾಗ, ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನ ಹಿಂದೆ ಡೊಮೇನ್ ಸ್ವತಃ "ಮರೆಮಾಡಲಾಗಿದೆ" ಎಂದು ನೀವು ನೋಡಬಹುದು.

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಆದರೆ RKN ನಿಂದ "ತಜ್ಞರು" ಭಿನ್ನವಾಗಿ, Beeline ನಿಂದ ಹೆಚ್ಚು ತಾಂತ್ರಿಕವಾಗಿ ಬುದ್ಧಿವಂತ ಉದ್ಯೋಗಿಗಳು (ಅಥವಾ ನಮ್ಮ ಪ್ರಸಿದ್ಧ ನಿಯಂತ್ರಕನ ಕಹಿ ಅನುಭವದಿಂದ ಕಲಿಸಿದ) IP ವಿಳಾಸದಿಂದ ಸೈಟ್ ಅನ್ನು ಮೂರ್ಖತನದಿಂದ ನಿಷೇಧಿಸಲಿಲ್ಲ, ಆದರೆ ಸ್ಟಾಪ್ ಪಟ್ಟಿಗೆ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಸೇರಿಸಿದರು. ಅದೇ IP ವಿಳಾಸದ ಹಿಂದೆ ಬೇರೆ ಯಾವ ಡೊಮೇನ್‌ಗಳನ್ನು ಮರೆಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದರೆ, ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಭೇಟಿ ಮಾಡಿ ಮತ್ತು ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿಲ್ಲ ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದರೆ ಇದನ್ನು ನೀವು ಸುಲಭವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು:

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ? ಎಲ್ಲಾ ಸಂವಹನಗಳು https ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ನಡೆಯುವುದರಿಂದ ಮತ್ತು Beeline ನಿಂದ https ಪ್ರಮಾಣಪತ್ರಗಳ ಪರ್ಯಾಯವನ್ನು ನಾವು ಇನ್ನೂ ಗಮನಿಸದೇ ಇರುವ ಕಾರಣ, ನನ್ನ ಬ್ರೌಸರ್ ಯಾವ ಡೊಮೇನ್ ಆನ್ ಆಗಿದೆ ಎಂದು ಪೂರೈಕೆದಾರರ DPI ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ? ಅವನು ದಿವ್ಯದೃಷ್ಟಿಯುಳ್ಳವನೇ ಅಥವಾ ನನ್ನನ್ನು ಹಿಂಬಾಲಿಸಲಾಗುತ್ತಿದೆಯೇ?

ವೈರ್‌ಶಾರ್ಕ್ ಮೂಲಕ ದಟ್ಟಣೆಯನ್ನು ನೋಡುವ ಮೂಲಕ ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಮೊದಲು ಬ್ರೌಸರ್ DNS ಮೂಲಕ ಸರ್ವರ್‌ನ IP ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂದು ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ತೋರಿಸುತ್ತದೆ, ನಂತರ ಗಮ್ಯಸ್ಥಾನ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಪ್ರಮಾಣಿತ TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಬ್ರೌಸರ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ SSL ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ಇದು SSL ಕ್ಲೈಂಟ್ ಹಲೋ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ಮೂಲ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಸರಿಯಾಗಿ ರೂಟ್ ಮಾಡಲು ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಮುಂಭಾಗದ ಸರ್ವರ್‌ನಿಂದ ಈ ಕ್ಷೇತ್ರವು ಅಗತ್ಯವಿದೆ. ಇಲ್ಲಿಯೇ ಪೂರೈಕೆದಾರ DPI ನಮ್ಮನ್ನು ಹಿಡಿಯುತ್ತದೆ, ನಮ್ಮ ಸಂಪರ್ಕವನ್ನು ಮುರಿಯುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಒದಗಿಸುವವರಿಂದ ಯಾವುದೇ ಸ್ಟಬ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸೈಟ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಅಥವಾ ಸರಳವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿರುವಂತೆ ನಾವು ಪ್ರಮಾಣಿತ ಬ್ರೌಸರ್ ದೋಷವನ್ನು ನೋಡುತ್ತೇವೆ:

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಸೂಚನೆಗಳಲ್ಲಿ ಬರೆದಂತೆ ಈಗ ಬ್ರೌಸರ್‌ನಲ್ಲಿ eSNI ಕಾರ್ಯವಿಧಾನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸೋಣ ಫೈರ್ಫಾಕ್ಸ್ :
ಇದನ್ನು ಮಾಡಲು ನಾವು ಫೈರ್‌ಫಾಕ್ಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಪುಟವನ್ನು ತೆರೆಯುತ್ತೇವೆ ಕುರಿತು: config ಮತ್ತು ಕೆಳಗಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

ಇದರ ನಂತರ, ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಲಿಂಕ್ ಮತ್ತು ನಮ್ಮ ಟೊರೆಂಟ್ ಟ್ರ್ಯಾಕರ್‌ನೊಂದಿಗೆ ಟ್ರಿಕ್ ಅನ್ನು ಮತ್ತೊಮ್ಮೆ ಪ್ರಯತ್ನಿಸೋಣ.

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ವಾಯ್ಲಾ. ನಮ್ಮ ನೆಚ್ಚಿನ ಟ್ರ್ಯಾಕರ್ ಯಾವುದೇ VPN ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳಿಲ್ಲದೆ ತೆರೆಯಲಾಗಿದೆ. ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೋಡಲು ವೈರ್‌ಶಾರ್ಕ್‌ನಲ್ಲಿನ ಟ್ರಾಫಿಕ್ ಡಂಪ್ ಅನ್ನು ಈಗ ನೋಡೋಣ.

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಈ ಸಮಯದಲ್ಲಿ, ssl ಕ್ಲೈಂಟ್ ಹಲೋ ಪ್ಯಾಕೇಜ್ ಸ್ಪಷ್ಟವಾಗಿ ಗಮ್ಯಸ್ಥಾನದ ಡೊಮೇನ್ ಅನ್ನು ಒಳಗೊಂಡಿಲ್ಲ, ಬದಲಿಗೆ, ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ಹೊಸ ಕ್ಷೇತ್ರವು ಕಾಣಿಸಿಕೊಂಡಿದೆ - encrypted_server_name - ಇಲ್ಲಿಯೇ rutracker.nl ಮೌಲ್ಯವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಮುಂಭಾಗದ ಸರ್ವರ್ ಮಾತ್ರ ಇದನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು ಕ್ಷೇತ್ರ. ಮತ್ತು ಹಾಗಿದ್ದಲ್ಲಿ, ಪೂರೈಕೆದಾರ DPI ತನ್ನ ಕೈಗಳನ್ನು ತೊಳೆದುಕೊಳ್ಳಲು ಮತ್ತು ಅಂತಹ ದಟ್ಟಣೆಯನ್ನು ಅನುಮತಿಸಲು ಬೇರೆ ಆಯ್ಕೆಯಿಲ್ಲ. ಗೂಢಲಿಪೀಕರಣದೊಂದಿಗೆ ಬೇರೆ ಯಾವುದೇ ಆಯ್ಕೆಗಳಿಲ್ಲ.

ಆದ್ದರಿಂದ, ಬ್ರೌಸರ್ನಲ್ಲಿ ತಂತ್ರಜ್ಞಾನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ. ಈಗ ಅದನ್ನು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳಿಗೆ ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ. ಮತ್ತು ಮೊದಲಿಗೆ, TLS 1.3 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು eSNI ಅನ್ನು ಬಳಸಲು ನಾವು ಅದೇ ಕರ್ಲ್ ಅನ್ನು ಕಲಿಸುತ್ತೇವೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ eSNI ಆಧಾರಿತ ಡೊಮೇನ್ ಮುಂಭಾಗವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.

eSNI ಜೊತೆಗೆ ಡೊಮೇನ್ ಮುಂಭಾಗ

https ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂಪರ್ಕಿಸಲು ಕರ್ಲ್ ಪ್ರಮಾಣಿತ openssl ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ, ಮೊದಲನೆಯದಾಗಿ ನಾವು ಅಲ್ಲಿ eSNI ಬೆಂಬಲವನ್ನು ಒದಗಿಸಬೇಕಾಗಿದೆ. ಇನ್ನೂ openssl ಮಾಸ್ಟರ್ ಶಾಖೆಗಳಲ್ಲಿ eSNI ಬೆಂಬಲವಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ವಿಶೇಷ openssl ಶಾಖೆಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಅದನ್ನು ಕಂಪೈಲ್ ಮಾಡಿ ಮತ್ತು ಸ್ಥಾಪಿಸಬೇಕು.

ನಾವು GitHub ನಿಂದ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಎಂದಿನಂತೆ ಕಂಪೈಲ್ ಮಾಡುತ್ತೇವೆ:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

ಮುಂದೆ, ನಾವು ರೆಪೊಸಿಟರಿಯನ್ನು ಕರ್ಲ್‌ನೊಂದಿಗೆ ಕ್ಲೋನ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಕಂಪೈಲ್ ಮಾಡಿದ openssl ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದರ ಸಂಕಲನವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

ಇಲ್ಲಿ openssl ಇರುವ ಎಲ್ಲಾ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು /opt/openssl/) ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಕ್ರಿಯೆಯು ದೋಷಗಳಿಲ್ಲದೆ ಹೋಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಸಂರಚನೆಯು ಯಶಸ್ವಿಯಾದರೆ, ನಾವು ಸಾಲನ್ನು ನೋಡುತ್ತೇವೆ:

ಎಚ್ಚರಿಕೆ: esni ESNI ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಆದರೆ ಪ್ರಾಯೋಗಿಕ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ. ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಿ!

$ make

ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಿರ್ಮಿಸಿದ ನಂತರ, ಕರ್ಲ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಮತ್ತು ರನ್ ಮಾಡಲು ನಾವು openssl ನಿಂದ ವಿಶೇಷ ಬ್ಯಾಷ್ ಫೈಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಅನುಕೂಲಕ್ಕಾಗಿ ಅದನ್ನು ಕರ್ಲ್‌ನೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಗೆ ನಕಲಿಸೋಣ:

cp /opt/openssl/esnistuff/curl-esni 

ಮತ್ತು ವೈರ್‌ಶಾರ್ಕ್‌ನಲ್ಲಿ DNS ಮತ್ತು TLS ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡುವಾಗ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗೆ ಪರೀಕ್ಷಾ https ವಿನಂತಿಯನ್ನು ಮಾಡಿ.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ, openssl ಮತ್ತು ಕರ್ಲ್‌ನಿಂದ ಸಾಕಷ್ಟು ಡೀಬಗ್ ಮಾಡುವ ಮಾಹಿತಿಯ ಜೊತೆಗೆ, ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನಿಂದ ಕೋಡ್ 301 ನೊಂದಿಗೆ ನಾವು HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

ಇದು ನಮ್ಮ ವಿನಂತಿಯನ್ನು ಗಮ್ಯಸ್ಥಾನದ ಸರ್ವರ್‌ಗೆ ಯಶಸ್ವಿಯಾಗಿ ತಲುಪಿಸಲಾಗಿದೆ, ಆಲಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.

ಈಗ ವೈರ್‌ಶಾರ್ಕ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಡಂಪ್ ಅನ್ನು ನೋಡೋಣ, ಅಂದರೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪೂರೈಕೆದಾರ DPI ಏನು ನೋಡಿದೆ.

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗಾಗಿ ಸಾರ್ವಜನಿಕ eSNI ಕೀಗಾಗಿ ಕರ್ಲ್ ಮೊದಲು DNS ಸರ್ವರ್‌ಗೆ ತಿರುಗಿರುವುದನ್ನು ಕಾಣಬಹುದು - _esni.cloudflare.com ಗೆ TXT DNS ವಿನಂತಿ (ಪ್ಯಾಕೇಜ್ ಸಂಖ್ಯೆ. 13). ನಂತರ, openssl ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿಕೊಂಡು, Curl ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗೆ TLS 1.3 ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿತು, ಇದರಲ್ಲಿ SNI ಕ್ಷೇತ್ರವನ್ನು ಹಿಂದಿನ ಹಂತದಲ್ಲಿ ಪಡೆದ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯೊಂದಿಗೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗಿದೆ (ಪ್ಯಾಕೆಟ್ #22). ಆದರೆ, eSNI ಕ್ಷೇತ್ರಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ, SSL-ಹಲೋ ಪ್ಯಾಕೆಟ್ ಸಾಮಾನ್ಯ - ತೆರೆದ SNI ನೊಂದಿಗೆ ಕ್ಷೇತ್ರವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ, ಅದನ್ನು ನಾವು ಯಾವುದೇ ಕ್ರಮದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು (ಈ ಸಂದರ್ಭದಲ್ಲಿ - www.hello-rkn.ru).

ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗಳಿಂದ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ ಈ ತೆರೆದ SNI ಕ್ಷೇತ್ರವನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿಲ್ಲ ಮತ್ತು ಪೂರೈಕೆದಾರ DPI ಗಾಗಿ ಮುಖವಾಡವಾಗಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್ ನಮ್ಮ ಎಸ್‌ಎಸ್‌ಎಲ್-ಹಲೋ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದೆ, ಇಎಸ್‌ಎನ್‌ಐ ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದೆ, ಅಲ್ಲಿಂದ ಮೂಲ ಎಸ್‌ಎನ್‌ಐ ಅನ್ನು ಹೊರತೆಗೆಯಿತು ಮತ್ತು ಏನೂ ಆಗಿಲ್ಲ ಎಂಬಂತೆ ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿತು (ಇಎಸ್‌ಎನ್‌ಐ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅದು ಯೋಜಿಸಿದಂತೆ ಎಲ್ಲವನ್ನೂ ಮಾಡಿದೆ).

DPI ದೃಷ್ಟಿಕೋನದಿಂದ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹಿಡಿಯಬಹುದಾದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ _esni.cloudflare.com ಗೆ ಪ್ರಾಥಮಿಕ DNS ವಿನಂತಿ. ಆದರೆ ಒಳಗಿನಿಂದ ಈ ಕಾರ್ಯವಿಧಾನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ಮಾತ್ರ ನಾವು DNS ವಿನಂತಿಯನ್ನು ತೆರೆದಿದ್ದೇವೆ.

ಅಂತಿಮವಾಗಿ DPI ಅಡಿಯಲ್ಲಿ ರಗ್ ಅನ್ನು ಎಳೆಯಲು, ನಾವು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿರುವ DNS-over-HTTPS ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ. ಸ್ವಲ್ಪ ವಿವರಣೆ - DOH ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು ಅದು HTTPS ಮೂಲಕ DNS ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಮನುಷ್ಯ-ಮಧ್ಯದ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ವಿನಂತಿಯನ್ನು ಮತ್ತೊಮ್ಮೆ ಕಾರ್ಯಗತಗೊಳಿಸೋಣ, ಆದರೆ ಈ ಬಾರಿ ನಾವು ಸಾರ್ವಜನಿಕ eSNI ಕೀಗಳನ್ನು https ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸ್ವೀಕರಿಸುತ್ತೇವೆ, DNS ಅಲ್ಲ:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

ವಿನಂತಿ ಟ್ರಾಫಿಕ್ ಡಂಪ್ ಅನ್ನು ಕೆಳಗಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ:

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

SNI ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ಗಾಗಿ ಸಾರ್ವಜನಿಕ ಕೀಗಳ ಮೌಲ್ಯಗಳನ್ನು ಅವರಿಂದ ಪಡೆಯಲು ಕರ್ಲ್ ಮೊದಲು Mozilla.cloudflare-dns.com ಸರ್ವರ್ ಅನ್ನು DoH ಪ್ರೋಟೋಕಾಲ್ (ಸರ್ವರ್‌ಗೆ https ಸಂಪರ್ಕ 104.16.249.249) ಮೂಲಕ ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂದು ನೋಡಬಹುದು. ಸರ್ವರ್, ಡೊಮೇನ್ ಹಿಂದೆ ಅಡಗಿದೆ www.hello-rkn.ru.

ಮೇಲಿನ DoH ಪರಿಹಾರಕ mozilla.cloudflare-dns.com ಜೊತೆಗೆ, ನಾವು ಇತರ ಜನಪ್ರಿಯ DoH ಸೇವೆಗಳನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಪ್ರಸಿದ್ಧ ದುಷ್ಟ ನಿಗಮದಿಂದ.
ಕೆಳಗಿನ ಪ್ರಶ್ನೆಯನ್ನು ಚಲಾಯಿಸೋಣ:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

ಮತ್ತು ನಾವು ಉತ್ತರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

TLS 1.3 ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗ

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು DoH ಪರಿಹಾರಕ dns.google (ಇಲ್ಲಿ ಯಾವುದೇ ಮುದ್ರಣದೋಷವಿಲ್ಲ, ಈಗ ಪ್ರಸಿದ್ಧ ನಿಗಮವು ತನ್ನದೇ ಆದ ಮೊದಲ ಹಂತದ ಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿದೆ) ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಬಂಧಿಸಲಾದ rutracker.nl ಸರ್ವರ್‌ಗೆ ತಿರುಗಿದ್ದೇವೆ ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಮತ್ತೊಂದು ಡೊಮೇನ್‌ನೊಂದಿಗೆ ನಮ್ಮನ್ನು ಆವರಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಸಾವಿನ ನೋವಿನ ಅಡಿಯಲ್ಲಿ ನಿರ್ಬಂಧಿಸಲು ಎಲ್ಲಾ DPI ಗಳಿಗೆ ನಿಷೇಧಿಸಲಾಗಿದೆ. ಸ್ವೀಕರಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಆಧರಿಸಿ, ನಮ್ಮ ವಿನಂತಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ಒದಗಿಸುವವರ DPI ತೆರೆದ SNI ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಎಂಬ ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನೆಯಾಗಿ, ನಾವು ಕವರ್ ಆಗಿ ರವಾನಿಸುತ್ತೇವೆ, ನಾವು ಇತರ ಕೆಲವು ನಿಷೇಧಿತ ಸಂಪನ್ಮೂಲಗಳ ಸೋಗಿನಲ್ಲಿ rutracker.nl ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮತ್ತೊಂದು "ಉತ್ತಮ" ಟೊರೆಂಟ್ ಟ್ರ್ಯಾಕರ್:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

ನಾವು ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ... ನಮ್ಮ ವಿನಂತಿಯನ್ನು DPI ವ್ಯವಸ್ಥೆಯಿಂದ ನಿರ್ಬಂಧಿಸಲಾಗುತ್ತದೆ.

ಮೊದಲ ಭಾಗಕ್ಕೆ ಒಂದು ಸಣ್ಣ ತೀರ್ಮಾನ

ಆದ್ದರಿಂದ, ನಾವು openssl ಮತ್ತು curl ಅನ್ನು ಬಳಸಿಕೊಂಡು eSNI ನ ಕಾರ್ಯವನ್ನು ಪ್ರದರ್ಶಿಸಲು ಮತ್ತು eSNI ಅನ್ನು ಆಧರಿಸಿ ಡೊಮೇನ್ ಮುಂಭಾಗದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಅದೇ ರೀತಿಯಲ್ಲಿ, ಇತರ ಡೊಮೇನ್‌ಗಳ "ಸೋಗಿನಲ್ಲಿ" ಕೆಲಸ ಮಾಡಲು openssl ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುವ ನಮ್ಮ ನೆಚ್ಚಿನ ಪರಿಕರಗಳನ್ನು ನಾವು ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು. ನಮ್ಮ ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ವಿವರಗಳು.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ