tlspuffin / tlspuffin Goto Github PK
View Code? Open in Web Editor NEWA Dolev-Yao-model-guided fuzzer for TLS
License: Apache License 2.0
A Dolev-Yao-model-guided fuzzer for TLS
License: Apache License 2.0
A term looks like the following f(g(a, b,c))
. There is a basic implementation which allows the following:
Some possibilities for ways of doing this:
KeyScheduleHandshake
to implement operations: Needs exposure here https://github.com/ctz/rustls/blob/d03bf27e0b520fe73c901d0027bab12753a42bb6/rustls/src/lib.rs#L279We want to be able to execute a TLS handshake successfully by only moving the statemachine of OpenSSL forward untili the handshake is established.
Right now we only have a client as an attacker (seed), which does the computations necessary.
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.
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.
LibAFL stores seeds on disk. It may require some serializable format for the trace and terms.
LibAFL needs to be setup:
I think we also could just have multiple In/Out steps
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.
Right now we use SslOptions::ENABLE_MIDDLEBOX_COMPAT
. Maybe we can increase the coverage by allowing the fuzzer to explore some more options
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 ).
Right now we manually deconstruct each message in the old Expect steps. We need a procedure to deconstruct it.
Maybe use generators?
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/
Add a nice lookin puffin!
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.
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.
Not all code of openssl is triggered by using a single static RSA certificate.
Try to include a set of certificates.
This means we want to be able to add input and output steps, as well as mutate who receives which handle.
https://www.possiblerust.com/guide/enum-or-trait-object
Pro Trait:
Pro Enum:
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.
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:
dynamic analysis ->
session->session_id
, ssl->server_random
, hs->secret
, derive_secret
, hs->client_handshake_secret
, hs->secret
, derive_secret
, hs->server_handshake_secret
There is no need for an other term.
We want to test whether the attacker is able to detect simple implementation vulnerabilities in TLS 1.3.
There are two ways:
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
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.
Like:
The project is added via an openssl crate and a git submodule to a fork of it.
Vec is more generic and can later be mapped to Payload, PayloadU16 etc.
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.
tlspuffin/rustls@clone-message...maxammann:remove-checks
Search by fn read(r: &mut Reader) -> Option<
in IntelliJ
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.
Have about 5 configs with different keys.
The basic trace should allow to "drive" the OpenSSL implementation forward.
Possible metrics:
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
Detect an authentification violation
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.