Προετοιμασία τομέα με βάση το TLS 1.3

Εισαγωγή

Τα σύγχρονα εταιρικά συστήματα φιλτραρίσματος περιεχομένου από διάσημους κατασκευαστές όπως οι Cisco, BlueCoat, FireEye έχουν πολλά κοινά με τα πιο ισχυρά αντίστοιχα συστήματα - συστήματα DPI, τα οποία εφαρμόζονται ενεργά σε εθνικό επίπεδο. Η ουσία της δουλειάς και των δύο είναι να επιθεωρήσουν την εισερχόμενη και εξερχόμενη κίνηση στο Διαδίκτυο και, με βάση τις ασπρόμαυρες λίστες, να λάβουν απόφαση για την απαγόρευση της σύνδεσης στο Διαδίκτυο. Και δεδομένου ότι και οι δύο βασίζονται σε παρόμοιες αρχές στα βασικά της δουλειάς τους, οι μέθοδοι για την παράκαμψή τους θα έχουν επίσης πολλά κοινά.

Μία από τις τεχνολογίες που σας επιτρέπει να παρακάμψετε αποτελεσματικά τόσο τα DPI όσο και τα εταιρικά συστήματα είναι η τεχνολογία domain-fronting. Η ουσία του είναι ότι πηγαίνουμε σε έναν αποκλεισμένο πόρο, κρυμμένος πίσω από έναν άλλο δημόσιο τομέα με καλή φήμη, ο οποίος προφανώς δεν θα αποκλειστεί από κανένα σύστημα, για παράδειγμα το google.com.

Έχουν ήδη γραφτεί αρκετά άρθρα σχετικά με αυτή την τεχνολογία και έχουν δοθεί πολλά παραδείγματα. Ωστόσο, οι δημοφιλείς και πρόσφατα συζητημένες τεχνολογίες DNS-over-HTTPS και κρυπτογραφημένου SNI, καθώς και η νέα έκδοση του πρωτοκόλλου TLS 1.3, καθιστούν δυνατή την εξέταση μιας άλλης επιλογής για το fronting τομέα.

Κατανόηση της τεχνολογίας

Αρχικά, ας ορίσουμε μερικές βασικές έννοιες, ώστε ο καθένας να κατανοήσει ποιος είναι ποιος και γιατί χρειάζονται όλα αυτά. Αναφέραμε τον μηχανισμό eSNI, η λειτουργία του οποίου θα συζητηθεί περαιτέρω. Ο μηχανισμός eSNI (κρυπτογραφημένη ένδειξη ονόματος διακομιστή) είναι μια ασφαλής έκδοση του SNI, διαθέσιμη μόνο για το πρωτόκολλο TLS 1.3. Η κύρια ιδέα είναι η κρυπτογράφηση, μεταξύ άλλων, πληροφοριών σχετικά με τον τομέα στον οποίο αποστέλλεται το αίτημα.

Τώρα ας δούμε πώς λειτουργεί στην πράξη ο μηχανισμός eSNI.

Ας υποθέσουμε ότι έχουμε έναν πόρο Διαδικτύου που είναι αποκλεισμένος από μια σύγχρονη λύση DPI (ας πάρουμε, για παράδειγμα, το διάσημο πρόγραμμα παρακολούθησης torrent rutracker.nl). Όταν προσπαθούμε να αποκτήσουμε πρόσβαση στον ιστότοπο ενός tracker torrent, βλέπουμε το τυπικό στέλεχος του παρόχου που υποδεικνύει ότι ο πόρος είναι αποκλεισμένος:

Στον ιστότοπο της RKN, αυτός ο τομέας αναφέρεται στην πραγματικότητα στις λίστες διακοπής:

Όταν ρωτάτε whois, μπορείτε να δείτε ότι ο ίδιος ο τομέας είναι "κρυμμένος" πίσω από τον πάροχο cloud Cloudflare.

