Timeline for patching SSL vulnerability (Heartbleed Bug)

barkas,

Ubuntu's also famous for blowing stuff out the door at a fast pace without doing as much QA as they probably should. SUSE/SLES, RHEL/CentOS won't patch within 24hours as they do a bunch of testing before release, but also often times backport changes to earlier versions.

A couple of days is reasonable for a major enterprise Linux vendor to respond to a vulnerability. Add in an extra day for trickle down to companies like Sophos that rebuild those distros, SLES in this case, and it gets fixed.

Then the end user spends weeks sitting on the patch. [:)] (tongue in cheek snark)

barkas,

Ubuntu's also famous for blowing stuff out the door at a fast pace without doing as much QA as they probably should. SUSE/SLES, RHEL/CentOS won't patch within 24hours as they do a bunch of testing before release, but also often times backport changes to earlier versions.

A couple of days is reasonable for a major enterprise Linux vendor to respond to a vulnerability. Add in an extra day for trickle down to companies like Sophos that rebuild those distros, SLES in this case, and it gets fixed.

Then the end user spends weeks sitting on the patch. [:)] (tongue in cheek snark)

For this patch, I can not wait a couple of days, it is too critical. Better to rush it out and break something than leave all your installations open for days.
I can not shut down every system, nor can I regenerate the certificates of certain systems.

For this patch, I can not wait a couple of days, it is too critical. Better to rush it out and break something than leave all your installations open for days.
I can not shut down every system, nor can I regenerate the certificates of certain systems.

not at the expense of downing your security device...that's just shortsighted and NOT the way to run a security appliance.

not at the expense of downing your insecurity device...that's just shortsighted and NOT the way to run a security appliance.

fixed that for you

not at the expense of downing your security device...that's just shortsighted and NOT the way to run a security appliance.

I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.

I'm certain that automated attacks are either already happening or are about to happen that make use of this bug.

I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.

Hi, I don't know if you read the whole thread, but all you need to do as a workaround is:

1. enable Webadmin for your management LAN(s), and disable it for Internet and ANY

2. disable the SSL remote access VPN

3. probably disable Web Server Protection

4. disable the End User Portal

Barry

and... once the patch is installed, it is recommended that you regenerate any SSL VPN certs, and the host cert, for the VPN as well, as you have no way of knowing if someone's "lifted" your certs or not (the attack is undetectable).

I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.

I'm certain that automated attacks are either already happening or are about to happen that make use of this bug.

so the patch downs your devices..how do you then get back online to patch the issues that took your entire network offline?  How much in lost revenue are you willing to tolerate?  I can bet your boss wouldn't be happy with this type of attitude...and if you are the owner you need to see beyond the immediate hysterics you are promoting.

I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.

I'm certain that automated attacks are either already happening or are about to happen that make use of this bug.

so the patch downs your devices..how do you then get back online to patch the issues that took your entire network offline?  How much in lost revenue are you willing to tolerate?  I can bet your boss wouldn't be happy with this type of attitude...and if you are the owner you need to see beyond the immediate hysterics you are promoting.