SSL Pinning: ουσία, μηχανισμός και προστασία από επιθέσεις MITM

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

SSL Pinning — είναι ένας μηχανισμός ασφαλείας κατά τον οποίο μια εφαρμογή κινητού ή web απομνημονεύει ένα αξιόπιστο πιστοποιητικό ή δημόσιο κλειδί του διακομιστή και απορρίπτει οποιαδήποτε σύνδεση της οποίας το πιστοποιητικό δεν ταιριάζει με το αποθηκευμένο. Στο τυπικό σχήμα HTTPS, ο πελάτης ελέγχει το πιστοποιητικό μέσω της αλυσίδας εμπιστοσύνης μέχρι το ριζικό CA — οποιοδήποτε CA μπορεί να υπογράψει ένα πιστοποιητικό για οποιοδήποτε domain. Το SSL Pinning εξαλείφει αυτήν την αδυναμία: αντί να εμπιστεύεται εκατοντάδες CA, η εφαρμογή εμπιστεύεται μόνο ένα συγκεκριμένο πιστοποιητικό.

Το πρόβλημα του τυπικού ελέγχου είναι ότι οποιοδήποτε από τα εκατοντάδες ριζικά CA μπορεί να εκδώσει ένα έγκυρο πιστοποιητικό για τον τομέα σας — τυχαία ή υπό πίεση. Ένας επιτιθέμενος που αποκτά πρόσβαση σε ένα εταιρικό διακομιστή μεσολάβησης με δικό του ριζικό πιστοποιητικό μπορεί να πραγματοποιήσει επίθεση MITM χωρίς προειδοποίηση του προγράμματος περιήγησης. Το SSL Pinning κλείνει αυτήν την ευπάθεια: ακόμα κι αν το CA εκδώσει πλαστό πιστοποιητικό, η εφαρμογή θα το απορρίψει, επειδή το αποτύπωμα δεν ταιριάζει με το καταγεγραμμένο.

Στις εφαρμογές κινητού, το SSL Pinning είναι ιδιαίτερα σημαντικό επειδή οι συσκευές συχνά λειτουργούν σε μη ασφαλή δίκτυα — δημόσιο Wi-Fi, εταιρικοί διακομιστές μεσολάβησης με επιθεώρηση κίνησης, μολυσμένα σημεία πρόσβασης. Σύμφωνα με το Verizon Mobile Security Index (2025), πάνω από το 60% των διαρροών δεδομένων σε εφαρμογές κινητού σχετίζονται με υποκλοπή κίνησης στο επίπεδο μεταφοράς.

Γιατί χρειάζεται το SSL Pinning στην ανάπτυξη κινητού

Οι εφαρμογές κινητού μεταδίδουν ευαίσθητα δεδομένα — διακριτικά ελέγχου ταυτότητας, πληροφορίες πληρωμής, προσωπικά δεδομένα χρηστών. Χωρίς πρόσθετη προστασία, το HTTPS μπορεί να τεθεί σε κίνδυνο μέσω υποκατάστασης του ριζικού πιστοποιητικού στη συσκευή — για παράδειγμα, μετά από εγκατάσταση εταιρικού προφίλ ή κακόβουλης εφαρμογής. Το SSL Pinning εγγυάται ότι, ακόμα κι αν είναι εγκατεστημένο ένα πλαστό ριζικό CA στη συσκευή, η εφαρμογή θα συνεχίσει να ελέγχει το πιστοποιητικό σύμφωνα με τη δική της λευκή λίστα.

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