Αλλά σε αντίθεση με τους «ειδικούς» από το RKN, οι πιο τεχνικά έμπειροι υπάλληλοι της Beeline (ή διδασκόμενοι από την πικρή εμπειρία του διάσημου ρυθμιστή μας) δεν απαγόρευσαν ανόητα τον ιστότοπο με διεύθυνση IP, αλλά πρόσθεσαν το όνομα τομέα στη λίστα διακοπής. Μπορείτε εύκολα να το επαληθεύσετε εάν δείτε ποιοι άλλοι τομείς είναι κρυμμένοι πίσω από την ίδια διεύθυνση IP, επισκεφτείτε έναν από αυτούς και δείτε ότι η πρόσβαση δεν έχει αποκλειστεί:

Πώς συμβαίνει αυτό; Πώς γνωρίζει το DPI του παρόχου σε ποιον τομέα βρίσκεται το πρόγραμμα περιήγησής μου, αφού όλες οι επικοινωνίες πραγματοποιούνται μέσω του πρωτοκόλλου https και δεν έχουμε ακόμη παρατηρήσει την αντικατάσταση των πιστοποιητικών https από τη Beeline; Είναι διορατικός ή με παρακολουθούν;

Ας προσπαθήσουμε να απαντήσουμε σε αυτήν την ερώτηση εξετάζοντας την κίνηση μέσω wireshark

Το στιγμιότυπο οθόνης δείχνει ότι πρώτα το πρόγραμμα περιήγησης λαμβάνει τη διεύθυνση IP του διακομιστή μέσω DNS, μετά λαμβάνει χώρα μια τυπική χειραψία TCP με τον διακομιστή προορισμού και, στη συνέχεια, το πρόγραμμα περιήγησης προσπαθεί να δημιουργήσει μια σύνδεση SSL με τον διακομιστή. Για να γίνει αυτό, στέλνει ένα πακέτο SSL Client Hello, το οποίο περιέχει το όνομα του τομέα προέλευσης σε καθαρό κείμενο. Αυτό το πεδίο απαιτείται από τον διακομιστή frontend του cloudflare προκειμένου να δρομολογηθεί σωστά η σύνδεση. Εδώ μας πιάνει ο πάροχος DPI, διακόπτοντας τη σύνδεσή μας. Ταυτόχρονα, δεν λαμβάνουμε κανένα στέλεχος από τον πάροχο και βλέπουμε το τυπικό σφάλμα προγράμματος περιήγησης σαν ο ιστότοπος να είναι απενεργοποιημένος ή απλά να μην λειτουργεί:

Τώρα ας ενεργοποιήσουμε τον μηχανισμό eSNI στο πρόγραμμα περιήγησης, όπως αναγράφεται στις οδηγίες για Firefox :
Για να το κάνουμε αυτό ανοίγουμε τη σελίδα διαμόρφωσης του Firefox about: config και ενεργοποιήστε τις παρακάτω ρυθμίσεις:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

Μετά από αυτό, θα ελέγξουμε ότι οι ρυθμίσεις λειτουργούν σωστά στον ιστότοπο του cloudflare. σύνδεσμος και ας δοκιμάσουμε ξανά το κόλπο με το torrent tracker μας.

Voila. Το αγαπημένο μας tracker άνοιξε χωρίς VPN ή διακομιστή μεσολάβησης. Ας δούμε τώρα τη χωματερή στο wireshark για να δούμε τι συνέβη.

Αυτή τη φορά, το πακέτο ssl client hello δεν περιέχει ρητά τον τομέα προορισμού, αλλά αντ 'αυτού, εμφανίστηκε ένα νέο πεδίο στο πακέτο - encrypted_server_name - εδώ περιέχεται η τιμή του rutracker.nl και μόνο ο κεντρικός διακομιστής cloudflare μπορεί να το αποκρυπτογραφήσει πεδίο. Και αν ναι, τότε ο πάροχος DPI δεν έχει άλλη επιλογή από το να πλύνει τα χέρια του και να επιτρέψει μια τέτοια κίνηση. Δεν υπάρχουν άλλες επιλογές με κρυπτογράφηση.

Έτσι, εξετάσαμε πώς λειτουργεί η τεχνολογία στο πρόγραμμα περιήγησης. Τώρα ας προσπαθήσουμε να το εφαρμόσουμε σε πιο συγκεκριμένα και ενδιαφέροντα πράγματα. Και πρώτα, θα διδάξουμε την ίδια μπούκλα να χρησιμοποιεί το eSNI για να λειτουργεί με το TLS 1.3 και ταυτόχρονα θα δούμε πώς λειτουργεί η ίδια η πρόσοψη τομέα που βασίζεται σε eSNI.

