Moduuli 5 · 5.4
Salattu toimitus: TLS, MTA-STS ja DANE
Moduuli 5: Maine ja suuret vastaanottajat · Lukuaika: 10 minuuttia
Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää, miten sähköpostipalvelimet salaavat yhteytensä keskenään, miksi sitä ei oletusarvoisesti voida pakottaa, ja mitä MTA-STS, TLS-RPT ja DANE muuttavat tähän. Osaat etsiä ja lukea näitä tietueita.
Keskeiset käsitteet: STARTTLS palvelinten välillä, opportunistinen salaus, downgrade-hyökkäys, MTA-STS (RFC 8461), _mta-sts-tietue, käytäntötiedosto, tila testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-tietue, DANE SMTP:lle (RFC 7672), TLSA-tietue, DNSSEC
Kaksi yhteystyyppiä
Oppitunnilla 1.4 käsiteltiin yhteyttä sähköpostiohjelmasi ja palveluntarjoajasi sähköpostipalvelimen välillä: portti 587 STARTTLS:n kanssa, tai 465 suoralla TLS:llä, kirjautumisen kera. Siinä sinulla itsellläsi on hallinta. Ohjelmasi tietää, mitä palvelinta se odottaa, tarkistaa varmenteen ja kieltäytyy yhdistämästä, jos jokin ei täsmää.
Tämä oppitunti käsittelee seuraavaa vaihetta: yhteyttä lähettävän palvelimen ja vastaanottavan palvelimen välillä, portissa 25. Se toimii eri tavalla.
Opportunistinen: salataan, jos mahdollista
Kun palvelin toimittaa sähköpostia, se muodostaa yhteyden vastaanottajan MX-palvelimeen. EHLO-komennon jälkeen se tarkistaa, tarjoaako vastaanottava palvelin STARTTLS:ää. Jos tarjoaa, se vaihtaa salattuun yhteyteen. Jos ei, se toimittaa viestin vain salaamattomana.
Tätä kutsutaan opportunistiseksi salaukseksi: salataan, jos mahdollista, muuten ei. Ja useimmiten lähettävä palvelin ei tarkista varmennetta tiukasti. Vanhentunut tai itse tehty varmenne ei silloin ole syy keskeyttää.
Miksi näin? Koska sähköpostin pitää toimia aina, myös vanhojen palvelinten kanssa. Lähettäjä ei voi tietää, pitäisikö vastaanottajalla olla TLS käytössä. Tämä mahdollistaa kaksi hyökkäystä:
- Downgrade-hyökkäys. Joku, joka pystyy muokkaamaan liikennettä matkan varrella, poistaa sanan
STARTTLSvastaanottajan vastauksesta. Lähettäjä luulee, ettei salausta ole, ja toimittaa viestin salaamattomana. Hyökkääjä lukee viestin mukana. - Väärennetty MX. Joku, joka pystyy väärentämään DNS-vastauksia, ilmoittaa oman palvelimensa MX:ksi. Koska varmennetta ei tarkisteta, lähettäjä ei huomaa mitään.
Nykyään lähes kaikki suuret sähköpostipalvelimet salaavat yhteytensä, ja Gmail vaatii lähettäjiltä TLS:n käyttöä (oppitunti 5.3). Mutta "yleensä salattu" on eri asia kuin "aina ja oikean palvelimen kanssa". Tähän on kaksi ratkaisua: MTA-STS ja DANE. Molemmat asettaa vastaanottaja: niiden avulla ilmoitat, että sinun verkkotunnuksellesi menevän sähköpostin pitää aina olla salattua, ja palvelimella pitää olla voimassa oleva varmenne.
MTA-STS: käytäntö verkkosivun kautta
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) toimii kahden osan avulla.
TXT-tietue, joka kertoo, että käytäntö on olemassa:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"Ja käytäntötiedosto kiinteässä osoitteessa, https:n kautta voimassa olevalla varmenteella:
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| Rivi | Merkitys |
|---|---|
mode: enforce | Toimita viesti vain TLS:n kautta voimassa olevalla varmenteella jollekin mainituista MX-palvelimista. Jos se ei onnistu, viestiä ei toimiteta (se jää jonoon) |
mode: testing | Toimita viesti kuten ennenkin, mutta ilmoita ongelmista TLS-RPT:n kautta |
mode: none | Käytäntöä ei ole (enää) |
mx: | Niiden MX-palvelinten nimet, joilla pitää olla varmenne; *. alussa on sallittu |
max_age: | Kuinka kauan (sekunteina) lähettäjä saa muistaa käytännön |
id= TXT-tietueessa | Versionumero. Kun muokkaat käytäntöä, muuta myös id, jotta lähettäjät hakevat tiedoston uudelleen |
Nerokasta tässä on se, että lähettäjä muistaa käytännön ajan, joka vastaa arvoa max_age. Hyökkääjä, joka myöhemmin poistaa STARTTLS-sanan tai antaa väärennetyn MX:n, paljastuu silloin: käytäntö kertoo, että salaus on pakollinen ja mitkä palvelimet ovat kelvollisia. Aivan ensimmäisellä yhteydellä (ennen kuin käytäntö on tiedossa) MTA-STS ei suojaa; se on tunnettu heikko kohta.
Todellinen esimerkki on gmail.com: TXT-tietue _mta-sts.gmail.com on olemassa, ja käytäntötiedosto osoitteessa https://mta-sts.gmail.com/.well-known/mta-sts.txt on tilassa mode: enforce.
TLS-RPT: raportit epäonnistuneesta salauksesta
Kun MTA-STS on tilassa enforce, sähköposti voi jäädä jumiin, jos varmenteessasi on jotain vialla. Haluat tietää siitä. Tähän on TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Lähettäjät, jotka tukevat TLS-RPT:tä (muun muassa Google ja Microsoft), lähettävät silloin päivittäin raportin JSON-muodossa: kuinka monta yhteyttä onnistui ja mitkä epäonnistuivat, syyn kera (esimerkiksi vanhentunut varmenne tai nimi, joka ei ole käytännössä mainittu). Aivan kuten DMARC-raporttien kanssa (oppitunti 4.5) voit antaa niiden käsittelyn raportointipalvelulle.
Käyttöönottojärjestys: ensin TLS-RPT, sitten MTA-STS tilassa testing, muutaman viikon raporttien lukeminen, ja vasta sen jälkeen enforce. Tämä muistuttaa DMARC:n asteittaista käyttöönottoa: ensin tarkkaillaan, sitten tiukennetaan.
DANE: varmenne DNS:ssä, suojattuna DNSSEC:llä
DANE (DNS-based Authentication of Named Entities) toimii eri tavalla. Lisäät DNS:ään TLSA-tietueen jokaiselle MX-palvelimelle, varmenteen tai avaimen sormenjäljen kera:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp tarkoittaa: SMTP:lle portissa 25. Kolme numeroa kertovat, miten arvo pitää lukea. Sähköpostipalvelimille yleisin on 3 1 1: "tämä on juuri tämän palvelimen julkisen avaimen SHA-256-sormenjälki". Myös 2 1 1 esiintyy: silloin tietueessa on välivarmenteen sormenjälki.
Lähettäjä, joka tukee DANEa, näkee TLSA-tietueen, vaatii salausta ja tarkistaa, täsmääkö palvelimen varmenne. Jos se ei täsmää, viestiä ei toimiteta.
Miksi DANE on turvallinen väärennettyjä DNS-vastauksia vastaan? Koska se toimii vain DNSSEC:n kanssa (DNS-kurssin oppitunti 8.1). Ilman voimassa olevaa DNSSEC-ketjua TLSA-tietueet jätetään huomiotta. Se on samalla kynnys: sekä verkkotunnuksesi (MX:ää varten) että sähköpostipalvelimen vyöhykkeen pitää olla allekirjoitettuja.
DANEssa ei ole "ensimmäinen kerta"-heikkoutta kuten MTA-STS:ssä, ja se on laajalti käytössä muun muassa Alankomaissa ja Saksassa. internet.nl testaa sitä. Microsoft tukee DANEa saapuvalle sähköpostille Exchange Onlinessa. Myös internet.nl:n MX-palvelimilla on TLSA-tietueet.
Sudenkuoppa: jos vaihdat DANEa käyttävän sähköpostipalvelimen varmenteen uuteen avaimeen, TLSA-tietueen pitää muuttua samalla, ja nimenomaan etukäteen: ensin lisää uusi tietue, odota kunnes TTL on kulunut umpeen, ja vasta sitten ota uusi avain käyttöön. Muuten DANEa käyttävät lähettäjät hylkäävät sähköpostisi. Kohdalla 3 1 1 tämä on ongelma vain, kun avain vaihtuu, ei jokaisella uusimisella samalla avaimella.
MTA-STS vai DANE?
| MTA-STS | DANE | |
|---|---|---|
| Vaatii DNSSEC:n | Ei | Kyllä |
| Missä sijaitsee | TXT-tietue sekä käytäntötiedosto verkkosivulla | TLSA-tietue jokaiselle MX-palvelimelle |
| Suojaa ensimmäisen yhteyden | Ei | Kyllä |
| Ylläpito | Verkkosivun ja mta-sts.-varmenteen ylläpito | TLSA:n päivittäminen uuden avaimen yhteydessä |
Niitä saa käyttää rinnakkain. RFC 8461 sanoo, että lähettäjä, joka tukee DANEa, antaa DANEn mennä edelle, jos voimassa olevia TLSA-tietueita löytyy.
Kuka hoitaa tämän?
Tämän asetat saapuvalle sähköpostille verkkotunnuksessasi. Jos sähköpostisi toimii hosting- tai sähköpostipalvelun kautta, se riippuu kyseisestä palveluntarjoajasta:
- DANE onnistuu vain, jos palveluntarjoaja julkaisee TLSA-tietueet sähköpostipalvelimilleen ja verkkotunnuksellasi on DNSSEC käytössä. WebOké:ssä voit esimerkiksi ottaa DANEn käyttöön samasta paikasta kuin DNSSEC:in (katso alta internet.nl-artikkeli); muilla palveluntarjoajilla toiminta on vastaavaa tai se on hoidettu oletuksena.
- MTA-STS:n voit joskus asettaa itse, mutta silloin
mta-sts.example.com:n pitää olla verkkosivu voimassa olevalla varmenteella, ja sinun pitää tietää palveluntarjoajasi MX-nimet. - TLS-RPT:n voit aina asettaa itse: se on vain TXT-tietue, jossa on raportointiosoite.
Lähtevää sähköpostia varten sinun ei tarvitse tehdä mitään: palveluntarjoajasi palvelin päättää, kunnioittaako se vastaanottajien MTA-STS:ää ja DANEa.
Yhteenveto
- Sähköpostipalvelinten välillä TLS on oletuksena opportunistinen: salataan, jos mahdollista, ilman tiukkaa varmenteen tarkistusta. Tämä mahdollistaa downgrade-hyökkäyksen ja väärennetyn MX:n.
- MTA-STS: TXT
_mta-stssekä käytäntötiedosto osoitteessahttps://mta-sts.<verkkotunnus>/.well-known/mta-sts.txt; tilatestingtaienforce. - TLS-RPT: TXT
_smtp._tlsraportointiosoitteen kera, päivittäisiä raportteja varten epäonnistuneesta salauksesta. - DANE: TLSA-tietue osoitteessa
_25._tcp.<mx-palvelin>, toimii vain DNSSEC:n kanssa ja suojaa myös ensimmäisen yhteyden. - Ota käyttöön kuten DMARC: ensin raportit (TLS-RPT,
testing), sitten tiukennus.
Tietovisa
Tehtävä
Tehtävä Z5.4: MTA-STS:n, TLS-RPT:n ja DANE:n etsiminen. Etsi gmail.com:lta MTA-STS-tietue ja TLS-RPT-tietue, avaa käytäntötiedosto ja täytä tila (enforce, testing tai none). Etsi sen jälkeen internet.nl:n MX-palvelimelta TLSA-tietue osoitteessa _25._tcp.<mx-palvelin> ja täytä yhden tietueen kolme ensimmäistä numeroa. Valinnainen: samat kysymykset omalle verkkotunnuksellesi (siellä vastaus voi olla "ei mitään"). Ohjelma hakee kaiken suoraan ja vertaa vastauksia.
Lue lisää
Näiden artikkelien vaiheet koskevat WebOké:n hallintapaneeleita; muilla palveluntarjoajilla toiminta on vastaavaa.
- Internet.nl-tarkistuslista: saavuta 100 % verkkosivustollasi ja sähköpostissasi
- DNSSEC on mitä?
- Ilmainen DNS-kurssi 8.1: DNSSEC selkokielellä
- internet.nl, testaa sähköpostisi (riippumaton STARTTLS:n, DANEn ja muun testi): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE SMTP:lle)