TLS 1.3 'ਤੇ ਆਧਾਰਿਤ ਡੋਮੇਨ ਫਰੰਟਿੰਗ

ਜਾਣ ਪਛਾਣ

Cisco, BlueCoat, FireEye ਵਰਗੇ ਮਸ਼ਹੂਰ ਨਿਰਮਾਤਾਵਾਂ ਦੇ ਆਧੁਨਿਕ ਕਾਰਪੋਰੇਟ ਸਮਗਰੀ ਫਿਲਟਰਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਮਰੁਤਬਾ - DPI ਪ੍ਰਣਾਲੀਆਂ, ਜੋ ਕਿ ਰਾਸ਼ਟਰੀ ਪੱਧਰ 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਦੇ ਨਾਲ ਕਾਫ਼ੀ ਸਮਾਨ ਹਨ। ਦੋਵਾਂ ਦੇ ਕੰਮ ਦਾ ਸਾਰ ਇਨਕਮਿੰਗ ਅਤੇ ਆਊਟਗੋਇੰਗ ਇੰਟਰਨੈਟ ਟ੍ਰੈਫਿਕ ਦਾ ਨਿਰੀਖਣ ਕਰਨਾ ਹੈ ਅਤੇ, ਬਲੈਕ/ਵਾਈਟ ਲਿਸਟਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਇੰਟਰਨੈਟ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾਉਣ ਦਾ ਫੈਸਲਾ ਕਰਨਾ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਦੋਵੇਂ ਆਪਣੇ ਕੰਮ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਸਿਧਾਂਤਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣ ਦੇ ਢੰਗਾਂ ਵਿੱਚ ਵੀ ਬਹੁਤ ਕੁਝ ਸਾਂਝਾ ਹੋਵੇਗਾ।

ਤਕਨੀਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜੋ ਤੁਹਾਨੂੰ DPI ਅਤੇ ਕਾਰਪੋਰੇਟ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਉਹ ਹੈ ਡੋਮੇਨ-ਫਰੰਟਿੰਗ ਤਕਨਾਲੋਜੀ। ਇਸਦਾ ਸਾਰ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਬਲੌਕ ਕੀਤੇ ਸਰੋਤ ਤੇ ਜਾਂਦੇ ਹਾਂ, ਦੂਜੇ ਦੇ ਪਿੱਛੇ ਛੁਪਦੇ ਹੋਏ, ਇੱਕ ਚੰਗੀ ਸਾਖ ਦੇ ਨਾਲ ਜਨਤਕ ਡੋਮੇਨ, ਜੋ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਸਿਸਟਮ ਦੁਆਰਾ ਬਲੌਕ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ, ਉਦਾਹਰਨ ਲਈ google.com.

ਇਸ ਤਕਨੀਕ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਲੇਖ ਲਿਖੇ ਜਾ ਚੁੱਕੇ ਹਨ ਅਤੇ ਕਈ ਉਦਾਹਰਣਾਂ ਦਿੱਤੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਪ੍ਰਸਿੱਧ ਅਤੇ ਹਾਲ ਹੀ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ DNS-ਓਵਰ-HTTPS ਅਤੇ ਐਨਕ੍ਰਿਪਟਡ-SNI ਤਕਨਾਲੋਜੀਆਂ, ਅਤੇ ਨਾਲ ਹੀ TLS 1.3 ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ, ਡੋਮੇਨ ਫਰੰਟਿੰਗ ਲਈ ਇੱਕ ਹੋਰ ਵਿਕਲਪ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ।

ਤਕਨਾਲੋਜੀ ਨੂੰ ਸਮਝਣਾ

