Κρυπτογραφημένη παράδοση: TLS, MTA-STS και DANE

Ενότητα 5: Φήμη και οι μεγάλοι πάροχοι · Χρόνος ανάγνωσης: 10 λεπτά

Στόχος μαθήματος: Μετά από αυτό το μάθημα θα μπορείτε να εξηγήσετε πώς κρυπτογραφούν μεταξύ τους οι mail servers, γιατί αυτό δεν είναι εξ ορισμού υποχρεωτικό, και τι αλλάζουν σε αυτό το MTA-STS, το TLS-RPT και το DANE. Θα μπορείτε να αναζητήσετε και να διαβάσετε τα records.

Βασικές έννοιες: STARTTLS μεταξύ servers, ευκαιριακή κρυπτογράφηση, επίθεση υποβάθμισης (downgrade), MTA-STS (RFC 8461), record _mta-sts, αρχείο πολιτικής, λειτουργία testing/enforce/none, TLS-RPT (RFC 8460), record _smtp._tls, DANE για SMTP (RFC 7672), record TLSA, DNSSEC

Δύο είδη συνδέσεων

Στο μάθημα 1.4 μιλήσαμε για τη σύνδεση μεταξύ του προγράμματος email σας και του mail server του παρόχου σας: θύρα 587 με STARTTLS, ή 465 με απευθείας TLS, με σύνδεση μέσω κωδικού. Εκεί έχετε εσείς τον έλεγχο. Το πρόγραμμά σας γνωρίζει ποιον server περιμένει, ελέγχει το πιστοποιητικό και αρνείται να συνδεθεί αν κάτι δεν είναι σωστό.

Αυτό το μάθημα αφορά το επόμενο βήμα: τη σύνδεση μεταξύ του server αποστολής και του server παραλαβής, στη θύρα 25. Εκεί τα πράγματα λειτουργούν διαφορετικά.

Ευκαιριακά: κρυπτογράφηση όταν είναι δυνατή

Όταν ένας server παραδίδει mail, συνδέεται με τον MX του παραλήπτη. Μετά το EHLO, ελέγχει αν ο server παραλαβής προσφέρει STARTTLS. Αν ναι, μεταβαίνει σε κρυπτογραφημένη σύνδεση. Αν όχι, παραδίδει το mail απλώς μη κρυπτογραφημένο.

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

Γιατί έτσι; Επειδή το email πρέπει πάντα να λειτουργεί, ακόμη και με παλιούς servers. Ένας αποστολέας δεν μπορεί να γνωρίζει αν ένας παραλήπτης οφείλει να διαθέτει TLS. Αυτό καθιστά δυνατές δύο επιθέσεις:

1. Υποβάθμιση (downgrade). Κάποιος που μπορεί να τροποποιήσει την κίνηση στη διαδρομή, αφαιρεί τη λέξη STARTTLS από την απάντηση του παραλήπτη. Ο αποστολέας νομίζει ότι δεν υπάρχει κρυπτογράφηση και παραδίδει μη κρυπτογραφημένα. Ο επιτιθέμενος διαβάζει μαζί.
2. Ψεύτικος MX. Κάποιος που μπορεί να παραποιήσει απαντήσεις DNS, δηλώνει τον δικό του server ως MX. Επειδή το πιστοποιητικό δεν ελέγχεται, ο αποστολέας δεν αντιλαμβάνεται τίποτα.

Σήμερα σχεδόν όλοι οι μεγάλοι mail servers κρυπτογραφούν, και το Gmail απαιτεί από τους αποστολείς να χρησιμοποιούν TLS (μάθημα 5.3). Αλλά το "συνήθως κρυπτογραφημένο" είναι διαφορετικό από το "πάντα και με τον σωστό server". Για αυτό υπάρχουν δύο λύσεις: το MTA-STS και το DANE. Και οι δύο ρυθμίζονται από τον παραλήπτη: με αυτές δηλώνετε ότι το mail προς το domain σας πρέπει πάντα να είναι κρυπτογραφημένο, σε έναν server με έγκυρο πιστοποιητικό.

MTA-STS: πολιτική μέσω μιας ιστοσελίδας

Το MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) λειτουργεί με δύο στοιχεία.

