Yn fyr, mae MTA-STS yn ffordd o amddiffyn negeseuon e-bost ymhellach rhag rhyng-gipio (hy, ymosodiadau dyn-yn-y-canol aka MitM) wrth eu trosglwyddo rhwng gweinyddwyr post. Mae'n rhannol yn datrys problemau pensaernïol etifeddiaeth protocolau e-bost ac fe'i disgrifir yn y safon gymharol ddiweddar RFC 8461. Mail.ru yw'r gwasanaeth post mawr cyntaf ar y RuNet i weithredu'r safon hon. Ac fe'i disgrifir yn fanylach o dan y toriad.

Pa broblem mae MTA-STS yn ei datrys?

Yn hanesyddol, roedd protocolau e-bost (SMTP, POP3, IMAP) yn trosglwyddo gwybodaeth mewn testun clir, a oedd yn ei gwneud hi'n bosibl ei rhyng-gipio, er enghraifft, wrth gyrchu sianel gyfathrebu.

Sut olwg sydd ar y mecanwaith ar gyfer dosbarthu llythyr gan un defnyddiwr i’r llall:

Yn hanesyddol, roedd ymosodiad MitM yn bosibl ym mhob man lle mae post yn cylchredeg.

Mae RFC 8314 yn gofyn am ddefnyddio TLS rhwng y rhaglen defnyddiwr post (MUA) a'r gweinydd post. Os yw'ch gweinydd a'r cymwysiadau post rydych chi'n eu defnyddio yn cydymffurfio â RFC 8314, yna rydych chi (yn bennaf) wedi dileu'r posibilrwydd o ymosodiadau Dyn-yn-y-Canol rhwng y defnyddiwr a'r gweinyddwyr post.

Mae dilyn arferion a dderbynnir yn gyffredinol (wedi'u safoni gan RFC 8314) yn dileu'r ymosodiad ger y defnyddiwr:

Cydymffurfiodd gweinyddwyr post Mail.ru â RFC 8314 hyd yn oed cyn i'r safon gael ei mabwysiadu; mewn gwirionedd, yn syml, mae'n dal arferion a dderbyniwyd eisoes, ac nid oedd yn rhaid i ni ffurfweddu unrhyw beth ychwanegol. Ond, os yw'ch gweinydd post yn dal i ganiatáu i ddefnyddwyr ddefnyddio protocolau ansicr, gwnewch yn siŵr eich bod yn gweithredu argymhellion y safon hon, oherwydd Yn fwyaf tebygol, mae o leiaf rhai o'ch defnyddwyr yn gweithio gyda phost heb amgryptio, hyd yn oed os ydych chi'n ei gefnogi.

Mae'r cleient post bob amser yn gweithio gyda'r un gweinydd post o'r un sefydliad. A gallwch chi orfodi pob defnyddiwr i gysylltu mewn modd diogel, ac yna ei gwneud hi'n dechnegol amhosibl i ddefnyddwyr nad ydynt yn ddiogel gysylltu (dyma'n union beth sydd ei angen ar RFC 8314). Mae hyn weithiau'n anodd, ond yn ymarferol. Mae traffig rhwng gweinyddwyr post yn dal yn fwy cymhleth. Mae gweinyddwyr yn perthyn i wahanol sefydliadau ac fe'u defnyddir yn aml mewn modd “gosod ac anghofio”, sy'n ei gwneud hi'n amhosibl newid i brotocol diogel ar unwaith heb dorri cysylltedd. Mae SMTP wedi darparu'r estyniad STARTTLS ers tro, sy'n caniatáu i weinyddion sy'n cefnogi amgryptio newid i TLS. Ond gall ymosodwr sydd â'r gallu i ddylanwadu ar draffig “dorri allan” gwybodaeth am gefnogaeth i'r gorchymyn hwn a gorfodi'r gweinyddwyr i gyfathrebu gan ddefnyddio protocol testun plaen (yr ymosodiad israddio fel y'i gelwir). Am yr un rheswm, nid yw STARTTLS fel arfer yn gwirio dilysrwydd y dystysgrif (gall tystysgrif ddi-ymddiried amddiffyn rhag ymosodiadau goddefol, ac nid yw hyn yn waeth nag anfon neges mewn testun clir). Felly, dim ond yn erbyn clustfeinio goddefol y mae STARTTLS yn amddiffyn.

Mae MTA-STS yn rhannol yn dileu'r broblem o ryng-gipio llythyrau rhwng gweinyddwyr post, pan fydd gan yr ymosodwr y gallu i ddylanwadu'n weithredol ar draffig. Os yw parth y derbynnydd yn cyhoeddi polisi MTA-STS a gweinydd yr anfonwr yn cefnogi MTA-STS, bydd yn anfon yr e-bost dros gysylltiad TLS yn unig, dim ond i weinyddion a ddiffinnir gan y polisi, a dim ond gyda dilysu tystysgrif y gweinydd.

Pam yn rhannol? Mae MTA-STS ond yn gweithio os yw'r ddau barti wedi cymryd gofal i weithredu'r safon hon, ac nid yw MTA-STS yn amddiffyn rhag senarios lle mae ymosodwr yn gallu cael tystysgrif parth ddilys gan un o'r CA cyhoeddus.

Sut mae MTA-STS yn gweithio

derbynnydd

Yn ffurfweddu cefnogaeth STARTTLS gyda thystysgrif ddilys ar y gweinydd post.
Yn cyhoeddi polisi MTA-STS trwy HTTPS; defnyddir parth mta-sts arbennig a llwybr adnabyddus arbennig ar gyfer cyhoeddi, er enghraifft https://mta-sts.mail.ru/.well-known/mta-sts.txt. Mae'r polisi yn cynnwys rhestr o weinyddion post (mx) sydd â'r hawl i dderbyn post ar gyfer y parth hwn.
Yn cyhoeddi cofnod TXT arbennig _mta-sts yn DNS gyda'r fersiwn polisi. Pan fydd y polisi'n newid, rhaid diweddaru'r cofnod hwn (mae hyn yn arwydd i'r anfonwr ail-holi'r polisi). Er enghraifft, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Anfonwr

Mae'r anfonwr yn gofyn am y cofnod DNS _mta-sts, ac os yw ar gael, mae'n gwneud cais polisi trwy HTTPS (gwirio'r dystysgrif). Mae'r polisi sy'n deillio o hyn yn cael ei storio (rhag ofn y bydd ymosodwr yn rhwystro mynediad ato neu'n ffugio'r cofnod DNS).

Wrth anfon post, mae'n cael ei wirio bod:

mae'r gweinydd y mae post yn cael ei ddosbarthu iddo yn y polisi;
mae'r gweinydd yn derbyn post gan ddefnyddio TLS (STARTTLS) ac mae ganddo dystysgrif ddilys.

Manteision MTA-STS

Mae MTA-STS yn defnyddio technolegau sydd eisoes ar waith yn y mwyafrif o sefydliadau (SMTP + STARTTLS, HTTPS, DNS). Ar gyfer gweithredu ar ochr y derbynnydd, nid oes angen cymorth meddalwedd arbennig ar gyfer y safon.

Anfanteision MTA-STS

Mae angen monitro dilysrwydd y we a thystysgrif gweinydd post, cyfatebiaeth enwau, ac adnewyddu amserol. Bydd problemau gyda'r dystysgrif yn golygu na fydd modd danfon post.

Ar ochr yr anfonwr, mae angen MTA gyda chefnogaeth ar gyfer polisïau MTA-STS; ar hyn o bryd, nid yw MTA-STS yn cael ei gefnogi allan o'r blwch yn y MTA.

Mae MTA-STS yn defnyddio rhestr o CAs gwraidd dibynadwy.

Nid yw MTA-STS yn amddiffyn rhag ymosodiadau lle mae'r ymosodwr yn defnyddio tystysgrif ddilys. Yn y rhan fwyaf o achosion, mae MitM ger y gweinydd yn awgrymu'r gallu i roi tystysgrif. Gellir canfod ymosodiad o'r fath trwy ddefnyddio Tryloywder Tystysgrif. Felly, yn gyffredinol, mae MTA-STS yn lliniaru'r posibilrwydd o ryng-gipio traffig, ond nid yw'n dileu'n llwyr.

Mae’r ddau bwynt olaf yn gwneud MTA-STS yn llai sicr na’r safon DANE sy’n cystadlu ar gyfer SMTP (RFC 7672), ond yn fwy technegol dibynadwy, h.y. ar gyfer MTA-STS mae tebygolrwydd isel na fydd y llythyr yn cael ei ddosbarthu oherwydd problemau technegol a achosir gan weithrediad y safon.

Safon cystadlu - DANE

Mae DANE yn defnyddio DNSSEC i gyhoeddi gwybodaeth tystysgrif ac nid oes angen ymddiriedaeth mewn awdurdodau tystysgrif allanol, sy'n llawer mwy diogel. Ond mae'r defnydd o DNSSEC yn llawer mwy aml yn arwain at fethiannau technegol, yn seiliedig ar ystadegau dros nifer o flynyddoedd o ddefnydd (er bod tuedd gadarnhaol yn gyffredinol yn nibynadwyedd DNSSEC a'i gefnogaeth dechnegol). Er mwyn gweithredu DANE yn SMTP ar ochr y derbynnydd, mae presenoldeb DNSSEC ar gyfer y parth DNS yn orfodol, ac mae cefnogaeth gywir ar gyfer NSEC / NSEC3 yn hanfodol ar gyfer DANE, y mae problemau systemig yn DNSSEC gyda nhw.

Os nad yw DNSSEC wedi'i ffurfweddu'n gywir, gall arwain at fethiannau dosbarthu post os yw'r ochr anfon yn cefnogi DANE, hyd yn oed os nad yw'r ochr sy'n derbyn yn gwybod dim amdano. Felly, er gwaethaf y ffaith bod DANE yn safon hŷn a mwy diogel ac yn cael ei gefnogi eisoes mewn rhai meddalwedd gweinydd ar ochr yr anfonwr, mewn gwirionedd mae ei dreiddiad yn parhau i fod yn ddibwys, nid yw llawer o sefydliadau yn barod i'w weithredu oherwydd yr angen i weithredu DNSSEC, mae hyn wedi arafu gweithrediad DANE yn sylweddol yr holl flynyddoedd y mae'r safon wedi bodoli.

Nid yw DANE a MTA-STS yn gwrthdaro â'i gilydd a gellir eu defnyddio gyda'i gilydd.

Beth sydd gyda chefnogaeth MTA-STS yn Mail.ru Mail?

Mae Mail.ru wedi bod yn cyhoeddi polisi MTA-STS ar gyfer pob prif barth ers cryn amser. Ar hyn o bryd rydym yn gweithredu'r rhan cleient o'r safon. Ar adeg ysgrifennu, mae polisïau'n cael eu cymhwyso mewn modd di-flocio (os yw'r danfoniad yn cael ei rwystro gan bolisi, bydd y llythyr yn cael ei ddosbarthu trwy weinydd "sbâr" heb gymhwyso polisïau), yna bydd y modd blocio yn cael ei orfodi am ran fach o draffig SMTP sy'n mynd allan, yn raddol ar gyfer 100% o'r traffig y bydd yn cael ei gefnogi. Cefnogir gorfodi polisïau.

Pwy arall sy'n cefnogi'r safon?

Hyd yn hyn, mae polisïau MTA-STS yn cyhoeddi tua 0.05% o barthau gweithredol, ond, serch hynny, maent eisoes yn amddiffyn llawer iawn o draffig post, oherwydd Cefnogir y safon gan chwaraewyr mawr - Google, Comcast ac yn rhannol Verizon (AOL, Yahoo). Mae llawer o wasanaethau post eraill wedi cyhoeddi y bydd cymorth ar gyfer y safon yn cael ei roi ar waith yn y dyfodol agos.

Sut bydd hyn yn effeithio arna i?

Nid oni bai bod eich parth yn cyhoeddi polisi MTA-STS. Os byddwch yn cyhoeddi'r polisi, bydd negeseuon e-bost ar gyfer defnyddwyr eich gweinydd post yn cael eu hamddiffyn yn well rhag rhyng-gipio.

Sut mae gweithredu MTA-STS?

Cefnogaeth MTA-STS ar ochr y derbynnydd

Mae'n ddigon cyhoeddi'r polisi trwy HTTPS a chofnodion yn DNS, ffurfweddu tystysgrif ddilys gan un o'r CA dibynadwy (Mae'n bosibl i ni amgryptio) ar gyfer STARTTLS yn y MTA (mae STARTTLS yn cael ei gefnogi ym mhob MTA modern), dim cefnogaeth arbennig gan y Mae angen MTA.

Cam wrth gam, mae'n edrych fel hyn:

Ffurfweddwch STARTTLS yn y MTA rydych chi'n ei ddefnyddio (postfix, exim, sendmail, Microsoft Exchange, ac ati).
Gwnewch yn siŵr eich bod yn defnyddio tystysgrif ddilys (a gyhoeddwyd gan CA dibynadwy, nid yw wedi dod i ben, mae testun y dystysgrif yn cyfateb i'r cofnod MX sy'n dosbarthu post ar gyfer eich parth).
Ffurfweddu cofnod TLS-RPT ar gyfer cyflwyno adroddiadau cais polisi (gan wasanaethau sy'n cefnogi anfon adroddiadau TLS). Cofnod enghreifftiol (ar gyfer y parth example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Mae'r cofnod hwn yn cyfarwyddo anfonwyr post i anfon adroddiadau ystadegol ar ddefnydd TLS yn SMTP i [email protected].

Monitro'r adroddiadau am sawl diwrnod i wneud yn siŵr nad oes unrhyw wallau.
Cyhoeddi'r polisi MTA-STS dros HTTPS. Cyhoeddir y polisi fel ffeil testun gyda therfynwyr llinell CRLF fesul lleoliad.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Polisi enghreifftiol:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Mae'r maes fersiwn yn cynnwys y fersiwn o'r polisi (ar hyn o bryd STSv1), Modd yn gosod y modd cais polisi, profi - modd prawf (nid yw'r polisi yn cael ei gymhwyso), gorfodi - modd “brwydro”. Yn gyntaf cyhoeddwch y polisi gyda modd: profi, os nad oes unrhyw broblemau gyda'r polisi yn y modd prawf, ar ôl ychydig gallwch chi newid i'r modd: gorfodi.

Yn mx, nodir rhestr o'r holl weinyddion post sy'n gallu derbyn post ar gyfer eich parth (rhaid i bob gweinydd gael tystysgrif wedi'i ffurfweddu sy'n cyfateb i'r enw a nodir yn mx). Mae Max_age yn pennu amser caching y polisi (unwaith y bydd y polisi a gofiwyd yn cael ei gymhwyso hyd yn oed os yw'r ymosodwr yn rhwystro ei ddanfoniad neu'n llygru'r cofnodion DNS yn ystod yr amser caching, gallwch nodi'r angen i ofyn am y polisi eto trwy newid y mta-sts DNS cofnod).
Cyhoeddi cofnod TXT yn DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Gellir defnyddio dynodwr mympwyol (er enghraifft, stamp amser) yn y maes id; pan fydd y polisi yn newid, dylai newid, mae hyn yn galluogi anfonwyr i ddeall bod angen iddynt ail-wneud cais am y polisi wedi'i storio (os yw'r dynodwr yn wahanol i'r un cached).

Cefnogaeth MTA-STS ar ochr yr anfonwr

Hyd yn hyn mae'n ddrwg gyda hi, oherwydd ... safon ffres.

Exim - dim cefnogaeth adeiledig, mae sgript trydydd parti https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - nid oes cefnogaeth adeiledig, mae sgript trydydd parti a ddisgrifir yn fanwl ar Habré https://habr.com/en/post/424961/

Fel ôl-air am “TLS gorfodol”

Yn ddiweddar, mae rheoleiddwyr wedi bod yn rhoi sylw i ddiogelwch e-bost (ac mae hynny'n beth da). Er enghraifft, mae DMARC yn orfodol i holl asiantaethau'r llywodraeth yn yr Unol Daleithiau ac mae ei angen yn gynyddol yn y sector ariannol, gyda threiddiad y safon yn cyrraedd 90% mewn meysydd a reoleiddir. Nawr mae rhai rheolyddion yn gofyn am weithredu “TLS gorfodol” gyda pharthau unigol, ond nid yw'r mecanwaith ar gyfer sicrhau "TLS gorfodol" wedi'i ddiffinio ac yn ymarferol mae'r gosodiad hwn yn aml yn cael ei weithredu mewn ffordd nad yw hyd yn oed yn amddiffyn cyn lleied â phosibl rhag ymosodiadau gwirioneddol sydd eisoes yn bodoli. darperir ar ei gyfer mewn mecanweithiau fel DANE neu MTA-STS.

Os yw'r rheolydd yn gofyn am weithredu “TLS gorfodol” gyda pharthau ar wahân, rydym yn argymell ystyried MTA-STS neu ei analog rhannol fel y mecanwaith mwyaf addas, mae'n dileu'r angen i wneud gosodiadau diogel ar gyfer pob parth ar wahân. Os ydych chi'n cael trafferth gweithredu'r rhan cleient o MTA-STS (hyd nes y bydd y protocol wedi derbyn cefnogaeth eang, maen nhw'n fwyaf tebygol o wneud hynny), gallwn argymell y dull hwn:

Cyhoeddi polisi MTA-STS a/neu gofnodion DANE (mae DANE yn gwneud synnwyr dim ond os yw DNSSEC eisoes wedi'i alluogi ar gyfer eich parth, a MTA-STS beth bynnag), bydd hyn yn amddiffyn traffig yn eich cyfeiriad ac yn dileu'r angen i ofyn am wasanaethau e-bost eraill i ffurfweddu TLS gorfodol ar gyfer eich parth os yw'r gwasanaeth post eisoes yn cefnogi MTA-STS a/neu DANE.
Ar gyfer gwasanaethau e-bost mawr, gweithredwch “analog” o MTA-STS trwy osodiadau trafnidiaeth ar wahân ar gyfer pob parth, a fydd yn trwsio'r MX a ddefnyddir ar gyfer trosglwyddo post a bydd angen dilysu tystysgrif TLS yn orfodol ar ei gyfer. Os yw'r parthau eisoes yn cyhoeddi polisi MTA-STS, mae'n debygol y gellir gwneud hyn yn ddi-boen. Ar ei ben ei hun, mae galluogi TLS gorfodol ar gyfer parth heb drwsio'r ras gyfnewid a dilysu'r dystysgrif ar ei gyfer yn aneffeithiol o safbwynt diogelwch ac nid yw'n ychwanegu dim at y mecanweithiau STARTTLS presennol.

Ffynhonnell: hab.com

Mae post Mail.ru yn dechrau cymhwyso polisïau MTA-STS yn y modd prawf