Η διαδικασία του SSL Pinning αποτελείται από τρία στάδια: λήψη αποτυπώματος, έλεγχος κατά τη σύνδεση και διαχείριση σφαλμάτων. Στο στάδιο ανάπτυξης, ο μηχανικός λαμβάνει το αποτύπωμα SHA-256 του πιστοποιητικού του διακομιστή (openssl x509 -fingerprint -sha256) και το ενσωματώνει στον κώδικα της εφαρμογής ή στο αρχείο διαμόρφωσης. Σε κάθε αίτημα HTTPS, η εφαρμογή υπολογίζει το αποτύπωμα του ληφθέντος πιστοποιητικού και το συγκρίνει με το αποθηκευμένο — εάν οι τιμές δεν ταιριάζουν, η σύνδεση διακόπτεται.

Πρώτο στάδιο — pinning στο στάδιο δημιουργίας: ο προγραμματιστής γνωρίζει εκ των προτέρων τα πιστοποιητικά του διακομιστή και ενσωματώνει τα hashes τους. Δεύτερο στάδιο — pinning στην πρώτη σύνδεση (trust on first use, TOFU): η εφαρμογή απομνημονεύει το πιστοποιητικό στο πρώτο αίτημα και το χρησιμοποιεί για τον έλεγχο όλων των επόμενων. Το TOFU είναι βολικό για δυναμικά περιβάλλοντα, αλλά είναι ευάλωτο στην πρώτη επίθεση — εάν η πρώτη σύνδεση έχει ήδη υποκλαπεί, το πλαστό πιστοποιητικό θα γίνει αποδεκτό ως αξιόπιστο.

Κρίσιμη λεπτομέρεια — εφεδρικά αποτυπώματα (backup pins). Τα πιστοποιητικά έχουν ημερομηνία λήξης και κατά την αντικατάστασή τους, η μη ενημερωμένη εφαρμογή χάνει τη σύνδεση με τον διακομιστή. Οι μηχανικοί προσθέτουν 2–3 επιπλέον αποτυπώματα — για παράδειγμα, το αποτύπωμα του εφεδρικού πιστοποιητικού και το αποτύπωμα του ριζικού CA. Εάν το κύριο πιστοποιητικό αλλάξει, η εφαρμογή ελέγχει βάσει των backup pins και η σύνδεση συνεχίζει να λειτουργεί.

# Λήψη αποτυπώματος SHA-256 του πιστοποιητικού
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

Τύποι SSL Pinning

Υπάρχουν δύο κύριες προσεγγίσεις για την υλοποίηση του pinning: σύνδεση σε ολόκληρο το πιστοποιητικό (certificate pinning) και σύνδεση στο δημόσιο κλειδί (public key pinning). Κάθε προσέγγιση έχει τα δυνατά της σημεία και τους περιορισμούς της που επηρεάζουν την ασφάλεια και την ευκολία συντήρησης.

Certificate Pinning

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

Public Key Pinning

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

SSL Pinning σε iOS

Στην πλατφόρμα Apple, το SSL Pinning υλοποιείται μέσω του εκπροσώπου URLSession. Ο προγραμματιστής δημιουργεί μια κλάση που υλοποιεί το πρωτόκολλο URLSessionDelegate και παρακάμπτει τη μέθοδο didReceive challenge, όπου ελέγχει χειροκίνητα το πιστοποιητικό του διακομιστή έναντι των αποθηκευμένων αποτυπωμάτων. Μια εναλλακτική προσέγγιση — χρήση του Alamofire με το ServerTrustManager, που απλοποιεί τη διαμόρφωση.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Στο παράδειγμα, ο εκπρόσωπος λαμβάνει ένα αίτημα ελέγχου ταυτότητας από το URLSession, εξάγει το serverTrust από το challenge και συγκρίνει το αποτύπωμα SHA-256 του πιστοποιητικού με το αποθηκευμένο. Εάν το αποτύπωμα ταιριάζει — η σύνδεση συνεχίζεται, διαφορετικά το challenge απορρίπτεται. Για το περιβάλλον παραγωγής, αξίζει να προστεθεί έλεγχος πολλαπλών backup pins και καταγραφή σφαλμάτων για παρακολούθηση.

Network Security Config σε iOS

