Δύο πεποιθήσεις κάνουν εδώ τη μεγαλύτερη ζημιά: ότι ένα αυτοϋπογεγραμμένο πιστοποιητικό VPN σημαίνει πως η σήραγγα δεν είναι κρυπτογραφημένη, και ότι η εγκατάσταση ό,τι ζήτησε ο πελάτης VPN επηρεάζει μόνο το VPN. Καμία δεν επιβιώνει από την επαφή με μια πραγματική ανάπτυξη. Ένα αυτοϋπογεγραμμένο πιστοποιητικό περιγράφει μια σχέση υπογραφής, όχι μια ετυμηγορία ασφαλείας, και η εμβέλεια της εμπιστοσύνης που προσθέτετε εξαρτάται από το σε ποια αποθήκη προσγειώνεται. Έχω δει helpdesk να εισάγει μια ρίζα παρόχου σε μηχάνημα Windows για να σιγήσει μια προειδοποίηση και μετά να περνά ένα απόγευμα εξηγώντας γιατί το πρόγραμμα περιήγησης σταμάτησε να παραπονιέται για μια άσχετη πύλη. Τα δύο μισά αυτού του ερωτήματος ανήκουν μαζί, οπότε αντιμετωπίστε τα ως ένα.

Ένα πιστοποιητικό δεν είναι αποθήκη εμπιστοσύνης

Το αρχείο που παρουσιάζει ο διακομιστής φέρει δημόσιο κλειδί, όνομα θέματος, όνομα εκδότη, ημερομηνίες ισχύος και επεκτάσεις. Αυτοϋπογεγραμμένο σημαίνει ότι το θέμα και ο εκδότης είναι η ίδια οντότητα και η υπογραφή επαληθεύεται με το ίδιο το κλειδί του πιστοποιητικού. Τίποτα σε αυτόν τον ορισμό δεν λέει ότι η σύνδεση είναι αδύναμη και τίποτα δεν λέει ότι ο πελάτης θα το δεχτεί.

Η αποδοχή έρχεται από αλλού: ένα αρχείο CA στο οποίο δείχνετε τον πελάτη, ένα αποτύπωμα που συγκρίνετε με το χέρι ή μια ρίζα που βρίσκεται ήδη σε μια αποθήκη που διαβάζει ο πελάτης. Μια ανάπτυξη μπορεί να είναι απολύτως υγιής ενώ το πιστοποιητικό της θα αποτύγχανε σε κάθε δημόσιο τεστ. Το openssl verify απέναντι στη δέσμη του συστήματος θα αναφέρει άγνωστο εκδότη, και αυτή η αναφορά είναι σωστή και όχι σφάλμα.

Η επιλογή ca του OpenVPN είναι η σαφέστερη περίπτωση εμπιστοσύνης περιορισμένης στην εφαρμογή. Αυτό το αρχείο ονομάζει τις άγκυρες που θα δεχτεί ο πελάτης και μπορεί να περιέχει ένα ιδιωτικό CA ή, σε μικρή ανάπτυξη, το δικό του αυτοϋπογεγραμμένο πιστοποιητικό του διακομιστή. Η έκδοση 2.6 δέχεται επίσης --peer-fingerprint για καρφίτσωμα αποτυπώματος SHA-256 αντί για διανομή αρχείου CA. Το WireGuard βρίσκεται ακόμη πιο έξω: δεν έχει καθόλου πιστοποιητικά, μόνο ένα στατικό δημόσιο κλειδί ανά ομότιμο, οπότε το ερώτημα του αυτοϋπογραφόμενου δεν του ταιριάζει.

Το πού εγκαθιστάτε την εμπιστοσύνη καθορίζει ποιος την κληρονομεί

