RE: Win10 - Outlook 2013 - SMTP + SSL
Mindegy is, mert tutira ssl (és 465-ös port), de azért próbáltam a starttls-t (587) is, nem működött. Ugyanazon a gépen Thunderbird alól azonban simán megy az ssl-lel. Szóval az elavult protokollra vonatkozó meglátásod irányában nyomozok tovább. Szerintem ott lesz a megoldás. Köszi! > To: techinfo@lista.sulinet.hu > Subject: Re: Win10 - Outlook 2013 - SMTP + SSL > Date: Mon, 7 Mar 2016 10:40:24 + > From: k...@mayten.sch.bme.hu > > On 2016-03-07 10:38, Szegeczky Tibor wrote: > > Sziasztok! > > > > Nem startssl, hanem starttls: > > > > koszi a pontositast. > > > 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/
Re: Win10 - Outlook 2013 - SMTP + SSL
On 2016-03-07 12:15, Hambuch Gabor wrote: Ezt azért egy kicsit árnyalnám. Ismeretlen szolgáltató esetén általában rá szoktam próbálkozni az adott szolgáltatást nevével ellátott aldomainre (jelen esetben smtp.debrecen.hu), és általában be jogos. smtp nem volt megadva a levelben, en csak az MX rekordig mentem, tovabb talalgatni mar lusta voltam. 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/
Re: Win10 - Outlook 2013 - SMTP + SSL
2016-03-07 10:29 keltezéssel, k...@mayten.sch.bme.hu írta: 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. [...] 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: Ezt azért egy kicsit árnyalnám. Ismeretlen szolgáltató esetén általában rá szoktam próbálkozni az adott szolgáltatást nevével ellátott aldomainre (jelen esetben smtp.debrecen.hu), és általában be szokott válni a dolog. Látszólag most is ez a helyzet, más ip-re mutat, mint a bejövő mx, és ezen még a 465-ös porton is működik szolgáltatás - igaz self-signed tanúsítvánnyal. Én inkább erre gyanakodnék, mint hiba - tehát valószínűleg az újabb outlook kérdés nélkül utasítja el az általa nem megbízhatónak ítélt tanúsítványt. Bár azért gyanús, hogy erről legalább figyelmeztetni szokott. -- Hambuch Gábor hamb...@w5.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/
Re: Win10 - Outlook 2013 - SMTP + SSL
On 2016-03-07 10:38, Szegeczky Tibor wrote: Sziasztok! Nem startssl, hanem starttls: koszi a pontositast. 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/
Re: Win10 - Outlook 2013 - SMTP + SSL
Sziasztok! Nem startssl, hanem starttls: 250-SIZE 5 250-PIPELINING 250-8BITMIME 250 HELP starttls 454 TLS not available due to temporary reason 2016-03-07 10:29 keltezéssel, k...@mayten.sch.bme.hu írta: > > 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 5 > 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/
RE: Win10 - Outlook 2013 - SMTP + SSL
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 + > 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 5 > 250-PIPELINING > 250-8BITMIME > 250 HELP > startssl > 500 Syntax error, command unrecognized
Re: Win10 - Outlook 2013 - SMTP + SSL
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 5 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/
