Certificate Pinning: τι είναι, μηχανισμός και μέθοδοι στερέωσης

Τι είναι το Certificate Pinning;

Certificate Pinning — είναι μια τεχνική ασφαλείας κατά την οποία η εφαρμογή αποθηκεύει το αποτύπωμα (fingerprint) ενός αξιόπιστου πιστοποιητικού και το χρησιμοποιεί ως μοναδικό κριτήριο για την εγκατάσταση σύνδεσης HTTPS. Στο τυπικό μοντέλο TLS, ο πελάτης ελέγχει αν το πιστοποιητικό του διακομιστή έχει υπογραφεί από ένα αξιόπιστο root CA — έναν από τους εκατοντάδες φορείς που είναι προεγκατεστημένοι στο σύστημα. Το Certificate Pinning αντικαθιστά αυτήν την αλυσίδα με έναν άμεσο έλεγχο: το πιστοποιητικό πρέπει να ταιριάζει με το αποθηκευμένο δείγμα ή να περιέχει το αναμενόμενο δημόσιο κλειδί.

Το πρόβλημα του τυπικού μοντέλου έγινε προφανές μετά τα περιστατικά παραβίασης CA — DigiNotar (2011), Comodo (2011), TrustCor (2022). Εάν ένα CA εκδώσει ψευδές πιστοποιητικό για τον τομέα σας, ο φυλλομετρητής ή η εφαρμογή το αποδέχεται ως έγκυρο. Certificate Pinning αποτρέπει αυτήν την επίθεση: ακόμη και ένα τέλεια υπογεγραμμένο ψευδές πιστοποιητικό θα απορριφθεί, επειδή το αποτύπωμά του δεν ταιριάζει με αυτό που έχει στερεωθεί στην εφαρμογή.

Ο όρος pinning προέρχεται από το pin — “καρφίτσα” ή “στερεωτήρας”: ο προγραμματιστής στερεώνει το αξιόπιστο πιστοποιητικό, και οποιαδήποτε απόκλιση από αυτό αποκλείει τη σύνδεση. Σύμφωνα με την έρευνα Mitre CWE-295, η εσφαλμένη επαλήθευση πιστοποιητικού παραμένει μία από τις top-10 πιο επικίνδυνες ασφάλειες σε εφαρμογές κινητών, και το Certificate Pinning είναι η άμεση μέθοδος πρόληψής της.

Ιστορία και εξέλιξη του Certificate Pinning

Αρχικά, το Certificate Pinning χρησιμοποιούνταν σε φυλλομετρητές μέσω του μηχανισμού HPKP (HTTP Public Key Pinning), που τυποποιήθηκε στο RFC 7469. Ο προγραμματιστής έστελνε μια κεφαλίδα HTTP Public-Key-Pins με hash των αναμενόμενων κλειδιών, και ο φυλλομετρητής τα απομνημόνευε για μια συγκεκριμένη περίοδο. Ωστόσο, το HPKP αποδείχθηκε επικίνδυνο: ένα λάθος στη ρύθμιση μπορούσε να αποκλείσει τον ιστότοπο για μήνες. Το 2018, το Chrome σταμάτησε την υποστήριξη για το HPKP και τώρα πρότυπο είναι η υλοποίηση λογισμικού στην πλευρά του πελάτη — μέσα σε εφαρμογή κινητού ή επέκταση φυλλομετρητή.

Πώς λειτουργεί το Certificate Pinning;

Η διαδικασία Certificate Pinning περιλαμβάνει τρία βασικά στάδια: υπολογισμό του αποτυπώματος, επαλήθευση κατά τη σύνδεση και χειρισμό σφάλματος. Στο στάδιο προετοιμασίας, ο προγραμματιστής λαμβάνει το SHA-256 hash του πιστοποιητικού ή του δημόσιου κλειδιού του διακομιστή παραγωγής. Για εφαρμογές συμβατές με GDPR και PCI DSS, απαιτείται επίσης η στερέωση των αποτυπωμάτων των ενδιάμεσων CA στην αλυσίδα.

Σε κάθε αίτημα HTTPS, η εφαρμογή παρακολουθεί το callback πιστοποίησης TLS, εξάγει το πιστοποιητικό του διακομιστή και υπολογίζει το SHA-256 hash του. Αυτό το hash συγκρίνεται με την αποθηκευμένη λίστα αξιόπιστων αποτυπωμάτων. Αν βρεθεί αντιστοιχία — η σύνδεση συνεχίζεται. Αν όχι — η εφαρμογή πρέπει να διακόψει τη σύνδεση και να αναφέρει το σφάλμα, χωρίς να αποκαλύπτει λεπτομέρειες υλοποίησης στον επιτιθέμενο.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

Η συνάρτηση λαμβάνει ένα X509Certificate αντικείμενο από τον διακομιστή και το αναμενόμενο hash. Πρώτα εξάγεται το δημόσιο κλειδί του πιστοποιητικού, υπολογίζεται το SHA-256 hash και κωδικοποιείται σε Base64. Το αποτέλεσμα συγκρίνεται με το αναμενόμενο αποτύπωμα. Στην παραγωγή, αξίζει να προστεθεί έλεγχος σε έναν πίνακα 2–3 αποτυπωμάτων για υποστήριξη εναλλαγής.

Certificate Pinning vs Public Key Pinning

Κατά την υλοποίηση pinning, πρέπει να επιλεγεί ποιο κρυπτογραφικό αντικείμενο θα στερεωθεί. Το Certificate Pinning συνδέεται με το ίδιο το X.509 πιστοποιητικό — τον αύξοντα αριθμό του, την περίοδο ισχύος και ολόκληρη την αλυσίδα. Το Public Key Pinning στερεώνει μόνο το δημόσιο κλειδί εντός του πιστοποιητικού, αγνοώντας τα άλλα πεδία. Η επιλογή επηρεάζει σημαντικά το λειτουργικό κόστος.

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

