TLS 1.3 ಇನ್ನೂ ಸರ್ವರ್ ಹೆಸರನ್ನು ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಕಳುಹಿಸುತ್ತದೆ

ಲಿಸನರ್ ಅನ್ನು TLS 1.3 ಗೆ ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದು ವೀಕ್ಷಕರು ಏನನ್ನು ಓದಬಹುದು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದರೆ ಆವೃತ್ತಿ ಸಂಖ್ಯೆ ಸೂಚಿಸುವಷ್ಟಲ್ಲ. ClientHello ಇನ್ನೂ ಯಾವುದೇ ಎನ್ಕ್ರಿಪ್ಷನ್ ಮೇಲೆ ಚರ್ಚೆಗೆ ಮೊದಲು ಪ್ರಯಾಣಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಸಂಪರ್ಕದಲ್ಲಿ ವಿನಂತಿಸಿದ ಸರ್ವರ್ ಹೆಸರು ಅಲ್ಲಿ ಸರಳ ಪಠ್ಯದಲ್ಲಿದೆ. Encrypted Client Hello ಅದನ್ನು ಮರೆಮಾಡುವ ವಿಧಾನವಾಗಿದೆ, ಮತ್ತು ಇದು ತನ್ನದೇ ಪೂರ್ವ ಷರತ್ತುಗಳಿರುವ ಪ್ರತ್ಯೇಕ ನಿಯೋಜನೆಯಾಗಿದೆ. ಎರಡೂ ನಡವಳಿಕೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಊಹಿಸುವ ನೀತಿ ಬರೆಯುವ ಮೊದಲು ಈ ನಾಲ್ಕು ಹಂತಗಳನ್ನು ಮಾಡಿ.

ಹಸ್ತಲಾಘವ ನಿಜವಾಗಿ ಏನನ್ನು ಬಯಲಿಗೆಳೆಯುತ್ತದೆ

TLS 1.3 ಸರ್ವರ್ನ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ServerHello ನಂತರ ಬರುವ ಹೆಚ್ಚಿನ ಹಸ್ತಲಾಘವವನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮೊದಲು ಕಳುಹಿಸುವುದೆಲ್ಲವೂ ಆ ರಕ್ಷಣೆಯ ಹೊರಗಿದೆ, ಏಕೆಂದರೆ ಕೀಗಳು ಇನ್ನೂ ಇಲ್ಲ. ಸರ್ವರ್ ಹೆಸರಿನ ಸೂಚನೆ ಆ ಮೊದಲ ಹಾರಾಟದ ಭಾಗವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಿಷ್ಕ್ರಿಯ ವೀಕ್ಷಕರು ಏನನ್ನೂ ಒಡೆಯದೆ ಅದನ್ನು ಇನ್ನೂ ಓದಬಹುದು.

ECH ವಿಶೇಷಣ, RFC 9849, ಸಹಕರಿಸುವ ಸರ್ವರ್ಗಾಗಿ ಆಂತರಿಕ ClientHello ಅನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಮೂಲಕ ಇದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಬಾಹ್ಯ ಹಸ್ತಲಾಘವ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ನೋಡಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಹೊತ್ತುಕೊಂಡಿದೆ, ಆದ್ದರಿಂದ ನಿಯೋಜನೆಗೆ ಇನ್ನೂ ಮಧ್ಯವರ್ತಿಗಳಿಗೆ ಅರ್ಥಪೂರ್ಣವಾದ ಬಾಹ್ಯ ಗುರುತು ಬೇಕು. ಆ ಬಾಹ್ಯ ಹೆಸರೇ ಸಂಪರ್ಕ ಅನಾಮಧೇಯವಾಗುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವಾಗ ಜನರು ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಭಾಗ. ಇದು ಮುಚ್ಚು ಹೆಸರು, ಮರೆಮಾಡಿದ ಹೆಸರಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಬೇರೆ ಯಾವುದರಂತೆಯೇ ಪರಿಹರಿಸಿ ದೃಢೀಕರಿಸಬೇಕು.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ವಿತರಣಾ ಮಾರ್ಗವನ್ನು ಮರೆಮಾಡುವುದಿಲ್ಲ. ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸಗಳು, ಪೋರ್ಟ್ಗಳು, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಗಳು ಮತ್ತು ಸಮಯವು ಗಮನಿಸಬಹುದಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಅವು ಹೆಸರಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಯಾರು ಮಾತನಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತವೆ. ಹೆಸರಿನ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಸಂಬಂಧಗಳು ಇನ್ನೊಂದು ಪದರ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಗೋಚರತೆ.

