Timeline for patching SSL vulnerability (Heartbleed Bug)

OK, so I spoke earlier with a customer that knows more than I about this issue (hey Mark!).  It has to do with the UDP keep-alive introduced in OpenSSL 1.1.   This is why it applies to WebAdmin (4444) as well as the other port 443 servers.

I have yet to listen to the Security Now podcast that Mark referenced, but, having taken action with my clients, will do so soon. 

Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

I did a check on this website OpenSSL Heartbeat Vulnerability Check (Heartbleed Checker) and the reverse proxy is vulnerable. I run my ssl vpn at a very high port number and turned it off for the time being. I agree with Bruce that you can't avoid a port scan and changing port is not a long term solution but it does help against bots and such that are looking at port 443 specifically.

Although I agree with most against releasing an untested patch, there is a fine line between testing for stable patch and dropping the ball. I think they should release a soft release patch sooner than wait for internal testing much longer.

@SophosSupport 
When the patch for this is available, will there be a period where the patch is available as Soft Release, or will this be skip the Soft Release step?  I'm wondering if it's worth contacting support periodically to check for a soft-released patch. Thanks!

@SophosSupport 
When the patch for this is available, will there be a period where the patch is available as Soft Release, or will this be skip the Soft Release step?  I'm wondering if it's worth contacting support periodically to check for a soft-released patch. Thanks!

Earlier I was concerned about the impact of this WRT other secrets stored in memory, but after reading up on this I think those concerns were unfounded, it sounds like anything inaccessible to the webserver process should be safe. 

It seems that an attacker is able to extract 64KB blocks of memory from the webserver process on a victim machine using an already-published PoC exploit, which means that secrets accessible by that process such as your certificates and corresponding private keys should be considered already compromised. However, anything that your apache or nginx process doesn't have access to should be safe. 

Please anyone correct me if I'm wrong.

What about Users with SSO for VPN / Portal? Do they have to change their AD Password after Fixing the UTM?

What about Users with SSO for VPN / Portal? Do they have to change their AD Password after Fixing the UTM?

In my opinion, yes

Earlier I was concerned about the impact of this WRT other secrets stored in memory, but after reading up on this I think those concerns were unfounded, it sounds like anything inaccessible to the webserver process should be safe. 

It seems that an attacker is able to extract 64KB blocks of memory from the webserver process on a victim machine using an already-published PoC exploit, which means that secrets accessible by that process such as your certificates and corresponding private keys should be considered already compromised. However, anything that your apache or nginx process doesn't have access to should be safe. 

Please anyone correct me if I'm wrong.

It would be nice if it was only the webserver, as far as I can see it's at least:

web admin
user portal
reverse proxy
forward proxy?
smtp
pop3
imap
probably ftp

ssh is ok.

In short, everything that uses SSL / TLS.

Hi folks,
I can see another issue. Comments have been made that the webadmin should not be accessible from the external interface, there in lies a problem for those using SUM4 to manage a number of UTMs.
If you disable the webadmin for remote access how does the SUM access the UTM?
You could could limit the webadmin by specifying the source address of the SUM?

Ian