Zitat von Jakob Curdes jc@info-systems.de:

Am 08.04.2014 19:00, schrieb John Rowe:

...

Do we know if dovecot is vulnerable to the heartbleed SSL problem?

I'm running dovecot-2.0.9 and openssl-1.01, the latter being intrinsically vulnerable. An on-line tool says that my machine is not affected on port 993 but it would be nice to know for sure if we were vulnerable for a while. (Naturally I've blocked it anyway!).

Usually all programs are linked dynamically to the library, so the
vulnerability depends on the library only. If you updated the
library today and restarted the service (!!) then it is very likely
that your mail installation is not vulnerable any more. Otherwise it
is very likely to be vulnerable, regardless what tests say. JC

Be aware that your private key might already have leaked without any
notice. So your best bet is to withdraw your certificates and renew
all keys/certificates on the affected machines.

Regards

Andreas

Be aware that your private key might already have leaked without any notice. So your best bet is to withdraw your certificates and renew all keys/certificates on the affected machines. Yes, I suppose by now everybody has read the general hints on heartbleed.com ; it might even be that previous traffic can be decrypted. You need to change private keys, certificates, etc, all that is used by openssl to identify the communication partner.

JC

On 4/9/2014 5:45 AM, Timo Sirainen tss@iki.fi wrote:

By default Dovecot's login processes run in the "high security mode" where each IMAP/POP3 connection runs in its own process. This was done especially to avoid security bugs in OpenSSL from leaking users' passwords. So unless you have switched to the "high performance mode", users' passwords or other sensitive data couldn't have been leaked.http://wiki2.dovecot.org/LoginProcess

Hi Timo,

Hmmm... ours is set to high performance mode, but, I didn't set it up, you did...

Now I'm wondering why you did this... ?

What are the ramifications of changing this on a production server? Any possible problems/gotchas? user impact?

Thanks,

--

Best regards,

Charles

Am 09.04.2014 19:03, schrieb Robert Schetterer:

Am 09.04.2014 18:42, schrieb Charles Marcus:

...

What are the ramifications of changing this on a production server? Any possible problems/gotchas? user impact?

in my understanding change ssl key and crts , do all needed ssl updates keep performance mode, if unsure change all passwords too

passwords too, in security mode only keys would have been affected and since this is a attack which no single indication that it ever happened on a machine there is no likely or unlikely

Am 09.04.2014 19:18, schrieb Robert Schetterer:

Am 09.04.2014 19:10, schrieb Reindl Harald:

...

Am 09.04.2014 19:03, schrieb Robert Schetterer:

...

Am 09.04.2014 18:42, schrieb Charles Marcus:

...

What are the ramifications of changing this on a production server? Any possible problems/gotchas? user impact?

in my understanding change ssl key and crts , do all needed ssl updates keep performance mode, if unsure change all passwords too

passwords too, in security mode only keys would have been affected and since this is a attack which no single indication that it ever happened on a machine there is no likely or unlikely

there should no issue if you havent used vulnerable openssl version i.e ubuntu lucid has 0.9.x which is not reported vulnerable anyway ,change passwords from time to time is always clever

if you you don't have used a vulnerable openssl you are not affected at all - if you used than private keys and certs are not your only problem, there are enough articles in the meantime explaining why

"change passwords from time to time is always clever" is a strawmans argument with no context to the issue, forcing people to change their passwords all the time for no good reasons leads mostly to completly insecured passwords to remember them easier or have them on a sticky on the screen or under the keyboard

the word "counterproductive" describes that policies perfectly

Am 09.04.2014 19:31, schrieb Robert Schetterer:

Am 09.04.2014 19:27, schrieb Reindl Harald:

...

the word "counterproductive" describes that policies perfectly

this is simply nonsense, go have a beer

don't strip quotes

i have faced users in real life with where punsihed by change their passwords each month and the result was that not a single of them was secure or not stored somewhere while the same person would have choosed something like below otherwise

!mH*IM*c!

derived from "my home is my castle" the first and last char lowercase, the others uppercase ! at the begin and end

• after each char between

easy to remember, not in rainbow tables *that* is real security because you don't need to note it while it is built with chars nobody else can guess and the user easily rememeber

anything else is nonsense cooked only with a technical point of view

Am 09.04.2014 22:06, schrieb Robert Schetterer:

Am 09.04.2014 19:54, schrieb Reindl Harald:

...

i have faced users in real life with where punsihed by change their passwords each month and the result was that not a single of them was secure or not stored somewhere while the same person would have choosed something like below otherwise

yes its common and old security practice to force password changes at some terms in many software products, looks like many coders agreed that this is a good idea, but for sure they had not your universal jedi power

that's polemic

it is not a matter of "jedi power", it's a matter of how likely it is that your password maybe get stolen and how many really secure passwords a human kan keep in his mind compared with change them again and again forcing to store the password on a place where it is more likely to get compromised

if the password i am using for critical infrastructure leaves my hands it would be a nightmare - a braindump is unliekly, get whatever store containing it compromised is more likely

the same for the class of not that critical passwords, generated with random algorithms and because that stored in password safes which *may* be compromised but better than "shitpwd-year-moth-123"

so stop this polemic, there is no asbolute right solution in case of credentials and before a user chosses "fuckingadmin123" i prefer passwords like "!Y*c*k*m*b*S!*"

Am 10.04.2014 02:28, schrieb Tim Groeneveld:

----- Original Message -----

...

the same for the class of not that critical passwords, generated with random algorithms and because that stored in password safes which *may* be compromised but better than "shitpwd-year-moth-123"

so stop this polemic, there is no asbolute right solution in case of credentials and before a user chosses "fuckingadmin123" i prefer passwords like "!Y*c*k*m*b*S!*"

I think now is a good time to point you to http://xkcd.com/936/

I would prefer "SuitableChooseNewspaper57" over "!Y*c*k*m*b*S!*" because I know that the first is definitely less likely to be stored on the back of a keyboard, or in a Word document named "Passwords.doc".

Plus, Suitable Choose Newspaper 57? Easy to say over the phone if someone ever needs my password

you missed that bit:

...

...

09.04.2014 19:54, schrieb Reindl Harald:

...

i have faced users in real life with where punsihed by change their passwords each month

maybe *now* that you can't use "SuitableChooseNewspaper57" as well as "SuitableChooseNewspaper58" the next month where such policies are applied or anything else you remember you understand what i mean and the next time read the whole thread before you reply to pieces out of context

On 4/9/2014 1:03 PM, Robert Schetterer rs@sys4.de wrote:

Am 09.04.2014 18:42, schrieb Charles Marcus:

...

...

What are the ramifications of changing this on a production server? Any possible problems/gotchas? user impact? in my understanding change ssl key and crts , do all needed ssl updates keep performance mode, if unsure change all passwords too

???

I was asking about the ramifications of switching from high performance mode to high security mode.

Not the ramifications of the security compromise.

--

Best regards,

Charles