This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Timeline for patching SSL vulnerability (Heartbleed Bug)

Heatbleed Bug (CVE-2014-0160)

Hi

Is there any timeframe for patching this SSL/TLS bug for Astaro Security Gateway V8.
We are on the latest 8.311 (as V8 is an approved appliance for us and V9 is not).

Thanks


Heartbleed Bug
https://news.ycombinator.com/item?id=7548991


This thread was automatically locked due to age.
Parents
  • So, I used the compromised VPN to shut down my server behind the firewall and all is good.  I don't have remote access to the administrative side so I couldn't turn off the SSL features, so it's just going to have to bear it.

    I understand all the certificates and stuff need to be rebuilt after this issue, but is it enough of a risk that I need to rebuild the machine when I get back to it?  I received the patch email, but it looks like it requires intervention to deploy and I won't be able to do that for a couple days.  Should the machine be considered compromised from that time period?
Reply
  • So, I used the compromised VPN to shut down my server behind the firewall and all is good.  I don't have remote access to the administrative side so I couldn't turn off the SSL features, so it's just going to have to bear it.

    I understand all the certificates and stuff need to be rebuilt after this issue, but is it enough of a risk that I need to rebuild the machine when I get back to it?  I received the patch email, but it looks like it requires intervention to deploy and I won't be able to do that for a couple days.  Should the machine be considered compromised from that time period?
Children
  • I understand all the certificates and stuff need to be rebuilt after this issue, but is it enough of a risk that I need to rebuild the machine when I get back to it?  I received the patch email, but it looks like it requires intervention to deploy and I won't be able to do that for a couple days.  Should the machine be considered compromised from that time period?


    Hi, 

    The certificates may have been compromised, and it's possible someone used that to get your passwords (if they could sniff your traffic when you logged in).

    And, if you allow admin logins from anywhere, they then may have logged in.

    If you don't allow admin (webadmin) logins from anywhere, then no one should have been able to get in, and re-keying the certs should be enough.

    You can re-key the webadmin cert remotely without affecting VPNs, etc.

    Barry
  • Hi, 

    The certificates may have been compromised, and it's possible someone used that to get your passwords (if they could sniff your traffic when you logged in).

    And, if you allow admin logins from anywhere, they then may have logged in.

    If you don't allow admin (webadmin) logins from anywhere, then no one should have been able to get in, and re-keying the certs should be enough.

    You can re-key the webadmin cert remotely without affecting VPNs, etc.

    Barry


    Thanks Barry.  I only allow web admin logins from the internal interface, but I have User Portal exposed to the internet.  I did not explicity allow admins to log in, but I think my admin account can login to the User Portal--along with my VPN user.

    I knew I should have set the User Portal to internal only.  [8-)]