Πρόσοψη τομέα με eSNI

Λόγω του γεγονότος ότι το curl χρησιμοποιεί την τυπική βιβλιοθήκη openssl για σύνδεση μέσω του πρωτοκόλλου https, πρώτα απ 'όλα πρέπει να παρέχουμε υποστήριξη eSNI εκεί. Δεν υπάρχει ακόμη υποστήριξη eSNI στους κύριους κλάδους του openssl, επομένως πρέπει να κατεβάσουμε ένα ειδικό υποκατάστημα openssl, να το μεταγλωττίσουμε και να το εγκαταστήσουμε.

Κλωνοποιούμε το αποθετήριο από το GitHub και μεταγλωττίζουμε ως συνήθως:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Στη συνέχεια, κλωνοποιούμε το αποθετήριο με το curl και διαμορφώνουμε τη μεταγλώττιση του χρησιμοποιώντας τη μεταγλωττισμένη μας βιβλιοθήκη openssl:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

Εδώ είναι σημαντικό να καθορίσετε σωστά όλους τους καταλόγους στους οποίους βρίσκεται το openssl (στην περίπτωσή μας, αυτός είναι ο /opt/openssl/) και να βεβαιωθείτε ότι η διαδικασία διαμόρφωσης περνάει χωρίς σφάλματα.

Εάν η διαμόρφωση είναι επιτυχής, θα δούμε τη γραμμή:

ΠΡΟΕΙΔΟΠΟΙΗΣΗ: το esni ESNI ενεργοποιήθηκε αλλά επισημάνθηκε ΠΕΙΡΑΜΑΤΙΚΟ. Χρησιμοποιήστε με προσοχή!

$ make

Μετά την επιτυχή κατασκευή του πακέτου, θα χρησιμοποιήσουμε ένα ειδικό αρχείο bash από το openssl για να ρυθμίσουμε και να εκτελέσουμε το curl. Ας το αντιγράψουμε στον κατάλογο με curl για ευκολία:

cp /opt/openssl/esnistuff/curl-esni 

και κάντε ένα δοκιμαστικό αίτημα https στον διακομιστή cloudflare, ενώ ταυτόχρονα καταγράφετε πακέτα DNS και TLS στο Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

Στην απόκριση διακομιστή, εκτός από πολλές πληροφορίες εντοπισμού σφαλμάτων από το openssl και το curl, θα λάβουμε μια απάντηση HTTP με κωδικό 301 από το cloudflare.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

που υποδηλώνει ότι το αίτημά μας παραδόθηκε επιτυχώς στον διακομιστή προορισμού, ακούστηκε και υποβλήθηκε σε επεξεργασία.

Τώρα ας δούμε την κυκλοφορία στο wireshark, δηλ. τι είδε ο πάροχος DPI σε αυτήν την περίπτωση.