Βάλτε το ίδιο πιστοποιητικό σε τρία σημεία και παίρνετε τρεις διαφορετικές ακτίνες έκρηξης. Μια δέσμη που διαβάζει μόνο ο πελάτης VPN επηρεάζει αυτόν τον πελάτη. Μια ρίζα στην αποθήκη του λειτουργικού συστήματος επηρεάζει κάθε πρόγραμμα που συμβουλεύεται αυτή την αποθήκη. Ένα πρόγραμμα περιήγησης με δική του βάση εμπιστοσύνης μπορεί να αγνοήσει και τα δύο, γι' αυτό μια προειδοποίηση μπορεί να επιβιώσει από μια εισαγωγή που φαινόταν να δουλεύει.

Σε Debian ή Ubuntu, η απόθεση αρχείου στο /usr/local/share/ca-certificates/ και η εκτέλεση του update-ca-certificates αλλάζουν τη δέσμη σε επίπεδο συστήματος. Στα Windows, το certutil -addstore -f Root γράφει στην αποθήκη μηχανήματος και απαιτεί αναβαθμισμένο περιβάλλον, ενώ η προσθήκη του -user στοχεύει την αποθήκη του τρέχοντος χρήστη· τα δύο δεν είναι εναλλάξιμα. Το Firefox κρατά τη δική του βάση NSS, οπότε μια εισαγωγή σε επίπεδο λειτουργικού μπορεί να μην εμφανιστεί ποτέ εκεί.

Η εμβέλεια έχει σημασία εξαιτίας του τι μπορεί να κάνει μια αρχή. Ένα CA έκδοσης μπορεί να υπογράφει ονόματα με τα οποία δεν έχει καμία σχέση, οπότε ό,τι εμπιστεύεται αυτή την αποθήκη θα δεχτεί αυτές τις υπογραφές. Ένα μόνο καρφιτσωμένο φύλλο δεν μπορεί να το κάνει· πιστοποιεί ακριβώς μία ταυτότητα ομοτίμου. Αν ο στόχος είναι να συνδεθεί ένα VPN, ένα CA περιορισμένο στην εφαρμογή ή ένα καρφιτσωμένο φύλλο το πετυχαίνει, ενώ μια ρίζα σε επίπεδο μηχανήματος είναι πολύ μεγαλύτερη παραχώρηση από όση απαιτεί το σύμπτωμα.

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

Η χειραψία TLS παράγει κλειδιά συνεδρίας είτε το πιστοποιητικό του ομοτίμου αλυσιδώνει σε κάτι που ήδη εμπιστεύεστε είτε όχι. Αυτοϋπογεγραμμένο δεν σημαίνει απλό κείμενο και δεν σημαίνει ότι η κίνηση είναι αναγνώσιμη εν πτήσει. Σημαίνει ότι ο πελάτης δεν έχει εκ των προτέρων λόγο να πιστεύει ότι το κλειδί ανήκει στον διακομιστή που ζήτησε.

Σε αυτό το κενό ζουν οι πραγματικές επιθέσεις. Ένας πελάτης ρυθμισμένος να δέχεται οποιοδήποτε πιστοποιητικό, είτε μέσω απενεργοποιημένης ρύθμισης επαλήθευσης είτε μέσω κουμπιού «εμπιστέψου το ούτως ή άλλως» που πατήθηκε μία φορά και ξεχάστηκε, θα κρυπτογραφεί ευχαρίστως σε όποιον απαντήσει. Η υποκλοπή συμβαίνει στο βήμα πιστοποίησης, πριν κινηθούν τα δεδομένα της εφαρμογής. Η κρυπτογράφηση χωρίς έλεγχο ταυτότητας κρατά έξω έναν παθητικό παρατηρητή και κάνει λίγα άλλα.

Η εμπιστοσύνη στον εκδότη δεν παρακάμπτει τον έλεγχο ονόματος