Ένα record TXT που δηλώνει ότι υπάρχει πολιτική:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Και ένα αρχείο πολιτικής σε σταθερή θέση, μέσω https με έγκυρο πιστοποιητικό:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Το έξυπνο σημείο: ένας αποστολέας θυμάται την πολιτική για τη διάρκεια του max_age. Ένας επιτιθέμενος που αργότερα αφαιρεί τη λέξη STARTTLS ή δηλώνει ψεύτικο MX, αποκαλύπτεται τότε: η πολιτική δηλώνει ότι η κρυπτογράφηση είναι υποχρεωτική και ποιοι servers είναι έγκυροι. Στην πρώτη ακριβώς σύνδεση (πριν γίνει γνωστή η πολιτική) το MTA-STS δεν προστατεύει· αυτό είναι το γνωστό αδύναμο σημείο.

Ένα πραγματικό παράδειγμα είναι το gmail.com: το record TXT _mta-sts.gmail.com υπάρχει, και το αρχείο πολιτικής στο https://mta-sts.gmail.com/.well-known/mta-sts.txt έχει mode: enforce.

TLS-RPT: αναφορές για αποτυχημένη κρυπτογράφηση

Με το MTA-STS σε enforce, το mail μπορεί να παραμείνει σε αναμονή αν κάτι δεν πάει καλά με το πιστοποιητικό σας. Θέλετε να το γνωρίζετε αυτό. Για αυτό υπάρχει το TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Οι αποστολείς που υποστηρίζουν TLS-RPT (μεταξύ άλλων η Google και η Microsoft), στέλνουν τότε καθημερινά μια αναφορά σε μορφή JSON: πόσες συνδέσεις πέτυχαν και ποιες απέτυχαν, με την αιτία (για παράδειγμα ένα ληγμένο πιστοποιητικό ή ένα όνομα που δεν βρίσκεται στην πολιτική). Όπως και με τις αναφορές DMARC (μάθημα 4.5), μπορείτε να τις αναθέσετε για επεξεργασία σε μια υπηρεσία αναφορών.

Σειρά εισαγωγής: πρώτα το TLS-RPT, μετά το MTA-STS σε testing, μερικές εβδομάδες ανάγνωση αναφορών, και μόνο έπειτα το enforce. Αυτό μοιάζει με τη συμβουλευτική γραμμή του DMARC: πρώτα παρατήρηση, μετά αυστηρότητα.

DANE: το πιστοποιητικό στο DNS, ασφαλισμένο με DNSSEC

Το DANE (DNS-based Authentication of Named Entities) το αντιμετωπίζει διαφορετικά. Τοποθετείτε στο DNS ένα record TLSA για κάθε MX server, με ένα αποτύπωμα (fingerprint) του πιστοποιητικού ή του κλειδιού:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

Το _25._tcp σημαίνει: για SMTP στη θύρα 25. Οι τρεις αριθμοί δηλώνουν πώς πρέπει να διαβαστεί η τιμή. Για mail servers, το 3 1 1 είναι το πιο συχνά χρησιμοποιούμενο: "αυτό είναι το αποτύπωμα SHA-256 του δημόσιου κλειδιού ακριβώς αυτού του server". Εμφανίζεται επίσης το 2 1 1: τότε περιέχει το αποτύπωμα ενός ενδιάμεσου πιστοποιητικού.

Ένας αποστολέας που υποστηρίζει DANE, βλέπει το record TLSA, απαιτεί κρυπτογράφηση και ελέγχει αν το πιστοποιητικό του server ταιριάζει. Αν δεν ταιριάζει, δεν παραδίδει.

Γιατί το DANE είναι ασφαλές απέναντι σε πλαστές απαντήσεις DNS; Επειδή λειτουργεί μόνο με το DNSSEC (μάθημα 8.1 του μαθήματος DNS). Χωρίς έγκυρη αλυσίδα DNSSEC, τα records TLSA αγνοούνται. Αυτό είναι ταυτόχρονα το εμπόδιο: τόσο το domain σας (για το MX) όσο και η ζώνη του mail server πρέπει να είναι υπογεγραμμένα.

Το DANE δεν έχει την αδυναμία "πρώτης φοράς" όπως το MTA-STS, και χρησιμοποιείται ευρέως στην Ολλανδία και τη Γερμανία. Το internet.nl το ελέγχει. Η Microsoft υποστηρίζει το DANE για εισερχόμενο mail στο Exchange Online. Επίσης οι MX servers του internet.nl διαθέτουν records TLSA.

Παγίδα: αν αντικαταστήσετε το πιστοποιητικό ενός mail server με DANE με ένα νέο κλειδί, το record TLSA πρέπει να αλλάξει μαζί, και μάλιστα εκ των προτέρων: πρώτα προσθέτετε το νέο record, περιμένετε να παρέλθει το TTL, και μόνο τότε θέτετε το νέο κλειδί σε χρήση. Διαφορετικά οι αποστολείς με DANE θα απορρίψουν το mail σας. Στο 3 1 1 αυτό ισχύει μόνο όταν αλλάζει το κλειδί, όχι σε κάθε ανανέωση με το ίδιο κλειδί.

