🥇Πώς να προστατεύσετε τον δημόσιο ιστότοπό σας με το ESNI

Γεια σου Habr, το όνομά μου είναι Ilya, εργάζομαι στην ομάδα πλατφόρμας της Exness. Αναπτύσσουμε και υλοποιούμε βασικά στοιχεία υποδομής που χρησιμοποιούν οι ομάδες ανάπτυξης προϊόντων μας.

Σε αυτό το άρθρο, θα ήθελα να μοιραστώ την εμπειρία μου από την εφαρμογή της τεχνολογίας κρυπτογραφημένου SNI (ESNI) στην υποδομή δημόσιων ιστοσελίδων.

Η χρήση αυτής της τεχνολογίας θα αυξήσει το επίπεδο ασφάλειας κατά την εργασία με έναν δημόσιο ιστότοπο και θα συμμορφωθεί με τα εσωτερικά πρότυπα ασφαλείας που έχει υιοθετήσει η Εταιρεία.

Καταρχάς, θέλω να επισημάνω ότι η τεχνολογία δεν είναι τυποποιημένη και βρίσκεται ακόμη σε στάδιο προσχεδίου, αλλά η CloudFlare και η Mozilla την υποστηρίζουν ήδη (σε προσχέδιο01). Αυτό μας παρακίνησε να διεξάγουμε ένα τέτοιο πείραμα.

Λίγο θεωρίας

ESNI – είναι μια επέκταση του πρωτοκόλλου TLS 1.3 που σας επιτρέπει να κρυπτογραφήσετε το SNI στο μήνυμα χειραψίας TLS "Client Hello". Δείτε πώς μοιάζει ένα Client Hello με υποστήριξη ESNI (αντί για το συνηθισμένο SNI, βλέπουμε ESNI):

Για να χρησιμοποιήσετε το ESNI, απαιτούνται τρία στοιχεία:

DNS;
Υποστήριξη πελατών;
Υποστήριξη από την πλευρά του διακομιστή.

DNS

Πρέπει να προσθέσετε δύο εγγραφές DNS – AΚαι TXT (Η εγγραφή TXT περιέχει το δημόσιο κλειδί με το οποίο ο πελάτης μπορεί να κρυπτογραφήσει το SNI) – δείτε παρακάτω. Επιπλέον, θα πρέπει να υπάρχει υποστήριξη DoH (DNS μέσω HTTPS), καθώς οι διαθέσιμοι πελάτες (βλ. παρακάτω) δεν ενεργοποιούν την υποστήριξη ESNI χωρίς DoH. Αυτό είναι λογικό, καθώς το ESNI συνεπάγεται κρυπτογράφηση του ονόματος πόρου στον οποίο έχουμε πρόσβαση, δηλαδή δεν έχει νόημα να έχουμε πρόσβαση στο DNS μέσω UDP. Επιπλέον, χρησιμοποιώντας DNSSEC σας επιτρέπει να προστατευτείτε από επιθέσεις δηλητηρίασης προσωρινής μνήμης σε αυτό το σενάριο.

Διαθέσιμο αυτήν τη στιγμή αρκετοί πάροχοι DoH, μεταξύ αυτών:

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. Αφού ρυθμιστεί το πρόγραμμα περιήγησης, θα πρέπει να δούμε κάτι σαν αυτό:

Σύνδεσμος για να ελέγξετε το πρόγραμμα περιήγησης.

Φυσικά, το TLS 1.3 πρέπει να χρησιμοποιηθεί για την υποστήριξη του ESNI, καθώς το ESNI είναι μια επέκταση του TLS 1.3.

Για τον σκοπό της δοκιμής του backend με υποστήριξη ESNI, υλοποιήσαμε έναν client στο go, Αλλά περισσότερα για αυτό αργότερα.

Υποστήριξη από την πλευρά του διακομιστή

Προς το παρόν, το ESNI δεν υποστηρίζεται από διακομιστές ιστού όπως nginx/apache κ.λπ., καθώς λειτουργούν με TLS μέσω OpenSSL/BoringSSL, τα οποία δεν υποστηρίζουν επίσημα το ESNI.

