HTTP/HTTPS: τι είναι, πρωτόκολλα μεταφοράς δεδομένων και κρυπτογράφηση TLS

Τι είναι τα HTTP και HTTPS;

HTTP (HyperText Transfer Protocol) — είναι ένα πρωτόκολλο επιπέδου εφαρμογής του μοντέλου OSI, που προορίζεται για τη μεταφορά εγγράφων υπερκειμένου και άλλων δεδομένων στον Παγκόσμιο Ιστό. Αναπτύχθηκε από τον Tim Berners-Lee το 1989, το HTTP έχει περάσει από πολλές εκδόσεις: από HTTP/0.9 (μόνο αιτήματα GET και αποκρίσεις HTML) έως τα σύγχρονα HTTP/2 και HTTP/3. Το πρωτόκολλο λειτουργεί με σχήμα αίτησης-απόκρισης: ο πελάτης στέλνει ένα αίτημα στον διακομιστή, ο διακομιστής το επεξεργάζεται και επιστρέφει μια απόκριση.

HTTPS (HTTP Secure) — είναι μια επέκταση του πρωτοκόλλου HTTP που προσθέτει ένα επίπεδο κρυπτογράφησης μέσω TLS (Transport Layer Security). Το HTTPS δεν είναι ξεχωριστό πρωτόκολλο — είναι ένας συνδυασμός HTTP και TLS. Τα δεδομένα που μεταδίδονται μέσω HTTPS κρυπτογραφούνται στην πλευρά του πελάτη και αποκρυπτογραφούνται στον διακομιστή, καθιστώντας τα μη προσβάσιμα για υποκλοπή και παραποίηση. Το HTTPS παρέχει επίσης αυθεντικοποίηση διακομιστή μέσω πιστοποιητικών SSL/TLS, εγγυώντας ότι ο πελάτης συνδέεται με τον πραγματικό διακομιστή και όχι με έναν επιτιθέμενο.

Η βασική διαφορά μεταξύ HTTP και HTTPS είναι η ασφάλεια. Το HTTP μεταδίδει δεδομένα σε ανοιχτή μορφή: οποιοσδήποτε κόμβος δικτύου μεταξύ πελάτη και διακομιστή μπορεί να διαβάσει το περιεχόμενο του αιτήματος ή της απόκρισης. Το HTTPS κρυπτογραφεί όλο το περιεχόμενο, συμπεριλαμβανομένων του URL, των κεφαλίδων και του σώματος του αιτήματος, αφήνοντας ορατά μόνο τη διεύθυνση IP του διακομιστή και τη θύρα σύνδεσης. Για εφαρμογές για κινητά που λειτουργούν μέσω δημόσιων δικτύων Wi-Fi, το HTTPS είναι υποχρεωτική απαίτηση ασφάλειας.

Πώς λειτουργεί το HTTP

HTTP — είναι ένα πρωτόκολλο χωρίς κατάσταση (stateless) που λειτουργεί πάνω από TCP/IP. Ο πελάτης δημιουργεί μια σύνδεση TCP με τον διακομιστή (συνήθως στη θύρα 80 για HTTP ή 443 για HTTPS), στέλνει ένα αίτημα HTTP, λαμβάνει μια απόκριση HTTP και κλείνει τη σύνδεση (στο HTTP/1.1 η σύνδεση μπορεί να επαναχρησιμοποιηθεί). Κάθε αλληλεπίδραση μεταξύ πελάτη και διακομιστή αποτελείται από ένα αίτημα και μια απόκριση. Χωρίς κατάσταση σημαίνει ότι ο διακομιστής δεν αποθηκεύει πληροφορίες σχετικά με προηγούμενα αιτήματα του πελάτη — κάθε αίτημα επεξεργάζεται ανεξάρτητα.

Η διαδικασία αλληλεπίδρασης HTTP περιλαμβάνει τα ακόλουθα βήματα:

• Επίλυση DNS — το πρόγραμμα περιήγησης ή ο πελάτης μετατρέπει το όνομα τομέα σε διεύθυνση IP μέσω DNS
• Χειραψία TCP — η σύνδεση TCP δημιουργείται μέσω τριπλής χειραψίας (SYN, SYN-ACK, ACK)
• Χειραψία TLS — για HTTPS, δημιουργείται επιπλέον μια κρυπτογραφημένη σύνδεση (ανταλλαγή πιστοποιητικών και κλειδιών)
• Αίτημα HTTP — ο πελάτης στέλνει τη μέθοδο, το URL, τις κεφαλίδες και προαιρετικά το σώμα του αιτήματος
• Απόκριση HTTP — ο διακομιστής επιστρέφει τον κωδικό κατάστασης, τις κεφαλίδες και το σώμα της απόκρισης

