Re: [Dovecot] Heartbleed openssl vulnerability?
On 8.4.2014, at 20.00, John Rowe j.m.r...@exeter.ac.uk wrote: Do we know if dovecot is vulnerable to the heartbleed SSL problem? It may be possible that the attacker was able to get the SSL private key(s), although this depends on the OS and its memory allocation patterns. If you use only a single SSL cert I think it might be possible that it doesn't leak with Dovecot, but it's definitely not a good idea to trust that. I haven't anyway looked closely enough into this to verify, I'm just guessing based on the information in http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html 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 Would be nice if it was possible to hide the SSL private keys to separate processes as well, but that would probably require changes to OpenSSL itself. (BTW. I've been too busy recently to even have time to read any mails in Dovecot list. I'll try to go through at least most of it before making the next Dovecot release. And hopefully by summer I've more time again.)
Re: [Dovecot] Heartbleed openssl vulnerability?
On 4/9/2014 5:45 AM, Timo Sirainen t...@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
Re: [Dovecot] Heartbleed openssl vulnerability?
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 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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 signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Heartbleed openssl vulnerability?
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 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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 signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Heartbleed openssl vulnerability?
Am 09.04.2014 19:27, schrieb Reindl Harald: the word counterproductive describes that policies perfectly this is simply nonsense, go have a beer 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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 signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Heartbleed openssl vulnerability?
It's an interesting issue. In my experience stale passwords are rarely used to compromise systems. However, passwords tend to end up on sticky notes and even worse, in email databases regardless. As far as compromised email passwords, they seem to mostly come from infected clients and insecure public logins as far as I can tell. A server can control the later, but not the former. I know of a major accounting software that forces Admin users to change their passwords every few months under certain circumstances. Those passwords always end up in emails to fellow users, so in that case forcing people to change seems to be definitely counterproductive. IMV the moral of the story is that you can't crypt your way into a 100% secure world. You need other forms of checks reconciliations that are disjoint from purely cryptographic infrastructure. For instance ask Mt. Gox and Bitcoin if they agree in hindsight, and Heartbleed is a very good example of this concept. Thanks, Jake On 4/9/2014 10:27 AM, Reindl Harald wrote: 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
Re: [Dovecot] Heartbleed openssl vulnerability?
On 4/9/2014 1:03 PM, Robert Schetterer r...@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
Re: [Dovecot] Heartbleed openssl vulnerability?
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 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
Am 09.04.2014 20:13, schrieb Charles Marcus: On 4/9/2014 1:03 PM, Robert Schetterer r...@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. i switched to performance mode when pop3 logins rised up to more then 1000 per minute, i did not see any significant rise or low of ram switching between modes, but i have no data for massive imap logins, dovecot in general is not very memory hungry, for exact compare data you might wait for Timo to answer, or do some measure by yourself 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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!* signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Heartbleed openssl vulnerability?
- 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.
Re: [Dovecot] Heartbleed openssl vulnerability?
Am 09.04.2014 22:38, schrieb Reindl Harald: 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 agreed you never will fix the problem sitting behind the keyboard with code 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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 signature.asc Description: OpenPGP digital signature
[Dovecot] Heartbleed openssl vulnerability?
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!). Thanks John
Re: [Dovecot] Heartbleed openssl vulnerability?
* John Rowe j.m.r...@exeter.ac.uk: Do we know if dovecot is vulnerable to the heartbleed SSL problem? ANY application using the affected OpenSSL versions is vulnerable. That includes dovecot. 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!). Thanks John -- [*] sys4 AG https://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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Heartbleed openssl vulnerability?
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
Re: [Dovecot] Heartbleed openssl vulnerability?
Zitat von Jakob Curdes j...@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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] Heartbleed openssl vulnerability?
Am 08.04.2014 21:38, schrieb lst_ho...@kwsoft.de: Zitat von Jakob Curdes j...@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. correct, that was my whole-day job from 10:00 AM to 16:00 PM for 10 certificates followed by openvpn-keys, better safe than sorry luckily some wildcard certs in the meantime instead a ton single ones signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Heartbleed openssl vulnerability?
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