ਪਹਿਲਾਂ, ਆਓ ਥੋੜ੍ਹੇ ਜਿਹੇ ਬੁਨਿਆਦੀ ਸੰਕਲਪਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੀਏ ਤਾਂ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਇਹ ਸਮਝ ਹੋਵੇ ਕਿ ਕੌਣ ਹੈ ਅਤੇ ਇਸ ਸਭ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ। ਅਸੀਂ eSNI ਵਿਧੀ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ, ਜਿਸ ਦੇ ਸੰਚਾਲਨ ਬਾਰੇ ਅੱਗੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ। eSNI (ਏਨਕ੍ਰਿਪਟਡ ਸਰਵਰ ਨੇਮ ਇੰਡੀਕੇਸ਼ਨ) ਵਿਧੀ SNI ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸੰਸਕਰਣ ਹੈ, ਜੋ ਸਿਰਫ TLS 1.3 ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਉਪਲਬਧ ਹੈ। ਮੁੱਖ ਵਿਚਾਰ ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਇਨਕ੍ਰਿਪਟ ਕਰਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਕਿ ਬੇਨਤੀ ਕਿਸ ਡੋਮੇਨ ਨੂੰ ਭੇਜੀ ਗਈ ਹੈ।

ਹੁਣ ਆਓ ਦੇਖੀਏ ਕਿ eSNI ਵਿਧੀ ਅਭਿਆਸ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਇੰਟਰਨੈਟ ਸਰੋਤ ਹੈ ਜੋ ਇੱਕ ਆਧੁਨਿਕ DPI ਹੱਲ ਦੁਆਰਾ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ (ਆਓ, ਉਦਾਹਰਨ ਲਈ, ਮਸ਼ਹੂਰ ਟੋਰੈਂਟ ਟਰੈਕਰ rutracker.nl ਨੂੰ ਲੈ ਲਓ)। ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਟੋਰੈਂਟ ਟਰੈਕਰ ਦੀ ਵੈੱਬਸਾਈਟ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਪ੍ਰਦਾਤਾ ਦਾ ਸਟੈਂਡਰਡ ਸਟੱਬ ਦੇਖਦੇ ਹਾਂ ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਰੋਤ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ:

RKN ਵੈੱਬਸਾਈਟ 'ਤੇ ਇਹ ਡੋਮੇਨ ਅਸਲ ਵਿੱਚ ਸਟਾਪ ਸੂਚੀਆਂ ਵਿੱਚ ਸੂਚੀਬੱਧ ਹੈ:

ਜਦੋਂ ਤੁਸੀਂ whois ਬਾਰੇ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਡੋਮੇਨ ਖੁਦ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਕਲਾਉਡਫਲੇਅਰ ਦੇ ਪਿੱਛੇ "ਲੁਕਿਆ ਹੋਇਆ" ਹੈ।

ਪਰ RKN ਦੇ "ਮਾਹਿਰਾਂ" ਦੇ ਉਲਟ, Beeline (ਜਾਂ ਸਾਡੇ ਮਸ਼ਹੂਰ ਰੈਗੂਲੇਟਰ ਦੇ ਕੌੜੇ ਅਨੁਭਵ ਦੁਆਰਾ ਸਿਖਾਏ ਗਏ) ਦੇ ਵਧੇਰੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਮਝਦਾਰ ਕਰਮਚਾਰੀਆਂ ਨੇ ਮੂਰਖਤਾ ਨਾਲ IP ਐਡਰੈੱਸ ਦੁਆਰਾ ਸਾਈਟ 'ਤੇ ਪਾਬੰਦੀ ਨਹੀਂ ਲਗਾਈ, ਪਰ ਡੋਮੇਨ ਨਾਮ ਨੂੰ ਸਟਾਪ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ। ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਇੱਕੋ IP ਪਤੇ ਦੇ ਪਿੱਛੇ ਕਿਹੜੇ ਹੋਰ ਡੋਮੇਨ ਲੁਕੇ ਹੋਏ ਹਨ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਜਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਪਹੁੰਚ ਬਲੌਕ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ:

ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ? ਪ੍ਰਦਾਤਾ ਦਾ DPI ਕਿਵੇਂ ਜਾਣਦਾ ਹੈ ਕਿ ਮੇਰਾ ਬ੍ਰਾਊਜ਼ਰ ਕਿਹੜਾ ਡੋਮੇਨ 'ਤੇ ਹੈ, ਕਿਉਂਕਿ ਸਾਰੇ ਸੰਚਾਰ https ਪ੍ਰੋਟੋਕੋਲ ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਅਸੀਂ ਹਾਲੇ ਤੱਕ ਬੀਲਾਈਨ ਤੋਂ https ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਬਦਲ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਹੈ? ਕੀ ਉਹ ਦਾਅਵੇਦਾਰ ਹੈ ਜਾਂ ਮੇਰਾ ਅਨੁਸਰਣ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?