Ένα σημαντικό χαρακτηριστικό του HTTP είναι η αδυναμία επηρεασμού (idempotency) των μεθόδων. Οι GET, HEAD, PUT, DELETE και OPTIONS είναι idempotent: η επαναλαμβανόμενη εκτέλεση του ίδιου αιτήματος δεν αλλάζει την κατάσταση του διακομιστή μετά την πρώτη εκτέλεση. Οι POST, PATCH και CONNECT δεν είναι idempotent — κάθε κλήση μπορεί να δημιουργήσει έναν νέο πόρο ή να αλλάξει την κατάσταση. Για την ανάπτυξη εφαρμογών για κινητά, η κατανόηση της idempotency είναι κρίσιμη: κατά την εκ νέου αποστολή ενός αιτήματος λόγω σφάλματος δικτύου, ο πελάτης πρέπει να γνωρίζει εάν είναι ασφαλές να επαναλάβει το αίτημα.

HTTPS και κρυπτογράφηση TLS

Το HTTPS χρησιμοποιεί το κρυπτογραφικό πρωτόκολλο TLS (Transport Layer Security) για την προστασία των μεταδιδόμενων δεδομένων. Το TLS — διάδοχος του SSL (Secure Sockets Layer), το οποίο αναπτύχθηκε από την εταιρεία Netscape το 1995. Οι εκδόσεις SSL 2.0 και 3.0 θεωρούνται ξεπερασμένες και μη ασφαλείς; οι σύγχρονες εκδόσεις TLS 1.2 (κυκλοφόρησε το 2008) και TLS 1.3 (κυκλοφόρησε το 2018) χρησιμοποιούνται ευρέως. Το TLS 1.3, συγκεκριμένα, μειώνει τον χρόνο δημιουργίας σύνδεσης από 2 round-trips σε 1, γεγονός που επιταχύνει σημαντικά τη φόρτωση σε κινητές συσκευές.

Η διαδικασία χειραψίας TLS (handshake) περιλαμβάνει τα ακόλουθα στάδια:

• Client Hello — ο πελάτης στέλνει μια λίστα υποστηριζόμενων εκδόσεων TLS και σετ κρυπτογράφησης
• Server Hello — ο διακομιστής επιλέγει την έκδοση TLS και το σετ κρυπτογράφησης, στέλνει το πιστοποιητικό SSL/TLS του
• Επαλήθευση πιστοποιητικού — ο πελάτης επαληθεύει το πιστοποιητικό του διακομιστή μέσω της αλυσίδας εμπιστοσύνης έως τη ρίζα CA
• Ανταλλαγή κλειδιών — ο πελάτης και ο διακομιστής δημιουργούν ένα κοινό μυστικό κλειδί (κλειδί συνεδρίας)
• Switch Cipher — και οι δύο πλευρές επιβεβαιώνουν τη μετάβαση στην κρυπτογραφημένη σύνδεση

Η επαλήθευση του πιστοποιητικού SSL/TLS — κρίσιμο στάδιο για την ασφάλεια. Ο πελάτης ελέγχει εάν το πιστοποιητικό: δεν έχει λήξει, είναι υπογεγραμμένο από αξιόπιστη αρχή πιστοποίησης (CA), αντιστοιχεί στον τομέα στο URL και δεν έχει ανακληθεί (μέσω CRL ή OCSP). Σε εφαρμογές για κινητά, συνιστάται η χρήση Certificate Pinning — δέσμευση σε ένα συγκεκριμένο πιστοποιητικό ή δημόσιο κλειδί του διακομιστή. Αυτό αποτρέπει επιθέσεις MITM ακόμη και σε περίπτωση παραβίασης της CA. Ωστόσο, το pinning απαιτεί προσοχή: κατά την αλλαγή πιστοποιητικού, η εφαρμογή πρέπει να ενημερωθεί εκ των προτέρων.

Δομή αιτήματος και απόκρισης HTTP

