Hi Timo, reading this http://www.kuketz-blog.de/perfect-forward-secrecy-mit-apple-mail/ it looks like DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA can be forced in use with apple mail ( if no ECDHE is possible ,by missing openssl 1.x etc, seems that apple mail tries ECDHE first if fails its going to use RSA-AES128-SHA ) force soltution as tried ssl_cipher_list DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4 so far so good , it worked nice with recent thunderbird too but it fails with outlook 2003 pop3s / win7 so i thought about using an order like this ssl_cipher_list DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ALL:!LOW:!SSLv2:!EXP:!aNULL does that makes sense ? ( using dove 2.1.x / openssl 0.9x ) Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Am 14.08.2013 18:54, schrieb Robert Schetterer:> http://www.kuketz-blog.de/perfect-forward-secrecy-mit-apple-mail/ > > it looks like DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA can be forced in use > with apple mail > > > ( if no ECDHE is possible ,by missing openssl 1.x etc, > seems that apple mail tries ECDHE first if fails its going to use > RSA-AES128-SHA ) > > force soltution as tried > > ssl_cipher_list > DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4 > > so far so good , it worked nice with recent thunderbird too > but it fails with outlook 2003 pop3s / win7 > > so i thought about using an order like this > > ssl_cipher_list > DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ALL:!LOW:!SSLv2:!EXP:!aNULLssl_cipher_list EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:HIGH:!aNULL:!eNULL:!EXP:!MD5:!LOW:!SSLv2 is what is *higly* recommended after testing webservers by https://www.ssllabs.com/ssltest/ and works with Outlook 2003/2007/2010 as well as Thunderbird, iOS, Apple Mail, currently there exists even no way to force web-browsers to FS without open BEAST-attack and i doubt in context mail it does not look much better however, make sure you are using *the latest* dovecot version and at least openssl 1.0.1e thunderbird: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20130814/cf219b12/attachment.bin>
Am 14.08.2013 22:04, schrieb Robert Schetterer:> Am 14.08.2013 21:30, schrieb Reindl Harald: >> Am 14.08.2013 21:19, schrieb Robert Schetterer: >>>>> thx Harald, upgrading openssl to 1.x and using dove 2.2.5 is no option >>>>> at my setup lucid ubuntu yeter >>>> >>>> so you can practically forget it >>> >>> perhaps true forever, as long old clients are around, cause the server >>> can only workaround them >> >> not absolutely >> >> playing around with the setings below and https://www.ssllabs.com/ssltest/ >> turned out that the order is what counts, and that is really tricky >> >> i played around 5 hours with this absoluetly crap > > that sounds good, so you allready did many real world testsyeah and the bad is that it prove *currently* it is imposible to have perfect forward secrecy for most real world clients without open other vectors leading to fall back to a yellow B really sad is that playing around turned out how hard it is to force different clients at the same time to a good cipher and how one change in the order refelcts the overall result and facing this: "ssllabs" simulates negotiation of real clients (skipped in the screenshot) but we are missing the same for mailservers and thats why my conclusion is that we are hopeless as admins and can only offer things but not do much in case of clients using them __________________________ attached the current results for our webservers the only positive from the current resullt is that the sever supports ciphers for "Perfect Forward Secrecy" and the negative that it is only theory, so i stay at this config and say "dear browser vendors, i support it so use it with your damned client" because i can hardly use a config which get a yellow CVSS on security-audits to support FS for you" well, i could reven aise up "key exchange" to 90/95 but after that "FS" would not be listed at all the real sad thing is that the "FS" you see is not used by current clients which mostly use RC4 and if you add !MEDIUM the most start using FS-ciphers but are vulerable by BEAST-attack which let you fall down to grade B if i add !MEDIUM to dovecot Thunderbird does no longer connect at all -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_analyse.gif Type: image/gif Size: 36735 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20130814/887b9260/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20130814/887b9260/attachment-0001.bin>
third try - a limit of 40 KB is ridiculous given the base64 overhead for e-mail and i hardly can cut more of the screenshot before it renders unusable at all....... Am 14.08.2013 22:04, schrieb Robert Schetterer:> Am 14.08.2013 21:30, schrieb Reindl Harald: >> Am 14.08.2013 21:19, schrieb Robert Schetterer: >> >> i played around 5 hours with this absoluetly crap > > that sounds good, so you allready did many real world testsyeah and the bad is that it prove *currently* it is imposible to have perfect forward secrecy for most real world clients without open other vectors leading to fall back to a yellow B really sad is that playing around turned out how hard it is to force different clients at the same time to a good cipher and how one change in the order refelcts the overall result and facing this: "ssllabs" simulates negotiation of real clients (skipped in the screenshot) but we are missing the same for mailservers and thats why my conclusion is that we are hopeless as admins and can only offer things but not do much in case of clients using them __________________________ attached the current results for our webservers the only positive from the current resullt is that the sever supports ciphers for "Perfect Forward Secrecy" and the negative that it is only theory, so i stay at this config and say "dear browser vendors, i support it so use it with your damned client" because i can hardly use a config which get a yellow CVSS on security-audits to support FS for you" well, i could reven aise up "key exchange" to 90/95 but after that "FS" would not be listed at all the real sad thing is that the "FS" you see is not used by current clients which mostly use RC4 and if you add !MEDIUM the most start using FS-ciphers but are vulerable by BEAST-attack which let you fall down to grade B if i add !MEDIUM to dovecot Thunderbird does no longer connect at all -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_analyse.gif Type: image/gif Size: 20151 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20130814/b6921cf4/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20130814/b6921cf4/attachment-0001.bin>