Certificate Error (android client)
I am receiving a Certificate Error when sending mail from K-9 on my android. I do not receive any error on my PC client (Thunderbird). I only have a self-signed public certificate and private key configured for use by Postfix. Should I create my own Certificate Authority and cat its certificate into a .chn file with the Postfix server certificate and use this instead of the standalone Postfix cert? Or should I create my own CA and just make use of the: $smtpd_tls_CAfile $smtpd_tls_CApath options in main.cf? Same result, I gather, via different means. But will it resolve this K-9 error? Thanks. -- syn.bsdbox.co
Re: Certificate Error (android client)
Original Message Date: Tuesday, December 24, 2013 12:57:53 AM +1100 From: nanotek nano...@bsdbox.co To: postfix-users@postfix.org Subject: Certificate Error (android client) I am receiving a Certificate Error when sending mail from K-9 on my android. I do not receive any error on my PC client (Thunderbird). I only have a self-signed public certificate and private key configured for use by Postfix. Should I create my own Certificate Authority and cat its certificate into a .chn file with the Postfix server certificate and use this instead of the standalone Postfix cert? Or should I create my own CA and just make use of the: $smtpd_tls_CAfile $smtpd_tls_CApath options in main.cf? Same result, I gather, via different means. But will it resolve this K-9 error? Thanks. Did you just upgrade to k9-4.802? They made some changes to the their certificate code and the change log notes indicate that you'll need to manually re-accept certificates that you manually accepted previously (e.g., self-signed certs) ... and I can confirm this. Once accepted I don't think you'll get prompted again -- I haven't. - Richard Wow. I feel foolish. Yes: I did just upgrade. After having re-accepted my certificate, I can now send mail sans said error. Thanks, Richard. Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? -- syn.bsdbox.co
Forward secrecy (was: Certificate Error)
nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. Wietse
Re: Forward secrecy
On 24/12/2013 1:40 AM, Wietse Venema wrote: nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. Wietse Thanks, Wietse. Much appreciated. I'll put it to use and let you know if I encounter any problems. -- syn.bsdbox.co
Re: Certificate Error (android client)
On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates You can deploy 4096-bit RSA key if it makes you feel more cool, but there is little point in going beyond 2048-bit RSA at this time. The further you stray away from current practice into the land of extreme cryptography, the more likely you are to run into interoperability problems, without any real security gains. using SHA512 algorithms TLSv1 and TLSv1.2 does not support negotiation of digest algorithms. Deploying digests beyond SHA1 will cause interoperability problems with systems that don't yet support the SHA2 family. and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. This is enabled in Postfix = 2.8 by default. If you stuck with 2.6 or 2.7, see the new forward secrecy document. We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way Thanks for the praise. -- Viktor.
Re: Certificate Error (android client)
On Mon, Dec 23, 2013 at 03:09:09PM +, Viktor Dukhovni wrote: using SHA512 algorithms TLSv1 and TLSv1.2 does not support negotiation of digest algorithms. I meant TLSv1 and TLSv1.1, but typed TLSv1.2. Speaking of TLSv1.2, does anyone have more information about: https://rt.openssl.org/Ticket/Display.html?id=3128user=guestpass=guest and the related OpenSSL post-1.0.1e fix: commit ca989269a2876bae79393bd54c3e72d49975fc75 Author: Dr. Stephen Henson st...@openssl.org Date: Thu Dec 19 14:37:39 2013 + Use version in SSL_METHOD not SSL structure. When deciding whether to use TLS 1.2 PRF and record hash algorithms use the version number in the corresponding SSL_METHOD structure instead of the SSL structure. The SSL structure version is sometimes inaccurate. Note: OpenSSL 1.0.2 and later effectively do this already. (CVE-2013-6449) The issue seems to be triggered by Squid trying to use SSL_read() to flush socket input after an SSL error. If that's the only way to run into this problem, it should not be an issue for Postfix. Postfix does not perform any further I/O on SSL connections after an SSL or I/O error. -- Viktor.
RE: Forward secrecy (was: Certificate Error)
On 24/12/2013 2:09 AM, Viktor Dukhovni wrote: On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates You can deploy 4096-bit RSA key if it makes you feel more cool, but there is little point in going beyond 2048-bit RSA at this time. The further you stray away from current practice into the land of extreme cryptography, the more likely you are to run into interoperability problems, without any real security gains. You're right; I'll keep 4096 bit for private data-, and key-encipherment and restrict service keys to 2048. using SHA512 algorithms TLSv1 and TLSv1.2 does not support negotiation of digest algorithms. Deploying digests beyond SHA1 will cause interoperability problems with systems that don't yet support the SHA2 family. I was just reading into this as I just upgraded to OpenSSL 1.0.1e (FreeBSD base system still installs 0.9.8y). I thought v1.x supported SHA256 cipher suites. Thanks for making me aware, Viktor. and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. This is enabled in Postfix = 2.8 by default. If you stuck with 2.6 or 2.7, see the new forward secrecy document. I'm running 2.11. Wietse provided the link, which I've read. It appears to contain all necessary intel. We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way Thanks for the praise. It's deserved; thank you all for your great work! -- syn.bsdbox.co
Re: Forward secrecy (was: Certificate Error)
On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote: We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I don't have any interoperability information for NIST P-384 (i.e. secp384r1). Like its P-256 cousin it is part of Suite B, and thus generally also supported by software that supports P-256, but it likely not as widely used as P-256. If there are any practical unpublished attacks on P-256, one might guess they would be due to the curve being cooked to be vulnerable. In that case, it would seem prudent to assume that P-384 is also suspect. If you're sufficiently paranoid, there is nothing you can trust. I don't see any compelling reason to prefer P-384 over P-256, but also know of no reasons to avoid it. P-384 has higher CPU cost, but this is generally tolerable in MTAs, since unlike web servers the SMTP connection rate is generally well below CPU performance limits. -- Viktor.
Re: Forward secrecy
On 24/12/2013 3:19 AM, Viktor Dukhovni wrote: On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote: We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I don't have any interoperability information for NIST P-384 (i.e. secp384r1). Like its P-256 cousin it is part of Suite B, and thus generally also supported by software that supports P-256, but it likely not as widely used as P-256. If there are any practical unpublished attacks on P-256, one might guess they would be due to the curve being cooked to be vulnerable. In that case, it would seem prudent to assume that P-384 is also suspect. If you're sufficiently paranoid, there is nothing you can trust. I don't see any compelling reason to prefer P-384 over P-256, but also know of no reasons to avoid it. P-384 has higher CPU cost, but this is generally tolerable in MTAs, since unlike web servers the SMTP connection rate is generally well below CPU performance limits. Thanks, Viktor. I will conduct some research and weigh my options. Whatever choice, a significant improvement on my current cryptographic protocol will be made. -- syn.bsdbox.co
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 15:40, Wietse Venema wrote: nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuGmkAAoJEJPfMZ19VO/1FbIP/jKzjUXPTGQLigTS5gZZzJA+ cEOuokXnYsUxcsce/kLfYvY0nPMI+YsByAPtcde8aNQ0efGJGI/sol4cfeJ2aXj0 ZGp3yUVN0RY+vcAdCvfL5Exa5nVM4UxMHfYuwJElZcid0ZpS/46D32EBZStq39n7 WbdPOqM2L3ey1PtsJZ4U9V0LSSz0uDfLTQRxtpK2nQJloPZHHShlWRZLsW3Sny4H UdUdMijR8tpItOeLedaxmCeoBRyNEYxO++J+PRVp4feeeUVUicyU4CwUkx/wbS13 mE5EUttUmOU5GYF34B+9z+HdpyecnZjlr1s51Sfb5pKwSid6PxIeuNS6IvsgvSDQ N0fP0wMNcTpgyDM196TctZc9OMtjhsUntXk90EnS34fOfEomjduXBHVGabZ+FARw /pmJWeGNPdi7WtZJ/Ptr8ZgzdiIfZhqEkJWL5nhdCPzZGBX/2aI1ZRk236guhRkv HOi6sRzrWw/iDdbfjbb31XqV4fsXCBUQ07SnVorCGcckt8PA5+KG6o/LRynhVK6r RdlDs7iKGjQtHN2/SgKvgrenSxUYXyuHaN6hH+yihKZJ4JwHVTcDOarfUBTTJpi1 lr/AWQcKDHau5QtVr6s/YlzcRyv50ejgecViIfNcuwYjZoVgAVrGCfT7NJhcRA5H 2lxFvOTrFKxlvFlBg3Mx =QrH8 -END PGP SIGNATURE-
Re: Forward secrecy
Tom Hendrikx: Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? I've no Note: greater security against pre-computation attacks against EDH can be obtained by periodically regenerating the EDH parameters as above (an hourly or daily cron job running as root can automate this task). The parameter files are not secret, after all these are sent to all SMTP clients in the clear. Mode 0644 is fine. However, this comment is (still) in the wrong place. It should precede the commands that compute the parameters and that set smtpd_tls_mumble_param_file stuff. Wietse
Re: Forward secrecy
On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. They don't *need* tweaking. However, the tweaked settings are *recommended. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. As stated. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs ... Postfix = 2.2 support 1024-bit-prime EDH out of the box, with no additional configuration, but you may want to override the default prime to be 2048 bits long, and you may want to regenerate your primes periodically. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? The default non-export prime is 1024 bits. As explained in the document, you should consider using a 2048 bit non-export prime. The best-attacks on prime EDH are pre-computation attacks, where one spends a bunch of time computing a bunch of data about a particular prime, and is then able to quickly solve the underlying problem much faster for any input. Though prime lengths are chosen based such pre-computation attacks (rule of thumb is that for equivalent security EDH primes should be about as long as RSA moduli) which are believed to be out of reach for 2048 bit primes and perhaps still out of reach even for 1024 bit primes, one can make the attacks much less attractive by frequently generating new primes independently at each site. The compiled-in default prime in the Postfix source code is perhaps within reach of the best-funded adversaries, who may have performed the requisite pre-computation. Primes you generate on your server, and use for a short time are unlikely to warrant the extraordinary cost of the pre-computation attack. I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? I don't believe that OpenSSL provides default parameters, but Postfix does. Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? The more advanced material we put in the document, the more intimidating it will be for the average reader. But of course an empty document is not optimal, so we have to aim for the middle. There is a range of reader sophistication we can support, it is a trade-off between readable hands-on knowledge and a more detailed, but technically demanding presentation of the rationale. -- Viktor.
Re: Forward secrecy
Viktor Dukhovni: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) In this section, the commands that compute the parameters PRECEDE the text that says why one might want to do this. This is not a skimming error, it is a presentation error. Wietse
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 18:30, Viktor Dukhovni wrote: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. They don't *need* tweaking. However, the tweaked settings are *recommended. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. As stated. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs ... Postfix = 2.2 support 1024-bit-prime EDH out of the box, with no additional configuration, but you may want to override the default prime to be 2048 bits long, and you may want to regenerate your primes periodically. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? The default non-export prime is 1024 bits. As explained in the document, you should consider using a 2048 bit non-export prime. The best-attacks on prime EDH are pre-computation attacks, where one spends a bunch of time computing a bunch of data about a particular prime, and is then able to quickly solve the underlying problem much faster for any input. Though prime lengths are chosen based such pre-computation attacks (rule of thumb is that for equivalent security EDH primes should be about as long as RSA moduli) which are believed to be out of reach for 2048 bit primes and perhaps still out of reach even for 1024 bit primes, one can make the attacks much less attractive by frequently generating new primes independently at each site. The compiled-in default prime in the Postfix source code is perhaps within reach of the best-funded adversaries, who may have performed the requisite pre-computation. Primes you generate on your server, and use for a short time are unlikely to warrant the extraordinary cost of the pre-computation attack. I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? I don't believe that OpenSSL provides default parameters, but Postfix does. Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? The more advanced material we put in the document, the more intimidating it will be for the average reader. But of course an empty document is not optimal, so we have to aim for the middle. As stated, I assumed that the default primes came from openssl, based on the smtpd_tls_dh1024_param_file description in postconf(5). While reading 'using the exact same parameter sets as distributed with other TLS packages', I was assuming 'other TLS packages' to be other (non-postfix, non-SMTP) software packages also using openssl. After another re-read of the forward secrecy document (and from your reply), I now found the part that states that the default primes are postfix builtins. I missed this link. So it doesn't have to be more technical or advanced. There were some connections between dots missing in the higher level picture. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHsrAAoJEJPfMZ19VO/1MY0P/RkJMxLYu77l8QVfQjuwQdk1 4xgMXiyR0IC8tSKFuulwX/sl+YoFcv2wkjupx0ZwTkVg32feccAUgnzy3wVfe3UM Di5sxIdNq7M2MOb/O3nuoGkKiFDTtd/PXpInI6iLtKL9ADKXPwsbikQda1BEbV++ lO9BsVA1sJsAJOl40nOvx639cFQCEoLyAkuIgk6dZ//7sn1jmIFpYnZhkFvPo2rT Y+3xwGtK+kz2E/b2uutkCO203iCf6hSkyV/jSF2rHl9L/iOkH2ohwt3ICrlH3r38 9Q3TUeMkJzWrHC1ME+LHA5bPhmKdtFsPywZHCWEMK/91U1EQSw8MI6JLHwiC9SZQ JspWkm2JroIrkHl1mKHWi3IazI2hRTgjhmGwkaHy8+m3Cvkq5u9W8jEIBQ045luF gKnCQdaDnfA0htg1dGmvpFItQeddraG+7DcXFDKtPny/mo3oTfAoSgiO3dKIjEDm NihRXgJAtfJRXZG+vLGW0G/+h1DHT5u+l0l9W+TntJi9F2gBk1L6Lz+RSH9Jg5Cc WBAvu2FH1HpoiTNKfdJu3Oi8P0PaSIbnwtODWZ0VVaRVT+YQgGkgjyMcMsvJkEF7 WknGNWBGk5/2n5/x7E/yX1VIV0416ehZSom0C/eBUZxCWAiidZwrRB+hQrcqGJUU UfgkVU/WR+i9bBSxByEa =i2Yp -END PGP SIGNATURE-
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 18:40, Wietse Venema wrote: Viktor Dukhovni: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) In this section, the commands that compute the parameters PRECEDE the text that says why one might want to do this. The text currently reads like: - - you need to generate the params files once - - for greater security, re-generate every now and then The improved security that is gained in the first step is not obvious, which is why I went looking for the details on the params that Postfix uses when the settings are left untouched. You might want to make it clearer that providing customized params is more secure than using the builtins. After that, running a cronjob to refresh them is another improvement. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuH0qAAoJEJPfMZ19VO/18wsQAIwzLUl26Q6+j43vXudQpEq2 x8JUt/jjTcRz+PkurynM51YLlmikxzhwC3J/reUvp2zSvHojOAsbomDdp6NN72Km eJdvxSgxc5i05tcoPxtoUZ3aKZUHHFdQ/p/HtnG2zXiU77AWnBzPPBwaZd0qo0f0 Ao22oL68qltuc23APMSYI78acwLFZO/X3Lky+UquyPiwn8qK1JkX3WtzOwsTiNX6 Xv4taIxLSn6sje3DCyWv2lAX0mPTo6B9mKzi7zO1PyUtym/jBo/6WUbW9QxB8ZWC D3hRVkarDdUlWHPOHx1P3nkaA9aiZgy93rVCT0yrB14KS57GvGCBptjo36QHzsvP QUSPo79jjIL/Z3YE+g/HbonFMiHdP0vCioFVU8rgRBZXH1/UbdKHu7eJxxgR6Ggm GssbJkz3hx+JJNzXJcrPjlCrERn9cROKIY0gkE0shjMMcgUG41H9OGBR8GzEOYvm wUOoORAkzaJddeApRrEPGQqQcnlCRulbkQYk8UmnkxH+/P+YSHZqbMXFbxOZzW6Z +5ueiasIxlXA3+Dgmj0xlpOsWFRArFiJLBxfpvkE9Cl/ZhBV31t6DR09doCJznvn 5fFS803QEiwVPuQc0OGg7xYJUG4iDv5gqRxZh27Zuzz2SF5zKxMzTYb7xBxcJCqf QGxvbqtkzTpKC1tE5wxv =bwAN -END PGP SIGNATURE-
Re: Forward secrecy
Tom Hendrikx: So it doesn't have to be more technical or advanced. There were some connections between dots missing in the higher level picture. Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. Wietse
Massive creation of virtual accounts
Hi, I need to create close to 150 virtual mailboxes (with maildir) and 200 aliases, and I only have text formatted (csv) listings of these mails and aliases addresses. I don't see any possibility to do that automaticaly in the postfix admin. Is there a way I can deal with this job easily ? Thanks for your replies. -- View this message in context: http://postfix.1071664.n5.nabble.com/Massive-creation-of-virtual-accounts-tp63977.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Massive creation of virtual accounts
In our previous episode (Monday, 23-Dec-2013), renoproc said:
Is there a way I can deal with this job easily ?
mkdir -p /path/to/virtualusers/$user\@$domain/{cur,new,tmp}
Put it in a loop where you get the user and domain from your list.
Can't help you with the aliases, because that depends on how you want them
handled and how you store your users. *I* would put them in virtual
alias1@domainrealuser1@domain
postfix admin has its own making list.
--
Laugh it up, fuzzball!
Re: Massive creation of virtual accounts
Some years (~7) ago I added this kind of feature to postfixadmin. Not much job to do this kind of modification to postfixadmin. -- Eero 2013/12/23 renoproc renop...@gmail.com Hi, I need to create close to 150 virtual mailboxes (with maildir) and 200 aliases, and I only have text formatted (csv) listings of these mails and aliases addresses. I don't see any possibility to do that automaticaly in the postfix admin. Is there a way I can deal with this job easily ? Thanks for your replies. -- View this message in context: http://postfix.1071664.n5.nabble.com/Massive-creation-of-virtual-accounts-tp63977.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Massive creation of virtual accounts
Em 23/12/13 16:46, renoproc escreveu: Hi, I need to create close to 150 virtual mailboxes (with maildir) and 200 aliases, and I only have text formatted (csv) listings of these mails and aliases addresses. I don't see any possibility to do that automaticaly in the postfix admin. Is there a way I can deal with this job easily ? this is the postfix (mail software) mailing list. Chances that you'll get better answers on postfix admin (the web interface) are greater than here. anyway, there's no way to give you answers without knowing a little more of your environment. Are your users virtual ? SQL, LDAP, flat files ? Doing that should not be too difficult but will probably require some scripting. -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
Re: Forward secrecy
Am 23.12.2013 13:13 schrieb Wietse Venema: Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very usefull. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. (or what's wrong on a server that is only Trusted but not Verified) Andreas
Re: Forward secrecy
Andreas Schulze: Am 23.12.2013 13:13 schrieb Wietse Venema: Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very usefull. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. The text says: Trusted (peer certificate signed by trusted CA, unverified peer name) Verified (peer certificate signed by trusted CA, verified peer name) The difference is that the client verifies that the name(s) in the certificate match with the name of the host that the client wanted to connect to. TLS_README goes into the details of verification. (or what's wrong on a server that is only Trusted but not Verified) You could be talking to the wrong server, some man in the middle, or anything else than the desired host. Wietse
Re: Forward secrecy
On Mon, Dec 23, 2013 at 09:45:45PM +0100, Andreas Schulze wrote: I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very useful. Good. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. If you must-have MITM protection for a particular destination, configure in smtp_tls_policy_maps a suitable TLS security level that unconditionally verifies the server, such as: - fingerprint - secure - dane-only (**) Or to authenticate all servers opportunistically via DANE TLSA records, set: smtp_tls_security_level = dane (*) (or what's wrong on a server that is only Trusted but not Verified) If mail delivery proceeded anyway, nothing is wrong: Postfix was not configured to verify the server certificate. This is the norm, MX record indirection makes it impossible to verify SMTP servers without explicit policy entries or help from DNSSEC (hence all the work to implement DANE support in Postfix 2.11). If mail delivery did not proceed, then the server certificate did not contain any of the expected names. -- Viktor. (*) Requires Postfix 2.11 on a platform with OpenSSL 1.0.0 or greater, with EC support not disabled by the vendor. Also requires minimal DNSSEC support in libresolv (the DO and AD bits must be implemented and the option RES_USE_DNSSEC must be defined). For actual security the MTA needs a DNSSEC validating caching nameserver on localhost. Systems with DNSSEC validated MX records and DNSSEC validated TLSA records for the MX hosts will be subject to mandatory TLS authentication. Other systems will be subject to opportunistic TLS. (**)As above, but secure TLSA RRs are required.
Re: Massive creation of virtual accounts
this is the postfix (mail software) mailing list. Chances that you'll get better answers on postfix admin (the web interface) are greater than here. anyway, there's no way to give you answers without knowing a little more of your environment. Are your users virtual ? SQL, LDAP, flat files ? Doing that should not be too difficult but will probably require some scripting. Postfixadmin uses SQL backend (postgres or mysql) and already contains php functions to create users or aliases. Just capture SQL inserts and do some scripting or use postfixadmins internal functions with php to create users.. -- Eero
Re: Certificate Error (android client)
Am 23.12.2013 16:09, schrieb Viktor Dukhovni: On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates You can deploy 4096-bit RSA key if it makes you feel more cool, but there is little point in going beyond 2048-bit RSA at this time. The further you stray away from current practice into the land of extreme cryptography, the more likely you are to run into interoperability problems, without any real security gains. using SHA512 algorithms TLSv1 and TLSv1.2 does not support negotiation of digest algorithms. Deploying digests beyond SHA1 will cause interoperability problems with systems that don't yet support the SHA2 family hopefully i do not get proven wrong here but: in the last few months i am about testing OpenSSL-Keys with RSA 3072 / SHA256 a far as i can see even old MSIE6 on Windows XP happily connects to a webserver which such a key - given that are you aware of systems / mailservers which would have a problem with it? my plans for 2014 originally are get a signed 3072 SHA 256 *wildcard* certificate for 2 years for use on several webservers as well as Postfix / Dovecot i am aware of the ironically domain below, but given that the NSA not only works on break into foreign systems but also protect US infracsturucture they may have a good reason to state 3072 Bit for AES128 http://www.nsa.gov/business/programs/elliptic_curve.shtml
Re: Certificate Error (android client)
nanotek nano...@bsdbox.co wrote: I am receiving a Certificate Error when sending mail from K-9 on my android. I do not receive any error on my PC client (Thunderbird). I only have a self-signed public certificate and private key configured for use by Postfix. Should I create my own Certificate Authority and cat its certificate into a .chn file with the Postfix server certificate and use this instead of the standalone Postfix cert? Or should I create my own CA and just make use of the: $smtpd_tls_CAfile $smtpd_tls_CApath options in main.cf? Same result, I gather, via different means. But will it resolve this K-9 error? Thanks. -- syn.bsdbox.co I use postfix (and dovecot) with self signed certificates, never had any issues, apart from initial 'accept?' , use 587 and 143ssl, it just works, both k9 and kaiten. Though, recent upgrade of mail client, either k9 or k10, caused the need to re accept certificate. -- Sent from Kaiten Mail. Please excuse my brevity. -- Sent from Kaiten Mail. Please excuse my brevity.
Re: Certificate Error (android client)
On Tue, Dec 24, 2013 at 01:16:33AM +0100, li...@rhsoft.net wrote: Deploying digests beyond SHA1 will cause interoperability problems with systems that don't yet support the SHA2 family Are you aware of systems / mailservers which would have a problem with it? Yes. Any OpenSSL based MTA, with OpenSSL older April 7 2010: OpenSSL_1_0_0-stable(first released as OpenSSL 1.0.0a): commit acc9938ba5aa32fc382399e9a8cbd3a0dea91b34 Author: Dr. Stephen Henson st...@openssl.org Date: Wed Apr 7 13:18:30 2010 + Add SHA2 algorithms to SSL_library_init(). Although these aren't used directly by SSL/TLS SHA2 certificates are becoming more common and applications that only call SSL_library_init() and not OpenSSL_add_all_alrgorithms() will fail when verifying certificates. OpenSSL_0_9_8-stable(first released as OpenSSL 0.9.8o): commit bc06baca76534abc2048a3ac4d109b144da4b706 Author: Dr. Stephen Henson st...@openssl.org Date: Wed Apr 7 13:19:48 2010 + Add SHA2 algorithms to SSL_library_init(). Although these aren't used directly by SSL/TLS SHA2 certificates are becoming more common and applications that only call SSL_library_init() and not OpenSSL_add_all_alrgorithms() will fail when verifying certificates. The symptom would be that your certificate chain is not verifiable, verify error:num=7:certificate signature failure which rather makes all those sha256 signatures pointless, since the whole certificate cannot be verified. I am aware of the ironically domain below, but given that the NSA not only works on break into foreign systems but also protect US infracsturucture they may have a good reason to state 3072 Bit for AES128 http://www.nsa.gov/business/programs/elliptic_curve.shtml The NIST (and/or NSA) recommended key sizes are for an ideal world without interoperability issues and implementation constraints. In the real world, you sometimes get better security from less ideal but more practical configurations. -- Viktor.