Το αίτημα HTTP αποτελείται από τρία μέρη: τη γραμμή έναρξης (request line), τις κεφαλίδες (headers) και το προαιρετικό σώμα (body). Η γραμμή έναρξης περιέχει τη μέθοδο HTTP, το URL του αιτήματος και την έκδοση HTTP. Οι κεφαλίδες μεταφέρουν μετα-πληροφορίες: τύπο περιεχομένου, διακριτικά αυθεντικοποίησης, ρυθμίσεις προσωρινής αποθήκευσης. Το σώμα υπάρχει μόνο σε μεθόδους που μεταφέρουν δεδομένα (POST, PUT, PATCH) και απουσιάζει σε GET και DELETE.

Παράδειγμα αιτήματος HTTP σε REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Άννα",
    "email": "anna@example.com"
}

Η απόκριση HTTP έχει ανάλογη δομή: γραμμή έναρξης με την έκδοση HTTP και τον κωδικό κατάστασης, κεφαλίδες και σώμα. Ο κωδικός κατάστασης — ένα τριψήφιο νούμερο που καθορίζει το αποτέλεσμα επεξεργασίας του αιτήματος. Οι κεφαλίδες απόκρισης περιλαμβάνουν Content-Type, Content-Length, Cache-Control, Set-Cookie και άλλες. Το σώμα απόκρισης περιέχει τα ζητούμενα δεδομένα στη μορφή που καθορίζεται στο Content-Type (συνήθως JSON για API, HTML για ιστοσελίδες, εικόνες για περιεχόμενο πολυμέσων).

Οι κεφαλίδες παίζουν κρίσιμο ρόλο στη λειτουργία του HTTP. Το Content-Type και το Accept διαχειρίζονται τη μορφή δεδομένων. Το Authorization μεταφέρει διακριτικά πρόσβασης. Το Cache-Control διαχειρίζεται την προσωρινή αποθήκευση. Οι κεφαλίδες CORS (Access-Control-Allow-Origin) ελέγχουν την πρόσβαση από άλλους τομείς στα προγράμματα περιήγησης. Το User-Agent αναγνωρίζει την εφαρμογή πελάτη. Για εφαρμογές για κινητά, οι κεφαλίδες διαχείρισης προσωρινής αποθήκευσης είναι ιδιαίτερα σημαντικές — μειώνουν τον όγκο των μεταδιδόμενων δεδομένων και βελτιώνουν τη λειτουργία σε ασθενές σήμα.

Κωδικοί κατάστασης HTTP

Οι κωδικοί κατάστασης HTTP ομαδοποιούνται σε πέντε κατηγορίες, που υποδηλώνονται από το πρώτο ψηφίο: 1xx (ενημερωτικοί), 2xx (επιτυχία), 3xx (ανακατεύθυνση), 4xx (σφάλμα πελάτη), 5xx (σφάλμα διακομιστή). Η κατανόηση αυτών των κωδικών είναι απαραίτητη για τη σωστή επεξεργασία αποκρίσεων σε μια εφαρμογή για κινητά: το 2xx σημαίνει επιτυχία και τα δεδομένα μπορούν να εμφανιστούν, το 4xx υποδηλώνει πρόβλημα στο αίτημα (πρέπει να εμφανιστεί σφάλμα στον χρήστη), το 5xx — πρόβλημα στον διακομιστή (το αίτημα πρέπει να επαναληφθεί αργότερα).

Για εφαρμογές για κινητά, ο χειρισμός του κωδικού 401 Unauthorized έχει ιδιαίτερη σημασία. Κατά τη λήψη αυτού του κωδικού, ο πελάτης πρέπει να προσπαθήσει να ανανεώσει το διακριτικό πρόσβασης μέσω Refresh Token και να επαναλάβει το αρχικό αίτημα. Εάν η ανανέωση του διακριτικού επιστρέφει επίσης 401, ο χρήστης πρέπει να ανακατευθυνθεί στην οθόνη σύνδεσης. Αυτή η λογική συνήθως υλοποιείται σε Interceptor (OkHttp) ή στο επίπεδο middleware του δικτυακού πελάτη.

HTTP/1.1, HTTP/2 και HTTP/3

Το HTTP/1.1, που δημοσιεύθηκε το 1999, παραμένει ακόμα μια ευρέως χρησιμοποιούμενη έκδοση του πρωτοκόλλου. Το κύριο μειονέκτημά του — head-of-line blocking: τα αιτήματα προς τον ίδιο διακομιστή εκτελούνται διαδοχικά, κάθε επόμενο περιμένει την ολοκλήρωση του προηγούμενου. Για να παρακάμψουν αυτόν τον περιορισμό, τα προγράμματα περιήγησης ανοίγουν 6–8 παράλληλες συνδέσεις TCP προς τον ίδιο τομέα, γεγονός που αυξάνει το φορτίο του διακομιστή και την κατανάλωση μνήμης. Το HTTP/1.1 μεταδίδει επίσης κεφαλίδες σε μη κρυπτογραφημένη μορφή και δεν υποστηρίζει server push.

