Certificate Error (android client)

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Certificate Error (android client)

nanotek
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
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Error (android client)

nanotek

> ------------ Original Message ------------
>> Date: Tuesday, December 24, 2013 12:57:53 AM +1100
>> From: nanotek <[hidden email]>
>> To: [hidden email]
>> 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


Reply | Threaded
Open this post in threaded view
|

Forward secrecy (was: Certificate Error)

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

nanotek
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
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Error (android client)

Viktor Dukhovni
In reply to this post by nanotek
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.
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Error (android client)

Viktor Dukhovni
On Mon, Dec 23, 2013 at 03:09:09PM +0000, 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=3128&user=guest&pass=guest

and the related OpenSSL post-1.0.1e fix:

    commit ca989269a2876bae79393bd54c3e72d49975fc75
    Author: Dr. Stephen Henson <[hidden email]>
    Date:   Thu Dec 19 14:37:39 2013 +0000

    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.
Reply | Threaded
Open this post in threaded view
|

RE: Forward secrecy (was: Certificate Error)

nanotek
In reply to this post by Viktor Dukhovni
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy (was: Certificate Error)

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

nanotek
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Tom Hendrikx
In reply to this post by Wietse Venema
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Viktor Dukhovni
In reply to this post by Tom Hendrikx
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.
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Tom Hendrikx
In reply to this post by Viktor Dukhovni
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Tom Hendrikx
In reply to this post by Wietse Venema
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Wietse Venema
In reply to this post by Tom Hendrikx
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

A. 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.
(or what's wrong on a server that is only Trusted but not Verified)

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Forward secrecy

Viktor Dukhovni
In reply to this post by A. Schulze
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.
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Error (android client)

lists@rhsoft.net
In reply to this post by Viktor Dukhovni


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
12