Μπορεί να φανεί ότι ο curl στράφηκε αρχικά στον διακομιστή DNS για ένα δημόσιο κλειδί eSNI για τον διακομιστή cloudflare - ένα αίτημα TXT DNS στο _esni.cloudflare.com (πακέτο αρ. 13). Στη συνέχεια, χρησιμοποιώντας τη βιβλιοθήκη openssl, ο Curl έστειλε ένα αίτημα TLS 1.3 στον διακομιστή cloudflare στον οποίο το πεδίο SNI ήταν κρυπτογραφημένο με το δημόσιο κλειδί που ελήφθη στο προηγούμενο βήμα (πακέτο #22). Αλλά, εκτός από το πεδίο eSNI, το πακέτο SSL-hello περιελάμβανε επίσης ένα πεδίο με το συνηθισμένο - ανοιχτό SNI, το οποίο μπορούμε να καθορίσουμε με οποιαδήποτε σειρά (σε αυτήν την περίπτωση - www.hello-rkn.ru).

Αυτό το ανοιχτό πεδίο SNI δεν ελήφθη υπόψη με κανέναν τρόπο κατά την επεξεργασία από διακομιστές cloudflare και χρησίμευε μόνο ως μάσκα για το DPI του παρόχου. Ο διακομιστής cloudflare έλαβε το πακέτο μας ssl-hello, αποκρυπτογράφηση του eSNI, εξαγωγή του αρχικού SNI από εκεί και το επεξεργάστηκε σαν να μην είχε συμβεί τίποτα (έκανε τα πάντα ακριβώς όπως είχε προγραμματιστεί κατά την ανάπτυξη του eSNI).

Το μόνο πράγμα που μπορεί να συλληφθεί σε αυτήν την περίπτωση από την άποψη του DPI είναι το κύριο αίτημα DNS στο _esni.cloudflare.com. Αλλά κάναμε το αίτημα DNS ανοιχτό μόνο για να δείξουμε πώς λειτουργεί αυτός ο μηχανισμός από μέσα.

Για να βγάλουμε τελικά το χαλί από κάτω από το DPI, χρησιμοποιούμε τον ήδη αναφερόμενο μηχανισμό DNS-over-HTTPS. Μια μικρή εξήγηση - Το DOH είναι ένα πρωτόκολλο που σας επιτρέπει να προστατεύεστε από μια επίθεση man-in-the-middle στέλνοντας ένα αίτημα DNS μέσω HTTPS.

Ας εκτελέσουμε ξανά το αίτημα, αλλά αυτή τη φορά θα λάβουμε δημόσια κλειδιά eSNI μέσω του πρωτοκόλλου https και όχι μέσω του DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

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

Μπορεί να φανεί ότι ο curl έχει πρόσβαση πρώτα στον διακομιστή mozilla.cloudflare-dns.com μέσω του πρωτοκόλλου DoH (σύνδεση https με τον διακομιστή 104.16.249.249) για να λάβει από αυτούς τις τιμές των δημόσιων κλειδιών για κρυπτογράφηση SNI και στη συνέχεια στον προορισμό διακομιστή, κρύβεται πίσω από τον τομέα www.hello-rkn.ru.

Εκτός από την παραπάνω συσκευή επίλυσης DoH mozilla.cloudflare-dns.com, μπορούμε να χρησιμοποιήσουμε άλλες δημοφιλείς υπηρεσίες DoH, για παράδειγμα, από τη διάσημη εταιρεία του κακού.
Ας εκτελέσουμε το ακόλουθο ερώτημα:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Και παίρνουμε την απάντηση:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

Σε αυτήν την περίπτωση, απευθυνθήκαμε στον αποκλεισμένο διακομιστή rutracker.nl, χρησιμοποιώντας τον αναλυτή DoH dns.google (δεν υπάρχει τυπογραφικό λάθος εδώ, τώρα η διάσημη εταιρεία έχει το δικό της domain πρώτου επιπέδου) και καλύψαμε τους εαυτούς μας με έναν άλλο τομέα, ο οποίος είναι αυστηρά Απαγορεύεται ο αποκλεισμός όλων των DPI υπό τον πόνο του θανάτου. Με βάση την απάντηση που λάβαμε, μπορείτε να καταλάβετε ότι το αίτημά μας διεκπεραιώθηκε με επιτυχία.

Ως πρόσθετος έλεγχος ότι το DPI του παρόχου ανταποκρίνεται στο ανοιχτό SNI, το οποίο μεταδίδουμε ως κάλυμμα, μπορούμε να υποβάλουμε αίτημα στο rutracker.nl με το πρόσχημα κάποιου άλλου απαγορευμένου πόρου, για παράδειγμα, ενός άλλου «καλού» torrent tracker:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Δεν θα λάβουμε απάντηση από τον διακομιστή, επειδή... Το αίτημά μας θα αποκλειστεί από το σύστημα DPI.

Σύντομο συμπέρασμα στο πρώτο μέρος

Έτσι, μπορέσαμε να επιδείξουμε τη λειτουργικότητα του eSNI χρησιμοποιώντας openssl και curl και να δοκιμάσουμε τη λειτουργία της πρόσοψης τομέα με βάση το eSNI. Με τον ίδιο τρόπο, μπορούμε να προσαρμόσουμε τα αγαπημένα μας εργαλεία που χρησιμοποιούν τη βιβλιοθήκη openssl για να λειτουργούν «υπό το πρόσχημα» άλλων τομέων. Περισσότερες λεπτομέρειες σχετικά με αυτό στα επόμενα άρθρα μας.

Πηγή: www.habr.com