ESNI மூலம் உங்கள் பொது இணையதளத்தை எவ்வாறு பாதுகாப்பது

வணக்கம் ஹப்ர், என் பெயர் இலியா, நான் Exness இல் இயங்குதள குழுவில் வேலை செய்கிறேன். எங்கள் தயாரிப்பு மேம்பாட்டுக் குழுக்கள் பயன்படுத்தும் முக்கிய உள்கட்டமைப்பு கூறுகளை நாங்கள் உருவாக்கி செயல்படுத்துகிறோம்.

இந்த கட்டுரையில், பொது இணையதளங்களின் உள்கட்டமைப்பில் மறைகுறியாக்கப்பட்ட SNI (ESNI) தொழில்நுட்பத்தை செயல்படுத்துவதில் எனது அனுபவத்தை பகிர்ந்து கொள்ள விரும்புகிறேன்.

இந்த தொழில்நுட்பத்தைப் பயன்படுத்துவது பொது இணையதளத்தில் பணிபுரியும் போது பாதுகாப்பின் அளவை அதிகரிக்கும் மற்றும் நிறுவனத்தால் ஏற்றுக்கொள்ளப்பட்ட உள் பாதுகாப்பு தரங்களுக்கு இணங்குகிறது.

முதலில், தொழில்நுட்பம் தரப்படுத்தப்படவில்லை மற்றும் இன்னும் வரைவில் உள்ளது என்பதை நான் சுட்டிக்காட்ட விரும்புகிறேன், ஆனால் CloudFlare மற்றும் Mozilla ஏற்கனவே அதை ஆதரிக்கின்றன. வரைவு01) இது எங்களை அத்தகைய பரிசோதனைக்கு தூண்டியது.

ஒரு பிட் கோட்பாடு

ESNI இது TLS 1.3 நெறிமுறையின் நீட்டிப்பாகும், இது TLS ஹேண்ட்ஷேக் "கிளையண்ட் ஹலோ" செய்தியில் SNI குறியாக்கத்தை அனுமதிக்கிறது. ESNI ஆதரவுடன் கிளையண்ட் ஹலோ எப்படி இருக்கும் என்பது இங்கே உள்ளது (வழக்கமான SNIக்கு பதிலாக ESNI ஐப் பார்க்கிறோம்):

 ESNI ஐப் பயன்படுத்த, உங்களுக்கு மூன்று கூறுகள் தேவை:

• டிஎன்எஸ்; 
• வாடிக்கையாளர் ஆதரவு;
• சர்வர் பக்க ஆதரவு.

டிஎன்எஸ்

நீங்கள் இரண்டு DNS பதிவுகளைச் சேர்க்க வேண்டும் - Aமற்றும் டிஎக்ஸ்டி டு (TXT பதிவில் கிளையன்ட் SNI ஐ குறியாக்கக்கூடிய பொது விசை உள்ளது) - கீழே பார்க்கவும். கூடுதலாக, ஆதரவு இருக்க வேண்டும் DoH (HTTPS மூலம் DNS) ஏனெனில் கிடைக்கும் கிளையன்ட்கள் (கீழே பார்க்கவும்) DoH இல்லாமல் ESNI ஆதரவை இயக்கவில்லை. இது தர்க்கரீதியானது, ஏனெனில் ESNI ஆனது நாம் அணுகும் வளத்தின் பெயரை குறியாக்குவதைக் குறிக்கிறது, அதாவது UDP வழியாக DNS ஐ அணுகுவதில் அர்த்தமில்லை. மேலும், பயன்பாடு DNSSEC இந்த சூழ்நிலையில் கேச் நச்சு தாக்குதல்களிலிருந்து பாதுகாக்க உங்களை அனுமதிக்கிறது.

தற்போது கிடைக்கிறது பல DoH வழங்குநர்கள், அவர்களில்:

• CloudFlare
• OpenDNS
• Google

CloudFlare மாநிலங்களில் (எனது உலாவியைச் சரிபார்க்கவும் → மறைகுறியாக்கப்பட்ட SNI → மேலும் அறிக) அவற்றின் சேவையகங்கள் ஏற்கனவே 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"
    }
  ]
}

டிஎக்ஸ்டி டு பதிவு, கோரிக்கை ஒரு டெம்ப்ளேட்டின் படி உருவாக்கப்படுகிறது _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 போன்ற இணைய சேவையகங்களால் ஆதரிக்கப்படவில்லை, ஏனெனில் அவை ESNI ஐ அதிகாரப்பூர்வமாக ஆதரிக்காத OpenSSL/BoringSSL வழியாக TLS உடன் வேலை செய்கின்றன.

