ESNI ನೊಂದಿಗೆ ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುವುದು

ಹಲೋ ಹಬ್ರ್, ನನ್ನ ಹೆಸರು ಇಲ್ಯಾ, ನಾನು ಎಕ್ಸ್‌ನೆಸ್‌ನಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಮ್ಮ ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಬಳಸುವ ಪ್ರಮುಖ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳನ್ನು ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ.

ಈ ಲೇಖನದಲ್ಲಿ, ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್‌ಗಳ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ SNI (ESNI) ತಂತ್ರಜ್ಞಾನವನ್ನು ಅಳವಡಿಸುವ ನನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.

ಈ ತಂತ್ರಜ್ಞಾನದ ಬಳಕೆಯು ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸುರಕ್ಷತೆಯ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಕಂಪನಿಯು ಅಳವಡಿಸಿಕೊಂಡ ಆಂತರಿಕ ಭದ್ರತಾ ಮಾನದಂಡಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಮೊದಲನೆಯದಾಗಿ, ತಂತ್ರಜ್ಞಾನವು ಪ್ರಮಾಣಿತವಾಗಿಲ್ಲ ಮತ್ತು ಇನ್ನೂ ಡ್ರಾಫ್ಟ್‌ನಲ್ಲಿದೆ ಎಂದು ನಾನು ಗಮನಸೆಳೆಯಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ CloudFlare ಮತ್ತು Mozilla ಈಗಾಗಲೇ ಅದನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ. ಕರಡು 01) ಇದು ಇಂತಹ ಪ್ರಯೋಗಕ್ಕೆ ನಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸಿತು.

ಸಿದ್ಧಾಂತದ ಒಂದು ಬಿಟ್

ESNI TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ "ಕ್ಲೈಂಟ್ ಹಲೋ" ಸಂದೇಶದಲ್ಲಿ SNI ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಅನುಮತಿಸುವ TLS 1.3 ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ವಿಸ್ತರಣೆಯಾಗಿದೆ. ESNI ಬೆಂಬಲದೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ಹಲೋ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ (ಸಾಮಾನ್ಯ SNI ಬದಲಿಗೆ ನಾವು ESNI ಅನ್ನು ನೋಡುತ್ತೇವೆ):

 ESNI ಅನ್ನು ಬಳಸಲು, ನಿಮಗೆ ಮೂರು ಘಟಕಗಳು ಬೇಕಾಗುತ್ತವೆ:

• DNS; 
• ಗ್ರಾಹಕ ಬೆಂಬಲ;
• ಸರ್ವರ್ ಸೈಡ್ ಬೆಂಬಲ.

ಡಿಎನ್ಎಸ್

ನೀವು ಎರಡು DNS ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ - Aಮತ್ತು TXT (TXT ದಾಖಲೆಯು ಕ್ಲೈಂಟ್ SNI ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯನ್ನು ಒಳಗೊಂಡಿದೆ) - ಕೆಳಗೆ ನೋಡಿ. ಜೊತೆಗೆ, ಬೆಂಬಲ ಇರಬೇಕು DoH (HTTPS ಮೂಲಕ DNS) ಏಕೆಂದರೆ ಲಭ್ಯವಿರುವ ಕ್ಲೈಂಟ್‌ಗಳು (ಕೆಳಗೆ ನೋಡಿ) DoH ಇಲ್ಲದೆ ESNI ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ. ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ, ಏಕೆಂದರೆ ESNI ನಾವು ಪ್ರವೇಶಿಸುತ್ತಿರುವ ಸಂಪನ್ಮೂಲದ ಹೆಸರಿನ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅಂದರೆ, UDP ಮೂಲಕ DNS ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಇದಲ್ಲದೆ, ಬಳಕೆ ಡಿಎನ್‌ಎಸ್‌ಎಸ್‌ಇಸಿ ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ ಸಂಗ್ರಹ ವಿಷದ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಪ್ರಸ್ತುತ ಲಭ್ಯವಿದೆ ಹಲವಾರು DoH ಪೂರೈಕೆದಾರರು, ಅವುಗಳಲ್ಲಿ:

