SMTP TLS nélkül

Mit érdemelnek azok, akik még mindig ott tartanak, hogy a mail szerverük semmilyen TLS-t nem tud?

Hozzászólások

belső hálón mi is így adjuk át egyik smtp-től a másiknak a leveleket. gyorsabb úgy. kifele ilyet biztos nem csinálnánk

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Mit érdemel az a postás, aki átveszi továbbításra a lebélyegzett levelezőlapot?

Látod, amit nekem írtál, az sem kritikus, mégis https alatt jött-ment, tisztára pazarló módon. :-)

Én a gyermekvédelmiterrorizmus ürügyén követelem minden titkosítás megszüntetését, és switchek helyett hubok alkalmazását, hogy bárki ellenőrizhessen bárkit. Free tcp 80! Free nipple!

Semmit. Mivel a szabávny nem írja elő, nem kötelező. Mivel nem kötelező, nem büntetheted érte őket. Ez egy rövid fórumtopik lesz így, dobj be még valami controversary-t.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

...és egy csomó esetben tök értelmetlen erőforrást pazarolni rá, tök publikus cuccoknál semmi haszna nincs annak, hogy titkosítva töltöd le, az ingyenes cert-ek miatt pedig még értelmes védelem sincs, hogy tényleg onnan töltötted-e le, ahonnan akartad... amúgy a keresőmotorok és a böngészők prefereláják, ezért van értelme https szolgáltatni.

Azért  a publikus oldalak üzemeltetői sem örülnének ha egy köztes entitás a tartalomban lecserélné az "osztogatnak" szót "fosztogatnak"-ra. :)

Egyébként az SMTP-nél is "bűntet" pl. a Gmail (webmail) megjelöli egy piros bizbasszal ha nem TLS-el ment az MTA- között a levél:

https://support.google.com/mail/answer/7039474?hl=en-GB&ref_topic=72802…

> "bűntet" pl. a Gmail

annyira "imadom" hogy ezek a (majdnem) monopol cegek, google & microsoft buntetgetnek mindenfele miatt... aztan a legacy rendszereket uzemeltetok meg extra szopast kapnak ajandekba. legujabb hogy az o365 megkoveteli az spf-et akkor is, ha van dkim is. de miert? dkim megbizhatobb es jobb, altalaban kibirja a forwardot is szemben az spf-el. a webes buzisagaikrol mar nem is beszelve.

Azért  a publikus oldalak üzemeltetői sem örülnének ha egy köztes entitás a tartalomban lecserélné az "osztogatnak" szót "fosztogatnak"-ra. :)

Erre van a checksum ellenőrzés, az SSL egy erőforrásigényes dolog, égetjük a pénzt a semmiért, amikor egy csomó statikus és publikus dolgot SSL csatornán küldünk át.

A köztes ISP-k profilozása, tartalom alapú QoS stb mind sokkal nehezebb (mondjuk nem lehetetlen) HTTPS-en, szép példa rá:

https://www.mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_IdentifyingHTT…

Folyamatosan megy a cicaharc a kontent providerek az isp-k és a kormányzati szervek között.

Ez nem a HTTP feladata, mert az jogosan megbízik a TCP rétegben, ami automatikusan használ checksumot.

Az egy teljesen másik checksum, teljesen más célra. Ha MitM támadás van, akkor a TCP-nek lövése nincs arról, hogy rosszarcú kicserélte a tartalmat, mert TCP szinten minden tökéletes lesz. Akkor tudod, hogy kicserélte, ha alá van írva digitálisan, amit ellenőrizni tudsz vagy van rajta checksum, amit más csatornán kapsz meg és nem tudja kicserélni a rosszarcú.

Ha az alkalmazás még ezen felül akar még egy checksumot, akkor az legyen az alkalmazás gondja.

Erről van szó kb.

"egy csomó esetben tök értelmetlen erőforrást pazarolni rá, tök publikus cuccoknál semmi haszna nincs annak"

Ez azért nem feltétlen igaz. Ott felesleges erőforrást pazarolni rá, ahol az integritás ellenőrzés meg van oldva másképp. Ha letölti a csomagkezelő az rpm-et vagy deb-et, és tudja ellenőrizni, hogy tényleg az-e. Ha letöltöd az ISO-t, és megnézed a checksumot utána, hogy tényleg az az iso érkezett-e hozzád, és valaki út közben nem tett-e bele valami kis trójait.

"az ingyenes cert-ek miatt pedig még értelmes védelem sincs"

Ez hülyeség. Pont ugyanannyi a védelem az ingyenes certen, mint a nem teljesen cég-validált fizetősökön.

"Sose a gép a hülye."

Ha mondjuk ki van rá írva, hogy kazán karbantartás 20000 Ft, és ezt valaki út közben átírja 2000-re? Örülsz, kihívod az embert, megcsinálja, majd modja hogy 20000... Te meg mondod hogy 2000 volt. És akkor ha kötcsög vagy, akkor jöhet az, hogy vásárló megtévesztése és hasonló szarakodások.

