Replacing openssl and the certs should be an effective patch. You can always check by running ldd against the stunnel binary to confirm it is linking to a specific SSL library. There is also some consideration that you must assume systems were compromised and snooped and change all passwords as well... Regards, KAM Koenraad Lelong <stunnel@ace-electronics.be> wrote:

op 10-04-14 12:15, Koenraad Lelong schreef:

...

op 08-04-14 16:58, Burak Say schreef:

...

Hello,

When do you think you can release a patch to use OpenSSL 1.0.1g instead of 1.0.1f?

Hi,

I would like to know if I'm safe when I installed the latest openssl-libraries comming from ubuntu (for 12.04LTS). Or do I need to update stunnel also ? The ubuntu package for the latest stunnel seems unavailable right now.

Regards,

Koenraad.

I just thought of looking in the package-manager. This says stunnel depends on libssl1.0.0 (installed 1.0.1-4ubuntu5.12) and on openssl (installed 1.0.1-4ubuntu5.12). So I presume I can generate new certificates.

Koenraad.

_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

On 11.04.2014 08:28, Koenraad Lelong wrote:

op 10-04-14 12:58, Kevin A. McGrail schreef:

...

There is also some consideration that you must assume systems were compromised and snooped and change all passwords as well...

I did to change passwords, but is this neccessary, since I'm using stunnel with certs on both sides of the tunnel ? Just to understand this case of openssl a bit more.

Heartbleed allows an attacker to retrieve parts of the server process's virtual memory, with whatever content that may happen to be there. It's IMHO very likely to be highly dynamic data, like the content of ongoing communication the server has with other clients. Nobody seems to have much of an idea how to *control* what data you get so far. https://www.xkcd.com/1354/ The data *everybody's talking about* as being in danger is the server's private key - which is pretty static, but necessarily present *somewhere* in virtual memory (actually likely to be memlocked into RAM, or so I'd hope) and useful to set up a MitM attack / decoy server. (Everybody and his dog's *also* referring only to HTTPS, while I'm currently working on IMAPS and OpenVPN servers' keypairs, and giving the suspicion-raised eyebrow to all sorts of STARTTLS-enabled stuff.) IIUC the yield is limited to ~16kB per (much smaller) keepalive request, but you may issue them at whatever rate your bandwidth and RTT allows, so I'd guess that on low-volume servers, you'd be able to snoop a substantial part of the server's traffic. Maybe with users' passwords and live session cookies if we're talking about a web UI with a <FORM>-based login ... Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel