Εν ολίγοις, το MTA-STS είναι ένας τρόπος για την περαιτέρω προστασία των email από υποκλοπές (δηλαδή, επιθέσεις man-in-the-middle γνωστό και ως MitM) όταν μεταδίδονται μεταξύ διακομιστών αλληλογραφίας. Επιλύει εν μέρει τα παλαιού τύπου αρχιτεκτονικά προβλήματα των πρωτοκόλλων email και περιγράφεται στο σχετικά πρόσφατο πρότυπο RFC 8461. Το Mail.ru είναι η πρώτη σημαντική υπηρεσία αλληλογραφίας στο RuNet που εφαρμόζει αυτό το πρότυπο. Και περιγράφεται λεπτομερέστερα κάτω από την περικοπή.
Τι πρόβλημα λύνει το MTA-STS;
Ιστορικά, τα πρωτόκολλα email (SMTP, POP3, IMAP) μετέδιδαν πληροφορίες σε καθαρό κείμενο, γεγονός που κατέστησε δυνατή την υποκλοπή τους, για παράδειγμα, κατά την πρόσβαση σε ένα κανάλι επικοινωνίας.
Πώς μοιάζει ο μηχανισμός παράδοσης μιας επιστολής από έναν χρήστη σε άλλον:
Ιστορικά, μια επίθεση MitM ήταν δυνατή σε όλα τα μέρη όπου κυκλοφορεί το ταχυδρομείο.
Το RFC 8314 απαιτεί τη χρήση TLS μεταξύ της εφαρμογής χρήστη αλληλογραφίας (MUA) και του διακομιστή αλληλογραφίας. Εάν ο διακομιστής σας και οι εφαρμογές αλληλογραφίας που χρησιμοποιείτε είναι συμβατές με το RFC 8314, τότε έχετε (σε μεγάλο βαθμό) εξαλείψει την πιθανότητα επιθέσεων Man-in-the-Middle μεταξύ του χρήστη και των διακομιστών αλληλογραφίας.
Ακολουθώντας γενικά αποδεκτές πρακτικές (τυποποιημένες από το RFC 8314) εξαλείφεται η επίθεση κοντά στον χρήστη:
Οι διακομιστές αλληλογραφίας Mail.ru συμμορφώνονταν με το RFC 8314 ακόμη και πριν από την υιοθέτηση του προτύπου· στην πραγματικότητα, απλώς καταγράφει ήδη αποδεκτές πρακτικές και δεν χρειάστηκε να διαμορφώσουμε τίποτα επιπλέον. Ωστόσο, εάν ο διακομιστής αλληλογραφίας σας εξακολουθεί να επιτρέπει στους χρήστες να χρησιμοποιούν μη ασφαλή πρωτόκολλα, φροντίστε να εφαρμόσετε τις συστάσεις αυτού του προτύπου, επειδή Πιθανότατα, τουλάχιστον ορισμένοι από τους χρήστες σας λειτουργούν με αλληλογραφία χωρίς κρυπτογράφηση, ακόμα κι αν το υποστηρίζετε.
Το πρόγραμμα-πελάτης αλληλογραφίας λειτουργεί πάντα με τον ίδιο διακομιστή αλληλογραφίας του ίδιου οργανισμού. Και μπορείτε να αναγκάσετε όλους τους χρήστες να συνδεθούν με ασφαλή τρόπο και στη συνέχεια να καταστήσετε τεχνικά αδύνατη τη σύνδεση για μη ασφαλείς χρήστες (αυτό ακριβώς απαιτεί το RFC 8314). Αυτό μερικές φορές είναι δύσκολο, αλλά εφικτό. Η κίνηση μεταξύ διακομιστών αλληλογραφίας είναι ακόμα πιο περίπλοκη. Οι διακομιστές ανήκουν σε διαφορετικούς οργανισμούς και χρησιμοποιούνται συχνά σε λειτουργία "ρυθμίστε και ξεχάστε", γεγονός που καθιστά αδύνατη την άμεση μετάβαση σε ένα ασφαλές πρωτόκολλο χωρίς διακοπή της συνδεσιμότητας. Το SMTP παρέχει εδώ και καιρό την επέκταση STARTTLS, η οποία επιτρέπει στους διακομιστές που υποστηρίζουν την κρυπτογράφηση να αλλάζουν σε TLS. Αλλά ένας εισβολέας που έχει την ικανότητα να επηρεάζει την κυκλοφορία μπορεί να «κόψει» πληροφορίες σχετικά με την υποστήριξη αυτής της εντολής και να αναγκάσει τους διακομιστές να επικοινωνούν χρησιμοποιώντας ένα πρωτόκολλο απλού κειμένου (τη λεγόμενη επίθεση υποβάθμισης). Για τον ίδιο λόγο, το STARTTLS συνήθως δεν ελέγχει την εγκυρότητα του πιστοποιητικού (ένα μη αξιόπιστο πιστοποιητικό μπορεί να προστατεύσει από παθητικές επιθέσεις και αυτό δεν είναι χειρότερο από την αποστολή ενός μηνύματος σε καθαρό κείμενο). Επομένως, το STARTTLS προστατεύει μόνο από την παθητική υποκλοπή.
Το MTA-STS εξαλείφει εν μέρει το πρόβλημα της υποκλοπής επιστολών μεταξύ διακομιστών αλληλογραφίας, όταν ο εισβολέας έχει τη δυνατότητα να επηρεάσει ενεργά την κυκλοφορία. Εάν ο τομέας του παραλήπτη δημοσιεύει μια πολιτική MTA-STS και ο διακομιστής του αποστολέα υποστηρίζει MTA-STS, θα στείλει το email μόνο μέσω σύνδεσης TLS, μόνο σε διακομιστές που ορίζονται από την πολιτική και μόνο με επαλήθευση του πιστοποιητικού του διακομιστή.
Γιατί εν μέρει; Το MTA-STS λειτουργεί μόνο εάν και τα δύο μέρη έχουν φροντίσει να εφαρμόσουν αυτό το πρότυπο και το MTA-STS δεν προστατεύει από σενάρια στα οποία ένας εισβολέας μπορεί να αποκτήσει ένα έγκυρο πιστοποιητικό τομέα από μία από τις δημόσιες ΑΠ.
Πώς λειτουργεί το MTA-STS
παραλήπτης
- Ρυθμίζει την υποστήριξη STARTTLS με ένα έγκυρο πιστοποιητικό στον διακομιστή αλληλογραφίας.
- Δημοσιεύει την πολιτική MTA-STS μέσω HTTPS· ένας ειδικός τομέας mta-sts και μια ειδική γνωστή διαδρομή χρησιμοποιούνται για δημοσίευση, για παράδειγμα
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Η πολιτική περιέχει μια λίστα διακομιστών αλληλογραφίας (mx) που έχουν το δικαίωμα να λαμβάνουν αλληλογραφία για αυτόν τον τομέα. - Δημοσιεύει μια ειδική εγγραφή TXT _mta-sts σε DNS με την έκδοση πολιτικής. Όταν αλλάξει η πολιτική, αυτή η καταχώριση πρέπει να ενημερωθεί (αυτό σηματοδοτεί τον αποστολέα να ζητήσει ξανά την πολιτική). Για παράδειγμα,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Αποστολέας
Ο αποστολέας ζητά την εγγραφή _mta-sts DNS και, εάν είναι διαθέσιμη, κάνει ένα αίτημα πολιτικής μέσω HTTPS (ελέγχοντας το πιστοποιητικό). Η πολιτική που προκύπτει αποθηκεύεται στην κρυφή μνήμη (σε περίπτωση που κάποιος εισβολέας αποκλείσει την πρόσβαση σε αυτήν ή παραπλανήσει την εγγραφή DNS).
Κατά την αποστολή αλληλογραφίας, ελέγχεται ότι:
- ο διακομιστής στον οποίο παραδίδεται η αλληλογραφία περιλαμβάνεται στην πολιτική.
- ο διακομιστής δέχεται αλληλογραφία χρησιμοποιώντας TLS (STARTTLS) και διαθέτει έγκυρο πιστοποιητικό.
Πλεονεκτήματα του MTA-STS
Το MTA-STS χρησιμοποιεί τεχνολογίες που έχουν ήδη εφαρμοστεί στους περισσότερους οργανισμούς (SMTP+STARTTLS, HTTPS, DNS). Για την υλοποίηση από την πλευρά του παραλήπτη, δεν απαιτείται ειδική υποστήριξη λογισμικού για το πρότυπο.
Μειονεκτήματα του MTA-STS
Είναι απαραίτητο να παρακολουθείται η εγκυρότητα του πιστοποιητικού web και διακομιστή αλληλογραφίας, η αντιστοιχία των ονομάτων και η έγκαιρη ανανέωση. Προβλήματα με το πιστοποιητικό θα έχουν ως αποτέλεσμα να μην είναι δυνατή η παράδοση της αλληλογραφίας.
Από την πλευρά του αποστολέα, απαιτείται MTA με υποστήριξη για πολιτικές MTA-STS· επί του παρόντος, το MTA-STS δεν υποστηρίζεται εκτός πλαισίου στο MTA.
Το MTA-STS χρησιμοποιεί μια λίστα με αξιόπιστες ΑΠ ρίζας.
Το MTA-STS δεν προστατεύει από επιθέσεις στις οποίες ο εισβολέας χρησιμοποιεί έγκυρο πιστοποιητικό. Στις περισσότερες περιπτώσεις, το MitM κοντά στον διακομιστή συνεπάγεται τη δυνατότητα έκδοσης πιστοποιητικού. Μια τέτοια επίθεση μπορεί να εντοπιστεί χρησιμοποιώντας τη Διαφάνεια Πιστοποιητικού. Ως εκ τούτου, σε γενικές γραμμές, το MTA-STS μετριάζει, αλλά δεν εξαλείφει εντελώς, την πιθανότητα παρακολούθησης της κυκλοφορίας.
Τα δύο τελευταία σημεία καθιστούν το MTA-STS λιγότερο ασφαλές από το ανταγωνιστικό πρότυπο DANE για SMTP (RFC 7672), αλλά πιο τεχνικά αξιόπιστο, π.χ. για το MTA-STS υπάρχει μικρή πιθανότητα να μην παραδοθεί η επιστολή λόγω τεχνικών προβλημάτων που προκαλούνται από την εφαρμογή του προτύπου.
Ανταγωνιστικό πρότυπο - DANE
Η DANE χρησιμοποιεί το DNSSEC για τη δημοσίευση πληροφοριών πιστοποιητικών και δεν απαιτεί εμπιστοσύνη σε εξωτερικές αρχές έκδοσης πιστοποιητικών, κάτι που είναι πολύ πιο ασφαλές. Ωστόσο, η χρήση του DNSSEC οδηγεί σημαντικά πιο συχνά σε τεχνικές βλάβες, με βάση στατιστικά στοιχεία για πολλά χρόνια χρήσης (αν και γενικά υπάρχει μια θετική τάση στην αξιοπιστία του DNSSEC και της τεχνικής του υποστήριξης). Για την εφαρμογή του DANE στο SMTP στην πλευρά του παραλήπτη, η παρουσία DNSSEC για τη ζώνη DNS είναι υποχρεωτική και η σωστή υποστήριξη για NSEC/NSEC3 είναι απαραίτητη για το DANE, με το οποίο υπάρχουν συστημικά προβλήματα στο DNSSEC.
Εάν το DNSSEC δεν έχει ρυθμιστεί σωστά, μπορεί να οδηγήσει σε αποτυχίες παράδοσης αλληλογραφίας εάν η πλευρά αποστολής υποστηρίζει το DANE, ακόμα κι αν η πλευρά λήψης δεν γνωρίζει τίποτα γι' αυτό. Επομένως, παρά το γεγονός ότι το DANE είναι ένα παλαιότερο και πιο ασφαλές πρότυπο και υποστηρίζεται ήδη σε κάποιο λογισμικό διακομιστή από την πλευρά του αποστολέα, στην πραγματικότητα η διείσδυσή του παραμένει ασήμαντη, πολλοί οργανισμοί δεν είναι έτοιμοι να το εφαρμόσουν λόγω της ανάγκης εφαρμογής DNSSEC. Αυτό έχει επιβραδύνει σημαντικά την εφαρμογή του DANE όλα αυτά τα χρόνια που υπάρχει το πρότυπο.
Το DANE και το MTA-STS δεν έρχονται σε σύγκρουση μεταξύ τους και μπορούν να χρησιμοποιηθούν μαζί.
Τι συμβαίνει με την υποστήριξη MTA-STS στο Mail.ru Mail;
Το Mail.ru δημοσιεύει μια πολιτική MTA-STS για όλους τους μεγάλους τομείς εδώ και αρκετό καιρό. Αυτήν τη στιγμή εφαρμόζουμε το τμήμα πελάτη του προτύπου. Κατά τη στιγμή της σύνταξης, οι πολιτικές εφαρμόζονται σε λειτουργία μη αποκλεισμού (εάν η παράδοση εμποδίζεται από μια πολιτική, η επιστολή θα παραδοθεί μέσω ενός "εφεδρικού" διακομιστή χωρίς εφαρμογή πολιτικών), στη συνέχεια η λειτουργία αποκλεισμού θα επιβληθεί για ένα μικρό μέρος της εξερχόμενης κίνησης SMTP, σταδιακά για το 100% της κυκλοφορίας θα υποστηρίζεται η επιβολή πολιτικών.
Ποιος άλλος υποστηρίζει το πρότυπο;
Μέχρι στιγμής, οι πολιτικές MTA-STS δημοσιεύουν περίπου το 0.05% των ενεργών τομέων, αλλά, ωστόσο, ήδη προστατεύουν μεγάλο όγκο επισκεψιμότητας αλληλογραφίας, επειδή Το πρότυπο υποστηρίζεται από σημαντικούς παίκτες - την Google, την Comcast και εν μέρει την Verizon (AOL, Yahoo). Πολλές άλλες ταχυδρομικές υπηρεσίες έχουν ανακοινώσει ότι η υποστήριξη για το πρότυπο θα εφαρμοστεί στο εγγύς μέλλον.
Πώς θα με επηρεάσει αυτό;
Όχι εκτός εάν ο τομέας σας δημοσιεύει μια πολιτική MTA-STS. Εάν δημοσιεύσετε την πολιτική, τα μηνύματα ηλεκτρονικού ταχυδρομείου για τους χρήστες του διακομιστή αλληλογραφίας σας θα προστατεύονται καλύτερα από την υποκλοπή.
Πώς μπορώ να εφαρμόσω το MTA-STS;
Υποστήριξη MTA-STS από την πλευρά του παραλήπτη
Αρκεί να δημοσιεύσετε την πολιτική μέσω HTTPS και εγγραφές σε DNS, να διαμορφώσετε ένα έγκυρο πιστοποιητικό από μία από τις αξιόπιστες CA (Ας κρυπτογραφήσουμε είναι δυνατή) για STARTTLS στο MTA (το STARTTLS υποστηρίζεται σε όλα τα σύγχρονα MTA), καμία ειδική υποστήριξη από το Απαιτείται MTA.
Βήμα προς βήμα, μοιάζει με αυτό:
- Διαμορφώστε το STARTTLS στο MTA που χρησιμοποιείτε (postfix, exim, sendmail, Microsoft Exchange, κ.λπ.).
- Βεβαιωθείτε ότι χρησιμοποιείτε ένα έγκυρο πιστοποιητικό (εκδόθηκε από αξιόπιστη αρχή έκδοσης πιστοποιητικών, δεν έχει λήξει, το θέμα του πιστοποιητικού αντιστοιχεί στην εγγραφή MX που παραδίδει αλληλογραφία για τον τομέα σας).
- Διαμορφώστε μια εγγραφή TLS-RPT μέσω της οποίας θα παραδίδονται οι αναφορές εφαρμογών πολιτικής (από υπηρεσίες που υποστηρίζουν την αποστολή αναφορών TLS). Παράδειγμα καταχώρισης (για τον τομέα example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Αυτή η καταχώρηση δίνει εντολή στους αποστολείς αλληλογραφίας να στέλνουν στατιστικές αναφορές σχετικά με τη χρήση του TLS στο SMTP
[email protected].Παρακολουθήστε τις αναφορές για αρκετές ημέρες για να βεβαιωθείτε ότι δεν υπάρχουν σφάλματα.
- Δημοσιεύστε την πολιτική MTA-STS μέσω HTTPS. Η πολιτική δημοσιεύεται ως αρχείο κειμένου με τερματιστές γραμμής CRLF ανά τοποθεσία.
https://mta-sts.example.com/.well-known/mta-sts.txtΠαράδειγμα πολιτικής:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Το πεδίο έκδοσης περιέχει την έκδοση της πολιτικής (προς το παρόν
STSv1), Η λειτουργία ορίζει τη λειτουργία εφαρμογής πολιτικής, δοκιμή — λειτουργία δοκιμής (η πολιτική δεν εφαρμόζεται), επιβολή — λειτουργία «μάχης». Πρώτα δημοσιεύστε την πολιτική με λειτουργία: δοκιμή, εάν δεν υπάρχουν προβλήματα με την πολιτική σε δοκιμαστική λειτουργία, μετά από λίγο μπορείτε να μεταβείτε στη λειτουργία: επιβολή.Στο mx, καθορίζεται μια λίστα με όλους τους διακομιστές αλληλογραφίας που μπορούν να δέχονται αλληλογραφία για τον τομέα σας (κάθε διακομιστής πρέπει να έχει διαμορφωμένο πιστοποιητικό που ταιριάζει με το όνομα που καθορίζεται στο mx). Το Max_age καθορίζει τον χρόνο προσωρινής αποθήκευσης της πολιτικής (από τη στιγμή που θα εφαρμοστεί η απομνημονευμένη πολιτική, ακόμα κι αν ο εισβολέας μπλοκάρει την παράδοσή της ή καταστρέψει τις εγγραφές DNS κατά τη διάρκεια του χρόνου αποθήκευσης στην κρυφή μνήμη, μπορείτε να υποδείξετε την ανάγκη να ζητήσετε ξανά την πολιτική αλλάζοντας το mta-sts DNS Ρεκόρ).
- Δημοσιεύστε μια εγγραφή TXT σε DNS:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Ένα αυθαίρετο αναγνωριστικό (για παράδειγμα, μια χρονική σήμανση) μπορεί να χρησιμοποιηθεί στο πεδίο id. Όταν αλλάξει η πολιτική, θα πρέπει να αλλάξει, αυτό επιτρέπει στους αποστολείς να κατανοήσουν ότι πρέπει να ζητήσουν ξανά την πολιτική που έχει αποθηκευτεί στην κρυφή μνήμη (εάν το αναγνωριστικό είναι διαφορετικό από το αποθηκευμένο στην κρυφή μνήμη).
Υποστήριξη MTA-STS στην πλευρά του αποστολέα
Μέχρι στιγμής είναι άσχημα μαζί της, γιατί... φρέσκο πρότυπο.
- Exim - δεν υπάρχει ενσωματωμένη υποστήριξη, υπάρχει σενάριο τρίτου κατασκευαστή
- Postfix - δεν υπάρχει ενσωματωμένη υποστήριξη, υπάρχει ένα σενάριο τρίτου μέρους το οποίο περιγράφεται λεπτομερώς στο Habré
Ως επίλογο για το "υποχρεωτικό TLS"
Τον τελευταίο καιρό, οι ρυθμιστικές αρχές έχουν δώσει προσοχή στην ασφάλεια του email (και αυτό είναι καλό). Για παράδειγμα, το DMARC είναι υποχρεωτικό για όλους τους κρατικούς φορείς στις Ηνωμένες Πολιτείες και απαιτείται ολοένα και περισσότερο στον χρηματοπιστωτικό τομέα, με τη διείσδυση του προτύπου να φτάνει το 90% σε ελεγχόμενες περιοχές. Τώρα, ορισμένες ρυθμιστικές αρχές απαιτούν την εφαρμογή του "υποχρεωτικού TLS" με μεμονωμένους τομείς, αλλά ο μηχανισμός για τη διασφάλιση του "υποχρεωτικού TLS" δεν έχει καθοριστεί και στην πράξη αυτή η ρύθμιση εφαρμόζεται συχνά με τρόπο που δεν προστατεύει ούτε ελάχιστα από πραγματικές επιθέσεις που έχουν ήδη που προβλέπονται σε μηχανισμούς όπως το DANE ή το MTA-STS.
Εάν ο ρυθμιστής απαιτεί την εφαρμογή "υποχρεωτικού TLS" με ξεχωριστούς τομείς, συνιστούμε να θεωρήσετε το MTA-STS ή το μερικό ανάλογό του ως τον καταλληλότερο μηχανισμό, εξαλείφει την ανάγκη να κάνετε ασφαλείς ρυθμίσεις για κάθε τομέα ξεχωριστά. Εάν αντιμετωπίζετε δυσκολίες στην υλοποίηση του τμήματος πελάτη του MTA-STS (μέχρι το πρωτόκολλο να λάβει ευρεία υποστήριξη, πιθανότατα θα λάβει), μπορούμε να προτείνουμε αυτήν την προσέγγιση:
- Δημοσιεύστε μια πολιτική MTA-STS ή/και εγγραφές DANE (το DANE έχει νόημα μόνο εάν το DNSSEC είναι ήδη ενεργοποιημένο για τον τομέα σας και το MTA-STS σε κάθε περίπτωση), αυτό θα προστατεύσει την κυκλοφορία προς την κατεύθυνση σας και θα εξαλείψει την ανάγκη να ζητήσετε από άλλες υπηρεσίες αλληλογραφίας για να διαμορφώσετε το υποχρεωτικό TLS για τον τομέα σας, εάν η υπηρεσία αλληλογραφίας υποστηρίζει ήδη MTA-STS ή/και DANE.
- Για μεγάλες υπηρεσίες email, εφαρμόστε ένα «ανάλογο» του MTA-STS μέσω ξεχωριστών ρυθμίσεων μεταφοράς για κάθε τομέα, το οποίο θα διορθώσει το MX που χρησιμοποιείται για την αναμετάδοση αλληλογραφίας και θα απαιτήσει υποχρεωτική επαλήθευση πιστοποιητικού TLS για αυτό. Εάν οι τομείς δημοσιεύουν ήδη μια πολιτική MTA-STS, αυτό πιθανότατα μπορεί να γίνει ανώδυνα. Από μόνη της, η ενεργοποίηση υποχρεωτικού TLS για έναν τομέα χωρίς τη διόρθωση του ρελέ και η επαλήθευση του πιστοποιητικού για αυτόν είναι αναποτελεσματική από άποψη ασφάλειας και δεν προσθέτει τίποτα στους υπάρχοντες μηχανισμούς STARTTLS.
Πηγή: www.habr.com