SSL/TLS — τι είναι, πρωτόκολλα και αρχή λειτουργίας της κρυπτογράφησης

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

SSL (Secure Sockets Layer) — είναι ένα πρωτόκολλο που αναπτύχθηκε από την εταιρεία Netscape το 1995 για την προστασία της διαδικτυακής κίνησης. Η πρώτη έκδοση SSL 1.0 δεν δημοσιεύθηκε ποτέ, οι SSL 2.0 (1995) και SSL 3.0 (1996) χρησιμοποιήθηκαν μέχρι τις αρχές της δεκαετίας του 2000, αλλά περιείχαν κρίσιμες ευπάθειες. Στη θέση του SSL ήρθε το TLS (Transport Layer Security) — μια βελτιωμένη έκδοση που τυποποιήθηκε από τον IETF. Το TLS 1.0 (1999) βασίστηκε στο SSL 3.0, και οι επόμενες εκδόσεις TLS 1.1 (2006), TLS 1.2 (2008) και TLS 1.3 (2018) απομακρύνθηκαν σταδιακά από την αρχική αρχιτεκτονική, προσθέτοντας νέους αλγόριθμους κρυπτογράφησης και εξαλείφοντας ευπάθειες. Σήμερα το SSL θεωρείται ξεπερασμένο και όλα τα σύγχρονα συστήματα χρησιμοποιούν TLS, αν και από συνήθεια και τα δύο πρωτόκολλα αναφέρονται συχνά μαζί ως SSL/TLS.

Ιστορία δημιουργίας του πρωτοκόλλου

Η ιστορία του SSL/TLS ξεκίνησε με την ανάγκη για ασφαλή μετάδοση δεδομένων στον πρώιμο ιστό. Το 1994, η Netscape ανέπτυξε το SSL 1.0 για τον browser Navigator, αλλά το πρωτόκολλο δεν δημοσιεύθηκε ποτέ λόγω σοβαρών προβλημάτων ασφαλείας. Το SSL 2.0 κυκλοφόρησε το 1995 και χρησιμοποιήθηκε στην πράξη, αλλά περιείχε πολυάριθμες ευπάθειες: έλλειψη προστασίας από επιθέσεις Man-in-the-Middle, αδύναμους αλγόριθμους κρυπτογράφησης και ευπάθεια σε επιθέσεις truncation. Το SSL 3.0 (1996) διόρθωσε τα περισσότερα προβλήματα, αλλά μέχρι το 2014 ανακαλύφθηκε η ευπάθεια POODLE, μετά την οποία ο IETF κήρυξε επίσημα όλες τις εκδόσεις SSL ως ξεπερασμένες. Τα TLS 1.0–1.3 βελτίωσαν διαδοχικά την κρυπτογραφική ισχύ, την απόδοση και την εμπιστευτικότητα, με το TLS 1.3 να μειώνει το handshake από δύο round-trip σε ένα, που είναι κρίσιμο για εφαρμογές κινητών με ασταθή σύνδεση.

Πώς λειτουργεί το SSL/TLS Handshake

Handshake — είναι η διαδικασία εγκαθίδρυσης ασφαλούς σύνδεσης μεταξύ πελάτη και διακομιστή. Αποτελείται από πολλά διαδοχικά βήματα κατά τα οποία τα μέρη συμφωνούν στην έκδοση του πρωτοκόλλου, επιλέγουν αλγόριθμους κρυπτογράφησης, ανταλλάσσουν κλειδιά και πιστοποιούν την ταυτότητά τους. Στο TLS 1.3, το handshake διαρκεί μόνο μία αλληλεπίδραση δικτύου (1-RTT), ενώ στο TLS 1.2 απαιτούνταν δύο (2-RTT).

Στο πρώτο βήμα, ο πελάτης στέλνει ClientHello — ένα μήνυμα που περιέχει λίστα υποστηριζόμενων εκδόσεων TLS, cipher suites και έναν τυχαίο αριθμό. Ο διακομιστής απαντά με ServerHello που περιλαμβάνει την επιλεγμένη έκδοση και κρυπτογράφηση, το πιστοποιητικό X.509 και την ψηφιακή υπογραφή του. Ο πελάτης επαληθεύει το πιστοποιητικό μέσω της αλυσίδας αρχών πιστοποίησης (CA), δημιουργεί ένα κλειδί συνόδου και το στέλνει κρυπτογραφημένο με το δημόσιο κλειδί του διακομιστή από το πιστοποιητικό. Μετά την επιβεβαίωση από τον διακομιστή, ξεκινά η ασφαλής μετάδοση δεδομένων. Ολόκληρο το handshake εκτελείται σε 1–3 χιλιοστά του δευτερολέπτου σε σύγχρονες συσκευές, καθιστώντας το αόρατο για τον χρήστη.

