OCSP έναντι CRL: πώς λειτουργεί στην πραγματικότητα κάθε έλεγχος ανάκλησης

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

Βήμα 1: Τι επιστρέφει κάθε έλεγχος και πόσο καιρό παραμένει χρησιμοποιήσιμος

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

Επομένως η προσωρινή αποθήκευση είναι το πρώτο που πρέπει να καθοριστεί: ποιο στοιχείο κρατά το αντίγραφο και σε ποιο ανώτατο όριο υπακούει αυτό το αντίγραφο. Σε μια πύλη το όριο πρέπει να είναι nextUpdate μείον ένα περιθώριο ασφαλείας, ποτέ ό,τι τυχαίνει να προτείνει μια κεφαλίδα προσωρινής μνήμης HTTP. Το openssl crl -in issuer.crl -noout -lastupdate -nextupdate εκτυπώνει και τις δύο ημερομηνίες, και μια λίστα της οποίας το nextUpdate είναι ήδη στο παρελθόν πρέπει να αντιμετωπίζεται ως απούσα και όχι απλώς ως παλιά.

Βήμα 2: Πού δείχνει το πιστοποιητικό τον πελάτη

Το φυλλικό πιστοποιητικό φέρει συνήθως δύο ενδείξεις: μια επέκταση σημείου διανομής CRL και μια καταχώριση πρόσβασης πληροφοριών αρχής για OCSP. Το openssl x509 -in client.pem -noout -ext crlDistributionPoints εκτυπώνει την πρώτη, και η δεύτερη βρίσκεται στην ενότητα AIA του openssl x509 -in client.pem -noout -text. Οποιαδήποτε από τις δύο επεκτάσεις είναι δείκτης, όχι υποχρέωση. Ένας πελάτης που δεν υλοποιεί ποτέ έλεγχο ανάκλησης θα συνδεθεί απόλυτα καλά με ένα πιστοποιητικό του οποίου οι επεκτάσεις ονομάζουν έναν responder που είναι νεκρός εδώ και ένα χρόνο.

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

Βήμα 3: Διαλέξτε fail-closed ή fail-open πριν από τη διακοπή

Ένας responder που δεν είναι προσβάσιμος ή μια ληγμένη λίστα επιβάλλει μια απόφαση: αρνηθείτε τη σύνδεση, ή δεχτείτε την και καταγράψτε το κενό. Η υποεντολή verify του OpenSSL καθιστά την αυστηρή επιλογή ρητή, γιατί η προσθήκη του -crl_check μετατρέπει μια μη διαθέσιμη CRL σε unable to get certificate CRL και σε αποτυχημένη επαλήθευση. Το soft-fail στις περισσότερες στοίβες δεν είναι καθόλου σημαία, είναι η απουσία του ελέγχου, και γι’ αυτό ακριβώς φτάνει κατά λάθος.

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

Βήμα 4: Αποδείξτε ότι ο έλεγχος εκτελείται εκεί όπου γίνεται δεκτή η κίνηση

Βρείτε τη διεργασία που τερματίζει ή εξουσιοδοτεί τη σύνδεση και μετά ρωτήστε την για τη γραμμή ρυθμίσεων που ενεργοποιεί τον έλεγχο ανάκλησης. Μια πύλη που επικυρώνει την αλυσίδα αλλά δεν ρωτά ποτέ για ανάκληση εφαρμόζει διαφορετική πολιτική από αυτήν στην τεκμηρίωσή σας, και κανένα στιγμιότυπο οθόνης μιας αλυσίδας πιστοποιητικών δεν αποδεικνύει το αντίθετο. Το OpenVPN γράφει την επιλογή ως crl-verify· το strongSwan κρατά τις αναζητήσεις CRL και OCSP στη διαμόρφωση της CA, όπου ορίζονται τα crl_uris ή ocsp_uris. Αν δεν μπορείτε να δείξετε κανένα από τα δύο, υποθέστε ότι ο έλεγχος απουσιάζει.

Μια απάντηση OCSP μετράει μόνο όταν την έχει υπογράψει η εκδίδουσα CA, ή όταν την έχει υπογράψει ένας responder που κατέχει την εκτεταμένη χρήση κλειδιού OCSPSigning που έχει εκχωρήσει αυτή η CA, οπότε μια απάντηση από μια άσχετη υπηρεσία δεν αποδεικνύει τίποτα. Αν εκτελείτε εσείς τον responder, παρακολουθήστε τον ως σκληρή εξάρτηση, γιατί μια νεκρή υπηρεσία γίνεται μεμιάς διακοπή για κάθε πελάτη fail-closed.

Βήμα 5: Ανακαλέστε επίτηδες ένα πιστοποιητικό

Πάρτε ένα δοκιμαστικό πιστοποιητικό, ανακαλέστε το μέσω του ίδιου καναλιού που χρησιμοποιεί η παραγωγή και ρωτήστε απευθείας τον responder. Το openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text θα πρέπει να αναφέρει Cert Status: revoked μαζί με χρόνο ανάκλησης, και μια απάντηση good σημαίνει ότι η ανάκλησή σας δεν έφτασε στον responder που ρωτούν οι πελάτες σας. Στη συνέχεια εκτελέστε το openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem για να δείτε την ίδια απόφαση μέσω της διαδρομής λίστας. Διαβάστε τη συμβολοσειρά αιτίας αντί για τον κωδικό εξόδου, γιατί μια απόρριψη λόγω ανάκλησης και ένα σφάλμα αλυσίδας καταλήγουν και τα δύο σε αποτυχία.

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