ਆਉ ਵਾਇਰਸ਼ਾਰਕ ਦੁਆਰਾ ਆਵਾਜਾਈ ਨੂੰ ਦੇਖ ਕੇ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ

ਸਕ੍ਰੀਨਸ਼ਾਟ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਬ੍ਰਾਊਜ਼ਰ DNS ਰਾਹੀਂ ਸਰਵਰ ਦਾ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਫਿਰ ਮੰਜ਼ਿਲ ਸਰਵਰ ਨਾਲ ਇੱਕ ਮਿਆਰੀ TCP ਹੈਂਡਸ਼ੇਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਸਰਵਰ ਨਾਲ ਇੱਕ SSL ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਇਹ ਇੱਕ SSL ਕਲਾਇੰਟ ਹੈਲੋ ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਟੈਕਸਟ ਵਿੱਚ ਸਰੋਤ ਡੋਮੇਨ ਦਾ ਨਾਮ ਹੁੰਦਾ ਹੈ। ਇਹ ਖੇਤਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਰੂਟ ਕਰਨ ਲਈ ਕਲਾਉਡਫਲੇਅਰ ਫਰੰਟਐਂਡ ਸਰਵਰ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪ੍ਰਦਾਤਾ DPI ਸਾਨੂੰ ਫੜਦਾ ਹੈ, ਸਾਡਾ ਕੁਨੈਕਸ਼ਨ ਤੋੜਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਸਾਨੂੰ ਪ੍ਰਦਾਤਾ ਤੋਂ ਕੋਈ ਸਟੱਬ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਸਟੈਂਡਰਡ ਬ੍ਰਾਊਜ਼ਰ ਗਲਤੀ ਦੇਖਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ ਸਾਈਟ ਅਯੋਗ ਹੈ ਜਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਹੈ:

ਹੁਣ ਆਉ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ eSNI ਵਿਧੀ ਨੂੰ ਸਮਰੱਥ ਕਰੀਏ, ਜਿਵੇਂ ਕਿ ਲਈ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ ਫਾਇਰਫਾਕਸ :
ਅਜਿਹਾ ਕਰਨ ਲਈ ਅਸੀਂ ਫਾਇਰਫਾਕਸ ਸੰਰਚਨਾ ਪੰਨਾ ਖੋਲ੍ਹਦੇ ਹਾਂ ਬਾਰੇ: ਸੰਰਚਨਾ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸਰਗਰਮ ਕਰੋ:

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

ਇਸ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਜਾਂਚ ਕਰਾਂਗੇ ਕਿ ਕਲਾਉਡਫਲੇਅਰ ਵੈੱਬਸਾਈਟ 'ਤੇ ਸੈਟਿੰਗਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ। ਲਿੰਕ ਨੂੰ ਅਤੇ ਆਉ ਆਪਣੇ ਟੋਰੈਂਟ ਟਰੈਕਰ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ।

ਵੋਇਲਾ। ਸਾਡਾ ਮਨਪਸੰਦ ਟਰੈਕਰ ਬਿਨਾਂ ਕਿਸੇ ਵੀਪੀਐਨ ਜਾਂ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਦੇ ਖੁੱਲ੍ਹਿਆ। ਆਉ ਹੁਣ ਵਾਇਰਸ਼ਾਰਕ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਡੰਪ ਨੂੰ ਵੇਖਦੇ ਹਾਂ ਕਿ ਕੀ ਹੋਇਆ.

