Πώς να ρυθμίσετε το HSTS χωρίς να αποκλείσετε τον εαυτό σας

Το HSTS είναι απλό μέχρι να μην είναι

Το HTTP Strict Transport Security, συνήθως συντομευμένο ως HSTS, λέει στους browsers: «για αυτόν τον ιστότοπο, να χρησιμοποιείτε πάντα HTTPS». Μόλις ένας browser λάβει την κεφαλίδα μέσω έγκυρης σύνδεσης HTTPS, θυμάται τον κανόνα για τη διάρκεια που ορίζετε.

Αυτό είναι χρήσιμο. Αποτρέπει επιθέσεις υποβάθμισης πρωτοκόλλου, μειώνει τα τυχαία μη ασφαλή αιτήματα και αποφεύγει την αμήχανη στιγμή όπου ένας χρήστης πληκτρολογεί example.com και ακουμπά για λίγο το απλό HTTP πριν ανακατευθυνθεί.

Είναι επίσης επίμονο. Αν δημοσιεύσετε λάθος πολιτική HSTS, οι browsers μπορεί να συνεχίσουν να την επιβάλλουν πολύ αφότου αφαιρέσετε την κεφαλίδα από τον server σας. Έτσι οι ομάδες αποκλείουν τον εαυτό τους: όχι ακριβώς από το δικό τους admin panel, αλλά από τους browsers των χρηστών, τα subdomains, τα staging συστήματα, τα legacy endpoints και τις ξεχασμένες υπηρεσίες που δεν είναι έτοιμες για υποχρεωτικό HTTPS.

Ο στόχος δεν είναι να αποφύγετε το HSTS. Ο στόχος είναι να το αναπτύξετε σαν migration, όχι σαν διακόπτη.

Τι κάνει στην πράξη η κεφαλίδα HSTS

Μια τυπική κεφαλίδα HSTS μοιάζει με αυτό:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Έχει τρία σημαντικά μέρη:

• max-age: για πόσο χρόνο, σε δευτερόλεπτα, ο browser πρέπει να επιβάλλει HTTPS για αυτόν τον host.
• includeSubDomains: αν ο κανόνας ισχύει επίσης για κάθε subdomain.
• preload: ένα σήμα ότι θέλετε το domain να συμπεριληφθεί στις λίστες preload των browsers.

Ο browser εμπιστεύεται αυτή την κεφαλίδα μόνο όταν τη λαμβάνει μέσω έγκυρου HTTPS. Αν το πιστοποιητικό είναι άκυρο, ληγμένο ή δεν ταιριάζει, ο browser δεν θα πρέπει να αποδεχθεί νέα πολιτική HSTS από αυτή την απόκριση.

Μόλις αποθηκευτεί η πολιτική, οι μελλοντικές προσπάθειες επίσκεψης στο http://example.com αναβαθμίζονται από τον browser σε https://example.com πριν σταλεί το αίτημα. Αυτό είναι το κέρδος για το απόρρητο: το μη ασφαλές αίτημα δεν φεύγει ποτέ από τη συσκευή.

Τα σενάρια αποκλεισμού που πρέπει να αποφύγετε

Οι περισσότερες αστοχίες HSTS δεν προκαλούνται από τον κύριο ιστότοπο. Συμβαίνουν στα άκρα.

1. Ένα ξεχασμένο subdomain δεν είναι έτοιμο για HTTPS

Το includeSubDomains ακούγεται τακτοποιημένο, αλλά είναι απόλυτο. Αν το ορίσετε στο example.com, ισχύει για:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• οτιδήποτε άλλο κάτω από αυτό το domain

Αν κάποιος από αυτούς τους hosts δεν μπορεί να εξυπηρετήσει έγκυρο HTTPS, οι χρήστες που έχουν αποθηκευμένη την πολιτική HSTS δεν θα μπορούν να τον φτάσουν μέσω HTTP.

2. Ένα πιστοποιητικό λήγει

Χωρίς HSTS, οι χρήστες μερικές φορές παρακάμπτουν προειδοποιήσεις πιστοποιητικού. Αυτό δεν είναι καλή πρακτική ασφάλειας, αλλά συμβαίνει.

Με HSTS, οι σύγχρονοι browsers δεν επιτρέπουν εύκολη παράκαμψη σφαλμάτων πιστοποιητικού για αυτόν τον host. Αυτό είναι το ζητούμενο. Σημαίνει επίσης ότι η ανανέωση πιστοποιητικών πρέπει να είναι βαρετή, παρακολουθούμενη και δοκιμασμένη.

