SSL/TLS: βασικές έννοιες και πρωτόκολλα στον προγραμματισμό

Τι είναι το SSL/TLS;

SSL (Secure Sockets Layer) και TLS (Transport Layer Security) — κρυπτογραφικά πρωτόκολλα που εξασφαλίζουν ασφαλή μετάδοση δεδομένων μέσω δικτύου. Το SSL, που αναπτύχθηκε από τη Netscape τη δεκαετία του 1990, κηρύχθηκε παρωχημένο μετά την έκδοση 3.0 λόγω των τρωτών σημείων POODLE και BEAST. Το TLS, ο διάδοχός του, πέρασε από τις εκδόσεις 1.0, 1.1, 1.2 και 1.3 — επί του παρόντος μόνο τα TLS 1.2 και TLS 1.3 θεωρούνται επίκαιρα. Όλες οι σύγχρονες πλατφόρμες κινητών απαιτούν τη χρήση TLS για συνδέσεις δικτύου, και τα App Store και Google Play το ελέγχουν στο στάδιο της αξιολόγησης.

Γιατί χρειάζεται TLS στις εφαρμογές κινητού

Χωρίς TLS, η κίνηση μεταξύ εφαρμογής και διακομιστή μεταδίδεται ως απλό κείμενο — οποιοσδήποτε στο ίδιο δίκτυο Wi-Fi μπορεί να υποκλέψει ονόματα χρήστη, κωδικούς πρόσβασης, διακριτικά και προσωπικά δεδομένα χρηστών με Wireshark ή tcpdump. Το TLS κρυπτογραφεί όλα τα μεταδιδόμενα δεδομένα (κρυπτογράφηση σε επίπεδο μεταφοράς) και επαληθεύει τη γνησιότητα του διακομιστή μέσω της αλυσίδας πιστοποιητικών X.509. Σύμφωνα με την IETF (2018), το TLS 1.3 χρησιμοποιεί μόνο σύγχρονους κρυπτογράφους AEAD (AES-GCM, ChaCha20-Poly1305), αποκλείοντας παρωχημένους αλγόριθμους όπως RC4 και 3DES.

HTTPS και TLS

HTTPS (HTTP Secure) — είναι HTTP πάνω από TLS. Όταν μια εφαρμογή κινητού κάνει αίτημα μέσω https://, πρώτα δημιουργεί μια TLS σύνδεση με τον διακομιστή και στη συνέχεια μεταδίδει τις κεφαλίδες HTTP και το σώμα του αιτήματος μέσω του κρυπτογραφημένου καναλιού. Χωρίς HTTPS, κανένα σοβαρό API δεν θα πρέπει να λειτουργεί — αυτή είναι η βασική υγιεινή ασφαλείας. Σύμφωνα με το OWASP (2026), οι μη ασφαλείς συνδέσεις συγκαταλέγονται στις 3 κορυφαίες τρωτότητες εφαρμογών κινητού.

Πώς λειτουργεί η TLS Χειραψία

TLS Χειραψία — η διαδικασία δημιουργίας ασφαλούς σύνδεσης μεταξύ πελάτη και διακομιστή. Τα μέρη συμφωνούν την έκδοση πρωτοκόλλου, επιλέγουν τη σουίτα κρυπτογράφησης (cipher suite), ανταλλάσσουν κλειδιά μέσω ασύμμετρης κρυπτογραφίας και επαληθεύουν πιστοποιητικά. Στο TLS 1.2, η χειραψία απαιτεί 2 Round Trip Time (2 RTT): πελάτης → διακομιστής με ClientHello, διακομιστής → πελάτης με ServerHello και Certificate, στη συνέχεια τα τελικά μηνύματα Finished. Το TLS 1.3 συντομεύει αυτή τη διαδικασία σε 1 RTT.

Λεπτομερή στάδια χειραψίας TLS 1.2

