Win10 - Outlook 2013 - SMTP + SSL

2016. Már. 7., H, 11:24:26 CET

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 at lista.sulinet.hu
> Subject: Re: Win10 - Outlook 2013 - SMTP + SSL
> Date: Mon, 7 Mar 2016 09:29:05 +0000
> From: ka at 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 at 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/

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lista.sulinet.hu/pipermail/techinfo/attachments/20160307/90d877e0/attachment.html>