• ಕ್ಲೌಡ್ಫಲೇರ್
• OpenDNS
• ಗೂಗಲ್

ಕ್ಲೌಡ್ಫಲೇರ್ ಘೋಷಿಸುತ್ತದೆ (ನನ್ನ ಬ್ರೌಸರ್ ಪರಿಶೀಲಿಸಿ → ಎನ್‌ಕ್ರಿಪ್ಟೆಡ್ SNI → ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ) ಅವರ ಸರ್ವರ್‌ಗಳು ಈಗಾಗಲೇ ESNI ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಅಂದರೆ, DNS ನಲ್ಲಿ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ನಾವು ಕನಿಷ್ಟ ಎರಡು ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - A ಮತ್ತು TXT. ಕೆಳಗಿನ ಉದಾಹರಣೆಯಲ್ಲಿ ನಾವು Google DNS ಅನ್ನು ಪ್ರಶ್ನಿಸುತ್ತೇವೆ (HTTPS ಮೂಲಕ): 

А ಪ್ರವೇಶ:

curl 'https://dns.google.com/resolve?name=www.cloudflare.com&type=A' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "www.cloudflare.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.210.9"
    },
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.209.9"
    }
  ]
}

TXT ರೆಕಾರ್ಡ್, ವಿನಂತಿಯನ್ನು ಟೆಂಪ್ಲೇಟ್ ಪ್ರಕಾರ ರಚಿಸಲಾಗಿದೆ _esni.FQDN:

curl 'https://dns.google.com/resolve?name=_esni.www.cloudflare.com&type=TXT' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16
    }
  ],
  "Answer": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16,
    "TTL": 1799,
    "data": ""/wEUgUKlACQAHQAg9SiAYQ9aUseUZr47HYHvF5jkt3aZ5802eAMJPhRz1QgAAhMBAQQAAAAAXtUmAAAAAABe3Q8AAAA=""
    }
  ],
  "Comment": "Response from 2400:cb00:2049:1::a29f:209."
}

ಆದ್ದರಿಂದ, DNS ದೃಷ್ಟಿಕೋನದಿಂದ, ನಾವು DoH ಅನ್ನು ಬಳಸಬೇಕು (ಆದ್ಯತೆ DNSSEC ಜೊತೆಗೆ) ಮತ್ತು ಎರಡು ನಮೂದುಗಳನ್ನು ಸೇರಿಸಬೇಕು. 

ಗ್ರಾಹಕ ಬೆಂಬಲ

ನಾವು ಬ್ರೌಸರ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಈ ಸಮಯದಲ್ಲಿ ಬೆಂಬಲವನ್ನು FireFox ನಲ್ಲಿ ಮಾತ್ರ ಅಳವಡಿಸಲಾಗಿದೆ. ಇದು FireFox ನಲ್ಲಿ ESNI ಮತ್ತು DoH ಬೆಂಬಲವನ್ನು ಹೇಗೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಸೂಚನೆಗಳು ಇಲ್ಲಿವೆ. ಬ್ರೌಸರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನಂತರ, ನಾವು ಈ ರೀತಿಯದನ್ನು ನೋಡಬೇಕು:

ಲಿಂಕ್ ಬ್ರೌಸರ್ ಪರಿಶೀಲಿಸಲು.

ಸಹಜವಾಗಿ, ESNI ಅನ್ನು ಬೆಂಬಲಿಸಲು TLS 1.3 ಅನ್ನು ಬಳಸಬೇಕು, ಏಕೆಂದರೆ ESNI TLS 1.3 ಗೆ ವಿಸ್ತರಣೆಯಾಗಿದೆ.