Γι' αυτό αποφασίσαμε να δημιουργήσουμε το δικό μας στοιχείο front-end (ESNI reverse proxy), το οποίο θα υποστηρίζει τερματισμό TLS 1.3 με ESNI και proxying της κίνησης HTTP(S) σε upstream, η οποία δεν υποστηρίζει ESNI. Αυτό επιτρέπει τη χρήση της τεχνολογίας σε μια ήδη υπάρχουσα υποδομή, χωρίς να αλλάζουν τα κύρια στοιχεία - δηλαδή, χρησιμοποιώντας τρέχοντες διακομιστές ιστού που δεν υποστηρίζουν ESNI.

Για λόγους σαφήνειας, ακολουθεί ένα διάγραμμα:

Θα ήθελα να σημειώσω ότι ο διακομιστής μεσολάβησης σχεδιάστηκε με τη δυνατότητα τερματισμού μιας σύνδεσης TLS χωρίς ESNI, για την υποστήριξη πελατών χωρίς ESNI. Επίσης, το πρωτόκολλο επικοινωνίας με το upstream μπορεί να είναι HTTP ή HTTPS με έκδοση TLS κάτω από την 1.3 (εάν το upstream δεν υποστηρίζει την 1.3). Αυτό το σχήμα παρέχει μέγιστη ευελιξία.

Υλοποίηση της υποστήριξης του ESNI go δανειστήκαμε από CloudflareΘα σημειώσω αμέσως ότι η ίδια η υλοποίηση είναι αρκετά απλή, καθώς συνεπάγεται αλλαγές στην τυπική βιβλιοθήκη. crypto/tls και ως εκ τούτου απαιτεί «επιδιόρθωση» GOROOT πριν από τη συναρμολόγηση.

Για να δημιουργήσουμε κλειδιά ESNI χρησιμοποιήσαμε esnitool (επίσης μια δημιουργία του CloudFlare). Αυτά τα κλειδιά χρησιμοποιούνται για την κρυπτογράφηση/αποκρυπτογράφηση SNI.
Δοκιμάσαμε την κατασκευή χρησιμοποιώντας την έκδοση go 1.13 στο Linux (Debian, Alpine) και MacOS.

Λίγα λόγια για τα λειτουργικά χαρακτηριστικά

Το ESNI reverse proxy παρέχει μετρήσεις σε μορφή Prometheus, όπως rps, upstream latency & response codes, αποτυχημένες/επιτυχημένες χειραψίες TLS και διάρκεια χειραψίας TLS. Με την πρώτη ματιά, αυτό φαινόταν επαρκές για να αξιολογηθεί ο τρόπος με τον οποίο το proxy χειρίζεται την κίνηση.

Πραγματοποιήσαμε επίσης δοκιμές φόρτωσης πριν από τη χρήση. Τα αποτελέσματα είναι τα παρακάτω:

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

Διεξήγαμε καθαρά ποιοτικές δοκιμές φορτίου για να συγκρίνουμε το σχήμα με και χωρίς αντίστροφο proxy ESNI. «Εκχύσαμε» την κυκλοφορία τοπικά για να εξαλείψουμε τις «παρεμβολές» σε ενδιάμεσα στοιχεία.

Έτσι, με την υποστήριξη ESNI και το upstream proxying με HTTP, λάβαμε περίπου ~550 rps από μία παρουσία, με τη μέση κατανάλωση CPU/RAM του reverse proxy του ESNI:

80% Χρήση CPU (4 vCPU, 4 GB RAM hosts, Linux)
130 MB μνήμης RSS

Για λόγους σύγκρισης, το RPS για το ίδιο upstream nginx χωρίς τερματισμό 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 RAM hosts, Linux), και στην πραγματικότητα το πιθανό RPS είναι υψηλότερο (λάβαμε στοιχεία έως και 2700 RPS σε πιο ισχυρούς πόρους).

Συμπερασματικά, θα ήθελα να σημειώσω ότι ότι η τεχνολογία ESNI φαίνεται αρκετά πολλά υποσχόμενη. Υπάρχουν ακόμη πολλά ανοιχτά ερωτήματα, για παράδειγμα, τα ζητήματα της αποθήκευσης του δημόσιου κλειδιού ESNI στο DNS και της εναλλαγής των κλειδιών ESNI - αυτά τα ζητήματα συζητούνται ενεργά και η τελευταία έκδοση του σχεδίου (κατά τη στιγμή της σύνταξης) του ESNI είναι ήδη διαθέσιμη. 7.

Πηγή: www.habr.com