ਇਸ ਵਾਰ, ssl ਕਲਾਇੰਟ ਹੈਲੋ ਪੈਕੇਜ ਵਿੱਚ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮੰਜ਼ਿਲ ਡੋਮੇਨ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ, ਪਰ ਇਸ ਦੀ ਬਜਾਏ, ਪੈਕੇਜ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਖੇਤਰ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ - encrypted_server_name - ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ rutracker.nl ਦਾ ਮੁੱਲ ਸ਼ਾਮਲ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਕਲਾਉਡਫਲੇਅਰ ਫਰੰਟਐਂਡ ਸਰਵਰ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦਾ ਹੈ। ਖੇਤਰ. ਅਤੇ ਜੇਕਰ ਅਜਿਹਾ ਹੈ, ਤਾਂ ਪ੍ਰਦਾਤਾ DPI ਕੋਲ ਆਪਣੇ ਹੱਥ ਧੋਣ ਅਤੇ ਅਜਿਹੀ ਆਵਾਜਾਈ ਦੀ ਆਗਿਆ ਦੇਣ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਹੈ। ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਨਾਲ ਕੋਈ ਹੋਰ ਵਿਕਲਪ ਨਹੀਂ ਹਨ।

ਇਸ ਲਈ, ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਤਕਨੀਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਹੁਣ ਆਉ ਇਸਨੂੰ ਹੋਰ ਖਾਸ ਅਤੇ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ. ਅਤੇ ਪਹਿਲਾਂ, ਅਸੀਂ TLS 1.3 ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ eSNI ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਉਹੀ ਕਰਲ ਸਿਖਾਵਾਂਗੇ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ eSNI- ਅਧਾਰਤ ਡੋਮੇਨ ਫਰੰਟਿੰਗ ਆਪਣੇ ਆਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ।

eSNI ਨਾਲ ਡੋਮੇਨ ਫਰੰਟਿੰਗ

ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ curl https ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਜੁੜਨ ਲਈ ਸਟੈਂਡਰਡ openssl ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਾਨੂੰ ਉੱਥੇ eSNI ਸਹਾਇਤਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। Openssl ਮਾਸਟਰ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਅਜੇ ਤੱਕ ਕੋਈ eSNI ਸਮਰਥਨ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਸਾਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ openssl ਸ਼ਾਖਾ ਨੂੰ ਡਾਉਨਲੋਡ ਕਰਨ, ਇਸਨੂੰ ਕੰਪਾਇਲ ਅਤੇ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਸੀਂ GitHub ਤੋਂ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਕਲੋਨ ਕਰਦੇ ਹਾਂ ਅਤੇ ਆਮ ਵਾਂਗ ਕੰਪਾਇਲ ਕਰਦੇ ਹਾਂ:

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

$ make
$ cd esnistuff
$ make

ਅੱਗੇ, ਅਸੀਂ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ curl ਨਾਲ ਕਲੋਨ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਾਡੀ ਕੰਪਾਇਲ ਕੀਤੀ 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

ਪੈਕੇਜ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ curl ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਅਤੇ ਚਲਾਉਣ ਲਈ openssl ਤੋਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬੈਸ਼ ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ। ਚਲੋ ਇਸਨੂੰ ਸਹੂਲਤ ਲਈ ਕਰਲ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕਾਪੀ ਕਰੀਏ:

cp /opt/openssl/esnistuff/curl-esni 

ਅਤੇ ਵਾਇਰਸ਼ਾਰਕ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ DNS ਅਤੇ TLS ਪੈਕੇਟਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੇ ਹੋਏ, ਕਲਾਉਡਫਲੇਅਰ ਸਰਵਰ ਨੂੰ ਇੱਕ ਜਾਂਚ https ਬੇਨਤੀ ਕਰੋ।

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