Πρώτο στάδιο: ClientHello — ο πελάτης στέλνει τις υποστηριζόμενες εκδόσεις TLS, τη λίστα σουιτών κρυπτογράφησης και έναν τυχαίο αριθμό. Ο διακομιστής απαντά με ServerHello, επιλέγοντας την έκδοση και τη σουίτα κρυπτογράφησης, στέλνει το πιστοποιητικό X.509 του (Certificate) και το μήνυμα ServerHelloDone. Ο πελάτης επαληθεύει το πιστοποιητικό μέσω της αλυσίδας αξιόπιστων αρχών πιστοποίησης (CA), δημιουργεί το pre-master secret, το κρυπτογραφεί με το δημόσιο κλειδί από το πιστοποιητικό και το στέλνει στον διακομιστή στο ClientKeyExchange. Μετά από αυτό, και τα δύο μέρη δημιουργούν κλειδιά συνόδου και ανταλλάσσουν μηνύματα ChangeCipherSpec και Finished. Από αυτή τη στιγμή, όλα τα δεδομένα κρυπτογραφούνται συμμετρικά.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Παράδειγμα χειρισμού του URLAuthenticationChallenge στο iOS μέσω URLSessionDelegate. Αυτή η μέθοδος καλείται σε κάθε TLS Χειραψία, επιτρέποντας στην εφαρμογή να επαληθεύσει προσαρμοσμένα το πιστοποιητικό του διακομιστή. Για παραγωγή, προσθέστε επαλήθευση πιστοποιητικού μέσω SecTrustEvaluateWithError και συγκρίνετε με το προαποθηκευμένο αποτύπωμα — μόνο τότε καλέστε το useCredential.

TLS 1.2 εναντίον TLS 1.3

TLS 1.3 (RFC 8446, 2018) — η πρώτη μεγάλη ενημέρωση του πρωτοκόλλου εδώ και 10 χρόνια. Κύριες βελτιώσεις: χειραψία μειωμένη σε 1 RTT (0 RTT για επανασυνδέσεις), παρωχημένες σουίτες κρυπτογράφησης (RSA key exchange, CBC-mode) αφαιρέθηκαν, υποχρεωτική πρόσθια μυστικότητα (PFS) και προστασία από επιθέσεις υποβάθμισης μέσω signed transcript. Σύμφωνα με τα Qualys SSL Labs (2026), το TLS 1.3 παρέχει προστασία ακόμη και σε περίπτωση παραβίασης του μακροπρόθεσμου κλειδιού διακομιστή χάρη στο PFS.

0-RTT (Zero Round Trip Time) — λειτουργία του TLS 1.3 που επιτρέπει στον πελάτη να στέλνει δεδομένα αμέσως μαζί με το ClientHello κατά την επανασύνδεση μέσω PSK (Pre-Shared Key). Αυτό επιταχύνει τη φόρτωση επόμενων οθονών σε εφαρμογές κινητού, ειδικά σε συχνά αιτήματα προς τον ίδιο διακομιστή. Ωστόσο, τα δεδομένα 0-RTT δεν προστατεύονται από επιθέσεις replay — μπορούν να υποκλαπούν και να σταλούν ξανά. Χρησιμοποιήστε το 0-RTT μόνο για αιτήματα idempotent (GET, PUT) χωρίς παρενέργειες.

TLS στο iOS: App Transport Security

App Transport Security (ATS) — μηχανισμός της Apple που απαιτεί συνδέσεις HTTPS με TLS 1.2 ή υψηλότερο, ενεργοποιημένος από προεπιλογή από το iOS 9. Το ATS αποκλείει όλες τις συνδέσεις HTTP και HTTPS με TLS κάτω από 1.2. Ο προγραμματιστής μπορεί να ρυθμίσει εξαιρέσεις στο Info.plist μέσω του NSAppTransportSecurity για συγκεκριμένα domain, αλλά η Apple συνιστά την ελαχιστοποίηση των εξαιρέσεων και τη χρήση HTTPS παντού. Η παραβίαση των απαιτήσεων ATS αποτελεί λόγο απόρριψης της εφαρμογής στην αξιολόγηση του App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Ρύθμιση ATS στο Info.plist. Το NSAllowsArbitraryLoads έχει οριστεί σε false — όλες οι συνδέσεις πρέπει να χρησιμοποιούν HTTPS. Για το domain cdn.example.com έχει οριστεί ελάχιστη έκδοση TLS 1.2, το NSAllowsLocalNetworking=true επιτρέπει HTTP για το τοπικό δίκτυο (χρήσιμο για διακομιστές ανάπτυξης). Η Apple συνιστά ανεπιφύλακτα να μην ενεργοποιείτε το NSAllowsArbitraryLoads χωρίς NSExceptionDomains — αυτό πρέπει να είναι εξαίρεση, όχι γενικός κανόνας.

