<div dir="ltr">Gidday,<div><br></div><div>On Thu, Apr 17, 2014 at 12:49 PM, Glen Turner <span dir="ltr"><<a href="mailto:gdt@gdt.id.au" target="_blank">gdt@gdt.id.au</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
> You're absolutely right, the process followed by the OpenSSL team and the<br>
> various distributions in fixing this has been very well done and is a model<br>
> for how these things should be fixed.<br>
<br>
</div>And here we part company. The advice for people with possibly-affected web<br>
servers should have been to shut that web server down. Then determine if<br>
the web server was vulnerable. Then patch it and reboot.<br>
<br></blockquote><div> Not getting the web server offline immediately simply allowed people to</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
pull 64KB blocks from webservers and archive them to disk for future<br>
analysis.<br></blockquote><div><br></div><div>Note that it was not proven in a wider sense that a servers private key could be gained until the CloudFlare challenge over the weekend of 12th and 13th of April.</div><div><a href="http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed">http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed</a><br>
</div><div><br></div><div>Up until that point, an exploit had not been posted nor had any proof been made that showed it could be done.</div><div>But it had to be assumed that the probability of the bug having been exploited in the last 12 months would have been as close to 1 as you could get.</div>
<div><br></div><div> As one who has to deal with this for many over the last few days... want to politely point out that an immediate shut down for a lot of servers was impossible for various reasons and in a lot of respects a waste of effort.</div>
<div>... the horse had already bolted ...</div><div><br></div><div>If the server had been up for a period, and if it used a vulnerable OpenSSL version then the smart course of action had to assume that it had already been compromised and perhaps had been for some time.<br>
</div><div><br></div><div>Shutting it down immediately was not going to fix that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Instead we've had major websites stay up whilst determining if the<br>
vulnerability is present. The seriousness of the issue and ease of<br>
exploitation demanded a more rapid and abrupt response from systems<br>
administrators.<br></blockquote><div><br></div><div>Determination was easy for some and not so for others.... </div><div><br></div><div>eg: The large number of orgs that use Akamai for content delivery were informed late last week that all was well.</div>
<div>THEN, they come out last Monday to tell us all that they have to re-issue every cert because they were shown to vulnerable after all.</div><div><br></div><div>With respect, I do understand your idea around shutting down a server but in the end it would have fixed nothing and it would have protected no-one, the damage had already been done.</div>
<div><br></div><div>The best efforts I have seen and participated in simply required a strict adherence to a simple hierarchy of mitigations:</div><div><br></div><div>1. Identify and Patch</div><div>2. Replace Certs</div>
<div>3. Inform users and have them change passwords.</div><div><br></div><div>HTH</div><div>BW</div></div></div></div>