ESNI ಬೆಂಬಲದೊಂದಿಗೆ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನಾವು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ go, ಆದರೆ ನಂತರ ಹೆಚ್ಚು.

ಸರ್ವರ್ ಸೈಡ್ ಬೆಂಬಲ

ಪ್ರಸ್ತುತ, ESNI ಅನ್ನು nginx/apache, ಇತ್ಯಾದಿ ವೆಬ್ ಸರ್ವರ್‌ಗಳು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವರು TLS ನೊಂದಿಗೆ OpenSSL/BoringSSL ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ಇದು ESNI ಅನ್ನು ಅಧಿಕೃತವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ, ನಾವು ನಮ್ಮದೇ ಆದ ಫ್ರಂಟ್-ಎಂಡ್ ಘಟಕವನ್ನು (ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ) ರಚಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಇದು ESNI ನೊಂದಿಗೆ TLS 1.3 ಮುಕ್ತಾಯವನ್ನು ಮತ್ತು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಪ್ರಾಕ್ಸಿ HTTP(S) ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು ESNI ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಇದು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಮುಖ್ಯ ಘಟಕಗಳನ್ನು ಬದಲಾಯಿಸದೆಯೇ - ಅಂದರೆ, ESNI ಅನ್ನು ಬೆಂಬಲಿಸದ ಪ್ರಸ್ತುತ ವೆಬ್ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವುದು. 

ಸ್ಪಷ್ಟತೆಗಾಗಿ, ಇಲ್ಲಿ ಒಂದು ರೇಖಾಚಿತ್ರವಿದೆ:

ESNI ಇಲ್ಲದೆ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಲು ESNI ಇಲ್ಲದೆ TLS ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಪ್ರಾಕ್ಸಿಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ. ಅಲ್ಲದೆ, ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ HTTP ಅಥವಾ HTTPS ಆಗಿರಬಹುದು TLS ಆವೃತ್ತಿಯು 1.3 ಕ್ಕಿಂತ ಕಡಿಮೆ (ಅಪ್‌ಸ್ಟ್ರೀಮ್ 1.3 ಅನ್ನು ಬೆಂಬಲಿಸದಿದ್ದರೆ). ಈ ಯೋಜನೆಯು ಗರಿಷ್ಠ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ.

ESNI ಬೆಂಬಲದ ಅನುಷ್ಠಾನ go ನಾವು ಎರವಲು ಪಡೆದಿದ್ದೇವೆ ಕ್ಲೌಡ್ಫಲೇರ್. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೈಬ್ರರಿಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದರಿಂದ ಅನುಷ್ಠಾನವು ಸಾಕಷ್ಟು ಕ್ಷುಲ್ಲಕವಲ್ಲ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಕ್ರಿಪ್ಟೋ/ಟಿಎಲ್ಎಸ್ ಮತ್ತು ಆದ್ದರಿಂದ "ಪ್ಯಾಚಿಂಗ್" ಅಗತ್ಯವಿದೆ ಗೊರೂಟ್ ಅಸೆಂಬ್ಲಿ ಮೊದಲು.

ನಾವು ಬಳಸಿದ ESNI ಕೀಗಳನ್ನು ರಚಿಸಲು ಎಸ್ನಿಟೂಲ್ (ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನ ಮೆದುಳಿನ ಕೂಸು ಕೂಡ). ಈ ಕೀಗಳನ್ನು SNI ಎನ್‌ಕ್ರಿಪ್ಶನ್/ಡಿಕ್ರಿಪ್ಶನ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ನಾವು Linux (Debian, Alpine) ಮತ್ತು MacOS ನಲ್ಲಿ go 1.13 ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಮಾಣವನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. 

ಕಾರ್ಯಾಚರಣೆಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು

ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಪ್ರೊಮೆಥಿಯಸ್ ಸ್ವರೂಪದಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ rps, ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳು, ವಿಫಲವಾದ/ಯಶಸ್ವಿಯಾದ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಳು ಮತ್ತು TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅವಧಿ. ಮೊದಲ ನೋಟದಲ್ಲಿ, ಪ್ರಾಕ್ಸಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಇದು ಸಾಕಾಗುತ್ತದೆ. 

