The OpenSSL package in Ubuntu supports SHA224, SHA256, SHA384, and SHA512, even though it's not actually shown in the help, with the command line options being -sha224, -sha256, -sha384 and -sha512.
I've been happily using SHA512 with a personal CA for the last year.
It's possible that other distributions have also compiled in support for these hash functions in their OpenSSL packages.
I just tried with a 2GB file from/dev/urandom and it was of course detected as headless encryption.
I then however tried with a file that was 2GB + 1 byte, and it was still seen as headless encryption. Based on the time taken for the program to think it's headless encryption probably means it's only scanning the first X bytes, so it's possible it's just an entropy test on the header area.
This is a bit like TCHunt, except TCHunt actually does do the mod 512 test.
It is worth noting that sites that use client certificates are not affected by this, as SSLStrip cannot sign the CertificateVerify TLS message due to it not having a client certificate that would be accepted (you hope), therefore the exchange between SSLStrip and the real site would fail.
Granted you can still downgrade the session to HTTP (if you start from a HTTP site), present a fake site, and possibly obtain a password or other form of authentication token, but a valid client certificate would still be required for the authentication tokens to be of any use (assuming this is the only site where said authentication tokens get used).
Faking the real site would be difficult though, as you wouldn't be able to see it as the web server would never serve it to you as you don't have a valid client certificate to view the page.
It's a simple entropy scanner, nothing more. You can prove this by doing the following like I have done. Generate a 75MB file from/dev/urandom using dd, copy it to a Windows machine, then run TCHunt. It will find the file you made, even though it isn't a TrueCrypt volume.
This is a very good point. I run my own DNS server here, and the NAT that it sits behind remaps the ports from the random ports that BIND uses, to sequential ports on the other side of the NAT, which gives a straight line graph on the already recommended DNS OARC test. http://entropy.dns-oarc.net/test/
If you are running "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" on the machine, your search term will be stored in memory, so you are certain to get a result. You would need to take a memory dump, then run strings on that instead, preferably after it's been transferred to another machine.
Why not have the virus scanner, upon detection of a virus, check for a Microsoft digital signature in the binary, and maybe behave differently in this situation? Might just save a few systems in the future from incorrect signatures. I can't see this change in logic being beneficial to malware writers as they won't have a Microsoft signature, and if they can somehow change the anti-virus program to check for digital signatures against a different public key, you are already compromised.
It would have been nice if the article confirmed that the HPET timer was active, which I believe is rather important for the tickless kernel to work most efficiently.
Slashdot Mirror
The OpenSSL package in Ubuntu supports SHA224, SHA256, SHA384, and SHA512, even though it's not actually shown in the help, with the command line options being -sha224, -sha256, -sha384 and -sha512.
I've been happily using SHA512 with a personal CA for the last year.
It's possible that other distributions have also compiled in support for these hash functions in their OpenSSL packages.
I just tried with a 2GB file from /dev/urandom and it was of course detected as headless encryption.
I then however tried with a file that was 2GB + 1 byte, and it was still seen as headless encryption. Based on the time taken for the program to think it's headless encryption probably means it's only scanning the first X bytes, so it's possible it's just an entropy test on the header area.
This is a bit like TCHunt, except TCHunt actually does do the mod 512 test.
What an incredibly useful option, thanks!
It is worth noting that sites that use client certificates are not affected by this, as SSLStrip cannot sign the CertificateVerify TLS message due to it not having a client certificate that would be accepted (you hope), therefore the exchange between SSLStrip and the real site would fail.
Granted you can still downgrade the session to HTTP (if you start from a HTTP site), present a fake site, and possibly obtain a password or other form of authentication token, but a valid client certificate would still be required for the authentication tokens to be of any use (assuming this is the only site where said authentication tokens get used).
Faking the real site would be difficult though, as you wouldn't be able to see it as the web server would never serve it to you as you don't have a valid client certificate to view the page.
It's a simple entropy scanner, nothing more. You can prove this by doing the following like I have done. Generate a 75MB file from /dev/urandom using dd, copy it to a Windows machine, then run TCHunt. It will find the file you made, even though it isn't a TrueCrypt volume.
This is a very good point. I run my own DNS server here, and the NAT that it sits behind remaps the ports from the random ports that BIND uses, to sequential ports on the other side of the NAT, which gives a straight line graph on the already recommended DNS OARC test. http://entropy.dns-oarc.net/test/
If you are running "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" on the machine, your search term will be stored in memory, so you are certain to get a result. You would need to take a memory dump, then run strings on that instead, preferably after it's been transferred to another machine.
Why not have the virus scanner, upon detection of a virus, check for a Microsoft digital signature in the binary, and maybe behave differently in this situation? Might just save a few systems in the future from incorrect signatures. I can't see this change in logic being beneficial to malware writers as they won't have a Microsoft signature, and if they can somehow change the anti-virus program to check for digital signatures against a different public key, you are already compromised.
It would have been nice if the article confirmed that the HPET timer was active, which I believe is rather important for the tickless kernel to work most efficiently.