Η επικύρωση αλυσίδας, η αντιστοίχιση ονόματος και ο σκοπός του πιστοποιητικού είναι ξεχωριστές αποφάσεις. Μια αλυσίδα μπορεί να είναι έγκυρη ενώ το όνομα είναι λάθος, και ένα όνομα μπορεί να ταιριάζει ενώ το πιστοποιητικό εκδόθηκε για άλλο ρόλο. Το RFC 5280 ορίζει τα πεδία που φέρουν αυτούς τους περιορισμούς, και το πόσο αυστηρά τα επιβάλλει ένας πελάτης είναι θέμα κάθε εφαρμογής.

Το OpenVPN κάνει τον διαχωρισμό ορατό. Το verify-x509-name καρφιτσώνει το αναμενόμενο θέμα μέσω αντιστοίχισης name, name-prefix ή subject. Το remote-cert-tls server απαιτεί το πιστοποιητικό του ομοτίμου να είναι χρησιμοποιήσιμο ως πιστοποιητικό διακομιστή, κάτι που απορρίπτει ένα πιστοποιητικό μόνο πελάτη ακόμη και όταν ο εκδότης είναι αξιόπιστος. Καμία από τις δύο ρυθμίσεις δεν αντικαθίσταται από την αποστολή αρχείου CA.

Εξετάστε το πιστοποιητικό προτού αποφασίσετε οτιδήποτε:

  • openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName δείχνει ποιος το εξέδωσε, για ποια ονόματα και μέχρι πότε.
  • openssl verify -CAfile ca.crt server.crt ελέγχει αν η αλυσίδα που σκοπεύετε να στείλετε επικυρώνει πράγματι το φύλλο.
  • openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error λειτουργεί για τελικά σημεία TLS όπως μια διαδικτυακή πύλη· το πρωτόκολλο OpenVPN στη θύρα 1194 δεν είναι απλή ροή TLS, οπότε αυτό το τεστ δεν ισχύει εκεί.

Ένα πιστοποιητικό με ληγμένη ημερομηνία, χωρίς subjectAltName για το όνομα στο οποίο συνδέεστε ή χωρίς χρήση serverAuth αποτυγχάνει ανεξάρτητα από το πόσο προσεκτικά εγκαταστάθηκε η άγκυρα.

Πέντε έλεγχοι πριν δεχτείτε ένα

Συγκρίνετε το αποτύπωμα μέσω καναλιού που δεν είναι η σύνδεση που προσπαθείτε να διορθώσετε: μια κονσόλα, ένα πρόγραμμα εγκατάστασης που έχετε ήδη, ένα υπογεγραμμένο αρχείο διαμόρφωσης. Το openssl x509 -in server.crt -noout -fingerprint -sha256 στον διακομιστή και η ίδια τιμή στο αρχείο καταγραφής του πελάτη αρκούν για να ξέρετε ότι κοιτάτε ένα αντικείμενο.

Στη συνέχεια, αποφασίστε τι εγκαθιστάτε: ένα φύλλο ή μια αρχή που μπορεί να κόψει περισσότερα. Έπειτα αποφασίστε πού πηγαίνει και ονομάστε τις εφαρμογές που διαβάζουν αυτή την αποθήκη. Γράψτε τη διαδρομή αφαίρεσης όσο ακόμη τη θυμάστε, γιατί το «εμπιστέψου και προχώρα» είναι πώς μια προσωρινή εισαγωγή γίνεται μόνιμη.

Τέλος, σχεδιάστε την αλλαγή. Ένα καρφιτσωμένο πιστοποιητικό ή αποτύπωμα πρέπει να ενημερώνεται μέσω του ίδιου αξιόπιστου καναλιού όταν το πιστοποιητικό περιστρέφεται, και ένα ιδιωτικό CA έχει τον δικό του κύκλο ζωής έκδοσης και ανάκλησης. Αν διαρρεύσει το ιδιωτικό κλειδί, η εκ νέου εμπιστοσύνη σε αντίγραφο του ίδιου πιστοποιητικού δεν διορθώνει τίποτα· η ταυτότητα πρέπει να αντικατασταθεί.

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

Σχετικά άρθρα