Η κατάργηση του ριζικού πιστοποιητικού AddTrust προκαλεί σφάλματα στα συστήματα OpenSSL και GnuTLS

Στις 30 Μαΐου έληξε η 20ετής περίοδος ισχύος του ριζικού πιστοποιητικού AddTrustΟ οποίος εφαρμοσμένος για τη δημιουργία πιστοποιητικών με διασταυρούμενη υπογραφή μιας από τις μεγαλύτερες αρχές πιστοποίησης Sectigo (Comodo). Η διασταυρούμενη υπογραφή επέτρεψε τη συμβατότητα με παλαιού τύπου συσκευές που δεν είχαν προστεθεί το νέο πιστοποιητικό ρίζας USERTRust στο χώρο αποθήκευσης πιστοποιητικών ρίζας.

Θεωρητικά, ο τερματισμός του ριζικού πιστοποιητικού AddTrust θα πρέπει να οδηγεί μόνο σε παραβίαση της συμβατότητας με παλαιού τύπου συστήματα (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, κ.λπ.), καθώς το δεύτερο πιστοποιητικό ρίζας που χρησιμοποιείται στη διασταυρούμενη υπογραφή παραμένει Τα έγκυρα και σύγχρονα προγράμματα περιήγησης το λαμβάνουν υπόψη κατά τον έλεγχο της αλυσίδας εμπιστοσύνης. Στην πράξη εμφανίστηκε Προβλήματα με την επαλήθευση διασταυρούμενης υπογραφής σε πελάτες TLS χωρίς πρόγραμμα περιήγησης, συμπεριλαμβανομένων εκείνων που βασίζονται στο OpenSSL 1.0.x και στο GnuTLS. Δεν δημιουργείται πλέον ασφαλής σύνδεση με ένα σφάλμα που υποδεικνύει ότι το πιστοποιητικό δεν είναι ενημερωμένο, εάν ο διακομιστής χρησιμοποιεί ένα πιστοποιητικό Sectigo που συνδέεται από μια αλυσίδα αξιοπιστίας με το ριζικό πιστοποιητικό AddTrust.

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

Για παράδειγμα, υπήρχαν προβλήματα με πρόσβαση σε ορισμένα αποθετήρια πακέτων στο Debian και το Ubuntu (το apt άρχισε να δημιουργεί ένα σφάλμα επαλήθευσης πιστοποιητικού), τα αιτήματα από σενάρια που χρησιμοποιούν τα βοηθητικά προγράμματα "curl" και "wget" άρχισαν να αποτυγχάνουν, παρατηρήθηκαν σφάλματα κατά τη χρήση του Git, παραβιάστηκε Η πλατφόρμα ροής Roku λειτουργεί, οι χειριστές δεν καλούνται πλέον Ταινία и DataDog, ξεκίνησε συμβαίνουν συντριβές στις εφαρμογές Heroku, σταμάτησε Οι πελάτες OpenLDAP συνδέονται, εντοπίζονται προβλήματα με την αποστολή αλληλογραφίας σε διακομιστές SMTPS και SMTP με STARTTLS. Επιπλέον, παρατηρούνται προβλήματα σε διάφορα σενάρια Ruby, PHP και Python που χρησιμοποιούν μια ενότητα με έναν πελάτη http. Πρόβλημα με το πρόγραμμα περιήγησης επηρεάζει Epiphany, η οποία σταμάτησε να φορτώνει λίστες αποκλεισμού διαφημίσεων.

Τα προγράμματα Go δεν επηρεάζονται από αυτό το πρόβλημα επειδή προσφέρει το Go ιδία υλοποίηση TLS.

υποτίθεταιότι το πρόβλημα επηρεάζει παλαιότερες εκδόσεις διανομής (συμπεριλαμβανομένων των Debian 9, Ubuntu 16.04, RHEL 6/7) που χρησιμοποιούν προβληματικούς κλάδους OpenSSL, αλλά το πρόβλημα εκδηλώθηκε επίσης όταν ο διαχειριστής πακέτων APT εκτελείται στις τρέχουσες εκδόσεις του Debian 10 και του Ubuntu 18.04/20.04, καθώς το APT χρησιμοποιεί τη βιβλιοθήκη GnuTLS. Η ουσία του προβλήματος είναι ότι πολλές βιβλιοθήκες TLS/SSL αναλύουν ένα πιστοποιητικό ως γραμμική αλυσίδα, ενώ σύμφωνα με το RFC 4158, ένα πιστοποιητικό μπορεί να αντιπροσωπεύει ένα κατευθυνόμενο κατανεμημένο κυκλικό γράφημα με πολλαπλές αγκυρώσεις εμπιστοσύνης που πρέπει να ληφθούν υπόψη. Σχετικά με αυτό το ελάττωμα στο OpenSSL και στο GnuTLS ήταν είναι γνωστό για πολλά χρόνια. Στο OpenSSL το πρόβλημα επιδιορθώθηκε στον κλάδο 1.1.1 και στο gnuTLS λείψανα αδιόρθωτος.

Ως λύση, προτείνεται η κατάργηση του πιστοποιητικού "AddTrust External CA Root" από το χώρο αποθήκευσης συστήματος (για παράδειγμα, καταργήστε το από /etc/ca-certificates.conf και /etc/ssl/certs και, στη συνέχεια, εκτελέστε το "update-ca -certificates -f -v"), μετά την οποία το OpenSSL αρχίζει να επεξεργάζεται κανονικά διασταυρούμενα πιστοποιητικά με τη συμμετοχή του. Όταν χρησιμοποιείτε τη διαχείριση πακέτων APT, μπορείτε να απενεργοποιήσετε την επαλήθευση πιστοποιητικού για μεμονωμένα αιτήματα με δική σας ευθύνη (για παράδειγμα, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false") .

Για να μπλοκάρετε το πρόβλημα Μαλακό καπέλλο и RHEL Προτείνεται η προσθήκη του πιστοποιητικού AddTrust στη μαύρη λίστα:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust απόσπασμα

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

Από την πλευρά του διακομιστή μπορείτε αλλαγή τάξη παραθέτοντας τα πιστοποιητικά στην αλυσίδα αξιοπιστίας που αποστέλλονται από τον διακομιστή στον πελάτη (εάν το πιστοποιητικό που σχετίζεται με το "AddTrust External CA Root" αφαιρεθεί από τη λίστα, τότε η επαλήθευση του πελάτη θα είναι επιτυχής). Για να ελέγξετε και να δημιουργήσετε μια νέα αλυσίδα εμπιστοσύνης, μπορείτε να χρησιμοποιήσετε την υπηρεσία whatsmychaincert.com. Sectigo επίσης предоставила εναλλακτικό διασταυρούμενο ενδιάμεσο πιστοποιητικό "Υπηρεσίες πιστοποιητικών AAA», το οποίο θα ισχύει μέχρι το 2028 και θα διατηρεί συμβατότητα με παλαιότερες εκδόσεις του ΛΣ.

Προσθήκη: Πρόβλημα επίσης εκδηλώνεται στο LibreSSL.

Πηγή: opennet.ru