3. Staging ή εσωτερικά εργαλεία βρίσκονται κάτω από το production domain

Η τοποθέτηση εσωτερικών εργαλείων κάτω από *.example.com μπορεί να γίνει επίπονη μόλις το γονικό domain χρησιμοποιήσει includeSubDomains. Αν αυτά τα εργαλεία χρησιμοποιούν αυτο-υπογεγραμμένα πιστοποιητικά, ιδιωτικές αρχές πιστοποίησης, παλιές ρυθμίσεις TLS ή καθόλου HTTPS, το HSTS θα αποκαλύψει την παράκαμψη.

Αυτός είναι ένας λόγος για τον οποίο πολλές ομάδες κρατούν τα εσωτερικά και πειραματικά συστήματα κάτω από ξεχωριστό domain που έχει τη δική του πολιτική ασφάλειας.

4. Το preload αντιμετωπίζεται ως τυπικό checkbox

Το HSTS preload δεν είναι απλώς άλλη μία directive. Σημαίνει ότι το domain σας μπορεί να διανεμηθεί μέσα στους browsers ως HTTPS-only πριν οποιοσδήποτε χρήστης επισκεφθεί τον ιστότοπό σας.

Αυτό κλείνει το κενό της «πρώτης επίσκεψης», αλλά είναι πολύ πιο δύσκολο να αναιρεθεί. Η αφαίρεση από τις λίστες preload μπορεί να χρειαστεί εβδομάδες ή μήνες για να φτάσει στους χρήστες, ανάλογα με τους κύκλους κυκλοφορίας των browsers. Το preload είναι κατάλληλο για σταθερά, ώριμα domains. Δεν είναι κατάλληλο για έναν ιστότοπο που ακόμη ανακαλύπτει το inventory των subdomains του.

Ένα ασφαλές σχέδιο διάθεσης

Βήμα 1: Ελέγξτε κάθε hostname που ελέγχετε

Πριν ορίσετε includeSubDomains, καταγράψτε κάθε hostname κάτω από το domain. Οι εγγραφές DNS είναι μια αρχή, αλλά όχι όλη η ιστορία. Ελέγξτε ρυθμίσεις CDN, dashboards φιλοξενίας, hostnames που σχετίζονται με email, παλιά εργαλεία marketing, storage buckets και εσωτερική τεκμηρίωση.

Για κάθε hostname, απαντήστε:

• Εξυπηρετεί HTTP, HTTPS ή και τα δύο;
• Είναι το πιστοποιητικό HTTPS έγκυρο και ανανεώνεται αυτόματα;
• Ανακατευθύνει το HTTP σε HTTPS καθαρά;
• Προορίζεται να είναι δημόσιο;
• Χρειάζεται ακόμα;

Αν η ομάδα σας έχει ήδη συνήθειες debugging για production headers, αυτό ταιριάζει φυσικά δίπλα στους ελέγχους ανακατευθύνσεων και κεφαλίδων. Καλύψαμε αυτή τη ροή εργασίας σε ένα μικρό toolkit για debugging ανακατευθύνσεων και HTTP headers σε production.

Βήμα 2: Διορθώστε το HTTPS πριν προσθέσετε HSTS

Το HSTS δεν κάνει μια χαλασμένη ρύθμιση HTTPS ασφαλή. Απλώς κάνει το HTTPS υποχρεωτικό.

Πριν το ενεργοποιήσετε, επαληθεύστε:

• Τα πιστοποιητικά TLS καλύπτουν τα σωστά hostnames.
• Τα πιστοποιητικά ανανεώνονται αυτόματα.
• Το HTTP ανακατευθύνει σε HTTPS με ένα μόνο καθαρό hop όπου είναι δυνατό.
• Οι ανακατευθύνσεις canonical host είναι συνεπείς, για παράδειγμα από non-www σε www, ή το αντίστροφο.
• Τα assets της εφαρμογής δεν εξαρτώνται από μη ασφαλή URLs http://.

Το mixed content είναι λιγότερο συχνό από ό,τι ήταν παλιότερα, αλλά εξακολουθεί να εμφανίζεται σε παλιά CMS themes, analytics snippets, ενσωματωμένα media και hard-coded διαδρομές εικόνων.

Βήμα 3: Ξεκινήστε με πολύ σύντομο max-age

Μην ξεκινήσετε με έναν χρόνο. Ξεκινήστε με πέντε λεπτά:

Strict-Transport-Security: max-age=300

Αναπτύξτε το μόνο στο hostname που δοκιμάζετε, συνήθως τον canonical production ιστότοπο. Αφήστε έξω το includeSubDomains προς το παρόν.