ಊಹಿಸುವ ಬದಲು ClientHello ಓದಿ

ServerHello ನಲ್ಲಿನ ಆವೃತ್ತಿ ಕ್ಲೈಂಟ್ ಏನು ಕಳುಹಿಸಿತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಮೊದಲ ಹಾರಾಟವನ್ನು ನೇರವಾಗಿ ನೋಡಿ, ನಿಮಗೆ ಮುಖ್ಯವಾದ ವೀಕ್ಷಕರನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಸ್ಥಾನದಿಂದ.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

ಮೊದಲ ಆದೇಶವು ಹಸ್ತಲಾಘವ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಪ್ಪಿಕೊಂಡ ನಿಯತಾಂಕಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿ ಮತ್ತು ನೀವು ವಿನಂತಿಸಿದ ಹೆಸರು ಸೇರಿವೆ. ಎರಡನೆಯದು ನಿಜವಾದ ಸಂಪರ್ಕದ ಮೊದಲ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ, ಮೂರನೆಯದು ಆ ಸೆರೆಹಿಡಿಯುವಿಕೆಯಿಂದ SNI ಕ್ಷೇತ್ರವನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ. ಕ್ಷೇತ್ರ ತುಂಬಿದ್ದರೆ, ನೀವು ಅನುಕರಿಸಿದ ವೀಕ್ಷಕರು ಅದನ್ನು ಓದಬಹುದು.

ಎರಡೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಮತ್ತು ಮಾರ್ಗದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಏಕೆಂದರೆ ಸ್ಥಳೀಯ ಸೆರೆಹಿಡಿಯುವಿಕೆ middlebox ನಂತರ ಮತ್ತೆ ಬರೆಯುವ ಅಥವಾ ಬಿಡುವ ಹೆಸರನ್ನು ತೋರಿಸಬಹುದು. ತಾನೇ TLS ಮುಗಿಸದ ಹೋಸ್ಟ್ನಿಂದಲೂ ಸೆರೆಹಿಡಿಯಿರಿ, ಏಕೆಂದರೆ ಮುಗಿಸುವ ಪ್ರಾಕ್ಸಿ ಸರಳ ಪಠ್ಯವನ್ನು ಅದರ ರಚನೆಯಂತೆಯೇ ನೋಡುತ್ತದೆ, ನೆಟ್ವರ್ಕ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಏನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ECH ವಿಸ್ತರಣೆಯನ್ನು ಪ್ರತಿಪಾದನೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಸಾಕ್ಷ್ಯವಲ್ಲ

ClientHello ನಲ್ಲಿ ECH ವಿಸ್ತರಣೆ ಕಾಣುವುದು ಸಂಪರ್ಕ ECH ಬಳಸಿತು ಎಂದಲ್ಲ. ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಬಳಸಬಹುದಾದ ಸಂರಚನೆ ಇಲ್ಲದಿದ್ದಾಗ GREASE ECH ಕಳುಹಿಸುತ್ತವೆ, ಅವುಗಳ ಹಸ್ತಲಾಘವಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುವಂತೆ. ವಿಸ್ತರಣೆ ಇದೆ, ಒಳಗಿನ hello ಒಂದು ಆಮಿಷ, ಮತ್ತು ನಿಜವಾದ ಹೆಸರು ಇನ್ನೂ ಓದಬಹುದಾಗಿದೆ.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

