Hi,
Long time lurker, new poster though!
I've got two servers running Stunnel v2.54 (yet to upgrade as I've been waiting for an x-forwardfor patch to become available). I noticed recently that one Stunnel nodes had exited, requiring a restart. I'm not sure if it's a co-incidence, but I've only just changed the cert on both installs last night.
This, of course, is very concerning as it's only just become a problem, but being the core SSL endpoint, it knocks our server offline until it's restarted.
Now comes the interesting bit, I've run the SSL Labs SSL Health check at https://www.ssllabs.com/ssltest/ just to see if anything comes out of it, and noticed that without fail every time it runs (and the first server is online) it'll know Stunnel offline as it goes through it's tests: *"Testing TLS v1.0...." "Testing TLS v1.2...."* *-- SERVER OFFLINE --*
This was noticed by a fluke, but appears to happen every time I restart and then rerun the test.
I'm not getting any segfaults, or errors from stunnel, and it only affects the one (primary) server. Can anyone shed any light as to what might be causing it, how I can get any more info out of stunnel, or better yet, fix it completely?
Thanks all
Alfie
Hi all,
Don't want to be a nuisance and repost, but I'm really having an issue here.
As a test, I've tried stud (https://github.com/bumptech/stud), and apart from the fact with the default combination the ciphers and security are incorrect (BEAST/CRIME vulnerable), the issue doesn't seem to exhibit itself at all. Yet without fail every time I test it with stunnel on, it hard crashes silently whilst going through the test. I did this test as I wanted to check if it was an issue with my build of stunnel, or something further down the stack (openssl/libcrypto, etc), however this could be a misnomer as there may be a corrupt library/dependency that stunnel is using that stud doesn't.
I've confirmed that the packages are the same on both servers, the first (former primary) crashes predictably, the second is perfectly fine. Running stunnel with debug logging (7) on returns nothing of note, just shows the last connection. And I also seem to not get anything useful tracing the crash with strace.
Finally, I've tried downgrading stunnel, as well as trying a new build (4.56), then finally rebooting the machine (hey, it should work... right?!), but I'm still seeing the same behaviour.
Short of wiping the machine completely and re-installing, can anyone think of anything else I can try?
Alf
On Thu, May 9, 2013 at 6:32 PM, Alfred Kernaghan alfakern@gmail.com wrote:
Hi,
Long time lurker, new poster though!
I've got two servers running Stunnel v2.54 (yet to upgrade as I've been waiting for an x-forwardfor patch to become available). I noticed recently that one Stunnel nodes had exited, requiring a restart. I'm not sure if it's a co-incidence, but I've only just changed the cert on both installs last night.
This, of course, is very concerning as it's only just become a problem, but being the core SSL endpoint, it knocks our server offline until it's restarted.
Now comes the interesting bit, I've run the SSL Labs SSL Health check at https://www.ssllabs.com/ssltest/ just to see if anything comes out of it, and noticed that without fail every time it runs (and the first server is online) it'll know Stunnel offline as it goes through it's tests: *"Testing TLS v1.0...." "Testing TLS v1.2...."* *-- SERVER OFFLINE --*
This was noticed by a fluke, but appears to happen every time I restart and then rerun the test.
I'm not getting any segfaults, or errors from stunnel, and it only affects the one (primary) server. Can anyone shed any light as to what might be causing it, how I can get any more info out of stunnel, or better yet, fix it completely?
Thanks all
Alfie
Alfred Kernaghan wrote:
apart from the fact with the default combination the ciphers and security are incorrect (BEAST/CRIME vulnerable)
Unfortunately I don't think anymore that RC4 is a better choice:
http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked/ http://ssl.entrust.net/blog/?p=1887 Also see some initial results of my own research of this topic: http://mike.mirt.net/AlFBPPS-4.png The ultimate solution would be to use TLS/1.2, which is already supported in stunnel. All we can do is to wait for client support. I think AlFBPPS attack is in most cases much easier to exploit than BEAST and Lucky Thirteen attacks for most practical scenarios. As for CRIME: stunnel has compression turned off by default since version 4.51.
Short of wiping the machine completely and re-installing, can anyone think of anything else I can try?
Please collect a stack backtrace: https://www.stunnel.org/pipermail/stunnel-users/2005-June/000551.html
Mike