Στη συνέχεια δοκιμάστε σε πραγματικούς browsers και με αιτήματα γραμμής εντολών:

curl -I https://example.com

Θα πρέπει να βλέπετε ακριβώς μία κεφαλίδα Strict-Transport-Security. Διπλές κεφαλίδες HSTS από έναν app server και ένα CDN είναι συνηθισμένη πηγή σύγχυσης. Οι browsers γενικά εφαρμόζουν την αποτελεσματική πολιτική, αλλά οι άνθρωποι που κάνουν debugging σε ένα incident δεν χρειάζονται ασάφεια.

Βήμα 4: Αυξήστε σταδιακά

Αν δεν σπάσει τίποτα, αυξήστε τη διάρκεια σε στάδια:

Strict-Transport-Security: max-age=86400

Μετά:

Strict-Transport-Security: max-age=604800

Ίσως μετά:

Strict-Transport-Security: max-age=2592000

Ένα πρακτικό χρονοδιάγραμμα είναι:

• 5 λεπτά
• 1 ημέρα
• 1 εβδομάδα
• 1 μήνας
• 6 μήνες ή 1 έτος

Δεν υπάρχει βραβείο για τη βιασύνη. Ολόκληρο το νόημα της σταδιακής διάθεσης είναι να δώσετε στο monitoring, στο support inbox και στις οριακές περιπτώσεις χρόνο να σας πουν τι έχασε το checklist σας.

Βήμα 5: Προσθέστε includeSubDomains μόνο αφού ο έλεγχος είναι πραγματικός

Μόλις κάθε δημόσιο subdomain είναι έτοιμο για HTTPS, μπορείτε να εξετάσετε:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Αυτή είναι η στιγμή να είστε συντηρητικοί. Αν μία legacy υπηρεσία εξακολουθεί να χρειάζεται HTTP, μην προσθέσετε includeSubDomains στο γονικό domain. Είτε μεταφέρετε αυτή την υπηρεσία, είτε μετακινήστε την σε άλλο domain, είτε αποδεχθείτε ότι η πολιτική HSTS σας πρέπει να παραμείνει πιο στενή προς το παρόν.

Οι κεφαλίδες ασφάλειας πρέπει να αντικατοπτρίζουν την πραγματικότητα. Δεν πρέπει να χρησιμοποιούνται ως motivational posters για υποδομή που ελπίζετε να έχετε αργότερα.

Βήμα 6: Αντιμετωπίστε το preload ως ξεχωριστό έργο

Εξετάστε το preload μόνο όταν ισχύουν όλα τα παρακάτω:

• Το domain και όλα τα subdomains υποστηρίζουν έγκυρο HTTPS.
• Το HTTP ανακατευθύνει σε HTTPS.
• Η κεφαλίδα HSTS χρησιμοποιεί max-age τουλάχιστον 31536000 δευτερολέπτων.
• Η κεφαλίδα περιλαμβάνει includeSubDomains.
• Η κεφαλίδα περιλαμβάνει preload.
• Είστε βέβαιοι ότι δεν θα χρειαστείτε plain HTTP πουθενά κάτω από το domain.

Μια κεφαλίδα έτοιμη για preload μοιάζει με αυτό:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Η υποβολή στη λίστα preload είναι μακροπρόθεσμη δέσμευση. Αν ο ιστότοπος είναι campaign microsite, προσωρινό product domain ή domain με ασαφή όρια ιδιοκτησίας, παραλείψτε το.

Παραδείγματα ρύθμισης

Nginx

Χρησιμοποιήστε always ώστε η κεφαλίδα να αποστέλλεται και σε αποκρίσεις σφάλματος:

add_header Strict-Transport-Security "max-age=300" always;

Αφού η διάθεση σταθεροποιηθεί:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Με ενεργοποιημένο το mod_headers:

Header always set Strict-Transport-Security "max-age=300"

Αργότερα:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN ή edge platform

Αν το CDN σας ορίζει κεφαλίδες απόκρισης, προτιμήστε να διαχειρίζεστε το HSTS σε ένα σημείο. Μην ορίζετε μία πολιτική στο origin και άλλη στο edge, εκτός αν έχετε πολύ σαφή λόγο.

Ελέγξτε επίσης αν το CDN εφαρμόζει κεφαλίδες σε ανακατευθύνσεις, cached errors και προσαρμοσμένες σελίδες σφάλματος. Ένας production ιστότοπος δεν είναι μόνο η απόκρισή του 200 OK.

Πώς να αναιρέσετε το HSTS με ασφάλεια