MTA-STS ή DANE;

Μπορείτε να τα χρησιμοποιήσετε παράλληλα. Το RFC 8461 δηλώνει ότι ένας αποστολέας που υποστηρίζει DANE, δίνει προτεραιότητα στο DANE όταν υπάρχουν έγκυρα records TLSA.

Ποιος το ρυθμίζει αυτό;

Αυτό το ρυθμίζετε για το εισερχόμενο mail στο domain σας. Αν το mail σας λειτουργεί μέσω μιας εταιρείας hosting ή υπηρεσίας mail, τότε εξαρτάται από αυτόν τον φορέα:

• Το DANE είναι δυνατό μόνο αν ο πάροχος δημοσιεύει records TLSA για τους mail servers του και το domain σας διαθέτει DNSSEC. Στο WebOké μπορείτε για παράδειγμα να ενεργοποιήσετε το DANE στο ίδιο σημείο με το DNSSEC (δείτε το άρθρο του internet.nl παρακάτω)· σε άλλους παρόχους λειτουργεί παρόμοια ή είναι ρυθμισμένο εξ ορισμού.
• Το MTA-STS μπορείτε μερικές φορές να το ρυθμίσετε μόνοι σας, αλλά τότε το mta-sts.example.com πρέπει να είναι μια ιστοσελίδα με έγκυρο πιστοποιητικό και πρέπει να γνωρίζετε τα ονόματα MX του παρόχου σας.
• Το TLS-RPT μπορείτε πάντα να το ρυθμίσετε μόνοι σας: είναι απλώς ένα record TXT με μια διεύθυνση αναφοράς.

Για το εξερχόμενο mail σας δεν χρειάζεται να κάνετε τίποτα: ο server του παρόχου σας αποφασίζει αν σέβεται το MTA-STS και το DANE των παραληπτών.

Σύνοψη

• Μεταξύ mail servers, το TLS είναι εξ ορισμού ευκαιριακό: κρυπτογραφημένο όταν είναι δυνατό, χωρίς αυστηρό έλεγχο πιστοποιητικού. Αυτό καθιστά δυνατή την υποβάθμιση και τον ψεύτικο MX.
• MTA-STS: TXT _mta-sts συν αρχείο πολιτικής στο https://mta-sts.<domain>/.well-known/mta-sts.txt· λειτουργία testing ή enforce.
• TLS-RPT: TXT _smtp._tls με διεύθυνση αναφοράς, για καθημερινές αναφορές σχετικά με αποτυχημένη κρυπτογράφηση.
• DANE: record TLSA στο _25._tcp.<mx-server>, λειτουργεί μόνο με DNSSEC και προστατεύει και την πρώτη σύνδεση.
• Εισαγωγή όπως το DMARC: πρώτα αναφορές (TLS-RPT, testing), μετά αυστηρότητα.

Κουίζ

Άσκηση

Άσκηση Z5.4: Αναζήτηση MTA-STS, TLS-RPT και DANE. Αναζητήστε για το gmail.com το record MTA-STS και το record TLS-RPT, ανοίξτε το αρχείο πολιτικής και συμπληρώστε τη λειτουργία (enforce, testing ή none). Στη συνέχεια αναζητήστε για έναν MX server του internet.nl το record TLSA στο _25._tcp.<mx-server> και συμπληρώστε τους πρώτους τρεις αριθμούς ενός από τα records. Προαιρετικά: ίδιες ερωτήσεις για το δικό σας domain (εκεί η απάντηση μπορεί να είναι "κανένα"). Το πρόγραμμα αναζητά τα πάντα ζωντανά και συγκρίνει.

Για περαιτέρω μελέτη

Τα βήματα σε αυτά τα άρθρα ισχύουν για τους πίνακες ελέγχου του WebOké· σε άλλους παρόχους λειτουργεί παρόμοια.

• Λίστα ελέγχου Internet.nl: Πετύχετε 100% με τον ιστότοπο και το email σας
• Τι είναι το DNSSEC;
• Δωρεάν μάθημα DNS 8.1: DNSSEC in απλή γλώσσα
• internet.nl, ελέγξτε το email σας (ανεξάρτητος έλεγχος STARTTLS, DANE και άλλων): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE για SMTP)