Trust On First Use (TOFU)

TOFU — στρατηγική όπου το Certificate Pinning δεν είναι προρυθμισμένο, αλλά απομνημονεύει το πιστοποιητικό κατά την πρώτη σύνδεση με τον διακομιστή. Αυτή η προσέγγιση είναι βολική για εφαρμογές που δεν γνωρίζουν εκ των προτέρων με ποιον διακομιστή θα συνδεθούν. Μειονέκτημα — ευπάθεια στην πρώτη επίθεση: αν η πρώτη σύνδεση υποκλαπεί, το ψευδές πιστοποιητικό θα γίνει αποδεκτό ως αξιόπιστο. Το TOFU εφαρμόζεται σε συνδέσεις SSH και σε ορισμένα πρωτόκολλα P2P.

Υλοποίηση σε iOS και Android

Και στις δύο πλατφόρμες, το Certificate Pinning υλοποιείται με υποκλοπή της σύνδεσης TLS στο επίπεδο της στοίβας δικτύου. Σε iOS χρησιμοποιείται ο εκπρόσωπος URLSession ή το Alamofire ServerTrustManager. Σε Android, η προτιμώμενη μέθοδος είναι το OkHttp CertificatePinner, το οποίο είναι ενσωματωμένο σε δημοφιλείς πελάτες HTTP και υποστηρίζει ρύθμιση πολλαπλών αποτυπωμάτων για κάθε τομέα.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Στη συνάρτηση Swift, από το serverTrust εξάγεται η αλυσίδα πιστοποιητικών, για κάθε ένα υπολογίζεται το SHA-256 hash, και το αποτέλεσμα συγκρίνεται με το αναμενόμενο. Η διέλευση από όλα τα πιστοποιητικά στην αλυσίδα επιτρέπει την υλοποίηση pinning στο επίπεδο του ενδιάμεσου CA — αν το ενδιάμεσο πιστοποιητικό ταιριάζει, η σύνδεση γίνεται αποδεκτή. Αυτό παρέχει ευελιξία στην εναλλαγή πιστοποιητικών leaf.

TrustManager για Android (προσαρμοσμένο)

Αν η εφαρμογή δεν χρησιμοποιεί OkHttp, το Certificate Pinning μπορεί να υλοποιηθεί μέσω προσαρμοσμένου X509TrustManager. Αυτή η μέθοδος απαιτεί περισσότερο κώδικα, αλλά παρέχει πλήρη έλεγχο επί της διαδικασίας επαλήθευσης. Ο TrustManager παρακάμπτει τη μέθοδο checkServerTrusted, όπου ο προγραμματιστής ελέγχει χειροκίνητα τα πιστοποιητικά του διακομιστή και λαμβάνει απόφαση εμπιστοσύνης. Συνιστάται μόνο για συγκεκριμένα σενάρια όπου η βιβλιοθήκη OkHttp δεν είναι διαθέσιμη.

Λάθη κατά την υλοποίηση Certificate Pinning

Το πιο συνηθισμένο λάθος — έλλειψη εφεδρικών pin. Ο προγραμματιστής τοποθετεί ένα αποτύπωμα πιστοποιητικού, και κατά τη λήξη του οι χρήστες χάνουν μαζικά τη σύνδεση. Η ελάχιστα αποδεκτή ρύθμιση — δύο αποτυπώματα: τρέχον πιστοποιητικό και εφεδρικό. Βέλτιστα — τρία: τρέχον, εφεδρικό και αποτύπωμα του root CA ως fallback.

Δεύτερο λάθος — αποθήκευση pin σε ανοιχτή μορφή στον κώδικα. Ένας επιτιθέμενος με πρόσβαση σε APK ή IPA μπορεί εύκολα να εξάγει και να αντικαταστήσει τα αποτυπώματα. Συνιστάται η συσκότιση hash: διαίρεση της συμβολοσειράς σε μέρη, αποθήκευση σε κρυπτογραφημένους πόρους ή υπολογισμός μέσω runtime. Για Android, το ProGuard με συσκότιση σταθερών συμβολοσειράς είναι αποτελεσματικό.

Τρίτο λάθος — pinning στο επίπεδο πιστοποιητικού ανάπτυξης. Τα πιστοποιητικά ανάπτυξης και παραγωγής είναι συνήθως διαφορετικά, αλλά οι προγραμματιστές συχνά ξεχνούν να αλλάξουν τα pin κατά την κατασκευή release. Αποτέλεσμα — η εφαρμογή παραγωγής δεν μπορεί να συνδεθεί με τον διακομιστή. Λύση — ξεχωριστή ρύθμιση pin για debug και release μέσω BuildConfig ή πόρων ειδικών για flavour.

• Ignoring certificate chain — έλεγχος μόνο του leaf πιστοποιητικού χωρίς να λαμβάνονται υπόψη τα ενδιάμεσα CA, που διακόπτει τη σύνδεση κατά την εναλλαγή
• Hardcoded dates — σκληρά κωδικοποιημένες ημερομηνίες λήξης πιστοποιητικών που δεν αλλάζουν μετά την ενημέρωση
• No monitoring — έλλειψη ειδοποιήσεων για σφάλματα Certificate Pinning, με αποτέλεσμα τα προβλήματα να ανακαλύπτονται μόνο από τους χρήστες
• TOFU χωρίς επαλήθευση — χρήση Trust On First Use χωρίς πρόσθετο έλεγχο, επιτρέποντας στην πρώτη επίθεση MITM να στερεώσει ψευδές πιστοποιητικό