ಬಳಕೆಗೆ ಮೊದಲು ನಾವು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಸಹ ನಡೆಸಿದ್ದೇವೆ. ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳು:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Running 6m test @ https://esni-rev-proxy.npw:443
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.77s     1.21s    7.20s    65.43%
    Req/Sec    13.78      8.84   140.00     83.70%
  206357 requests in 6.00m, 6.08GB read
Requests/sec:    573.07
Transfer/sec:     17.28MB 

ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಇಲ್ಲದೆಯೇ ಸ್ಕೀಮ್ ಅನ್ನು ಹೋಲಿಸಲು ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಗುಣಾತ್ಮಕ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ. ಮಧ್ಯಂತರ ಘಟಕಗಳಲ್ಲಿನ "ಹಸ್ತಕ್ಷೇಪ" ವನ್ನು ತೊಡೆದುಹಾಕಲು ನಾವು ಸ್ಥಳೀಯವಾಗಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು "ಸುರಿಸಿದ್ದೇವೆ".

ಆದ್ದರಿಂದ, ESNI ಬೆಂಬಲ ಮತ್ತು HTTP ಯೊಂದಿಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಮಾಡುವುದರೊಂದಿಗೆ, ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯ ಸರಾಸರಿ CPU/RAM ಬಳಕೆಯೊಂದಿಗೆ ನಾವು ಒಂದು ನಿದರ್ಶನದಿಂದ ಸುಮಾರು ~550 rps ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:

• 80% CPU ಬಳಕೆ (4 vCPU, 4 GB RAM ಹೋಸ್ಟ್‌ಗಳು, Linux)
• 130 MB ಮೆಮ್ RSS

ಹೋಲಿಕೆಗಾಗಿ, TLS (HTTP ಪ್ರೋಟೋಕಾಲ್) ಮುಕ್ತಾಯವಿಲ್ಲದೆ ಅದೇ nginx ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಾಗಿ RPS ~ 1100 ಆಗಿದೆ:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Running 6m test @ http://lb.npw:80
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11s     2.30s   15.00s    90.94%
    Req/Sec    23.25     13.55   282.00     79.25%
  393093 requests in 6.00m, 11.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 9555
  Non-2xx or 3xx responses: 8111
Requests/sec:   1091.62
Transfer/sec:     32.27MB 

ಸಮಯ ಮೀರುವಿಕೆಗಳ ಉಪಸ್ಥಿತಿಯು ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ (ನಾವು 4 vCPU ಗಳು, 4 GB RAM ಹೋಸ್ಟ್‌ಗಳು, Linux ಅನ್ನು ಬಳಸಿದ್ದೇವೆ), ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಸಂಭಾವ್ಯ RPS ಹೆಚ್ಚಾಗಿದೆ (ನಾವು ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ 2700 RPS ವರೆಗಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ).

ಕೊನೆಯಲ್ಲಿ, ನಾನು ಗಮನಿಸುತ್ತೇನೆ ESNI ತಂತ್ರಜ್ಞಾನವು ಸಾಕಷ್ಟು ಭರವಸೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಇನ್ನೂ ಅನೇಕ ಮುಕ್ತ ಪ್ರಶ್ನೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, DNS ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ESNI ಕೀಲಿಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ESNI ಕೀಗಳನ್ನು ತಿರುಗಿಸುವ ಸಮಸ್ಯೆಗಳು - ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಚರ್ಚಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ESNI ಡ್ರಾಫ್ಟ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯು (ಬರೆಯುವ ಸಮಯದಲ್ಲಿ) ಈಗಾಗಲೇ ಆಗಿದೆ 7.

ಮೂಲ: www.habr.com