ESNI සමඟ ඔබේ පොදු වෙබ් අඩවිය ආරක්ෂා කරන්නේ කෙසේද?

හෙලෝ හබ්ර්, මගේ නම ඉල්යා, මම වැඩ කරන්නේ Exness හි වේදිකා කණ්ඩායමේ. අපගේ නිෂ්පාදන සංවර්ධන කණ්ඩායම් භාවිතා කරන මූලික යටිතල පහසුකම් සංරචක අපි සංවර්ධනය කර ක්‍රියාත්මක කරමු.

මෙම ලිපියෙන්, පොදු වෙබ් අඩවිවල යටිතල ව්‍යුහය තුළ සංකේතාත්මක SNI (ESNI) තාක්ෂණය ක්‍රියාත්මක කිරීමේ මගේ අත්දැකීම් බෙදා ගැනීමට මම කැමැත්තෙමි.

මෙම තාක්ෂණය භාවිතා කිරීම පොදු වෙබ් අඩවියක් සමඟ වැඩ කිරීමේදී ආරක්ෂක මට්ටම ඉහළ නංවන අතර සමාගම විසින් අනුගමනය කරන ලද අභ්යන්තර ආරක්ෂක ප්රමිතීන්ට අනුකූල වේ.

ප්‍රථමයෙන්ම, තාක්‍ෂණය ප්‍රමිතිගත කර නොමැති අතර තවමත් කෙටුම්පතේ පවතින බව පෙන්වා දීමට කැමැත්තෙමි, නමුත් CloudFlare සහ Mozilla දැනටමත් එයට සහය දක්වයි. කෙටුම්පත 01) එවැනි අත්හදා බැලීමක් සඳහා අපව පෙලඹවූයේ මෙයයි.

න්යායන් ටිකක්

ESNI TLS හෑන්ඩ්ෂේක් "Client Hello" පණිවිඩයේ SNI සංකේතනයට ඉඩ දෙන TLS 1.3 ප්‍රොටෝකෝලය වෙත දිගුවකි. ESNI සහය ඇතිව Client Hello පෙනෙන ආකාරය මෙන්න (සාමාන්‍ය SNI වෙනුවට අපි ESNI දකිමු):

 ESNI භාවිතා කිරීමට, ඔබට සංරචක තුනක් අවශ්‍ය වේ:

• DNS; 
• පාරිභෝගික සහාය;
• සේවාදායක පැත්තේ සහාය.

DNS

ඔබට DNS වාර්තා දෙකක් එක් කිරීමට අවශ්‍යයි - Aහා TXT (TXT වාර්තාවේ සේවාදායකයාට SNI සංකේතනය කළ හැකි පොදු යතුර අඩංගු වේ) - පහත බලන්න. ඊට අමතරව, සහාය තිබිය යුතුය DoH (HTTPS හරහා DNS) පවතින සේවාලාභීන් (පහත බලන්න) DoH නොමැතිව ESNI සහාය සක්‍රීය නොකරන නිසා. මෙය තාර්කික ය, මන්ද ESNI මඟින් අප ප්‍රවේශ වන සම්පතේ නම සංකේතනය කිරීම අදහස් කරයි, එනම් UDP හරහා DNS වෙත ප්‍රවේශ වීම තේරුමක් නැත. ඊට අමතරව, භාවිතය DNSSEC මෙම අවස්ථාවෙහිදී හැඹිලි විෂ ප්‍රහාර වලින් ආරක්ෂා වීමට ඔබට ඉඩ සලසයි.

දැනට ලබා ගත DoH සපයන්නන් කිහිපයක්, ඒ අය අතරින්:

• CloudFlare
• OpenDNS
• ගූගල්

CloudFlare ප්‍රකාශ කරයි (Check My Browser → Encrypted SNI → More Learn) ඔවුන්ගේ සේවාදායකයන් දැනටමත් ESNI සඳහා සහය දක්වයි, එනම් DNS හි CloudFlare සේවාදායකයන් සඳහා අපට අවම වශයෙන් වාර්තා දෙකක් තිබේ - 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 නිල වශයෙන් ESNI සඳහා සහය නොදක්වන OpenSSL/BoringSSL හරහා TLS සමඟ වැඩ කරන බැවින්, nginx/apache වැනි වෙබ් සේවාදායකයන් විසින් ESNI සඳහා සහය නොදක්වයි.