Πιστοποιητικά X.509 και αλυσίδα εμπιστοσύνης

Η βάση της πιστοποίησης ταυτότητας TLS είναι η υποδομή δημόσιου κλειδιού (PKI) που βασίζεται σε πιστοποιητικά μορφής X.509. Κάθε πιστοποιητικό περιέχει: όνομα τομέα (Common Name ή Subject Alternative Name), δημόσιο κλειδί διακομιστή, όνομα εκδότη (Certificate Authority), περίοδο ισχύος και ψηφιακή υπογραφή CA. Ο πελάτης επαληθεύει το πιστοποιητικό του διακομιστή μέσω της αλυσίδας εμπιστοσύνης: από το πιστοποιητικό του διακομιστή έως τη ρίζα CA, της οποίας το πιστοποιητικό είναι ενσωματωμένο στο λειτουργικό σύστημα. Σε συσκευές Android, τα ριζικά πιστοποιητικά αποθηκεύονται στο χώρο αποθήκευσης συστήματος που ενημερώνεται μέσω Google Play Services· στο iOS — μέσω iOS Updates. Σε περίπτωση παραβίασης οποιουδήποτε κρίκου της αλυσίδας (ληγμένο πιστοποιητικό, ασυμφωνία τομέα, άγνωστο CA), ο πελάτης διακόπτει τη σύνδεση. Για αυτο-υπογεγραμμένα πιστοποιητικά (που χρησιμοποιούνται στην ανάπτυξη) απαιτείται ρητή εμπιστοσύνη — στο Android μέσω Network Security Config, στο iOS μέσω NSExceptionDomains στο Info.plist. Η διαδικασία επικύρωσης της αλυσίδας πιστοποιητικών περιλαμβάνει επίσης τον έλεγχο κατάστασης ανάκλησης μέσω CRL (Certificate Revocation List) ή OCSP (Online Certificate Status Protocol), αν και σε κινητές συσκευές τα αιτήματα OCSP συχνά παραλείπονται για επιτάχυνση της σύνδεσης — αυτός είναι ένας συμβιβασμός μεταξύ ασφάλειας και απόδοσης που οι αρχιτέκτονες πρέπει να λάβουν υπόψη.

SSL εναντίον TLS: βασικές διαφορές

Αν και οι όροι SSL και TLS χρησιμοποιούνται συχνά ως συνώνυμα, υπάρχουν θεμελιώδεις τεχνικές διαφορές μεταξύ τους που επηρεάζουν την ασφάλεια και την απόδοση των εφαρμογών κινητών.

Η κύρια διαφορά του TLS 1.3 από τους προκατόχους του — η υποχρεωτική χρήση του Perfect Forward Secrecy (PFS) μέσω του πρωτοκόλλου ECDHE. Αυτό σημαίνει ότι ακόμα κι αν ένας επιτιθέμενος αποκτήσει πρόσβαση στο ιδιωτικό κλειδί του διακομιστή, δεν θα μπορέσει να αποκρυπτογραφήσει την προηγουμένως υποκλαπείσα κίνηση. Για εφαρμογές κινητών, όπου η παραβίαση του διακομιστή είναι πραγματική απειλή, το TLS 1.3 με PFS είναι υποχρεωτική απαίτηση ασφαλείας.

Γνωστές ευπάθειες παλαιών εκδόσεων

Οι παλαιές εκδόσεις των SSL και TLS έχουν τεκμηριωμένες ευπάθειες που τις καθιστούν ακατάλληλες για χρήση σε παραγωγή. Το POODLE (CVE-2014-3566) επιτίθεται στο SSL 3.0 μέσω padding oracle, επιτρέποντας την αποκρυπτογράφηση του cookie συνόδου σε 256 αιτήματα. Το BEAST (CVE-2011-3389) εκμεταλλεύεται την ευπάθεια του TLS 1.0 σε λειτουργία CBC μέσω προβλέψιμου IV. Το Heartbleed (CVE-2014-0160) — δεν είναι ευπάθεια πρωτοκόλλου, αλλά σφάλμα στην υλοποίηση OpenSSL που επιτρέπει την ανάγνωση μνήμης διακομιστή: σύμφωνα με τη Netcraft, το 2014 πάνω από 500 χιλιάδες διακομιστές ήταν ευάλωτοι. Από το Android 10 (API 29) και το iOS 13, όλα τα αναφερόμενα πρωτόκολλα είναι απενεργοποιημένα σε επίπεδο συστήματος. Ωστόσο, οι προγραμματιστές θα πρέπει να ελέγχουν τη διαμόρφωση του διακομιστή μέσω SSL Labs Test (qualys.com) πριν από την εκκίνηση της εφαρμογής για να βεβαιωθούν ότι δεν υπάρχουν ξεπερασμένα cipher suites και ότι το TLS 1.3 υποστηρίζεται.