Το HTTP/2 (2015) λύνει το πρόβλημα αποκλεισμού μέσω πολυπλεξίας — πολλαπλές ροές δεδομένων μεταδίδονται μέσω μιας σύνδεσης TCP ταυτόχρονα. Ο διακομιστής μπορεί να στέλνει πόρους στον πελάτη πριν ο πελάτης τους ζητήσει (server push). Το HTTP/2 επίσης συμπιέζει τις κεφαλίδες μέσω HPACK, μειώνοντας τον όγκο των μεταδιδόμενων δεδομένων. Για εφαρμογές για κινητά, το HTTP/2 είναι ιδιαίτερα χρήσιμο: μία σύνδεση αντικαθιστά πολλές, μειώνοντας τον χρόνο χειραψίας TLS και την κατανάλωση μπαταρίας.

Το HTTP/3 (2022) — η πιο πρόσφατη έκδοση του πρωτοκόλλου, η οποία χρησιμοποιεί QUIC (Quick UDP Internet Connections) αντί για TCP. Το QUIC λειτουργεί πάνω από UDP, εξαλείφοντας το πρόβλημα head-of-line blocking σε επίπεδο πρωτοκόλλου μεταφοράς. Το HTTP/3 μειώνει τον χρόνο δημιουργίας σύνδεσης σε 0 round-trips στην καλύτερη περίπτωση (σε επαναλαμβανόμενες συνδέσεις) και σε 1 round-trip στην πρώτη σύνδεση, που είναι σημαντικά ταχύτερο από το HTTP/2 με τα 2–3 round-trips του. Για κινητές συσκευές, το HTTP/3 είναι ιδιαίτερα αποτελεσματικό κατά την εναλλαγή μεταξύ Wi-Fi και δικτύου κινητής τηλεφωνίας — η σύνδεση δεν διακόπτεται, επειδή το QUIC χρησιμοποιεί αναγνωριστικό σύνδεσης αντί για διεύθυνση IP.

HTTPS στην ανάπτυξη εφαρμογών για κινητά

Η χρήση HTTPS σε εφαρμογές για κινητά — δεν είναι σύσταση, αλλά υποχρεωτική απαίτηση. Ξεκινώντας από Android 9 (API 28) και iOS 9 (ATS — App Transport Security), όλα τα αιτήματα δικτύου πρέπει από προεπιλογή να χρησιμοποιούν HTTPS. Τα αιτήματα HTTP αποκλείονται από το σύστημα και για την έγκρισή τους απαιτείται ρητή εξαίρεση στη διαμόρφωση της εφαρμογής. Το Google Play Store και το App Store απορρίπτουν εφαρμογές που μεταδίδουν εμπιστευτικά δεδομένα μέσω HTTP, συμπεριλαμβανομένων κωδικών πρόσβασης, διακριτικών και προσωπικών δεδομένων.

Η διαμόρφωση HTTPS σε εφαρμογή για κινητά σε Android περιλαμβάνει:

<!-- AndroidManifest.xml — άδεια για αιτήματα δικτύου -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — διαμόρφωση HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Στο iOS, ανάλογη διαμόρφωση γίνεται μέσω Info.plist με το κλειδί NSAppTransportSecurity. Για τον εντοπισμό σφαλμάτων κυκλοφορίας HTTPS σε εφαρμογές για κινητά, χρησιμοποιούνται εργαλεία διακομιστή μεσολάβησης: Charles Proxy, Proxyman ή mitmproxy. Απαιτούν εγκατάσταση αξιόπιστου πιστοποιητικού SSL στη συσκευή. Σε εκδόσεις παραγωγής, πρέπει να απενεργοποιηθεί η δυνατότητα εντοπισμού σφαλμάτων και να ελεγχθεί ότι το Certificate Pinning είναι σωστά διαμορφωμένο. Η χρήση OkHttp σε Android με το CertificatePinner ή TrustManager σε iOS με SecTrustEvaluate — τυπικές προσεγγίσεις για την υλοποίηση pinning.

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