Vagy fordítva: ő 20000-ért vállalja, de a konkurencia meg belenyúl, hogy te 40000-ret lássál, és így nem őt fogod hívni, azaz magának csinálja a bizniszt.

Tudom, ezek nagyon kisarkított dolgok és témák.... De ugye látszik a lényeg. Bármilyen információ akkor tekinthető validnak, ha biztos vagy benne, hogy ez szerepel ott, és onnan jön. Erre jó a HTTPS.

"Sose a gép a hülye."

Ott felesleges erőforrást pazarolni rá, ahol az integritás ellenőrzés meg van oldva másképp.

Meg lehetne oldani HTTP-n is.

Ez hülyeség. Pont ugyanannyi a védelem az ingyenes certen, mint a nem teljesen cég-validált fizetősökön.

Fel akarsz menni az otpbank.hu oldalra és elírod, az optbank.hu oldalt megvette a rosszarcú, csinált rá ingyenes cert, felépített egy proxy-t a bank felé, a böngésző szerint ez teljesen rendben lesz, téged meg kirabol. Mi ellen véd akkor? :)

Tudom, hogy ez meglepetésként ér sokakat, de a levelezés mint olyan, RFC szabványok által irányított technológia. Mind az SMTP (RFC 5321) mind pedig a levél MIME tartalma (RFC 822 / RFC 2822) elég kötött módon szabályozott dolog. És itt nincs olyan szabadosság, mint a böngészőknél, hogy majd mi jól leimplementálunk belterjes kis háziszabványokat, mert ha azt a levelezők többsége nem támogatja, akkor kiteheted az ablakba.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

mennyire jellemzo, hogy mail szerverek kozotti adatforgalmat lehallgatjak?

mennyire jellemzo, hogy titkokat titkositatlan emailben kuldozgetnek egymasnak?

"mennyire jellemzo, hogy mail szerverek kozotti adatforgalmat lehallgatjak?"

Pont annyira, mint ahogy a kliens-szerver vagy kliens-kliens közti kommunikációt.

"mennyire jellemzo, hogy titkokat titkositatlan emailben kuldozgetnek egymasnak?"

Ugye, mi is a "titok"? Egy emailben érkező 2FA auth? Egy elfelejtett jelszó link? Egy árajánlat, megrendelő? Egy bescannelt szerződés?

"Sose a gép a hülye."

mennyire jellemzo, hogy mail szerverek kozotti adatforgalmat lehallgatjak?

Most belenéztem a zeek smtp logjaiba, van benne pár .gov.hu-s cucc ami nem látta szükségességét a TLS-nek. Az egyik mondjuk pont elfelejtett jelszós linket küldözget így ami szerintem sem annyira faszányos. 
(amiben a három delikvens is egyezik az a JavaMail a Message-ID-ben :))

Ha versenyszféra lennék kiszámláznék még 20 milliárdot beszúrnék egy "mail.smtp.starttls.enable=true" sort. (mert úgy rémlik default az false :))

Ha csak levél fogadásra van, és nem kell neki auth, akkor minek?

ezek fqdn domain-ek publikus MX-ei.

Azaz levél fogadására vannak. Ezt jelenti, hogy valami publikus MX.

A relayhost nem kötelezően azonos az MX-szel, és jellemzően nem is szokott az lenni.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

kerdes, hogy van-e integritas ellenorzes.

pl. a debian letoltes utan csomagonkent ellenorzi az integritast, johet http-n is.

neked aztan fura humorod van...

jo, de amikor terveztek, nem gondoltak, hogy mimindenre lesz hasznalva, ezert nem tettek bele az integritas ellenorzest.

nagyobb problema, hogy most, hogy mar tudjak, hogy most mire van hasznalva, most sem minden uzemelteto hasznalja a lehetosegeket.

ha nincs ssl, legalabb dkim legyen.

neked aztan fura humorod van...

Vajon mennyi energiát lehetne megspórolni, ha 10 éven keresztül a világ összes levele hanyagolná a titkosítást és plain text -ben utaznva, kivéve azokat ahol a tudatos felhasználó PGP titkosítást használ? Mennyire lassabban melegedne a föld?

Vannak nagyobb gondok, az oktatásunk épp kibertámad :

ELTE: https://www.abuseipdb.com/check/157.181.151.89
Békés: https://www.abuseipdb.com/check/195.199.210.194
Tatabánya: https://www.abuseipdb.com/check/195.199.197.147
Böszörmény: https://www.abuseipdb.com/check/195.199.212.141

Még jó, hogy van kibervédelmi törvényünk és hozzá jogászaink (kár , hogy az ellen pont nem véd, de senkit nem hagyunk az út szélén :P)

az első IP érdekes:

ISPEotvos Lorand University of Sciences
Usage TypeUniversity/College/School
ASNAS2012 
Hostname(s)aleph.elte.hu 
 
Domain Namebme.hu
Country🇭🇺 Hungary
CityBudapest, Budapest

most akkor ELTE vagy BME?

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.