ಮೊದಲ ಆದೇಶವು ಮೂಲವು ECH ಸಂರಚನೆ ನಿಯತಾಂಕದೊಂದಿಗೆ HTTPS ಸಂಪನ್ಮೂಲ ದಾಖಲೆಯನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಹೀಗೆಯೇ ಕ್ಲೈಂಟ್ಗಳು ಕೀಯನ್ನು ಕಲಿಯುತ್ತವೆ. ಎರಡನೆಯದು ಹಸ್ತಲಾಘವದ ಸ್ಥಿತಿ ಮಾಹಿತಿಯನ್ನು ಹುಡುಕುತ್ತದೆ, ಆದರೂ ಕ್ಲೈಂಟ್ನ ಯಶಸ್ಸಿನ ಸಂದೇಶ ಬಲವಾದ ಸಾಕ್ಷ್ಯ. ಸ್ವೀಕಾರವೇ ಮುಖ್ಯ: ಹೊಂದುವ ಕೀ ಇಲ್ಲದ ಸರ್ವರ್ ಒಳಗಿನ hello ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲಾರದು, ಮತ್ತು ಸಂಪರ್ಕ ಹಿಂದೆ ಸರಿಯುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್ ಬೆಂಬಲ ಮತ್ತು ಸಂರಚನೆ ಆವೃತ್ತಿ ಮತ್ತು ವೇದಿಕೆಯ ಪ್ರಕಾರ ಬದಲಾಗುತ್ತದೆ. „ಆಧುನಿಕ ಬ್ರೌಸರ್ಗಳು ECH ಬಳಸುತ್ತವೆ“ ಎಂಬುದರ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ನೀತಿ ಒಂದು ಕಾಫಲದ ಬಗ್ಗೆ ಊಹೆ, ನಿಮ್ಮ ಕಾಫಲದ ಬಗ್ಗೆ ಸತ್ಯವಲ್ಲ. ನಿಜವಾಗಿ ಸಂಪರ್ಕಿಸುವ ಆವೃತ್ತಿಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ನಂತರ ಪ್ರತಿಯೊಂದರಿಂದ ಒಂದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪ್ರಸ್ತುತ ಡೆಸ್ಕ್ಟಾಪ್ ಬ್ರೌಸರ್ನಿಂದ ಕೆಲಸ ಮಾಡುವ ಅದೇ ಪುಟವು ಅದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಹಳೆಯ ಕ್ಲೈಂಟ್ನಿಂದ ಏನನ್ನೂ ಮರೆಮಾಡದೇ ಇರಬಹುದು.

ವೀಕ್ಷಕರ ವ್ಯಾಪ್ತಿಯನ್ನು ನೀತಿಯಲ್ಲಿ ಬರೆಯಿರಿ

ನಿಯಂತ್ರಣವು ಯಾವುದನ್ನು ಅವಲಂಬಿಸಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ವೀಕ್ಷಕರು ಎಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಆ ಬಿಂದುವಿನಲ್ಲಿ ಏನು ಗೋಚರವಾಗಿದೆ ಎಂದು ತಿಳಿಸಿ. ಬ್ರೌಸರ್ನ ಸೈಟ್ಗೆ ಸಂಪರ್ಕ, ಬಾಹ್ಯ VPN ಸಾಗಣೆ ಮತ್ತು TLS ಮುಗಿಸುವ ಪ್ರಾಕ್ಸಿ — ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಸತ್ಯಸಂಗ್ರಹವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಒಂದು ಸ್ಥಾನಕ್ಕೆ ಬರೆದ ನಿಯಮವು ಇನ್ನೊಂದಕ್ಕೆ ಅಪರೂಪವಾಗಿ ಸ್ವಚ್ಛವಾಗಿ ವರ್ಗಾವಣೆಯಾಗುತ್ತದೆ.

ನಿಯಂತ್ರಣವು SNI ಓದುವಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ECH ಲಭ್ಯವಿದ್ದಾಗ ಮತ್ತು ಇಲ್ಲದಿದ್ದಾಗ ನಿಯೋಜಿತ ಕ್ಲೈಂಟ್ಗಳು ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ ಎಂದು ಪರೀಕ್ಷಿಸಿ. ನಂತರ ಹೊಂದಾಣಿಕೆಯ ಪರಿಣಾಮವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮೌನವಾಗಿ ಹೊಂದಿಕೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಫಿಲ್ಟರ್ ಎಂದಿಗೂ ನಿಯೋಜಿಸದ ಫಿಲ್ಟರ್ಗಿಂತ ಕೆಟ್ಟದು.

ಕೊನೆಯದಾಗಿ, ಅನಿಶ್ಚಿತತೆಯನ್ನು ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ. ಹಳೆಯ ಸಾರ್ವತ್ರಿಕ ಪ್ರತಿಪಾದನೆಯನ್ನು ಹೊಸದರಿಂದ ಬದಲಾಯಿಸುವುದು ಅದೇ ಅಂತರವನ್ನು ಇನ್ನೊಂದು ಪ್ರೋಟೋಕಾಲ್ ಹೆಸರಿನ ಅಡಿಯಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವಿಮರ್ಶಕರು ಅದನ್ನು ಅಷ್ಟೇ ದೃಢವಾಗಿ ನಂಬುತ್ತಾರೆ.