Mit érdemelnek azok, akik még mindig ott tartanak, hogy a mail szerverük semmilyen TLS-t nem tud?
- 1367 megtekintés
Hozzászólások
Nem kötelező, de mondjuk úgy, hogy illene így 2025-ben...
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Igen, kötelező. Általam üzemeltetett összes rendszerben az.
Persze ha valakinek nem fontos az email, akkor nem fog tőlem kapni és ő se nekem küldeni. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Belső hálón teljesen OK. Ez public net...
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Mit érdemel az a postás, aki átveszi továbbításra a lebélyegzett levelezőlapot?
- A hozzászóláshoz be kell jelentkezni
Emailben általában komolyabb dolgok mennek, nem csak annyi, hogy "Szia Mama, itt vagyunk a Balatonon, az idő remek, nagyon jól érezzük magunkat! Puszi, Öcsi"
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Legyen alapból titkosítatlan broadcast minden forgalom... az egész interneten :)
- A hozzászóláshoz be kell jelentkezni
Emailben általában komolyabb dolgok mennek, nem csak annyi, hogy "Szia Mama, itt vagyunk a Balatonon, az idő remek, nagyon jól érezzük magunkat! Puszi, Öcsi"
persze, ha meg rossz lesz az idő akkor egész nap csak gubbasztanak majd.
- A hozzászóláshoz be kell jelentkezni
Rossz az idő, egész nap a sátorban gubbasztunk.
A válasz:
Ó jaj... De mi az a gub?
- A hozzászóláshoz be kell jelentkezni
Én sem tudom, de nagyon sajnálom szegényt. :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
...é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.
- A hozzászóláshoz be kell jelentkezni
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…
- A hozzászóláshoz be kell jelentkezni
> "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.
- A hozzászóláshoz be kell jelentkezni
Speciel ennek a "büntetésnek" van értelme.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Az SPF és a DKIM másra való.
- A hozzászóláshoz be kell jelentkezni
Nyilván, hiszen az egyik HBR, a másik meg NBR. :-)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Erre van a checksum ellenőrzés
Már ha a HTTP tudna ilyet. De nem tud.
- A hozzászóláshoz be kell jelentkezni
Már ha a HTTP tudna ilyet. De nem tud.
Oszt? Lehetetlen belefejleszteni? Vagy a böngészőbe?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Hát, nem lehetetlen belefejleszteni - bár "fejleszteni" a szónak a köznapi értelmében nem kell, mert ez "csak" egy szabvány, abba csak beleírni kell dolgokat.
A probléma nehézségét pont ugyanaz adja, amiért a HTTPS kikényszerítése is kínlódik, amiért az IPv6 se terjedt el, hiába fogadkozott mindenki, hogy "ez lesz az új internet alapja". Egyszerűen túl sok eszköz használja ezt a protokollt, amihez már nincs semmiféle támogatás, support, de igény a létezésükre viszont van, és azok nem fognak egy ilyen változást tudni elkezelni. Ugyanúgy szét fog hasadni a világ a HTTPC-t (HTTP with checksum) használó és nem használó részekre. És ugyanúgy szopás lesz a visszafelé kompatibilitás, mint ahogy most a böngészőknél szopás van, ha valami olyasmit akarsz elérni, ami nem HTTPS hanem HTTP felett van.
Aztán egy szép napon változik a checksum mögötti kriptográfiai technológia, és a most tök jó Win11-es gépem többé nem fog tudni kommunikálni a világ többi részével, ahogy a Windows 98-ak sem tudnak kommunikálni a mai internettel.
Ismerjük már ezt a történetet, és a történelem sajnos olyan, mint a Hallmark műsora: jórészt isméltésekből álll.
- A hozzászóláshoz be kell jelentkezni
Oké, is ki és hogyan mondja meg a checksum-ot, amivel egyeznie kell a tartalom helyben checksum számolt értékének?
Röviden a kérdésre is válaszolva: nem, nem lehetetlen, hanem totálisan fölösleges. Pláne, hogy a http nem állapottartó protokoll, azaz egy darab kérés - egy darab válasz és ennyi. Te azt szeretnéd, hogy mellé legyen még egy másik, hiteles/védett csatorna, amiben a checksum "utazik", amit mindkét oldalon számolni kell... Ha két lépést hátrébb lépsz, látható az ötleted khm. nem átgondoltsága...
- A hozzászóláshoz be kell jelentkezni
Ez nem a HTTP feladata, mert az jogosan megbízik a TCP rétegben, ami automatikusan használ checksumot.
Ha az alkalmazás még ezen felül akar még egy checksumot, akkor az legyen az alkalmazás gondja.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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."
- A hozzászóláshoz be kell jelentkezni
Sarki víz/gáz/fűtésszerelő csak informálódásra szolgáló honlapja (nincs reg, és statikus az egész) ugyan mi a francnak lenne https?
Más kérdés, hogy ez mára már egy kb. kihalt műfaj, amióta a facebook-ra költöztek ezek.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Erre jó a HTTPS.
Egyrészt nem mindenre jó, másrészt van más technológia is arra, hogy észre vedd, ha nem azt kapod, amit kértél.
- A hozzászóláshoz be kell jelentkezni
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? :)
- A hozzászóláshoz be kell jelentkezni
Aki egy ilyen csinál, szerinted az tartja vissza, hogy ki kell fizetni 10 000 Forintot egy certért? Nem hiszem...
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Az ellen véd, hogy felmész egy akármilyen wifi-re, ahol dns kamu IP-re visz. Nem akkor, amikor hülye vagy és más oldalt gépelsz be, hanem akár könyvjelzőből kattintasz az igazi otpbank.hu oldalra.
HTTP-n egy ilyen MITM támadást úgy benyelsz, ahogy kell, esélyed sincs kivédeni. HTTPS-en pedig a támadónak nincs esélye sem átverni, mert képtelen érvényes cert-et csinálni az otpbank.hu oldalra, hiába irányitja a DNS-t és a teljes forgalmadat.
- A hozzászóláshoz be kell jelentkezni
ez igaz. Ma is, pl nagyon sok repo ad http-t is, pont azert mert pl a checkum, vagy a gpg alairas miatt igazabol semmi szukseg a https-re... es amugy sok esetben jobb is, meg ceges kornyezetben is a http repo...
- A hozzászóláshoz be kell jelentkezni
És persze ha a checksum ugyanazon az SSL nélküli oldalon van, akkor nem sokra mész az ellenőrzéssel sem :D
- A hozzászóláshoz be kell jelentkezni
Így van, de ez már más téma.
Emiatt pl. repónál a gpg kulcsot mindig HTTPS-sel adom meg, a csomagok meg jöhetnek HTTP-n.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Nagyon jól mondod. Van két full publik weblapam, azért voltam kénytelen ezt a https szart belegányolni, hogy a gugli megjelenítse. Esetemben SEMMI SZÜKSÉG TITKOSÍTÁSRA. Nem kicsit túl van tolva ez a bicikli.
- A hozzászóláshoz be kell jelentkezni
onellentmondas :)
- A hozzászóláshoz be kell jelentkezni
Miért? Részleteznéd? Nincs belépés, semmilyen személyes adatot nem kezelek. Mi a fasznak ehhez https ???
Vagy titkosítsuk a szórólapokat is? Mondjuk én inkább betiltanám.
- A hozzászóláshoz be kell jelentkezni
semmi szukseg vs. KENYSZERITETTEK!!!!1111 :D
akkor most vo't szukseg vagy nem vo't szukseg? :D
hogy a klasszikust idezzem: megszoksz vagy megszoksz. :)
- A hozzászóláshoz be kell jelentkezni
TLS nélkül az, hogy mit szolgáltat a webszervered, mint tartalom, és adott URL-en mit lát az arra tévedő, mint tartalom... Nos az attól függ, hogy a kliens valóban a megfelelő ip-címet kapja vissza az általa használt dns szervertől, és a tartalom, amit kér, áthalad-e egy transzparens, tartalmat módosító proxy-n vagy sem. Semmi és senki nem garantálja, hogy a kérés, ami a webszerveredhez érkezik, az valóban arról az IP-ről indult, amit látsz, és azt sem, hogy amit a webszervered kibüfög magából, az jut el a kliens böngészőjéhez.
- A hozzászóláshoz be kell jelentkezni
Miért, ha a szabvány előírja, akkor kötelező?
És milyen szabvány?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Van ami pont attól működik, ha kiteszed az ablakba, pl. RFC 1149 és RFC 2549. :-)
- A hozzászóláshoz be kell jelentkezni
Hát, ja, de melgepően kevés levelező támogatja is ezeket. :P
- A hozzászóláshoz be kell jelentkezni
itt nincs olyan ... hogy majd mi jól leimplementálunk belterjes kis háziszabványokat
o, dehogynem!
ha azt a levelezők többsége
eleg ha az outlyuk tamogatja, a tobbi meg majd szepen alkalmazkodik. lasd pl winmail.dat es hasonlo ms okossagok. vagy az if-ek a html mailekben. es meg hosszan sorolhatnam...
a MIME rfc is olyan mint az alsogatya, folyton cserelgetik...
levelezsnel az smtp es mime rfc-k pont annyit ernek, mint webnel a http protokoll rfc-je. de a tartalom ugyanugy a dominans kliens programok (bongeszoknel regen az msie, manapsag a chrome motor, levelezesnel az outlook) egyeni ertelmezesen es haziszabvanyain mulik...
- A hozzászóláshoz be kell jelentkezni
"levelezés mint olyan"
Nincs ilyen hogy levelezés, van IMAP, meg SMTP, meg MAPI, stb...
"RFC szabványok"
Persze. Szép is lenne. Én még emlékszek arra is, amikor az Exchange olyan "tájszólással" beszélt SMTP-ül, hogy külön állítani kellett a postfixon hogy működjön. Meg arra is, hogy a dovecot-ban volt konkrét opció az outlook express szarságainak bekapcsolásához.
"majd mi jól leimplementálunk belterjes kis háziszabványokat"
Pedig ugyanerről szól. Ha próbáltál már valaha is egy "komolyabban" formázott levelet, vagy email sablon csinálni... Akkor tudod mekkora orbitális szopás.
"ha azt a levelezők többsége nem támogatja"
Pontosan ezért van a mai napig pl. az összes hírlevél html table-el összekókányolva, mert azt minden tudja, míg pl. a div-et nem..
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
itt nincs olyan szabadosság, mint a böngészőknél, hogy majd mi jól leimplementálunk belterjes kis háziszabványokat
Ha jól értem, akkor valahol közben témát váltottunk, és már nem arról az emailforgalomról van szó, ami világszerte egy 2-3 cég között felosztott oligopólium, ugye? :D
- A hozzászóláshoz be kell jelentkezni
Az RFC-k semmelyik része nem kötelező. Nem mindenki tartja magát hozzá - lásd pl: Microsoft.
Én meg büntetem érte őket. Nem friss találmány az SMTP TLS. Egyszerű lustaság és hozzáértés hiánya a túloldalon.
- A hozzászóláshoz be kell jelentkezni
mennyire jellemzo, hogy mail szerverek kozotti adatforgalmat lehallgatjak?
mennyire jellemzo, hogy titkokat titkositatlan emailben kuldozgetnek egymasnak?
- A hozzászóláshoz be kell jelentkezni
"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."
- A hozzászóláshoz be kell jelentkezni
Pont annyira, mint ahogy a kliens-szerver vagy kliens-kliens közti kommunikációt.
Tökéletes válasz, az ember ebből mindent megtud, ami rá tartozik: semmit.
- A hozzászóláshoz be kell jelentkezni
Elvileg szakmabeli vagy, nem hiszem hogy túl kéne magyarázni. Tök mindegy, hogy ki kommunikál kivel, ha nincs end-to-end encryption, akkor út közben bárhol lehallgathajták, és akár bele is tudnak nyúlni.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
"Egy elfelejtett jelszó link? Egy árajánlat, megrendelő? Egy bescannelt szerződés?"
-elviszem a linkedet, és én cserélek jelszót... Utána a fiókhoz tartozó címet cserélem le... Elég, ha a megfelelő levél pár percet "késik".
-Árajánlat, megrendelő, szerződés.. Hint: üzleti titok. Illetve lehet még személyes adat is...
- A hozzászóláshoz be kell jelentkezni
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 :))
- A hozzászóláshoz be kell jelentkezni
haaat, attol fugg mikori az a java. mert ha csak valami regi, konnyen torheto titkositot tud, nem vagyunk sokkal beljebb.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Mintha a JavaMail-nak bármennyi köze is lenne a levélkézbesítéshez, úgy csináltok. :D
A JavaMail az a levél feladásáért felel egy céges belső levelezőszervernek, de ő közvetlenül nem képes még az MX rekordot sem lekérdezni, hogy hova kell kézbesíteni. Még ha LAN-ról TLS-sel is adsz fel (ami localhostra pl felesleges is), az se jelent garanciát arra, hogy az edge SMTP szerver hogy kézbesít.
Srácok-srácok, én értem a humort, de ez most nem volt vicces.
- A hozzászóláshoz be kell jelentkezni
Igen, mindhárom esetben a JavaMail feladja egy belső postfixnak (TLS nélkül), ami kézbesíti (szintén TLS nélkül).
Csak paranoia kérdése, hogy LAN-on belül érdemes-e titkosítani, szerintem igen. :)
Az meg egy másik kérdés, hogy mennyire kibervédelmi püttypürütty kompatibilis az intranetes Received fejléceket a kiküldött levélben bennehagyni ;)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Igen, pont a .gov.hu alatti levelezés az, ami 1000 sebből vérzik. Rengeteg hivatal, állami szerv. Hozzáértés és szakember hiány miatt nem is értik, hogy mi a baj mondjuk az SSL 3.0-val (megtörtént eset alapján írom).
Ha kellően komolyan vennék ott az IT biztonságot, akkor TLS 1.2-nél gyengébb (cipherekre most nem térek ki) gyengébb SMTP / HTTP kommunikációt nem is kellene engedniük.
- A hozzászóláshoz be kell jelentkezni
- Sajnos elég jellemző.
- Ez is elég jellemző. Sajnos. Fogom a fejem, amikor ilyet látok.
- A hozzászóláshoz be kell jelentkezni
Ha csak levél fogadásra van, és nem kell neki auth, akkor minek?
- A hozzászóláshoz be kell jelentkezni
Nem csak levél fogadására van, ezek fqdn domain-ek publikus MX-ei.
Egyébként meg, teljesen mindegy hogy csak fogadásra van.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
És persze az MX mire való? Fogadásra :D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Azaz levél fogadására vannak"
Tehát nem tudok neki TLS-sel levelet küldeni.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
kerdes, hogy van-e integritas ellenorzes.
pl. a debian letoltes utan csomagonkent ellenorzi az integritast, johet http-n is.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Az SMTP alapból erre semmi metódust nem ad, ezért akkora szopás a spam, és ezért kellett mindenféle utólagos meg külső megoldásokat bele/hozzátenni.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Az csak a módosítás ellen véd, a lehallgatás ellen nem.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
"ezért akkora szopás a spam"
ezen meg az ssl nem segit :)
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
kb egy AI kérdésre adott választ :-)
- A hozzászóláshoz be kell jelentkezni
Vajon mennyi energiát lehetne megspórolni...
És akkor mennyi levelező lenne hirtelen közvetlenül, vagy közvetve open relay? Akkor mennyi spam szabadulna el? Azokat mennyi energia lenne minden switchen, routeren, ASR-en...stb átszállítani, mert MTA oldalon nincs szűrve? Mennyi plusz erőforrás kellene ahhoz, hogy a titkosítás hiánya miatt elszabadult spameket az ISP-k szállítszák, adott esetben ügyfeles postafiókban tárolják, backupolják? Aztán a felhasználók végignézzék?
Ha címzett oldalon akarod inkább kezelni a spameket, akkor ezen felül mennyi plusz energia a klienseken a spamszűrők futtatása?
Mennyire lassabban melegedne a föld?
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
Ha nem létezne email SPAM, akkor sokkal több energiát megspóroltunk volna az elmúlt ~30 évben.
- A hozzászóláshoz be kell jelentkezni
es ha szorolap/oriasplakat/whatever sem, akkor meg sok sok hektar erdot is... :)
- A hozzászóláshoz be kell jelentkezni
Greenpeace "szakértőket" kellene megkérdezni, hogy melyik a károsabb:
- szórólap / óriásplakát
- email spam
- A hozzászóláshoz be kell jelentkezni
A Greenpeace "szakértőket" meg a szórólapozókat meg a spammereket is tűzzel-vassal kell írtani.
- A hozzászóláshoz be kell jelentkezni
es utana mi? a kevesbe fosabbat engedni? vagy mire gondol a kolto? :D
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
az első IP érdekes:
| ISP | Eotvos Lorand University of Sciences |
|---|---|
| Usage Type | University/College/School |
| ASN | AS2012 |
| Hostname(s) | aleph.elte.hu |
| Domain Name | bme.hu |
| Country | 🇭🇺 Hungary |
| City | Budapest, 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.
- A hozzászóláshoz be kell jelentkezni
Szerintem csereberélték egymás közt az IP-ket, csak az adminisztráció senkinek nem erős oldala.
- A hozzászóláshoz be kell jelentkezni
vagy egyik sem, mert a niiifi-tol - vagy kifu vagy epp hogy a tokombe hivjak hivatalosan az egyetemi halo karbantartojat - kapjak, nem az ovek a subnet :)
- A hozzászóláshoz be kell jelentkezni
Publikus szolgáltatásnál valóban gáz, belső levelezésnél nem. Ha ennyire zavar a hiánya az adott szolgáltatónál, akkor titkosítsd a leveleid PGP-vel.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Amit a userek (=levelező emberek) 95%-a azt se tudja, hogy eszik-e vagy isszák, ráadásul nem tudom a thunderbird-ön kívül milyen a támogatottsága most, de jópár éve pocsék volt.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Szeremcsére nem csak PGP, hanem S/MIME titkosítás is létezik, ami ráadásul szabványos is, és elég sok levelező támogatja, csak hát ilyen tanusítvány izéket kell csinálni, amitől az openszósz huszárok ódzkodnak.
- A hozzászóláshoz be kell jelentkezni
csak hát ilyen tanusítvány izéket kell csinálni, amitől az openszósz huszárok ódzkodnak.
Rábíznád az életed arra a feltételezésre, hogy ha mondjuk elég magas szinten ki akarnak cseszni veled, akkor a Krajowa Izba Rozliczeniowa nevű közismert root CA nem fog kiadni a támadónak egy certet?
- A hozzászóláshoz be kell jelentkezni
Ha az említett ca üzleti értékével összemérhető, de célszerűen annál magasabb összegű pénzt kap, akkor talán kibocsátja. Ilyen alapon dr. Görcs-Pennahuszár Béla közjegyzőben sem bízhatsz meg, mert ugye... Mindenkinek, mindenki becsületének van egy ára.
- A hozzászóláshoz be kell jelentkezni
És akkor mi van? Mivel az email-forgalomban nem kötelező a TLS, hanem opcionális, az egyetlen biztos megoldás, ha azt feltételezzük, hogy a levélforgalomban nincs titkosítás, minden más hamis biztonságérzet. Inkább ezt kéne tudatosítani mindenkiben, mint azon keseregni, puffogni, hogy nem tud minden mailserver TLS-t.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg aki nem tud egy TLS-t bekapcsolni, beállítani, az ne üzemeltessen mail szervert. Annak tökéletes a gmail, vagy az office365...
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Örülök annak, hogy kihangsúlyoztad, hogy szerinted. Egyébként korántsem biztos, hogy valaki nem tud TLS-t bekapcsolni, gondolhatja azt is, hogy az esetleges nyereség nem éri meg.
- A hozzászóláshoz be kell jelentkezni
olyan ez, mint a backup, addig csak viszi a pe'zt, amig nem vo't ra szukseg :)
- A hozzászóláshoz be kell jelentkezni
+1000
- A hozzászóláshoz be kell jelentkezni
PGP-t tudsz akkor is használni, ha a levelező nem támogatja. Persze, kicsit kényelmetlen, mert be kell illesztened az előre megírt email szövegét, azt CLI-ben titkosítani OpenPGP-vel, majd azt illesztgetni a mailkliensbe, sok embernek, akik egybitesek, meg lusta egy GUI gombklikkelősek, azoknak kapásból dealbreaker lehet, de aki biztonságtudatos, annak egy valós alternatíva. Plusz még első használatkor tanúsítványokkal, kulcslétrehozással is kell szívni, természetesen, de ez ott van akkor is, ha a levelezőprogram tudja a PGP-t.
Akár még automatizálni is lehet, hogy bedrótozod gyorsbillentyűre, egy scriptként, kijelölöd a szöveget, gyorsbillentyű benyom, a script lefuttat mindent, titkosít, végül lecseréli a szöveget a titkosított verzióra.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
és mit érdemel az akié tud, de csak valamilyen ma már - nem ok nélkül - ritkán látható cipherrel, ami miatt az én tls-es smtp-m bár elkezdi a handshaket, de nem sikerül, és mivel szabvány szerint unencryptedre visszaváltani nem lehet, nem megy el a levél?:)
- A hozzászóláshoz be kell jelentkezni
Jó, hát ilyet én is tudok mondani. :)
Átírja az SMTP bannert MERT ÚRISTEN SECURITY ÉS MEGLÁTJÁK HOGY POSTFIX!!!4 Átírja "mailserver"-re... Amiben nincs benne hogy ESMTP, és ugye rá se próbál a TLS-re a másik oldal, mert ha nem ESMTP, akkor nem is tudhatja.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
"MERT ÚRISTEN SECURITY ÉS MEGLÁTJÁK HOGY POSTFIX!"
Nagyon nem mindegy, hogy tudjuk, kivel beszélgetünk, és célzottan lehet támadni, vagy csak azt tudjuk, hogy xyz tcp porton beküldött kérésre válaszol valami.
- A hozzászóláshoz be kell jelentkezni