We want to be able to execute a TLS handshake successfully by only moving the statemachine of OpenSSL forward untili the handshake is established.

Like:

• SKIP
• ...

Not all code of openssl is triggered by using a single static RSA certificate.

Try to include a set of certificates.

It must be possible to get data out of it. This will probably rusttls Messages.
It also must be possible to inject data. This could come from the attacker.

This task includes refactoring as we do not need the same kind of agents as in the current code.
We should also rename Send to Output and Expect to Input.

• Are only agents referenced which exist?
• Are only steps referenced which exist?

This means we want to be able to add input and output steps, as well as mutate who receives which handle.

Ignore the TLS client and implement the handshake on our self.

After that send an encrypted Finished from the client to the server:

After sending CH and Finished the handshake is finished.

Refactor such that we only deal with buffers of rustls messages. Right now we only want to send rustls messages. This means we do not need to store them as byte buffers.

This maybe simplifies code as the parsing of packages happens right at the interface between openssl and rust.

The VariableData and the data which flows into operations is basically the same. We could simply remove VariableData and replace it with any probably.

Another way would be to add a Enum VariableData. That would also remove the need of Box<> inside the dynamic function type, because the enum would be copyable/cloneable.

The project is added via an openssl crate and a git submodule to a fork of it.

In TLS we keep a transcript hash of all actions. Maybe the attacker needs some kind of "memory" from which we can calculate a transcript hash.

Right now we manually deconstruct each message in the old Expect steps. We need a procedure to deconstruct it.

Maybe use generators?

We want to test whether the attacker is able to detect simple implementation vulnerabilities in TLS 1.3.

There are two ways:

• Choose a known volnerability of which we know that we can trigger it by modifing fields in a TLS message
• Introduce a vulnerability which can be triggered by an attacker

We do not yet need a way of automatically detecting it. This is done e.g. in https://gitlab.inria.fr/mammann/tlspuffin/-/issues/15

A term looks like the following f(g(a, b,c)). There is a basic implementation which allows the following:

• Evaluate it using concrete implementations
• Make it possible to dynamically build terms during runtime.

Some possibilities for ways of doing this:

• Use a message (enum) type from which the types can be derived
  • The defined operations take care of getting the correct type
• Use higher level apis like KeyScheduleHandshake to implement operations: Needs exposure here https://github.com/ctz/rustls/blob/d03bf27e0b520fe73c901d0027bab12753a42bb6/rustls/src/lib.rs#L279
• Automatically get all functions from rustls and make it possible to call them (through Map<str, fn>
  • Statically analyze rustls and get all possible ways of calling functions
  • -> This would eliminate the need to define all operations manually
  • Also very hard because attacker capabilities are not exposed easily. Some need context which can not easily be provided (deep static understanding is required)

https://gitlab.inria.fr/mammann/tlspuffin/-/issues/15

Def.:

Unique Channel Identifier: If a client session and a
server session have the same identifier cid , then all
other parameters in these sessions must match (same
cid , offer C , mode S , pk C , pk S , psk , kc , ks, psk ).

The attacker needs to have knowledge available to be able to generate terms.

This could be as simple as a Vector of variables with a specific types and corresponding handles to VariableData.

• Cipher Suite
• Keys

Have about 5 configs with different keys.

Maybe we can use macros to speed up the calling of dynamic functions: https://doc.rust-lang.org/book/ch19-06-macros.html#procedural-macros-for-generating-code-from-attributes

This does not demolish the use of Box because we still need a dynamic trait. To get rid of this we would need an enum type.

LibAFL stores seeds on disk. It may require some serializable format for the trace and terms.

The rust-analyzer tool allows to rewrite rust code based on syntax trees: rust-analyzer ssr 'fn $a() -> $d { $e } ==>> pub fn $a() -> $d { $e }'

Unfortunately this fails right now: rust-lang/rust-analyzer#5868

Other deprecated tool: https://github.com/google/rerast/

Vec is more generic and can later be mapped to Payload, PayloadU16 etc.

When OpenSSl outputs a TLS message we can only see which fields are there. We are not able to see deeper and know which secrets have been used to compute the message. This would be needed to detect secrecy.

Here are some notes:

• keyloging callback
• -> follow flow into bitstrings

dynamic analysis ->

• find constructors and desctructors in source code manually
• When creating a tls message log which in formation was used in which order
  • e.g. session->session_id, ssl->server_random, hs->secret, derive_secret , hs->client_handshake_secret, hs->secret, derive_secret , hs->server_handshake_secret
• Instrument these variables/functions which are traceable via XRay
• Build terms out of these logs via heuristics.

https://llvm.org/docs/XRay.html#xray-runtime-library

https://github.com/llvm/llvm-project/tree/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/compiler-rt/lib/xray

For:

• https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-pcs-with-guards
• https://llvm.org/docs/LibFuzzer.html

Right now we only have a client as an attacker (seed), which does the computations necessary.

There is no need for an other term.

https://datatracker.ietf.org/doc/html/rfc8446#section-2.2

tlspuffin/rustls@clone-message...maxammann:remove-checks

Search by fn read(r: &mut Reader) -> Option< in IntelliJ

https://www.possiblerust.com/guide/enum-or-trait-object

Pro Trait:

• Open Set
• No code generation

Pro Enum:

• Fast
• Cloneable and no Heap required

The VariableData and the data which flows into operations is basically the same. We could simply remove VariableData and replace it with any probably.

Another way would be to add a Enum VariableData. That would also remove the need of Box<> inside the dynamic function type, because the enum would be copyable/cloneable.

Add a nice lookin puffin!

LibAFL needs to be setup:

• Allow the fuzzer to execute a trace
• Serialize traces
• Define a dummy mutator, which does nothing

https://github.com/maxammann/LibAFL/blob/bfbaa7ae83cfab6d94853b6be4081a54f772d921/fuzzers/libfuzzer_libpng_launcher/src/lib.rs#L170

Even with var! and app! the syntax is still verbose and hard to get right. Maybe we can improve on this. Maybe we should have just one macro with multiple cases.

I think we also could just have multiple In/Out steps

Right now we use SslOptions::ENABLE_MIDDLEBOX_COMPAT. Maybe we can increase the coverage by allowing the fuzzer to explore some more options

• Run tests
• Generate documentation: https://mammann.gitlabpages.inria.fr/tlspuffin/tlspuffin/

The function symbol op_attack_cve_2021_3449 already removes a specific extension. The renegotiation ClientHello must be constructed and signed/encrypted such that this works.

Use OpenSSL: 1.1.1j

The basic trace should allow to "drive" the OpenSSL implementation forward.

If the harness panics then the process is stopped. This is usually not a security vulnerability and shouldn't be counted as one by LibAFL.

Therefore we need to make sure that the Harness is not crashing. This can be done using Rust's Result.

Possible metrics:

• Path Coverage
• Node Coverage to some extend
• Different Protocol Runs (probably similar to Path Coverage)
• New Types of messages/alerts discovered?

Detect an authentification violation