The only way I can think of to check this is to manipulate the payload length. Making this length something lower than what we actually send should return in only a part of the original data being sent back. Of course this is behavior in both the bad and good versions, so we can't check it that way. We could also make the length field something higher than what we actually send, but this would mean getting back data.
*However*, if there's a way to specify the data it sends back, that wouldn't be a problem (I'm no legal specialist though). I have not yet tested my theory, but sending a few extra bytes in the heartbeat message (and of course incrementing 'length' in the 'ssl3_record_st' struct) should do that. It would allow causing the server to return data the client sent. If it's not sent back, the server isn't vulnerable. No random memory is read as the server did in fact allocate the memory, it's simply not supposed to use it.
Just a thought, maybe someone with more knowledge of these things can confirm it?
Tom Alexander Dietrich schreef op 09/04/14 21:07:
According to Qualys, they have developed a test that "verifies the problem without retrieving any bytes from the server, other than the bytes we send in the heartbeat request": https://community.qualys.com/blogs/securitylabs/2014/04/08/ssl-labs-test-for-the-heartbleed-attackBest regards, Alexander --- PGP Key: 0xC55A356B | https://dietrich.cx/pgp On 2014-04-09 20:51, Paul Pearce wrote:* Should authorities scan for bad OpenSSL versions and force their weightdown to 20?I'd be interested in hearing people's thoughts on how to do such scanning ethically (and perhaps legally). I was under the impression the only way to do this right now is to actually trigger the bounds bug and export some quantity (at least 1 byte) of memory from the vulnerable machine. _______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays