Forum » Informacijska varnost » SMTP TLS enkripcija
SMTP TLS enkripcija
SeMiNeSanja ::
Vprašanje za eksperte s tega področja....
Ker imam to možnost, sem na požarni pregradi vključil 'enforce TLS encryption' za SMTP protokol. To dejansko povzroči, da mi požarna pregrada zavrne vse pošiljatelje, ki TLS enkripcijo ne podpirajo.
Rezultat tega je, da se je količina spama v hipu zmanjšala za več kot 90%.
Me je pa nekoliko strah, da mi to ne bo 'poradiralo' tudi legitimno pošto s strežnikov, ki TLS enkripcijo nebi podpirali. Koliko je ta strah upravičen?
Kot sem do sedaj opazil, legitimne strežnike brez TLS podpore zavrne, na kar ti poskušajo dostaviti pošto preko sekundarnega strežnika navedenega v MX zapisu (providerjev strežnik). Ker ta TLS podpira, se ta sporočila kljub temu dostavijo (pride do nekaj zamude pri dostavi).
Nisem pa 100% prepričan, da se res nič ne more izgubiti.
Ima kdo izkušnje s tem področjem? Kakšne?
Vključil sem tudi TLS enkripcijo za pošto, ki jo sam pošiljam, vendar sem tu raje bolj previden in sem izbral opcijo 'preferred' namesto 'required'. Predvidevam, da marsikdo nima urejenega sekundarnega MX-a preko ponudnika in bi prihajalo do nezmožnosti pošiljanja, če nasprotna stran ne podpira TLS.
Ker imam to možnost, sem na požarni pregradi vključil 'enforce TLS encryption' za SMTP protokol. To dejansko povzroči, da mi požarna pregrada zavrne vse pošiljatelje, ki TLS enkripcijo ne podpirajo.
Rezultat tega je, da se je količina spama v hipu zmanjšala za več kot 90%.
Me je pa nekoliko strah, da mi to ne bo 'poradiralo' tudi legitimno pošto s strežnikov, ki TLS enkripcijo nebi podpirali. Koliko je ta strah upravičen?
Kot sem do sedaj opazil, legitimne strežnike brez TLS podpore zavrne, na kar ti poskušajo dostaviti pošto preko sekundarnega strežnika navedenega v MX zapisu (providerjev strežnik). Ker ta TLS podpira, se ta sporočila kljub temu dostavijo (pride do nekaj zamude pri dostavi).
Nisem pa 100% prepričan, da se res nič ne more izgubiti.
Ima kdo izkušnje s tem področjem? Kakšne?
Vključil sem tudi TLS enkripcijo za pošto, ki jo sam pošiljam, vendar sem tu raje bolj previden in sem izbral opcijo 'preferred' namesto 'required'. Predvidevam, da marsikdo nima urejenega sekundarnega MX-a preko ponudnika in bi prihajalo do nezmožnosti pošiljanja, če nasprotna stran ne podpira TLS.
AndrejO ::
Pravilno sklepaš. Čeprav največji uporabljajo TLS pri pošiljanju in prejemanju sporočil, je še zdaleč ne uporabljajo vsi. Samo pomisli na vse administratorje, ki imajo strežnike, kot ga imaš ti in, ki jim še ni padlo na misel, da bi vključili TLS.
Če boš za dohodno pošto zahteval TLS, pošiljatelj pa tega ne bo podpiral, potem pošta ne bo dostavljena. Pošiljatelj bo praviloma (odvisno od nastavitev strežnika na njihovi strani) obveščen, da sporočilo ni bilo dostavljeno, ti pa o temu verjetno ne boš vedel nič.
Če boš za odhodno pošto zahteval TLS, prejemnik pa tega ne bo podpiral, potem pošta tudi ne bo dostavljena. O temu bo znova obveščen pošiljatelj (če boš svoj strežnik tako nastavil), kot vzdrževalec strežnika pa boš lahko v dnevniških zapisih videl kdaj in pri komu je do tega prišlo, še preden bo sporočilo odstranjeno iz odhodne čakalne liste.
Če boš za dohodno pošto zahteval TLS, pošiljatelj pa tega ne bo podpiral, potem pošta ne bo dostavljena. Pošiljatelj bo praviloma (odvisno od nastavitev strežnika na njihovi strani) obveščen, da sporočilo ni bilo dostavljeno, ti pa o temu verjetno ne boš vedel nič.
Če boš za odhodno pošto zahteval TLS, prejemnik pa tega ne bo podpiral, potem pošta tudi ne bo dostavljena. O temu bo znova obveščen pošiljatelj (če boš svoj strežnik tako nastavil), kot vzdrževalec strežnika pa boš lahko v dnevniških zapisih videl kdaj in pri komu je do tega prišlo, še preden bo sporočilo odstranjeno iz odhodne čakalne liste.
fujtajksel ::
Zelo hecno, da si v post-snowdenovski dobi še vedno pošiljamo e-pošto na nivoju razglednic ;)
OmegaBlue ::
Razen to, da tvoj strežnik potem krši RFC 3207 bi mogla vsa pošta prispet do tebe, saj jo bo vsak proper smtp strežnik dostavil na sekundarni MX, ki se bo obnašal pravilno in jo posredoval tebi.
Bo pa tako kot omenjeno zgoraj pošiljatelj obveščen o tem, da potša ni bila dostavljena (če bi prišlo do tega), seveda z nekaj zamika.
Bo pa tako kot omenjeno zgoraj pošiljatelj obveščen o tem, da potša ni bila dostavljena (če bi prišlo do tega), seveda z nekaj zamika.
Never attribute to malice that which can be adequately explained by stupidity.
Zgodovina sprememb…
- spremenil: OmegaBlue ()
AndrejO ::
fujtajksel je izjavil:
Zelo hecno, da si v post-snowdenovski dobi še vedno pošiljamo e-pošto na nivoju razglednic ;)
Pa jo daj v kuverto, če ne zaupaš lokalnem poštarju. TLS je flika, ki za prvo silo skrije "metapodatke" (oz. podatke o prometu) pred neiznajdljivimi lokalnimi administratorji, sicer pa v trenutnem stanju ne rešuje veliko.
Razen to, da tvoj strežnik potem krši RFC 3207 bi mogla vsa pošta prispet do tebe, saj jo bo vsak proper smtp strežnik dostavil na sekundarni MX, ki se bo obnašal pravilno in jo posredoval tebi.
Meh, sekundarni in vsak naslednji MX je nerelevanten, ker bi moral tudi ta čisto lepo omogočati TLS. Ni razloga, da bi imel nekaj strežnikov z TLS, nekaj pa brez TLS.
Nedosegljivost MX-a, ki ima najvišjo prioriteto, pa je še vedno učinkovit recept za odvračanje SPAM sporočil, ki jih pošiljajo brezumni roboti, ki vse ostale MX-e preprosto ignorirajo. Če se bo začel ta recept množično uporabljati, se boto roboti zelo hitro popravili, da bo postal neučinkovit. TLS pri tej zgodbi nima veliko.
SeMiNeSanja ::
Vsaj za enkrat ne opažam, da kakšen legitimni mail nebi bil dostavljen.
Ravno tako mi še nihče ni javil, da bi prejel obvestilo o nedostavljivosti pošte.
Se je pa razmerje legitimne/spam pošte spremenil iz 40% na 88%, pa še tega je 2/3 v kategoriji Bulk mail.
Me pa malo jezi to neskladje z RFC 3207, saj predvidevam, da se bo vsul plaz spama takoj, ko bom prestavil na TLS enkripcijo na 'preferred'.
Dejansko v RFC-ju dobesedno piše "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.", kar po svoje vsiljuje 'preferred' opcijo.
Vendar pa navaja kot razlog "This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure". Ta 'Interoperabilnost' pa je vendarle deloma pokrita preko sekundarnega MX strežnika, ki pa sprejema tudi pošto z 'nekompatibilnih' strežnikov.
Po svoje bi mi bilo ljubše, če bi v RFC pisalo "Any internet facing mail server must support STARTTLS". Žal smo od tega očitno še nekaj Snowdenov oddaljeni.
Dilema je torej ustreči RFC-ju (v celoti) ali ne. Kakšno menite?
P.S. - sam spam sicer učinkovito filtriram lokalno v karanteno, tako da 'plaz' nebi pomenil konec sveta.
Je pa tako lepo videt, ko je karantena praktično prazna!
Ravno tako mi še nihče ni javil, da bi prejel obvestilo o nedostavljivosti pošte.
Se je pa razmerje legitimne/spam pošte spremenil iz 40% na 88%, pa še tega je 2/3 v kategoriji Bulk mail.
Me pa malo jezi to neskladje z RFC 3207, saj predvidevam, da se bo vsul plaz spama takoj, ko bom prestavil na TLS enkripcijo na 'preferred'.
Dejansko v RFC-ju dobesedno piše "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.", kar po svoje vsiljuje 'preferred' opcijo.
Vendar pa navaja kot razlog "This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure". Ta 'Interoperabilnost' pa je vendarle deloma pokrita preko sekundarnega MX strežnika, ki pa sprejema tudi pošto z 'nekompatibilnih' strežnikov.
Po svoje bi mi bilo ljubše, če bi v RFC pisalo "Any internet facing mail server must support STARTTLS". Žal smo od tega očitno še nekaj Snowdenov oddaljeni.
Dilema je torej ustreči RFC-ju (v celoti) ali ne. Kakšno menite?
P.S. - sam spam sicer učinkovito filtriram lokalno v karanteno, tako da 'plaz' nebi pomenil konec sveta.
Je pa tako lepo videt, ko je karantena praktično prazna!
Zgodovina sprememb…
- spremenilo: SeMiNeSanja ()
OmegaBlue ::
Well v njegovem primeru ima podoben efekt. S tem ko forsira TLS polomi kliente, ki tega ne podpirajo (roko na srce večina bi jih mogla). Količina končnega spama je potem odvisna od tega koliko spam botov ne pozna TLS ampak zna poslat na sekundarni MX in pride mimo spam filtrov ponudnika.
Za kaj takega potem skoraj raje ustvarim bogus MX zapis z najvišjo prioriteto in na svojem serverju lepo omogočim tudi kliente brez TLS, kot pa da polomim konfiguracijo strežnika.
Za kaj takega potem skoraj raje ustvarim bogus MX zapis z najvišjo prioriteto in na svojem serverju lepo omogočim tudi kliente brez TLS, kot pa da polomim konfiguracijo strežnika.
Never attribute to malice that which can be adequately explained by stupidity.
OmegaBlue ::
@SeMiNeSanja
RFC ne domneva, da imaš sekundarni MX, pač pa zahteva maksimalno kompatibilnost.
Bogus primarni MX je tak lušten hack, ki izkorišča failover mehanizme znotraj SMTP in glupe spambote, ki tega ne podpirajo.
Seveda gre kompletna uporabnost v kanto ko spamerju ni več pomembna količina poslanega ampak procent dejansko dostavljene pošte. Tam še potem prideš na območje spear-phishinga. Za običen bulkmail je preverjanje sekundarnega MX preveč potratno.
P.S.
Sicer se večkrat opazi spambote, da pošiljajo mail na MX z nižjo prioriteto v upanju da ima slabše spam filtre.
RFC ne domneva, da imaš sekundarni MX, pač pa zahteva maksimalno kompatibilnost.
Bogus primarni MX je tak lušten hack, ki izkorišča failover mehanizme znotraj SMTP in glupe spambote, ki tega ne podpirajo.
Seveda gre kompletna uporabnost v kanto ko spamerju ni več pomembna količina poslanega ampak procent dejansko dostavljene pošte. Tam še potem prideš na območje spear-phishinga. Za običen bulkmail je preverjanje sekundarnega MX preveč potratno.
P.S.
Sicer se večkrat opazi spambote, da pošiljajo mail na MX z nižjo prioriteto v upanju da ima slabše spam filtre.
Never attribute to malice that which can be adequately explained by stupidity.
AndrejO ::
Skratka: če se mu da, naj poskusi ustaviti primarni MX in bo videl, da je SPAM rate še vedno enako nizek. Brezpogojno zahtevati TLS je pač samo način kako se znebiti množice primitivnih botov.
Obe recepturi pa bosta propadli, ko bo to začelo početi dovoljšnjo število prejemnikov. Torej se izplača že danes gledati alternative za ta dan, ki bo slej, kot prej prišel.
Obe recepturi pa bosta propadli, ko bo to začelo početi dovoljšnjo število prejemnikov. Torej se izplača že danes gledati alternative za ta dan, ki bo slej, kot prej prišel.
SeMiNeSanja ::
Nekako imam občutek, da bom TLS enkripcijo prestavil na 'preferred'.
Dejansko mi več pomeni promptna dostava maila (brez delayev), kot pa prazna spam karantena, pa naj bo še tako lepo za videt.
Iz istega razloga tudi ne maram greylistinga, ki vnaša nepotrebne delaye (in še kake druge težave).
Tudi bogus MX vnaša delay pri dostavi, ki ga ne želim imeti.
Zoprno je namreč nekomu nuditi tehnično podporo in pri tem čakat, kdaj misli prispeti mail s screenshotom njegovih težav.
Dejansko mi več pomeni promptna dostava maila (brez delayev), kot pa prazna spam karantena, pa naj bo še tako lepo za videt.
Iz istega razloga tudi ne maram greylistinga, ki vnaša nepotrebne delaye (in še kake druge težave).
Tudi bogus MX vnaša delay pri dostavi, ki ga ne želim imeti.
Zoprno je namreč nekomu nuditi tehnično podporo in pri tem čakat, kdaj misli prispeti mail s screenshotom njegovih težav.
AndrejO ::
Po mojih logih, kadar mi je primarni MX obtičal, je bila ta zakasnitev vsaj pri velikih (gmail.com, gmx.de in yahoo.com) nekaj sekund. Če strežnik ne deluje, potem gre klient zelo hitro na naslednjega v vrsti, ker nima razloga, da bi čakal ure in ure, če se bo prvi slučajno zbudil.
Bi pa moral za boljšo oceno "stanja" pregledati kako se obnašajo pogosto uprabljeni MTA-ji, a-la sendmail, postfix, exim in še kakšen.
Bi pa moral za boljšo oceno "stanja" pregledati kako se obnašajo pogosto uprabljeni MTA-ji, a-la sendmail, postfix, exim in še kakšen.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Pošiljanje emaila na @siol.netOddelek: Pomoč in nasveti | 4928 (4097) | SeMiNeSanja |
| » | Poštni strežnik in nedosegljivostOddelek: Omrežja in internet | 6400 (5716) | jype |
| » | Googlovo opozarjanje na nešifrirano e-pošto povečalo delež šifriraneOddelek: Novice / Omrežja / internet | 5333 (3834) | Furbo |
| » | SMTP promet (strani: 1 2 3 4 )Oddelek: Omrežja in internet | 18862 (16913) | NeMeTko |
| » | e-mail serverOddelek: Omrežja in internet | 2249 (1790) | 'FireSTORM' |