Αν χρειάζεται να απενεργοποιήσετε το HSTS, στείλτε:

Strict-Transport-Security: max-age=0

Υπάρχει όμως μια παγίδα: ο browser πρέπει να φτάσει επιτυχώς στον ιστότοπο μέσω έγκυρου HTTPS για να λάβει αυτή την κεφαλίδα. Αν το ίδιο το HTTPS είναι χαλασμένο, οι χρήστες με αποθηκευμένη πολιτική HSTS δεν μπορούν να λάβουν την οδηγία που θα την καθάριζε.

Άρα η συνηθισμένη σειρά ανάκαμψης είναι:

1. Επαναφέρετε έγκυρο HTTPS.
2. Εξυπηρετήστε Strict-Transport-Security: max-age=0.
3. Κρατήστε το στη θέση του αρκετό χρόνο ώστε οι χρήστες που επιστρέφουν να το λάβουν.
4. Αφαιρέστε ή αντικαταστήστε την κεφαλίδα αφού επιλυθεί το incident.

Αν το domain είναι preloaded, η εξυπηρέτηση max-age=0 δεν αρκεί για νέα προφίλ browser. Πρέπει επίσης να ζητήσετε αφαίρεση από τη λίστα preload και να περιμένετε να διανεμηθεί αυτή η αλλαγή μέσω ενημερώσεων των browsers.

Checklist δοκιμών πριν το διαθέσετε

Χρησιμοποιήστε αυτό το checklist πριν αυξήσετε το max-age ή προσθέσετε includeSubDomains:

• Το canonical HTTPS URL επιστρέφει έγκυρο πιστοποιητικό.
• Το HTTP ανακατευθύνει σε HTTPS.
• Υπάρχει μόνο μία κεφαλίδα HSTS.
• Η κεφαλίδα εμφανίζεται σε ανακατευθύνσεις και αποκρίσεις σφάλματος όπου είναι κατάλληλο.
• Όλα τα δημόσια subdomains έχουν έγκυρο HTTPS.
• Η ανανέωση πιστοποιητικών παρακολουθείται.
• Κανένα κρίσιμο εσωτερικό σύστημα δεν εξαρτάται από HTTP κάτω από το ίδιο γονικό domain.
• Το preload έχει συζητηθεί ρητά, όχι προστεθεί από συνήθεια.

Το Lighthouse μπορεί επίσης να επισημάνει ελλιπείς ή αδύναμες κεφαλίδες ασφάλειας σε ορισμένα πλαίσια, αλλά δεν πρέπει να είναι η μόνη μέθοδος επαλήθευσής σας. Αν το χρησιμοποιείτε ως μέρος ενός ευρύτερου review, διαβάστε τα ευρήματα ως σήματα και όχι ως ετυμηγορίες· η ίδια νοοτροπία ισχύει όταν διαβάζετε ένα Lighthouse report χωρίς πανικό.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Πριν και μετά από κάθε αλλαγή HSTS, ελέγξτε την απόκριση Strict-Transport-Security με το Get Headers, για να επιβεβαιώσετε ότι τα max-age, includeSubDomains και preload είναι όπως τα περιμένετε.

<!-- tool-cta:end -->

Η υπόθεση απορρήτου υπέρ του HSTS

Το HSTS συχνά παρουσιάζεται ως κεφαλίδα ασφάλειας, και είναι. Έχει επίσης όφελος για το απόρρητο: μειώνει την πιθανότητα το πρώτο αίτημα ενός χρήστη να διαρρεύσει μέσω απλού HTTP σε μη έμπιστο δίκτυο.

Αυτό έχει σημασία σε airport Wi-Fi, δίκτυα ξενοδοχείων, εταιρικά guest networks και οπουδήποτε η κίνηση ενός χρήστη μπορεί να παρατηρηθεί ή να τροποποιηθεί. Ένα απλό αίτημα HTTP μπορεί να αποκαλύψει το hostname, το path, cookies χωρίς τη σημαία Secure και άλλες λεπτομέρειες του αιτήματος. Το HTTPS δεν είναι μαγεία, αλλά η συνεπής επιβολή του αφαιρεί μια ολόκληρη κατηγορία αποφεύξιμης διαρροής.

Οι καλύτερες υλοποιήσεις HSTS είναι αδιάφορες. Διατίθενται αργά, υποστηρίζονται από αξιόπιστα πιστοποιητικά και είναι αρκετά βαρετές ώστε να μην τις προσέχει κανείς. Αυτό ακριβώς θέλετε από μια κεφαλίδα της οποίας ο τρόπος αστοχίας μπορεί να είναι δραματικός.