Από το iOS 14, η Apple πρόσθεσε ενσωματωμένη υποστήριξη για Certificate Pinning μέσω του Info.plist. Ο προγραμματιστής καθορίζει αξιόπιστα πιστοποιητικά στο κλειδί NSAppTransportSecurity με το υπολεξικό NSPinnedDomains. Αυτή η προσέγγιση δεν απαιτεί σύνταξη κώδικα, αλλά είναι λιγότερο ευέλικτη — δεν μπορείτε να αλλάξετε δυναμικά τα pins ή να καταγράψετε σφάλματα ελέγχου.

SSL Pinning σε Android

Στο Android υπάρχουν τρεις κύριοι τρόποι υλοποίησης του SSL Pinning: μέσω του CertificatePinner της βιβλιοθήκης OkHttp, μέσω του Network Security Config σε XML και μέσω προσαρμοσμένου ελέγχου στο HttpsURLConnection. Το OkHttp — η πιο δημοφιλής και συνιστώμενη προσέγγιση, που χρησιμοποιείται στο Retrofit και σε άλλους πελάτες HTTP.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // εφεδρικό pin
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Στη διαμόρφωση του OkHttp, ο προγραμματιστής καθορίζει τον τομέα και ένα ή περισσότερα αποτυπώματα SHA-256. Στο πρώτο αποτύπωμα, το OkHttp συγκρίνει το πιστοποιητικό του διακομιστή με τα καθορισμένα pins. Εάν δεν υπάρχει αντιστοιχία, ο πελάτης ρίχνει SSLPeerUnverifiedException. Το εφεδρικό pin είναι υποχρεωτικό — χωρίς αυτό, κατά την αλλαγή πιστοποιητικού, τα αιτήματα API θα αρχίσουν αμέσως να αποτυγχάνουν.

Network Security Configuration σε Android

Το Android υποστηρίζει δηλωτικό Certificate Pinning μέσω διαμόρφωσης XML από το API 24. Το αρχείο res/xml/network_security_config.xml περιέχει μια λίστα τομέων και των αποτυπωμάτων τους. Αυτή η μέθοδος είναι βολική για στατικές διαμορφώσεις, αλλά δεν επιτρέπει την υλοποίηση TOFU ή προσαρμοσμένης λογικής ελέγχου με καταγραφή ανωμαλιών.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Πλεονεκτήματα και μειονεκτήματα του SSL Pinning

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

Το κύριο μειονέκτημα — η πολυπλοκότητα εναλλαγής πιστοποιητικών. Εάν ένα πιστοποιητικό λήξει ή ανακληθεί, οι χρήστες χωρίς ενημέρωση της εφαρμογής χάνουν τη σύνδεση. Επιλύεται μέσω εφεδρικών pins και μηχανισμού σταδιακής ενημέρωσης: η νέα εφαρμογή γνωρίζει το παλιό και το νέο πιστοποιητικό και μετά την πλήρη ενημέρωση των χρηστών, το παλιό pin αφαιρείται από τον κώδικα. Συνιστάται τουλάχιστον 2 εφεδρικά pins — ένα για το τρέχον πιστοποιητικό, ένα για το μελλοντικό.

Ένας άλλος συμβιβασμός — η αδυναμία χρήσης δημόσιων διακομιστών μεσολάβησης για τον εντοπισμό σφαλμάτων κίνησης (Charles Proxy, Burp Suite) χωρίς απενεργοποίηση του pinning. Αυτό περιπλέκει τον εντοπισμό σφαλμάτων αιτημάτων δικτύου στο στάδιο ανάπτυξης. Λύση — υπό όρους μεταγλώττιση: στη μεταγλώττιση debug το pinning είναι απενεργοποιημένο, στη release είναι ενεργοποιημένο. Το OWASP συνιστά τη χρήση της σημαίας BuildConfig.DEBUG για εναλλαγή.