එබැවින්, ESNI සහය නොදක්වන ESNI සහ ප්‍රොක්සි HTTP(S) ගමනාගමනය සමඟින් TLS 1.3 අවසන් කිරීමට සහය දක්වන අපගේම ඉදිරිපස අංගයක් (ESNI reverse proxy) නිර්මාණය කිරීමට අපි තීරණය කළෙමු. ප්‍රධාන සංරචක වෙනස් නොකර දැනටමත් පවතින යටිතල ව්‍යුහයක තාක්ෂණය භාවිතා කිරීමට මෙය ඔබට ඉඩ සලසයි - එනම්, ESNI සඳහා සහය නොදක්වන වත්මන් වෙබ් සේවාදායකයන් භාවිතා කරන්න. 

පැහැදිලිකම සඳහා, මෙන්න රූප සටහනක්:

ප්‍රොක්සි නිර්මාණය කර ඇත්තේ ESNI නොමැතිව TLS සම්බන්ධතාවයක් අවසන් කිරීමට, ESNI නොමැතිව සේවාලාභීන්ට සහාය වීම සඳහා බව මම සටහන් කරමි. එසේම, upstream සමඟ ඇති සන්නිවේදන ප්‍රොටෝකෝලය 1.3ට වඩා අඩු TLS අනුවාදයක් සහිත HTTP හෝ HTTPS විය හැකිය (උඩු ධාරාව 1.3 සඳහා සහය නොදක්වන්නේ නම්). මෙම යෝජනා ක්රමය උපරිම නම්යශීලී බවක් ලබා දෙයි.

ESNI සහාය ක්‍රියාත්මක කිරීම go අපි ණයට ගත්තා CloudFlare. සම්මත පුස්තකාලයේ වෙනස්කම් ඇතුළත් වන බැවින් ක්‍රියාත්මක කිරීම ඉතා සුළු නොවන බව මම වහාම සටහන් කිරීමට කැමැත්තෙමි. crypto/tls එබැවින් "පැච් කිරීම" අවශ්ය වේ ගෝරූට් එකලස් කිරීමට පෙර.

අපි භාවිතා කළ ESNI යතුරු ජනනය කිරීමට esnitool (ඒවගේම CloudFlare හි සංකල්පයක්). මෙම යතුරු SNI සංකේතනය/විකේතනය සඳහා භාවිතා වේ.
අපි Linux (Debian, Alpine) සහ MacOS මත go 1.13 භාවිතයෙන් ගොඩනැගීම පරීක්ෂා කළෙමු. 

මෙහෙයුම් විශේෂාංග ගැන වචන කිහිපයක්

ESNI ප්‍රතිලෝම ප්‍රොක්සි මඟින් rps, උඩුගං ප්‍රමාද සහ ප්‍රතිචාර කේත, අසාර්ථක/සාර්ථක TLS හෑන්ඩ්ෂේක් සහ TLS අතට අත දීමේ කාලසීමාව වැනි Prometheus ආකෘතියෙන් ප්‍රමිතික සපයයි. මුලින්ම බැලූ බැල්මට, ප්‍රොක්සිය ගමනාගමනය හසුරුවන්නේ කෙසේද යන්න තක්සේරු කිරීමට මෙය ප්‍රමාණවත් බව පෙනුණි. 

අපි භාවිතයට පෙර බර පරීක්ෂාව ද සිදු කළෙමු. පහත ප්‍රතිඵල:

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 වෙතින් ඉහළට ප්‍රොක්සි කිරීම සමඟින්, අපි එක් අවස්ථාවක සිට ~550 rps පමණ ලබා ගත්තෙමු, ESNI ප්‍රතිලෝම ප්‍රොක්සියේ සාමාන්‍ය CPU/RAM පරිභෝජනය සමඟ:

• 80% CPU භාවිතය (4 vCPU, 4 GB RAM සත්කාරක, Linux)
• 130 MB Mem RSS

සංසන්දනය කිරීම සඳහා, TLS (HTTP ප්‍රොටෝකෝලය) අවසන් කිරීමකින් තොරව එකම nginx upstream සඳහා 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 වැඩිය (වඩා බලවත් සම්පත් මත අපට RPS 2700 දක්වා සංඛ්‍යා ලැබී ඇත).

අවසාන වශයෙන්, මම සටහන් කරමි ESNI තාක්ෂණය ඉතා හොඳ පෙනුමක් ඇති බව. තවමත් බොහෝ විවෘත ප්‍රශ්න තිබේ, නිදසුනක් ලෙස, DNS හි පොදු ESNI යතුර ගබඩා කිරීමේ ගැටළු සහ ESNI යතුරු භ්‍රමණය කිරීමේ ගැටළු - මෙම ගැටළු ක්‍රියාකාරීව සාකච්ඡා වෙමින් පවතින අතර ESNI කෙටුම්පතේ නවතම අනුවාදය (ලියන අවස්ථාවේදී) දැනටමත් ඇත. 7.

මූලාශ්රය: www.habr.com