როგორ დავიცვათ თქვენი საჯარო ვებგვერდი ESNI-ით

გამარჯობა ჰაბრ, მე ილია მქვია და Exness-ის პლატფორმის გუნდში ვმუშაობ. ჩვენ ვავითარებთ და ვნერგავთ ჩვენი პროდუქტის განვითარების გუნდების მიერ გამოყენებულ ინფრასტრუქტურის ძირითად კომპონენტებს.

ამ სტატიაში მსურს გაგიზიაროთ ჩემი გამოცდილება საჯარო ვებსაიტების ინფრასტრუქტურაში დაშიფრული SNI (ESNI) ტექნოლოგიის დანერგვასთან დაკავშირებით.

ამ ტექნოლოგიის გამოყენება გააუმჯობესებს უსაფრთხოების დონეს საჯარო ვებსაიტთან მუშაობისას და დააკმაყოფილებს კომპანიის მიერ მიღებულ შიდა უსაფრთხოების სტანდარტებს.

პირველ რიგში, მინდა აღვნიშნო, რომ ტექნოლოგია არ არის სტანდარტიზებული და ჯერ კიდევ პროექტის ეტაპზეა, თუმცა CloudFlare და Mozilla უკვე უჭერენ მხარს მას (... დრაფტი01). სწორედ ამან მოგვცა მოტივაცია, ჩაგვეტარებინა ასეთი ექსპერიმენტი.

ცოტა თეორია

ESNI – წარმოადგენს TLS 1.3 პროტოკოლის გაფართოებას, რომელიც საშუალებას იძლევა SNI-ის დაშიფვრა „Client Hello“ TLS handshake შეტყობინებაში. აი, როგორ გამოიყურება ESNI მხარდაჭერის მქონე Client Hello (ჩვეულებრივი SNI-ს ნაცვლად, ჩვენ ვხედავთ ESNI-ს):

 ESNI-ის გამოსაყენებლად საჭიროა სამი კომპონენტი:

• DNS; 
• მომხმარებელთა მხარდაჭერა;
• სერვერის მხარის მხარდაჭერა.

DNS

თქვენ უნდა დაამატოთ ორი DNS ჩანაწერი - Aდა TXT (TXT ჩანაწერი შეიცავს საჯარო გასაღებს, რომლითაც კლიენტს შეუძლია SNI-ის დაშიფვრა) – იხილეთ ქვემოთ. გარდა ამისა, უნდა არსებობდეს მხარდაჭერა დოჰ (DNS HTTPS-ის საშუალებით), რადგან ხელმისაწვდომი კლიენტები (იხილეთ ქვემოთ) არ რთავენ ESNI მხარდაჭერას DoH-ის გარეშე. ეს ლოგიკურია, რადგან ESNI მოითხოვს იმ რესურსის სახელის დაშიფვრას, რომელზეც ჩვენ ვწვდებით, რაც იმას ნიშნავს, რომ DNS-ზე წვდომას UDP-ის საშუალებით აზრი არ აქვს. უფრო მეტიც, გამოყენება DNSSEC საშუალებას გაძლევთ დაიცვათ თავი ქეშის მოწამვლის შეტევებისგან ამ სცენარში.

ამჟამად ხელმისაწვდომია რამდენიმე DoH პროვაიდერი, მათ შორის:

• CloudFlare
• OpenDNS
• Google

CloudFlare აცხადებს (შეამოწმეთ ჩემი ბრაუზერი → დაშიფრული SNI → შეიტყვეთ მეტი) რომ მათი სერვერები უკვე მხარს უჭერენ ESNI-ს, რაც ნიშნავს, რომ CloudFlare-ის სერვერებს აქვთ მინიმუმ ორი 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-ში არის დანერგილი. აქ აქ მოცემულია ინსტრუქციები, თუ როგორ ჩართოთ ESNI და DoH მხარდაჭერა Firefox-ში. ბრაუზერის კონფიგურაციის შემდეგ, თქვენ უნდა ნახოთ მსგავსი რამ:

ლინკები ბრაუზერის შესამოწმებლად.

რა თქმა უნდა, ESNI-ის მხარდასაჭერად უნდა იქნას გამოყენებული TLS 1.3, რადგან ESNI TLS 1.3-ის გაფართოებაა.

