Implementation of RA-learning without parameters.

[00oskpet]

Initial draft without parameters, currently cannot learn a complete handshake.

[00oskpet]

I think I'm running into a possible permissions issue. I get the following when trying to run the scandic configuration.
se.uu.it.dtlsfuzzer.components.sul.core.TlsSulAdapterException: java.net.ConnectException: Connection refused
This is the command I'm trying to run:
java -jar target/dtls-fuzzer-0.3-SNAPSHOT-ra-jar-with-dependencies.jar args/scandium/learn_scandium_server_psk_ra

[kostis]

I suggest you update file .github/workflows/ci.yml by adding one more test configuration that exercises RA learning (e.g. on Scandium or some other SUT), so that we can all clearly see the possible error that occurs or the final model that is produced. I can provide some help, if it's not clear how to do this.

Now, regarding the issue you experiencing when running the above command, I also get the same error ( java.net.ConnectException: Connection refused) when running it on that particular machine, so the error is due to some other (generic) reason, not due to not having sufficient permissions (on that machine). But, just to be sure, you can try to build DTLS-Fuzzer on your machine and see whether you get something different there or not.

[kostis]

Update on the above. The issue you are experiencing is most likely due to not having set up the Scandium 2.6.2 SUT.
Start by

./setup_sut.sh scandium-2.6.2

After that, you can issue the command you want to test and you will most likely experience another error from Java, not a java.net.ConnectException. In all likelihood, it will be similar to the following:

...
The lower layer did not produce a data stream: 
java.net.SocketTimeoutException: Receive timed out
        at java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:703) ~[?:?]
        at java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:633) ~[?:?]
        at java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:240) ~[?:?]
        at java.base/java.net.DatagramSocket.receive(DatagramSocket.java:700) ~[?:?]

In any case, the errors have nothing to do with (permissions on) the machine you are using.

[00oskpet]

@kostis @pfg666
I'm close to being able to run my final experiments and begin analyzing results, there are however two files which are still having issues:
/args/ra/ctinydtls/learn_ctinydtls_server_ecdhe_cert_none
args/ra/ctinydtls/learn_ctinydtls_server_ecdhe_cert_req
both get the same serialization exception:
[com.sun.istack.SAXParseException2; lineNumber: 49; columnNumber: 28; unexpected element (uri:"", local:"autoSelectCertificate")
I've taken the most relevant part, it lists all expected elements afterwards of which there are many.
What I don't understand is that it refers to a line 49, but both the relevant alphabets are shorter than that at around 30 lines each.

Is this error related to some other xml file, or are we doing some preprocessing of the xml before we are parsing the alphabet? I've attached the log I get when running, but I might need to adjust logging levels because it I could not see anything obviously wrong happening.
learning.log

[pfg666]

@00oskpet I checked (belatedly). The short story is that I think you should omit the tinydtls configurations you mention from the experiments. The problem you mention also affects DTLS-Fuzzer master, when learning plain Mealy machines. This will require investigation to see whether it is the configuration file that's the problem, or something else. Support for raw keys in the past was a bit sketchy in TLS-Attacker. Hence, my suggestion is to ignore this problem. Once you feel the tool is ready for review, notify me in private (e.g., on Slack) and I will check (I am absolutely flooded with GitHub notifications, so might miss messages here). Well done on the extensive work!

[pfg666]

I checked, it all looks good. The concern I have is that there are SUT-specific alphabets. I would like if, wherever possible, the alphabets are SUT-agnostic, even if it means that they will contain output symbols that some SUTs never generate. This better aligns with the theory, according to which alphabets are decoupled from SUTs. I hence suggest that alphabets in the ra directory are merged, such that you have an alphabet for each configuration (e.g., dhe_cert.xml), and only have SUT-specific alphabets (named, e.g., piondtls_ecdhe_cert.xml) for cases where this is needed (similar to the Mealy alphabets). You will also need to update the argument files accordingly!

I understand why you made SUT-specific alphabets for RA learning: RALib algorithms currently require that you supply the entire output alphabet before learning. So it was natural to just have for each SUT alphabets containing all the output symbols the SUT generates. However, to be in line with the theory, I think it is better to have SUT-agnostic alphabets wherever possible.

Let me know what you think! Perhaps @kostis can also chip in.

Other than that, as RA support in PSF is developed (e.g., completing RATestRunner), the code will need to be updated, but for now it should be good!

Best, Paul.