Πώς το SSL/TLS προστατεύει δεδομένα σε εφαρμογές κινητών

Στις εφαρμογές κινητών, το TLS προστατεύει τα δεδομένα σε τρία επίπεδα: κρυπτογράφηση περιεχομένου (κανείς εκτός από τον διακομιστή δεν μπορεί να διαβάσει τα δεδομένα), έλεγχος ακεραιότητας (τα δεδομένα δεν μπορούν να τροποποιηθούν κατά τη μεταφορά) και πιστοποίηση ταυτότητας διακομιστή (ο πελάτης είναι σίγουρος ότι συνδέεται με τον σωστό διακομιστή). Η πιστοποίηση ταυτότητας είναι ιδιαίτερα κρίσιμη: χωρίς αυτήν, ένας επιτιθέμενος μπορεί να υποκαταστήσει τον διακομιστή μέσω DNS-spoofing ή πλαστού σημείου πρόσβασης Wi-Fi.

Σύμφωνα με τη μελέτη Google Play Protect (2024), το 76% των εφαρμογών Android χρησιμοποιούν σωστά TLS με έλεγχο πιστοποιητικών. Το υπόλοιπο 24% κάνει λάθη: απενεργοποιεί τον έλεγχο πιστοποιητικών για δοκιμές (και ξεχνά να τον ενεργοποιήσει στην παραγωγή), χρησιμοποιεί αυτο-υπογεγραμμένα πιστοποιητικά χωρίς επικύρωση ή επιτρέπει ξεπερασμένα πρωτόκολλα SSL 3.0 και TLS 1.0. Το Apple App Transport Security (ATS) στο iOS απαιτεί τουλάχιστον TLS 1.2 από το 2017, και από το iOS 15 χρησιμοποιεί προεπιλεγμένα TLS 1.3 για όλα τα αιτήματα δικτύου. Για πρόσθετη προστασία, συνιστάται επίσης η εφαρμογή του Certificate Pinning — η σύνδεση με συγκεκριμένο πιστοποιητικό διακομιστή.

Υλοποίηση SSL/TLS σε εφαρμογές κινητών

Ας εξετάσουμε ένα παράδειγμα ρύθμισης ασφαλούς σύνδεσης HTTPS στο Android χρησιμοποιώντας το OkHttp — μια από τις πιο δημοφιλείς βιβλιοθήκες για εργασία με δίκτυο. Η σωστή διαμόρφωση περιλαμβάνει υποχρεωτική χρήση TLS 1.3 και έλεγχο πιστοποιητικών.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

Σε αυτό το παράδειγμα, περιορίζουμε το σύνολο των υποστηριζόμενων εκδόσεων TLS μόνο στα πρωτόκολλα 1.3 και 1.2, εξαιρώντας τα ξεπερασμένα TLS 1.0/1.1. Τα cipher suites επιλέγονται από σύγχρονους αλγόριθμους με λειτουργία AEAD και υποχρεωτική Perfect Forward Secrecy. Το HostnameVerifier ελέγχει την αντιστοιχία ονόματος κεντρικού υπολογιστή με το πιστοποιητικό. Για iOS, παρόμοια ρύθμιση γίνεται μέσω διαμόρφωσης URLSession με την παράμετρο tlsMinimumSupportedProtocolVersion, όπου καθορίζεται το .TLSv13. Επιπλέον, στο iOS μπορεί να οριστεί tlsMaximumSupportedProtocolVersion για τον περιορισμό του ανώτατου ορίου εκδόσεων — αυτό είναι χρήσιμο για συμβατότητα με παλαιούς διακομιστές που δεν έχουν ακόμη μεταβεί σε TLS 1.3. Μια τέτοια διαμόρφωση εγγυάται το μέγιστο επίπεδο ασφάλειας κατά τη μετάδοση δεδομένων στην εφαρμογή κινητού.