Εν ολίγοις: Μια στέρεη ρύθμιση TLS για διακομιστές ιστού προσφέρει μόνο TLS 1.2 και TLS 1.3, χρησιμοποιεί cipher suites με Forward Secrecy και πιστοποιημένη κρυπτογράφηση (AES-GCM, ChaCha20-Poly1305) και ένα πιστοποιητικό με κλειδί ECDSA ή RSA επαρκούς μήκους, που ανανεώνεται αυτόματα. Προσανατολισμό δίνουν η οδηγία TR-02102-2 της BSI (Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών της Γερμανίας) και οι συστάσεις Server-Side TLS του TLSRef. Ελέγξτε το αποτέλεσμα από έξω και μην ξεχάσετε τις συνδέσεις που δημιουργεί η ίδια η PHP.
Γιατί οι παλιές ρυθμίσεις TLS επιβιώνουν τόσο πολύ
Το λουκέτο στον browser υπάρχει, άρα η κρυπτογράφηση θεωρείται τακτοποιημένη. Έτσι σκέφτονται πολλοί διαχειριστές και γι' αυτό η ρύθμιση TLS μένει συχνά αμετάβλητη για χρόνια. Προέρχεται τότε από την εποχή της εγκατάστασης του διακομιστή, από ένα αντιγραμμένο πρότυπο ή από τις προεπιλογές ενός πάνελ.
Το πρόβλημα: οι συστάσεις αλλάζουν. Εκδόσεις πρωτοκόλλων αντικαθίστανται, μέθοδοι θεωρούνται αδύναμες, προστίθενται νέες μέθοδοι ανταλλαγής κλειδιών. Η BSI δημοσίευσε την TR-02102 τελευταία φορά στην έκδοση 2026-01 της 27/01/2026 και επισημαίνει εκεί ήδη υβριδικές μεθόδους μετα-κβαντικής κρυπτογραφίας για το TLS 1.3. Όποιος δεν έχει δει τις ρυθμίσεις του εδώ και χρόνια, με μεγάλη πιθανότητα δεν βρίσκεται πια στο τρέχον επίπεδο.
Όποιος ελέγχει ήδη διακομιστές μετά το PHP2Shell, μπορεί να εξετάσει τη ρύθμιση TLS με την ευκαιρία. Δεν κλείνει την ευπάθεια της PHP, ανήκει όμως σε κάθε σωστή σκλήρυνση.
Σε τι βασίζεται μια καλή ρύθμιση TLS για διακομιστές ιστού
Δύο πηγές είναι ιδιαίτερα χρήσιμες για διαχειριστές στη Γερμανία. Η BSI TR-02102 αξιολογεί κρυπτογραφικές μεθόδους· το μέρος 2 πραγματεύεται το TLS. Απευθύνεται κυρίως σε προγραμματιστές και σχεδιαστές και για δημόσιες αρχές και ρυθμιζόμενους τομείς αποτελεί συχνά το μέτρο σύγκρισης. Οι συστάσεις Server-Side TLS, που παλαιότερα τηρούνταν στο wiki της Mozilla, συνεχίζονται σήμερα στο TLSRef και παρέχουν συγκεκριμένα προφίλ έτοιμα για αντιγραφή.
Το TLSRef διακρίνει στην έκδοση 6.0 δύο προφίλ:
| Χαρακτηριστικό | Intermediate (για τους περισσότερους ιστοτόπους) | Modern |
|---|---|---|
| Πρωτόκολλα | TLS 1.2 και TLS 1.3 | μόνο TLS 1.3 |
| Cipher suites TLS 1.2 | ECDHE με AES-GCM ή ChaCha20-Poly1305 | καμία |
| Ομάδες ανταλλαγής κλειδιών | X25519MLKEM768, X25519, prime256v1, secp384r1 | όπως στο Intermediate |
| Πιστοποιητικό | συνιστάται ECDSA P-256 ή RSA 2048 bit | ECDSA P-256 |
| Διάρκεια πιστοποιητικού | συνιστώνται 90 ημέρες, το πολύ 366 ημέρες | 90 ημέρες |
| HSTS max-age | δύο έτη | δύο έτη |
Για δημόσιους ιστότοπους το Intermediate είναι το συνηθισμένο σημείο εκκίνησης. Το προφίλ αποκλείει πολύ παλιές συσκευές, καλύπτει όμως τους τρέχοντες browsers και τα λειτουργικά συστήματα. Η υβριδική ομάδα X25519MLKEM768 προϋποθέτει μια τρέχουσα βιβλιοθήκη TLS. Ελέγξτε αν η έκδοση του OpenSSL σας τη γνωρίζει, προτού τη δηλώσετε.
Nginx και Apache: ένα ασφαλές σημείο εκκίνησης
Τα παρακάτω παραδείγματα υλοποιούν το προφίλ Intermediate. Οι διαδρομές είναι δείγματα, η λίστα των cipher suites ισχύει για το TLS 1.2· το TLS 1.3 φέρνει δικές του, ασφαλείς προεπιλεγμένες μεθόδους.
server {
listen 443 ssl;
server_name www.example.de;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
}
server {
listen 80;
server_name www.example.de;
return 301 https://$host$request_uri;
}
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
Το δεύτερο μπλοκ server ανακατευθύνει μόνιμα τις μη κρυπτογραφημένες κλήσεις στο HTTPS. Η ανακατεύθυνση πρέπει να δείχνει απευθείας στην τελική διεύθυνση και να μην περνά από πολλούς ενδιάμεσους σταθμούς. Ελέγξτε έπειτα και τους ενσωματωμένους πόρους: εικόνες, σενάρια ή γραμματοσειρές που φορτώνονται ακόμη μέσω HTTP προκαλούν προειδοποιήσεις στον browser ή αποκλείονται.
Η ρύθμιση να επιλέγει τη σειρά ο πελάτης ανταποκρίνεται στη σύσταση του TLSRef: όλες οι προσφερόμενες μέθοδοι θεωρούνται ασφαλείς και συσκευές χωρίς επιτάχυνση AES μπορούν έτσι να προτιμήσουν το ChaCha20. Μετά από κάθε αλλαγή δοκιμάστε τη διαμόρφωση (nginx -t ή apachectl configtest) και φορτώστε ξανά την υπηρεσία. Την κατάλληλη κεφαλίδα HSTS και άλλες οδηγίες για τον browser περιγράφει ο οδηγός Κεφαλίδες ασφαλείας για ιστότοπους.
Πάνελ όπως το Plesk ή το cPanel αντικαθιστούν συχνά τις δικές σας αλλαγές σε παραγόμενα αρχεία. Ορίστε εκεί τις οδηγίες TLS μέσω των προβλεπόμενων ρυθμίσεων ή προτύπων του πάνελ.
Πιστοποιητικά: κλειδιά, αλυσίδα, ανανέωση
Ένα μεγάλο μέρος των προβλημάτων TLS στην πράξη δεν έχει σχέση με τα cipher suites, αλλά με τα πιστοποιητικά. Τυπικά σφάλματα είναι μια ελλιπής αλυσίδα, όπου λείπει το ενδιάμεσο πιστοποιητικό, ληγμένα πιστοποιητικά σε δευτερεύοντα domains και ιδιωτικά κλειδιά με υπερβολικά ευρεία δικαιώματα αρχείων.
Τρεις κανόνες βοηθούν:
- Αυτόματη ανανέωση και παρακολούθηση της ανανέωσης. Οι σύντομες διάρκειες ισχύος, όπως τις συνιστά το TLSRef, είναι εφαρμόσιμες μόνο με αυτοματοποίηση.
- Προστασία των ιδιωτικών κλειδιών: αναγνώσιμα μόνο για τον root και τη διεργασία του διακομιστή ιστού, ποτέ στο webroot, ποτέ σε αποθετήριο.
- Καταγραφή όλων των ονομάτων: κύριο domain, www, υποτομείς για κατάστημα, staging, διεπαφή web αλληλογραφίας και πάνελ.
Όποιος χρησιμοποιεί πιστοποιητικά σε πολλά σημεία, για παράδειγμα σε CDN, load balancer και διακομιστή προέλευσης, πρέπει να τηρεί μια επισκόπηση: ποιο πιστοποιητικό είναι εγκατεστημένο πού, ποιος το ανανεώνει και πότε λήγει. Αν λείπει αυτή η επισκόπηση, ένα ληγμένο πιστοποιητικό γίνεται συχνά αντιληπτό μόνο όταν επικοινωνήσουν οι πελάτες.
Πώς ελέγχετε τη ρύθμισή σας από έξω
Οι παρακάτω εντολές είναι καθαροί έλεγχοι και δεν αλλάζουν τίποτα. Αντικαταστήστε το hostname με το δικό σας:
# Το TLS 1.3 και το TLS 1.2 πρέπει να λειτουργούν
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# Το TLS 1.1 πρέπει να αποτυγχάνει
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Διάρκεια ισχύος και κάτοχος του πιστοποιητικού που παραδίδεται
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Μια αποτυχία στη δοκιμή TLS 1.1 μπορεί να οφείλεται και στο ότι η τοπική σας έκδοση OpenSSL δεν προσφέρει πια καθόλου το παλιό πρωτόκολλο. Για μια πλήρη αναφορά σε όλες τις προσφερόμενες μεθόδους ταιριάζει ένας εξειδικευμένος σαρωτής TLS. Ελέγξτε κάθε υποτομέα ξεχωριστά, γιατί συχνά λειτουργούν με δικές τους ρυθμίσεις.
Το ξεχασμένο σημείο: TLS εκεί όπου η ίδια η PHP είναι πελάτης
Οι εφαρμογές PHP δημιουργούν οι ίδιες πολλές συνδέσεις: προς παρόχους πληρωμών, εταιρείες μεταφοράς, διεπαφές, διακομιστές αλληλογραφίας και βάσεις δεδομένων. Εδώ το πιο συχνό σφάλμα δεν είναι μια αδύναμη ρύθμιση, αλλά ένας απενεργοποιημένος έλεγχος του πιστοποιητικού, συχνά ως γρήγορη λύση σε ένα πρόβλημα στην ανάπτυξη.
<?php
// Ασφαλές: ελέγχονται το πιστοποιητικό και το όνομα του hostname (διατηρήστε την προεπιλεγμένη συμπεριφορά)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_SSL_VERIFYHOST => 2,
CURLOPT_TIMEOUT => 10,
]);
$antwort = curl_exec($ch);
Αναζητήστε στον κώδικα το CURLOPT_SSL_VERIFYPEER με τιμή false και το verify_peer σε stream contexts. Κάθε εύρημα καταργεί στην πράξη την προστασία του TLS για αυτή τη σύνδεση. Όπου οι υπηρεσίες βρίσκονται πίσω από ένα CDN, και η διαδρομή ανάμεσα στο CDN και τον διακομιστή προέλευσης πρέπει να χρησιμοποιεί ένα έγκυρο, ελεγμένο πιστοποιητικό. Περισσότερες ρυθμίσεις διακομιστή ιστού για περιβάλλοντα PHP θα βρείτε στο Ασφαλής διαμόρφωση του Nginx για PHP, μέτρα σύγκρισης για ολόκληρη τη σκλήρυνση στο Οδηγοί CIS Benchmarks και ενότητες BSI.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Καταγράφουμε όλα τα hostnames και τις υπηρεσίες με TLS, συμπεριλαμβανομένων πάνελ, staging και διεπαφών web αλληλογραφίας.
- Συγκρίνουμε τις ρυθμίσεις με την TR-02102 και το κατάλληλο προφίλ TLSRef και τεκμηριώνουμε τις συνειδητές αποκλίσεις.
- Μεταφέρουμε τα πιστοποιητικά σε αυτόματη ανανέωση με παρακολούθηση.
- Αναζητούμε στον κώδικα της εφαρμογής απενεργοποιημένους ελέγχους πιστοποιητικών και δείχνουμε τη διόρθωση.
Το TLS είναι μία από τις ενότητες της σκλήρυνσης διακομιστή για διακομιστές ιστού PHP· τη σχέση με την τρέχουσα κατάσταση εξηγεί το Τι είναι το PHP2Shell;.
Συχνές ερωτήσεις
Πρέπει να προσφέρω ακόμη TLS 1.0 και TLS 1.1;
Κατά κανόνα όχι. Οι τρέχουσες συστάσεις, όπως το προφίλ Intermediate του TLSRef, ορίζουν το TLS 1.2 ως κατώτατο όριο. Όποιος χρειάζεται παλαιότερα πρωτόκολλα για παλιές συσκευές, πρέπει να το αποφασίσει συνειδητά, να το τεκμηριώσει και να το περιορίσει σε ξεχωριστή υπηρεσία.
Είναι ένα δωρεάν πιστοποιητικό λιγότερο ασφαλές από ένα αγορασμένο;
Για την κρυπτογράφηση δεν κάνει διαφορά. Αποφασιστικά είναι ο τύπος και το μήκος του κλειδιού, μια πλήρης αλυσίδα πιστοποιητικών και μια αξιόπιστη αυτόματη ανανέωση. Διαφορές υπάρχουν στην έκταση του ελέγχου, στη διάρκεια ισχύος και στην εξυπηρέτηση του παρόχου.
Αρκεί το HTTPS ανάμεσα στον επισκέπτη και το CDN;
Όχι. Και η σύνδεση ανάμεσα στο CDN και τον διακομιστή προέλευσης πρέπει να είναι κρυπτογραφημένη και να ελέγχει το πιστοποιητικό της προέλευσης. Διαφορετικά, στο δεύτερο τμήμα της διαδρομής τα δεδομένα κινούνται στο δίκτυο μη κρυπτογραφημένα ή χωρίς έλεγχο.
Τι σχέση έχει το TLS με το PHP2Shell;
Άμεσα καμία. Το TLS προστατεύει δεδομένα στη διαδρομή μεταφοράς, ενώ το PHP2Shell αφορά τον διερμηνέα PHP στον διακομιστή. Μια κρυπτογραφημένη σύνδεση μεταφέρει αξιόπιστα και αιτήματα επίθεσης, γι' αυτό η ενημέρωση της PHP παραμένει υποχρεωτική ανεξάρτητα από αυτό.