Nagyon köszönöm a választ! Ilyenkor mindig szégyenkezem kicsit, hogy rendszergazdának merem nevezni magam, ilyen nagy tudású kolléga mellett, de mentségemre legyen mondva, igyekszem azért fejlődni, tanulni és felnőni a feladathoz. Ebből a levélből is sokat tanultam ám!
A cím majdnem stimmel, de biztonsági okokból nem akarom nagy nyilvánosság előtt megosztani. A lényeg, hogy most már tudom merre lépjek tovább! Köszönöm, mégegyszer! Ha sikerült megoldanom a problémát vagy kideríteni az okát majd referálok. A megoldást úgy értem, hogy nem azt mondom "Használjon thunderbird"-öt :) Bár hozzáteszem, intelligens felhasználóról van szó, simán venné az akadályt :) Üdv, Venczel József > To: techinfo@lista.sulinet.hu > Subject: Re: Win10 - Outlook 2013 - SMTP + SSL > Date: Mon, 7 Mar 2016 09:29:05 +0000 > From: k...@mayten.sch.bme.hu > > > Szia, > > On 2016-03-07 07:32, Venczel József wrote: > > Tehát csak és kizárólag a Win10+Outlook illetve Win8.1+Outlook > > kombinációkkal nem megy a levélküldés. > > > > Ennel a mondatnal volt egy otletem, de aztan kiprobaltam kezzel es > megvaltozott a velemenyem. De azert leirom mindket gondolatot, mert a > masodik azon tul, hogy cafolja az elsot, nincs sok ertelme, ha win7 > alatt mukodik. Felteve, hogy titkositassal mukodik. > > Szoval elso korben arra gyanakodtam, hogy a szerver valamilyen regebbi, > nem biztonsagos openssl verziot hasznal. Mint az kozismert, az elmult > evben - masfel evben szamtalan ssl-lel kapcsolatos hiba derult ki - a > legutobbi a mult heten, ez a DROWN tamadas. De voltak korabban is: > heartbleed (CVE-2014-0160), POODLE (CVE-2014-3566), FREAK > (CVE-2015-0204), LogJam (CVE-2015-4000). Ezek szinte mindegyike ellen a > megoldas nem csak az volt, hogy tessek frissiteni az ssl-t, de az is, > hogy korabbi titkositasi algoritmusokat, kulcsmereteket elerhetetlenne > lehetett tenni. Tobb tamadas a felsoroltak kozul arra epult, hogy a > kulcsmeretet lecsokkentette a tamado megfelelo protokoll uzenetekkel, > illetve arra, hogy csokkentette az adott kapcsolat titkositasat, peldaul > SSLv2 szintig, ami mar regen nem elfogadhato. Ezek ellen tehat a > megoldas az volt, hogy a szerver nem fogad el bizonyos titkositasi > algoritmusnal gyengebbet, vagy bizonyos kulcsmeretnel rovidebbet. > > Ezeket a vedekezesi modszereket a kliens oldalon is meg kellett tenni, > tehat a bongeszokbe, levelezo programokba es ugy altalaban minden kliens > alkalmazasba epitett titkositast erintoen a fenti valtozasok > vegbementek. Letiltasra kerultek regi protokollok es a minimum > kulcsmeret megnott. > > Azok alapjan amit irsz, hogy ti. win 7 es tarsai alatt teljesen jol > mukozik (titkositassal!), de friss windowson nem, arra gondoltam, hogy a > kliensedben mar ezek a valtozasok megtortentek (alapertelmezetten a > friss rendszerben ezek a beallitasok) de a szerver oldalon ezek a > javitasok nem tortentek meg. Igy jelenleg nincs kozos algoritmus amit > beszelni tudnanak. > > A jelenseg ahhoz, hasonlatos, mintha ma egy korszeru (tls 1.2) https > webldalt IE6 -tal akarnek megnezni. Nem lehet, mert az IE6 nem ismeri > meg azokat a protokollokat, amiket ma hasznalunk. > > A levelben szerepelt a debrecen.hu, mint domain, aminek DNS szerint az > MX-e mx-in.debrecen.hu (193.6.184.23). Nem irtad, igy csak > feltetelezem, hogy ezt hasznalod az SMTP beallitasoknal. > > Azt irod SMTP+SSL, ez a 465-os portra utal, de ezen nem biztosit > szolgaltatasokat a szerver, igy szerintem STARTSSL -re gondolsz, amikor > a plain text kapcsolatbol a STARTSSL parancs hatasara varazsolodik > titkositott kapcsolat. A 25-os port ugyanis elerheto es bzitosit > szolgaltatasokat. > > Igy aztan megneztem, milyen titkositasokat tamogat es a fenti elmeletem > igazolasat latom: > > 193.6.184.29:443 > supports SSLv2 export ciphers > > Azaz a fenti IP cimen van egy HTTPS szerver is, ami kivulrol elfogad > SSLv2 titkositast is. Azaz minden jel arra utal, hogy a rajta levo > webszerver serulekeny, regi openssl verziot tamogat. Eselyes, hogy > ugyanaz a tanusitvany ugyanolyan beallitasokkal erheto el SMTP-re is, > igy egyszeruen arrol van szo, hogy a kliensed tul intelligens a szerver > elmaradottsagahoz kepest. > > Egy kicsit jobban megvizsgalva ezt a szervert, az latszik, hogy a > kulcshossza 1024 bites (regi, rovid), az alkalmazott hitelesites SHA1-re > epul (regi, nem megbizhato). > > Szoval az elso gondolatom a fenti volt. Aztan kiprobaltam kezzel is. A > 465-os porton nem valaszol semmi, a 25-oson pedig semmilyen > titkositasnak tuno optio nincs: > > 250-SIZE 500000000 > 250-PIPELINING > 250-8BITMIME > 250 HELP > startssl > 500 Syntax error, command unrecognized > > Igy aztan nem csoda, hogy nem mukodik a klienseddel. > > A helyedben egy wireshark-kal megneznem, pontosan mi tortenik a halozati > forgalomban, mikor nem mukodik, ugyanis ott le lesz irva pontosan az oka > mindennek (esetleg osszevetnem egy mukodo mintaval win7-rol). Ha ez > kliens oldali hibara utal, javitsd ki, ha nem, jelezd a szerver > uzemelteteoje fele. > > udv > adam > > > > > > > > > _______________________________________________ > Techinfo mailing list > Techinfo@lista.sulinet.hu > Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
_______________________________________________ Techinfo mailing list Techinfo@lista.sulinet.hu Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
