Γιατί να χρησιμοποιήσετε το CAA;
Μια ΑΠ χρησιμοποιεί πάντα μεθόδους επικύρωση τομέα για να βεβαιωθείτε ότι κάθε SSL /TLS Το αίτημα πιστοποιητικού έχει εγκριθεί (συνήθως διασφαλίζοντας ότι συνδέεται κατά κάποιο τρόπο με έναν συγκεκριμένο ιστότοπο που χρησιμοποιεί αυτόν τον τομέα).
Για παράδειγμα, μια ΑΠ ενδέχεται να παρέχει ένα ειδικό αρχείο επαλήθευσης στον αιτούντα. Η τοποθέτηση αυτού του αρχείου στον ιστότοπο αποδεικνύει ότι ο αιτών ελέγχει επίσης αυτόν τον ιστότοπο, αλλά δεν μπορεί να εγγυηθεί το νομιμότητα αυτού του ελέγχου. Ένας χάκερ που αποκτά τον έλεγχο ενός ιστότοπου ενδέχεται να μεταμφιέζεται ως ο νόμιμος κάτοχος και, στη συνέχεια, θα μπορούσε να ζητήσει και να λάβει ένα SSL /TLS πιστοποιητικό που περνά τους τυπικούς ελέγχους της ΚΑ και ως εκ τούτου φαίνεται νόμιμος. Θα μπορούσαν τότε να γυρίσουν και να χρησιμοποιήσουν αυτό το SSL /TLS πιστοποιητικό για αναταραχή, σε αυτόν τον ιστότοπο ή αλλού.
Το CAA συμβάλλει στον αποκλεισμό αυτού του είδους εκμετάλλευσης, ορίζοντας ποιες ΑΠ επιτρέπεται να εκδίδουν πιστοποιητικά για έναν τομέα (ή ακόμη και τον περιορισμό της έκδοσης πιστοποιητικών συνολικά). Αυτό περιορίζει τη ζημιά που μπορεί να προκαλέσει ένας αεροπειρατής - ακόμη και αν έχουν τον έλεγχο ενός ιστότοπου, θα έχουν δραστικά λιγότερες επιλογές για να σκοράρουν ένα κακόβουλο SSL /TLS πιστοποιητικό.
Πώς λειτουργεί το CAA
Η CAA χρησιμοποιεί DNS
Η Σύστημα ονομάτων τομέα (DNS) είναι ένα κρίσιμο μέρος της υποδομής του Διαδικτύου. Ο κάτοχος οποιουδήποτε τομέα διατηρεί εγγραφές DNS (εντός των λεγόμενων αρχεία ζώνης) δείχνοντας το όνομα τομέα τους στη διεύθυνση IP όπου φιλοξενείται ο ιστότοπός τους και ας πληκτρολογήσουμε google.com σε ένα παράθυρο του προγράμματος περιήγησης αντί 216.58.194.46.
Οι εγγραφές DNS χρησιμοποιούνται συνήθως ως "τηλεφωνικός κατάλογος για το Διαδίκτυο", αλλά το DNS επιτρέπει επίσης άλλους τύπους ειδικών εγγραφών που μπορούν να εκχωρήσουν άλλες πληροφορίες σε ένα όνομα τομέα.
Εγγραφές CAA
Η CAA χρησιμοποιεί ένα ειδικό είδος δίσκου που ονομάζεται a Αρχείο πόρων εξουσιοδότησης αρχής πιστοποίησης (Εγγραφή CAA). Αυτά δημοσιεύονται χρησιμοποιώντας το DNS και ο κάτοχος του τομέα προσθέτει απλώς εγγραφές CAA μαζί με τις άλλες εγγραφές του DNS. Μια εγγραφή CAA περιλαμβάνει ένα ετικέτα και σε έναν αξίακαι το ζεύγος τιμής-τιμής αναφέρεται ως περιουσία. Υπάρχει επίσης ένα σημαία υποδεικνύοντας πόσο κρίσιμη είναι αυτή η ιδιότητα. Δείτε πώς φαίνεται:
example.com. Έκδοση CAA 0 "ssl.com"
Εδώ, example.com είναι ο τομέας στον οποίο ισχύει αυτή η εγγραφή και η CAA μας ενημερώνει για το είδος της εγγραφής. ο 0 είναι η σημαία (το μηδέν είναι η προεπιλογή - θα το συζητήσουμε παρακάτω). Η ετικέτα είναι ζήτημα και η τιμή (σε εισαγωγικά) είναι ssl.com, που αποτελούν μαζί το ακίνητο.
Σημαίες
Οι σημαίες έχουν μόνο δύο αυστηρά καθορισμένες καταστάσεις αυτήν τη στιγμή: 0 (μη κριτική) και 1 (κρίσιμος). Μια κριτική σημαία λέει στην ΑΑ ότι αυτό πρέπει κατανοήστε πλήρως την ετικέτα ιδιοκτησίας για να συνεχίσετε. Το RFC 6844 αφήνει ανοιχτές άλλες δυνατότητες για χρήση σημαίας που καθορίζεται από τον χρήστη (θα μιλήσουμε και για αυτές τις παρακάτω).
Ετικέτες
Το RFC 6844 ορίζει τη χρήση τριών κοινών ετικετών: ζήτημα, έκδοση και ιωδιού. (Όπως με τις σημαίες, επιτρέπει άλλους πιθανούς προσαρμοσμένους τύπους ετικετών.)
Η ζήτημα ετικέτα
Η ζήτημα Η ετικέτα καθορίζει ποια (εάν υπάρχει) αρχή εξουσιοδότησης για την έκδοση πιστοποιητικών για αυτόν τον τομέα. Για παράδειγμα, ο κάτοχος του τομέα example.com μπορεί να περιορίσει την έκδοση πιστοποιητικών σε μία ΑΠ (εδώ, SSL.com) χρησιμοποιώντας το ακόλουθο αρχείο ζώνης DNS:
example.com. Έκδοση CAA 0 "ssl.com"
Ένας κάτοχος τομέα μπορεί να επιλέξει να ρυθμίσει πολλά αρχεία ζώνης για έναν τομέα:
example.com. Έκδοση CAA 0 "ssl.com" example.com. Έκδοση CAA 0 "comodoca.com"
Οι παραπάνω εγγραφές περιορίζουν SSL /TLS έκδοση πιστοποιητικού για example.com σε δύο CA (SSL.com και Comodo.com).
Η ζήτημα Η εγγραφή επιτρέπει επίσης στο όνομα CA να εκδίδει πιστοποιητικά για οποιονδήποτε υποτομέα του καθορισμένου τομέα. Ένα αρχείο που επιτρέπει το SSL.com μπορεί έτσι να επιτρέπει την έκδοση πιστοποιητικών για example.com και υποτομείς όπως www.example.com, mail.example.com και ακόμη και τον ειδικό υποτομέα μπαλαντέρ * .example.com.
Μια εγγραφή CAA μπορεί να χρησιμοποιηθεί για περιορίζω έκδοση πιστοποιητικού, επίσης - αυτή η εγγραφή ενημερώνει τις αρχές έκδοσης πιστοποιητικών που χρησιμοποιούν το CAA Όχι. SSL /TLS πιστοποιητικά θα πρέπει να εκδοθούν για example.com και υποτομείς από κάθε ΑΑ:
example.com. Πρόβλημα CAA 0 ";"
(Το ερωτηματικό σε αυτό το παράδειγμα σημαίνει «μην επιτρέπετε τίποτα εδώ", Αλλά όπως θα δείξουμε αργότερα χρησιμοποιείται επίσης για τον καθορισμό προσαρμοσμένων παραμέτρων."
Λάβετε υπόψη ότι μια τυπική ετικέτα έκδοσης επιτρέπει στην ΑΠ να εκδίδει πιστοποιητικό για χαρακτήρες μπαλαντέρ εκτός εάν τροποποιηθεί από…
Η έκδοση ετικέτα
Αυτή η ετικέτα καθορίζει ότι μια ΑΠ έχει εξουσιοδότηση να εκδίδει πιστοποιητικά μπαλαντέρ για τον τομέα του κατόχου (π.χ. * .example.com).
Οι χαρακτήρες μπαλαντέρ είναι ένα ιδιαίτερο είδος υποτομέα catch-all και αξίζει ιδιαίτερη προσοχή και προσοχή κατά την έκδοση πιστοποιητικών μπαλαντέρ. ο έκδοση Η ετικέτα επιτρέπει στον κάτοχο του τομέα να καθορίσει ποιες ΑΠ μπορούν να εκδίδουν πιστοποιητικά για χαρακτήρες μπαλαντέρ ξεχωριστά από τον κύριο τομέα ή άλλους υποτομείς. έκδοση Οι ετικέτες έχουν προτεραιότητα έναντι οποιουδήποτε άλλου ζήτημα ετικέτες. Χρησιμοποιούν την ίδια σύνταξη με το ζήτημα ετικέτα. Μερικά παραδείγματα:
example.com. Έκδοση CAA 0 "ssl.com" example.com. CAA 0 Issuewild ";"
Τα παραπάνω επιτρέπουν στο SSL.com να εκδίδει πιστοποιητικά για example.com και όλους τους υποτομείς εκτός για το μπαλαντέρ * .example.com. (Ούτε το SSL.com ούτε οποιαδήποτε άλλη ΑΠ επιτρέπεται να εκδίδουν πιστοποιητικά μπαλαντέρ για example.com.)
example.com. Πρόβλημα CAA 0 ";" example.com. CAA 0 Issuewild "ssl.com"
Αυτό το παράδειγμα απαγορεύει όλοι Αρχές έκδοσης πιστοποιητικών προς example.com και τους υποτομείς του, αλλά δημιουργεί μια εξαίρεση που επιτρέπει στο SSL.com να εκδίδει πιστοποιητικά μπαλαντέρ (και αποκλειστικά πιστοποιητικά μπαλαντέρ) για example.com.
Η ιωδιού ετικέτα
Η τρίτη καθορισμένη ετικέτα είναι ιωδιού. Αυτή η ετικέτα μπορεί να χρησιμοποιηθεί για την αναφορά μη έγκυρων αιτημάτων πιστοποιητικού στον κάτοχο του τομέα και μοιάζουν με αυτό:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Η κορυφαία εγγραφή παρέχει τις πληροφορίες CA που απαιτούνται για την αποστολή ειδοποίησης μέσω email στη διεύθυνση certissues@example.com. Ο δεύτερος κατευθύνει την ΑΠ να δημοσιεύσει ένα μήνυμα συμβάντος σε μια υπηρεσία ιστού (που έχει ρυθμιστεί για αυτόν τον σκοπό από τον κάτοχο του τομέα) στη διεύθυνση certissues.example.com. (Μπορούν να χρησιμοποιηθούν μία ή και οι δύο μέθοδοι, ανάλογα με τον τρόπο με τον οποίο η ΑΠ και ο κάτοχος τομέα έχουν ρυθμίσει τις λειτουργίες τους.)
ιωδιού μετά τα μηνύματα χρησιμοποιούν μια τυπική μορφή που ονομάζεται Αντικείμενο συμβάντος Περιγραφή ανταλλαγής μορφής ή IODEF - εξ ου και το όνομα. (Το IODEF ορίζεται σε RFC 6546.)
Σημαίες και ετικέτες που καθορίζονται από ΑΠ
Το CAA όπως περιγράφεται στο RFC 6844 ορίζει συγκεκριμένα μόνο δύο καταστάσεις σημαίας (0 και 1) και τρεις ετικέτες (ζήτημα, έκδοση και ιωδιού). Ωστόσο, αφήνει το σχέδιο αρκετά ανοιχτό ώστε οι ΑΠ να δημιουργούν και να χρησιμοποιούν προσαρμοσμένες ετικέτες και σημαίες για τον καθορισμό της διαδικασίας έκδοσης πιστοποιητικών. Παραδείγματα μπορεί να είναι:
example.com. Πρόβλημα CAA 0 "SSL.com; policy = ev"
Αυτή η εγγραφή χρησιμοποιεί ένα πρότυπο ζήτημα ετικέτα με μια επιπλέον παράμετρο που καθοδηγεί την ΑΠ να χρησιμοποιεί την πολιτική εκτεταμένης επικύρωσης (EV) κατά την έκδοση πιστοποιητικού για αυτόν τον τομέα.
example.com. CAA 128 pca "PCA = 12345"
Ο κάτοχος τομέα θα μπορούσε να χρησιμοποιήσει αυτήν την εγγραφή με ένα νέο, καθορισμένο από την ΑΠ pca για να δείξει ότι έχουν έναν προτιμώμενο λογαριασμό πελάτη και ορίζει τον αριθμό λογαριασμού ως παράμετρο. (Η σημαία μπορεί να είναι και μια προσαρμοσμένη τιμή έως και 255.) Ανάλογα με τον τρόπο με τον οποίο η ΑΑ ρυθμίζει τον λογαριασμό, αυτό θα μπορούσε να επιτρέψει συγκεκριμένες μεθόδους χρέωσης, επιπλέον επαλήθευση που καθορίζεται από λογαριασμό ή άλλο ειδικό χειρισμό.
Υπέρ και κατά
Συν…
Υπάρχουν πολλοί εξαιρετικοί λόγοι για να χρησιμοποιήσετε το CAA. Το κύριο και σημαντικότερο πλεονέκτημα είναι η ικανότητα της CAA να μειώσει σημαντικά τον κίνδυνο έκδοσης πιστοποιητικών. Αυτό βοηθά στην προστασία του τομέα σας, της επιχείρησής σας και της διαδικτυακής σας ταυτότητας. Οι πιθανοί εισβολείς που μπορεί να βρήκαν ένα σφάλμα σε ένα συγκεκριμένο λογισμικό της CA δεν μπορούν να το εκμεταλλευτούν για να εκδώσουν πιστοποιητικά SSL για τον τομέα σας. Επιπλέον, η χρήση της ετικέτας iodef σάς επιτρέπει να λαμβάνετε μια αναφορά εάν επιχειρείται εκμετάλλευση.
Ο σχεδιασμός της CAA αυξάνει την ασφάλεια, αλλά μπορεί επίσης να επιτρέψει πιο λεπτομερή κατανομή πόρων - για παράδειγμα, μια εταιρεία θα μπορούσε να δημιουργήσει αρχεία για να επιτρέψει (ή να περιορίσει) το τμήμα πωλήσεων και μάρκετινγκ να αγοράσει πιστοποιητικά SSL για το sales.example.com από μια καθορισμένη πηγή.
Επιπλέον, το CAA προσφέρει μεγάλη ευελιξία. Για έναν κάτοχο τομέα, χρησιμοποιεί εγγραφές πόρων DNS που βρίσκονται υπό τον δικό τους έλεγχο και μπορούν να αλλάξουν ανάλογα με τις ανάγκες, έτσι δεν συνδέονται με μια συγκεκριμένη ΑΠ (και μπορούν να έχουν περισσότερες από μία ΑΠ εξουσιοδοτημένες με εγγραφές ζητημάτων για οποιοδήποτε συγκεκριμένο όνομα τομέα) . Για CA, ακόμη και εκτός από προσαρμοσμένες χρήσεις, οι κανόνες που θεσπίστηκαν πρόσφατα από το CA / B Forum (η ομάδα που ορίζει πρότυπα για θέματα ασφαλείας CA και προγράμματος περιήγησης) μπορούν να επιτρέψουν τη χρήση εγγραφών CAA για σκοπούς επικύρωσης, παρέχοντας έναν άλλο καλό λόγο να τις χρησιμοποιήσουμε.
… Και πλην
Το μεγαλύτερο πρόβλημα με την CAA είναι ότι δεν έχει υιοθετηθεί από όλες τις ΑΠ. Οι βασικές απαιτήσεις του φόρουμ CA / B (τις οποίες πληρούν όλες οι αξιόπιστες ΑΠ) καθοδηγούν μια ΑΠ να καθορίσει τον βαθμό στον οποίο υποστηρίζει την CAA στην ηλεκτρονική τεκμηρίωσή τους. Από αυτό το γράψιμο, ωστόσο, η χρήση CAA είναι μόνο συνιστάται, δεν απαιτείται. Οι αρχές έκδοσης πιστοποιητικών που δεν συμμορφώνονται με το CAA εξακολουθούν να είναι στοχευμένες και έως ότου η CAA χρησιμοποιηθεί ευρύτερα, ένας αεροπειρατής πιθανότατα θα μπορεί να βρει μια μη συμμορφούμενη CA που είναι πρόθυμη να εκδώσει ένα αδίστακτο πιστοποιητικό.
Ένα σχετικό μειονέκτημα είναι ότι ακόμη και όταν υπάρχουν εγγραφές CAA, ένας χρήστης δεν μπορεί επιβάλλω η χρήση του από αρχή έκδοσης πιστοποιητικών. Μια ΑΠ πρέπει να συμμορφώνεται με το RFC 6844 για την εκτέλεση αυτών των εγγραφών και μια μη συμμορφούμενη ΑΠ μπορεί απλώς να αγνοήσει τις ρητές επιθυμίες του κατόχου τομέα, όπως δηλώνεται στις εγγραφές CAA.
Το CAA πρέπει επίσης να ρυθμιστεί σωστά τόσο από τον κάτοχο του τομέα όσο και από ένα CA. Ας κρυπτογραφήσουμε (το οποίο υποστηρίζει CAA) πρόσφατα ανέφεραν ένα μικρό πρόβλημα με τη βάση κώδικα που δυστυχώς οδήγησε στην παράβλεψη των κανόνων της CAA και στην κακή έκδοση έξι πιστοποιητικών. Κανένα από αυτά δεν ήταν κακόβουλες εξαιρέσεις (και kudos στην ομάδα Let's Encrypt για επίλυση και αναφορά του ζητήματος εντός ωρών από την ανακάλυψή τους). Ωστόσο, αυτό τονίζει ότι μια συμμορφούμενη αρχή έκδοσης πιστοποιητικών πρέπει εφαρμόστε το CAA άψογα.
Ένα άλλο πιθανό ζήτημα είναι η εξάρτηση της CAA στο DNS. Εκτός αν ένας κάτοχος τομέα ασφαλίσει τις υπηρεσίες ονομάτων τους, αυτό μπορεί να είναι ένας φορέας επίθεσης. Το RFC 6844 προτείνει εφαρμογή Επεκτάσεις ασφάλειας συστήματος ονόματος τομέα (DNSSEC), που χρησιμοποιεί ψηφιακά υπογεγραμμένες εγγραφές DNS για έλεγχο ταυτότητας δεδομένων και καταπολέμηση της απειλής της πλαστογράφησης DNS.
Τέλος, ακόμη και με την εφαρμογή CAA και τη σωστή εφαρμογή, μια εγγραφή CAA από μόνη της δεν μπορεί να αποτρέψει εντελώς την έκδοση πιστοποιητικών απατεώνων. Παρόλο που το CAA είναι ένα χρήσιμο και σημαντικό εργαλείο για τον περιορισμό των επιλογών ενός εισβολέα, ένας αεροπειρατής με επαρκή πρόσβαση (για παράδειγμα, ελέγχοντας το DNS ή μέσω της κοινωνικής μηχανικής) μπορεί να είναι σε θέση να το δρομολογήσει.
Συμπέρασμα
Η Εξουσιοδότηση Αρχής Πιστοποίησης έχει τεράστιες δυνατότητες ως μέρος ενός ευρύτερου οικοσυστήματος ασφαλείας και η ευρεία υιοθέτηση και εφαρμογή της CAA θα προστατεύσει από την κακή έκδοση πιστοποιητικών. Παρόλο που είναι ατυχές το γεγονός ότι δεν υποστηρίζουν προς το παρόν όλες τις αρχές έκδοσης πιστοποιητικών CAA, υπάρχει συζήτηση σχετικά με το να γίνει πιο έντονα προτεινόμενο ή υποχρεωτικό για όλες τις ΑΠ. Παρόλο που η CAA από μόνη της δεν θα σταματήσει κάθε λανθασμένη έκδοση πιστοποιητικού, είναι ένα καλό βήμα προς τη σωστή κατεύθυνση και το SSL.com θα ήθελε να σας παροτρύνει να σκεφτείτε να χρησιμοποιήσετε μόνοι σας εγγραφές CAA.
αναφορές
- RFC6844: Εγγραφή πόρων εξουσιοδότησης αρχής πιστοποίησης DNS (CAA)
- RFC5070: Η μορφή ανταλλαγής περιγραφής αντικειμένου περιστατικού
- RFC6546: Μεταφορά μηνυμάτων Διαδικτύου Άμυνας σε πραγματικό χρόνο (RID) μέσω HTTP /TLS
- RFC4033: Εισαγωγή και απαιτήσεις ασφάλειας DNS
- CA / B Forum Ballot 125 - Εγγραφές CAA
- Καταχώριση Wikipedia σχετικά με την Εξουσιοδότηση αρχής πιστοποίησης DNS
