assist-project/dtls-fuzzer

OpenSSL 3.0.0

Opened this issue ยท 4 comments

Hi, I've been interested in this fuzzer. I tried to use it to fuzz the new Openssl 3.0.0, while in the end there were only 2 hyps.

Is it need some changes to support openssl 3.0.0?

Thanks for your interest in DTLS-Fuzzer!

AFAIK, we have not tried to learn models of OpenSSL 3.0.0, so we have little experience about them to say anything definitive. But generating only two hypotheses seems a bit suspicious. On the other hand, it's impossible to comment further without also knowing which configuration and command-line arguments you've used for your experiment or without knowing how these hypotheses look like. Perhaps posting here some information on how to repeat your experiment may help us further investigate this.

Thanks for your reply! Here is my workflow.

First, I compiled the OpenSSL 3.0.0 using setup_sut.sh.

Second, I was considering to fuzz all key exchange algrithoms. I copied openssl1.1.1b_all_cert_req_rwalk_incl and renamed it to openssl3.0.0_all_cert_req_rwalk_incl.

Then, because OpenSSL 3.0.0 didn't change a lot compared to 1.1.1. So, I just used the same alphabet, arguments, key and certificate as 1.1.1. The only diference here is the directory name of suts and arguments.

LD_LIBRARY_PATH=suts/openssl-3.0. java -jar target/dtls-fuzzer.jar @args/openssl-3.0.0/learn_openssl-3.0.0_all_cert_req_rwalk_incl -queries 5000

Finally, I began the learning and the result said:

12:07:47 [main] WARN : ReceiveMessageHelper - Received ICMP Port Unreachable while recieving for Messages.

It seems like the server even didn't start.

Hi @mufanlin ,

The reason why it did not start is because the command used to launch OpenSSL is no longer valid. I updated the argument files to make them work with all versions of OpenSSL, including 3.0.0. The only argument file/configuration which still causes issues is the one requiring a certificate (which is the one you use, unfortunately). All others should work.

To test that you can complete a handshake with a 'certificate auth. disabled' server, run:

java -jar target/dtls-fuzzer.jar args/openssl/learn_openssl_server_all_cert_none -Dopenssl.version=3.0.0 -test examples/tests/servers/rsa

This should complete a handshake on your system. You can generate a model for such a configuration (capping test queries to 5000) by running:

java -jar target/dtls-fuzzer.jar args/openssl/learn_openssl_server_all_cert_none -queries 5000

Thanks for reporting the issue! When I find the time I will look at the server setting requiring a client certificate, and why it still does not work properly for OpenSSL 3.0.0 (essentially, we cannot complete a handshake).

Thanks! It works with the new argument (though I'm sure why a deleted "timeout" makes the server start correctly).