எனவே, எங்களின் சொந்த முன்-இறுதி கூறுகளை (ESNI ரிவர்ஸ் ப்ராக்ஸி) உருவாக்க முடிவு செய்தோம், இது ESNI உடன் TLS 1.3 முடிவுறுதலையும், ESNIயை ஆதரிக்காத அப்ஸ்ட்ரீமிற்கு HTTP(S) ட்ராஃபிக்கை ப்ராக்ஸியையும் ஆதரிக்கும். இது தொழில்நுட்பத்தை ஏற்கனவே உள்ள உள்கட்டமைப்பில், முக்கிய கூறுகளை மாற்றாமல் பயன்படுத்த அனுமதிக்கிறது - அதாவது, ESNI ஐ ஆதரிக்காத தற்போதைய வலை சேவையகங்களைப் பயன்படுத்துகிறது. 

தெளிவுக்காக, இங்கே ஒரு வரைபடம் உள்ளது:

ESNI இல்லாமல் வாடிக்கையாளர்களுக்கு ஆதரவளிக்கும் வகையில், ESNI இல்லாமல் TLS இணைப்பை நிறுத்தும் திறனுடன் ப்ராக்ஸி வடிவமைக்கப்பட்டுள்ளது என்பதை நான் கவனிக்கிறேன். மேலும், அப்ஸ்ட்ரீமில் உள்ள தகவல்தொடர்பு நெறிமுறையானது HTTP அல்லது HTTPS ஆக இருக்கும் TLS பதிப்பு 1.3 ஐ விடக் குறைவாக இருக்கும் (அப்ஸ்ட்ரீம் 1.3 ஐ ஆதரிக்கவில்லை என்றால்). இந்த திட்டம் அதிகபட்ச நெகிழ்வுத்தன்மையை வழங்குகிறது.

ESNI ஆதரவை செயல்படுத்துதல் go நாங்கள் கடன் வாங்கினோம் CloudFlare. நிலையான நூலகத்தில் மாற்றங்களை உள்ளடக்கியதால், செயல்படுத்துவது மிகவும் அற்பமானது அல்ல என்பதை நான் இப்போதே கவனிக்க விரும்புகிறேன். crypto/tls எனவே "ஒட்டுதல்" தேவைப்படுகிறது கோரூட் சட்டசபைக்கு முன்.

ESNI விசைகளை உருவாக்க நாங்கள் பயன்படுத்தினோம் எஸ்னிடூல் (மேலும் கிளவுட் ஃப்ளேரின் சிந்தனை). இந்த விசைகள் 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 இலிருந்து அப்ஸ்ட்ரீமுக்கு ப்ராக்ஸிங் செய்வதன் மூலம், ESNI ரிவர்ஸ் ப்ராக்ஸியின் சராசரி CPU/RAM நுகர்வுடன், ஒரு நிகழ்விலிருந்து சுமார் ~550 rps ஐப் பெற்றோம்:

• 80% CPU பயன்பாடு (4 vCPU, 4 GB RAM ஹோஸ்ட்கள், லினக்ஸ்)
• 130 எம்பி மெம் ஆர்எஸ்எஸ்

ஒப்பிடுகையில், 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 ஜிபி ரேம் ஹோஸ்ட்கள், லினக்ஸ் ஆகியவற்றைப் பயன்படுத்தினோம்), உண்மையில் சாத்தியமான RPS அதிகமாக உள்ளது (அதிக சக்தி வாய்ந்த ஆதாரங்களில் 2700 RPS வரையிலான புள்ளிவிவரங்களைப் பெற்றுள்ளோம்).

முடிவில், நான் கவனிக்கிறேன் ESNI தொழில்நுட்பம் மிகவும் நம்பிக்கைக்குரியதாக இருக்கிறது. இன்னும் பல திறந்த கேள்விகள் உள்ளன, எடுத்துக்காட்டாக, பொது ESNI விசையை DNS இல் சேமிப்பதில் உள்ள சிக்கல்கள் மற்றும் ESNI விசைகளை சுழற்றுவது - இந்த சிக்கல்கள் தீவிரமாக விவாதிக்கப்படுகின்றன, மேலும் ESNI வரைவின் சமீபத்திய பதிப்பு (எழுதும் நேரத்தில்) ஏற்கனவே உள்ளது 7.

ஆதாரம்: www.habr.com