TLS στο Android: Network Security Config

Network Security Config — μηχανισμός Android για τη ρύθμιση HTTPS και TLS χωρίς τροποποίηση κώδικα Java/Kotlin. Η ρύθμιση ορίζεται στο αρχείο XML network_security_config.xml και συνδέεται στο AndroidManifest μέσω του χαρακτηριστικού android:networkSecurityConfig. Υποστηρίζει ρύθμιση αξιόπιστων πιστοποιητικών (user και system CA), Certificate Pinning, απενεργοποίηση απλού HTTP, παρακάμψεις debug και ανακατεύθυνση κίνησης.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config για Android. Το Base-config απαγορεύει την απλή κίνηση και εμπιστεύεται μόνο πιστοποιητικά CA συστήματος (χωρίς πιστοποιητικά χρήστη — προστασία από εγκατάσταση πιστοποιητικών MitM από τον χρήστη). Το Domain-config για api.example.com περιέχει pin-set με αποτύπωμα SHA-256 του πιστοποιητικού. Εάν το πιστοποιητικό διακομιστή αλλάξει πριν από την καθορισμένη ημερομηνία λήξης, η σύνδεση θα απορριφθεί — αυτή είναι μια αυστηρή μορφή Certificate Pinning.

Certificate Pinning και ασφάλεια

Certificate Pinning — τεχνική καθήλωσης του πιστοποιητικού ή του δημόσιου κλειδιού του διακομιστή στον κώδικα της εφαρμογής. Σε κάθε TLS Χειραψία, ο πελάτης συγκρίνει το πιστοποιητικό διακομιστή με το προαποθηκευμένο αποτύπωμα (hash SHA-256). Ακόμη κι αν ένας εισβολέας αποκτήσει ένα αξιόπιστο πιστοποιητικό CA ή παραβιάσει μια αρχή πιστοποίησης, δεν μπορεί να πραγματοποιήσει επίθεση MitM — η εφαρμογή ελέγχει το συγκεκριμένο αποτύπωμα, όχι την αλυσίδα CA. Αυτό είναι ιδιαίτερα σημαντικό για χρηματοοικονομικές εφαρμογές και εφαρμογές με ευαίσθητα δεδομένα.

Κίνδυνοι και εναλλακτικές του Pinning

Certificate Pinning απαιτεί προσοχή: όταν αλλάζει το πιστοποιητικό στον διακομιστή, όλες οι παλιές εκδόσεις της εφαρμογής δεν θα μπορούν να συνδεθούν. Συνιστάται η αποθήκευση πολλαπλών εφεδρικών αποτυπωμάτων (κύριο + εφεδρικό), ο καθορισμός ημερομηνίας λήξης του pin-set και η υλοποίηση μηχανισμού fallback μέσω τυπικής επαλήθευσης CA. Εναλλακτική — Trust On First Use (TOFU), όταν η εφαρμογή θυμάται το πιστοποιητικό κατά την πρώτη σύνδεση και προειδοποιεί τον χρήστη όταν αλλάζει. Σύμφωνα με το OWASP (2026), η έλλειψη Certificate Pinning συγκαταλέγεται στις 3 κορυφαίες τρωτότητες εφαρμογών κινητού (M3: Insecure Communication).

Υλοποίηση Pinning στο Alamofire

Στο Alamofire 5+, το Certificate Pinning ρυθμίζεται μέσω του ServerTrustManager με PinnedCertificatesTrustEvaluator (έλεγχος ολόκληρου του πιστοποιητικού) ή PublicKeysTrustEvaluator (μόνο δημόσιο κλειδί). Το δημόσιο κλειδί είναι προτιμότερο — δεν αλλάζει κατά την ενημέρωση του πιστοποιητικού στον ίδιο CA. Δημιουργήστε ένα ServerTrustManager με λεξικό [host: evaluator], μεταβιβάστε το στο Session και χρησιμοποιήστε το για όλα τα αιτήματα σε προστατευμένα API.