ESNI მხარდაჭერით ბექენდის ტესტირების მიზნით, ჩვენ დავანერგეთ კლიენტი go, მაგრამ ამის შესახებ მოგვიანებით.

სერვერის მხარის მხარდაჭერა

ამჟამად, ESNI-ს არ უჭერს მხარს ვებ სერვერები, როგორიცაა nginx/apache და ა.შ., რადგან ისინი მუშაობენ TLS-თან OpenSSL/BoringSSL-ის საშუალებით, რომლებიც ოფიციალურად არ უჭერენ მხარს ESNI-ს.

ამიტომ, ჩვენ გადავწყვიტეთ შეგვექმნა ჩვენი საკუთარი წინა ნაწილის კომპონენტი (ESNI reverse proxy), რომელიც მხარს დაუჭერდა TLS 1.3 ტერმინაციას ESNI-ით და პროქსი HTTP(S) ტრაფიკს გადასცემდა ზედა ნაკადის სერვერებზე, რომლებიც არ უჭერენ მხარს ESNI-ს. ეს საშუალებას გვაძლევს გამოვიყენოთ ტექნოლოგია არსებულ ინფრასტრუქტურაში ძირითადი კომპონენტების შეცვლის გარეშე — ანუ გამოვიყენოთ არსებული ვებ სერვერები, რომლებიც არ უჭერენ მხარს ESNI-ს. 

სიცხადისთვის, აქ მოცემულია დიაგრამა:

აღსანიშნავია, რომ პროქსი შექმნილია ESNI-ის გარეშე TLS კავშირების დასრულების შესაძლებლობით, რათა მხარი დაუჭიროს ESNI-ის არმქონე კლიენტებს. ასევე, ზემოთ კომუნიკაციის პროტოკოლი შეიძლება იყოს HTTP ან HTTPS 1.3-ზე დაბალი TLS ვერსიით (თუ ზემოთ კომუნიკაციის პროტოკოლი არ უჭერს მხარს 1.3-ს). ეს დიზაინი უზრუნველყოფს მაქსიმალურ მოქნილობას.

ESNI-ის მხარდაჭერის განხორციელება go ჩვენ ვისესხეთ CloudFlareმაშინვე აღვნიშნავ, რომ თავად იმპლემენტაცია საკმაოდ არატრივიალურია, რადგან ის სტანდარტულ ბიბლიოთეკაში ცვლილებებს გულისხმობს. კრიპტო/ტლ და ამიტომ საჭიროებს „შეკეთებას“ გოროტი შეკრებამდე.

ESNI გასაღებების გენერირებისთვის ჩვენ გამოვიყენეთ ესნიტული (ასევე CloudFlare-ის ნამუშევარი). ეს გასაღებები გამოიყენება SNI-ის დაშიფვრისთვის/გაშიფვრისთვის.
ჩვენ გამოვცადეთ ბილდი go 1.13-ის გამოყენებით Linux (Debian, Alpine) და MacOS. 

რამდენიმე სიტყვა ოპერაციული მახასიათებლების შესახებ

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-ით ზემოთ პროქსირებით, ერთი ეგზემპლარიდან დაახლოებით ~550 rps მივიღეთ, ESNI უკუ პროქსის საშუალო CPU/RAM მოხმარებით:

• 80% CPU-ს გამოყენება (4 vCPU, 4 GB RAM ჰოსტი, Linux)
• 130 მბ მემორანდუმი RSS

შედარებისთვის, იგივე ზემოთ ნაკადის nginx-ისთვის RPS TLS შეწყვეტის (HTTP პროტოკოლი) გარეშე არის ~ 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 ოპერატიული მეხსიერება, Linux), და სინამდვილეში პოტენციური RPS უფრო მაღალია (უფრო მძლავრ რესურსებზე 2700 RPS-მდე მაჩვენებლები მივიღეთ).

დასასრულ, მინდა აღვნიშნო, რომ ESNI ტექნოლოგია საკმაოდ პერსპექტიულად გამოიყურება. ჯერ კიდევ ბევრი ღია კითხვაა, როგორიცაა საჯარო ESNI გასაღების DNS-ში შენახვა და ESNI გასაღებების როტაცია - ეს საკითხები აქტიურად განიხილება და ESNI-ის უახლესი პროექტი (ამ სტატიის დაწერის მომენტისთვის) უკვე მზადაა. 7.

წყარო: www.habr.com