I came across a difference between a source file t1_lib.c in OpenSSL between version 1.0.1g and version 1.0.1e, which is the critical file that had the HeartBleed security problem. This is file is only for TLS1.0. From the picture below, can you figure out which version(1.0.1e) has the HeartBleed problem, and which doesn’t(1.0.1g)? How does the HeartBleed problem work?
Here is a blog from the CVP of Microsoft Trustworthy Computing, and a change is undergoing now!
http://blogs.microsoft.com/cybertrust/2014/09/22/looking-forward-trustworthy-computing/
If I read it correctly, this is going to get security operation practices as quick as internet, as fast as services updates, comparing to what we had before for large cycles of Windows. I hope it is good for me!
Continuing the previous post.
Another problem that people might need to know is that the memory consumption in sslyze. The memory consumption is huge when scanning thousands of servers, and you won’t be able to run hundreds of thousands of hosts at one time, ’cause the memory will be sky rocketed.
The root cause it that the sslyze is trying to generate all the xml at the end of scanning, probably it want to load all the XML content with some DOM model, which requires a lot of memory. In my scanning, I actually partition hosts to small batches and use two processes running on one machine to do that work. The batch size is 5000, and the 2nd process should be started after at least 1 minute later than the 1st one, avoiding both of them completing at the same time for memory, generating a memory request peak. The server is an VM with 64GB. Usually at this batch size, the memory peak will be below 17GB.
Lately did a lot of work on SSL/TLS scanning work, for a lot of hosts, well, hundreds of thousands of them. The major tool I am using is the sslyze 0.9, which is an open source python tool, based on the OpenSSL 1.0.1g. I got a few bugs in it and hope others can be warned before using it.
For now as I can remember, one issue is that the sslyze 0.9 doesn’t generate the cipher suite order for the target (neither did any other versions). It just sort the cipher suites alphabetically! To write code to figure out the server’s cipher suite order is not very straightforward. The server won’t return the whole list for you, cause there is no such a thing in the SSL/TLS protocol. Getting the order by multiple handshake for all SSL/TLS versions for one server is not very hard, but doing it for hundreds of thousands of servers is a different story. Finally I did a good parallel quick sort algorithm to do it parallelly in about log(n) stages. The # of requests would be n log (n). The result turns out pretty much like what is described in computer textbooks. The average time on the new method is much faster than linear one.
Another one is that in HSTS (HTTP Strict Transport Security) plugin, the code will follow the 30x redirect to the new location and try to find the HSTS header there. It make no sense. It needs to come from the target server. If I report I found HSTS header from the redirected server as the original server has the header, it will be mistake. Strangely, the plugin did it correctly in 0.8.
The major bug in it, which cost me 3~4 days to get a solution, is that the http get request sent by the tool. The request could be a result from the option –http_get or –hsts. Both the PluginOpenSSLCipherSuites and PluginHSTS will issue this request. According to the SSL/TLS handshake protocol, the server may send HELLO REQUEST to the client at any time, demanding a new handshake should be made. If that’s the case, the client should immediately send CLIENT HELLO request and do the handshake job. In many cases, the server who didn’t send the REQUEST CERTIFICATE in the initial handshake sends it in the second handshake. For this kind of server, the http request sent by sslyze gets a timeout, ’cause it stupidly waiting the server to send back a HTTP response. The root cause is that it didn’t set the OpenSSL to do the auto retry (SSL_set_mode(SSL_MODE_AUTO_RETRY )). The worst thing is: The C component wrapping the OpenSSL which sslyze is calling, named nassl and is also open source, doesn’t expose this stuff to python. I failed to get the nassl source code build successfully on my windows environment. So finally I write a new dll in C doing the http request and get response via OpenSSL directly. I spent one day to do the all the tests in all cases, and also did the perf test, fearing any memory leaking, multithreading problem, or access violation problem. I hope it will work at expected when running for a large number of hosts.
Rick Xu Technology Blog 