ਸਰਵਰ ਜਵਾਬ ਵਿੱਚ, openssl ਅਤੇ curl ਤੋਂ ਬਹੁਤ ਸਾਰੀ ਡੀਬਗਿੰਗ ਜਾਣਕਾਰੀ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਕਲਾਉਡਫਲੇਅਰ ਤੋਂ ਕੋਡ 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 ਨੇ ਇਸ ਕੇਸ ਵਿੱਚ ਕੀ ਦੇਖਿਆ।

ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ curl ਨੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਉਡਫਲੇਅਰ ਸਰਵਰ ਲਈ ਇੱਕ ਜਨਤਕ eSNI ਕੁੰਜੀ ਲਈ DNS ਸਰਵਰ ਵੱਲ ਮੁੜਿਆ - _esni.cloudflare.com (ਪੈਕੇਜ ਨੰ. 13) ਨੂੰ ਇੱਕ TXT DNS ਬੇਨਤੀ। ਫਿਰ, openssl ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, curl ਨੇ ਕਲਾਉਡਫਲੇਅਰ ਸਰਵਰ ਨੂੰ ਇੱਕ TLS 1.3 ਬੇਨਤੀ ਭੇਜੀ ਜਿਸ ਵਿੱਚ SNI ਫੀਲਡ ਨੂੰ ਪਿਛਲੇ ਪੜਾਅ (ਪੈਕੇਟ #22) ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਨਤਕ ਕੁੰਜੀ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਸੀ। ਪਰ, eSNI ਫੀਲਡ ਤੋਂ ਇਲਾਵਾ, SSL-hello ਪੈਕੇਟ ਵਿੱਚ ਆਮ - ਓਪਨ SNI ਦੇ ਨਾਲ ਇੱਕ ਫੀਲਡ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਕਿਸੇ ਵੀ ਕ੍ਰਮ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ (ਇਸ ਕੇਸ ਵਿੱਚ - www.hello-rkn.ru).

ਇਸ ਓਪਨ SNI ਫੀਲਡ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ ਗਿਆ ਸੀ ਜਦੋਂ ਕਲਾਉਡਫਲੇਅਰ ਸਰਵਰਾਂ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਕੇਵਲ ਪ੍ਰਦਾਤਾ DPI ਲਈ ਇੱਕ ਮਾਸਕ ਵਜੋਂ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ। ਕਲਾਉਡਫਲੇਅਰ ਸਰਵਰ ਨੇ ਸਾਡਾ ssl-hello ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕੀਤਾ, eSNI ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ, ਉੱਥੋਂ ਅਸਲੀ SNI ਕੱਢਿਆ ਅਤੇ ਇਸ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਿਵੇਂ ਕਿ ਕੁਝ ਨਹੀਂ ਹੋਇਆ ਸੀ (ਇਸਨੇ eSNI ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵੇਲੇ ਯੋਜਨਾ ਅਨੁਸਾਰ ਸਭ ਕੁਝ ਕੀਤਾ)।

DPI ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇਸ ਕੇਸ ਵਿੱਚ ਸਿਰਫ ਇਕੋ ਚੀਜ਼ ਫੜੀ ਜਾ ਸਕਦੀ ਹੈ _esni.cloudflare.com ਨੂੰ ਪ੍ਰਾਇਮਰੀ DNS ਬੇਨਤੀ. ਪਰ ਅਸੀਂ DNS ਬੇਨਤੀ ਨੂੰ ਸਿਰਫ ਇਹ ਦਿਖਾਉਣ ਲਈ ਖੋਲ੍ਹਿਆ ਹੈ ਕਿ ਇਹ ਵਿਧੀ ਅੰਦਰੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ।

ਅੰਤ ਵਿੱਚ ਡੀਪੀਆਈ ਦੇ ਹੇਠਾਂ ਤੋਂ ਗਲੀਚੇ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤੇ DNS-ਓਵਰ-HTTPS ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਵਿਆਖਿਆ - DOH ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ HTTPS ਉੱਤੇ ਇੱਕ DNS ਬੇਨਤੀ ਭੇਜ ਕੇ ਇੱਕ ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲੇ ਤੋਂ ਬਚਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਚਲੋ ਬੇਨਤੀ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰੀਏ, ਪਰ ਇਸ ਵਾਰ ਅਸੀਂ https ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਜਨਤਕ eSNI ਕੁੰਜੀਆਂ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ, ਨਾ ਕਿ DNS:

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

ਬੇਨਤੀ ਟ੍ਰੈਫਿਕ ਡੰਪ ਹੇਠਾਂ ਦਿੱਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:

ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ curl ਪਹਿਲਾਂ Mozilla.cloudflare-dns.com ਸਰਵਰ ਨੂੰ DoH ਪ੍ਰੋਟੋਕੋਲ (ਸਰਵਰ 104.16.249.249 ਨਾਲ https ਕਨੈਕਸ਼ਨ) ਦੁਆਰਾ ਐਕਸੈਸ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹਨਾਂ ਤੋਂ SNI ਐਨਕ੍ਰਿਪਸ਼ਨ ਲਈ ਜਨਤਕ ਕੁੰਜੀਆਂ ਦੇ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾ ਸਕਣ, ਅਤੇ ਫਿਰ ਮੰਜ਼ਿਲ ਤੱਕ ਸਰਵਰ, ਡੋਮੇਨ ਦੇ ਪਿੱਛੇ ਲੁਕਿਆ ਹੋਇਆ ਹੈ 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

ਇਸ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ DoH ਰੈਜ਼ੋਲਵਰ dns.google (ਇੱਥੇ ਕੋਈ ਟਾਈਪੋ ਨਹੀਂ ਹੈ, ਹੁਣ ਮਸ਼ਹੂਰ ਕਾਰਪੋਰੇਸ਼ਨ ਦਾ ਆਪਣਾ ਪਹਿਲਾ-ਪੱਧਰ ਦਾ ਡੋਮੇਨ ਹੈ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਬਲੌਕ ਕੀਤੇ rutracker.nl ਸਰਵਰ ਵੱਲ ਮੁੜਿਆ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਹੋਰ ਡੋਮੇਨ ਨਾਲ ਕਵਰ ਕੀਤਾ, ਜੋ ਕਿ ਸਖਤੀ ਨਾਲ ਸਾਰੇ DPIs ਲਈ ਮੌਤ ਦੇ ਦਰਦ ਦੇ ਅਧੀਨ ਬਲਾਕ ਕਰਨ ਦੀ ਮਨਾਹੀ ਹੈ। ਪ੍ਰਾਪਤ ਹੋਏ ਜਵਾਬ ਦੇ ਆਧਾਰ 'ਤੇ, ਤੁਸੀਂ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੀ ਬੇਨਤੀ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਸੰਸਾਧਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇੱਕ ਵਾਧੂ ਜਾਂਚ ਦੇ ਤੌਰ ਤੇ ਕਿ ਪ੍ਰਦਾਤਾ ਦਾ 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 'ਤੇ ਅਧਾਰਤ ਡੋਮੇਨ ਫਰੰਟਿੰਗ ਦੇ ਸੰਚਾਲਨ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਇਸੇ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਆਪਣੇ ਮਨਪਸੰਦ ਸਾਧਨਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਓਪਨਸਲ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਦੂਜੇ ਡੋਮੇਨਾਂ ਦੀ "ਆੜ ਵਿੱਚ" ਕੰਮ ਕਰਨ ਲਈ ਕਰਦੇ ਹਨ। ਸਾਡੇ ਅਗਲੇ ਲੇਖਾਂ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ।

ਸਰੋਤ: www.habr.com