Notes on X3DH
Published:
Some notes on X3DH (Extended Triple Diffie-Hellman).
Published:
Some notes on X3DH (Extended Triple Diffie-Hellman).
Published:
Lack of X.509 TLS certificate validation in OWASP ZAP (Zed Attack Proxy) could be used for man-in-the-middle attacks.
Published:
Some notes about how TLS v1.3 works. This is a follow-up of the previous episode about TLS v1.2. As before, the goal is to have a high-level overview about how the protocol works, what is the role of the different messages and be able to understand (and debug) a network traffic dump.
Published:
Some notes about how TLS v1.2 (Transport Layer Security) works. The goal explain what is going on in a network traffic dump, the role of the different TLS extensions, the impact of the different cipher suites on security, etc. It includes several diagrams and many references.
Published:
The Diffie-Hellman (DH) key exchange (and variants thereof) is widely used in many protocols (such as TLS, SSH, IKE (IPSec), Signal, etc.) to bootstrap some symmetric key material which may then be used to secure communication channel between two parties. This introduction focuses on the different ways the DH key exchange is used in practice in several protocols (especially TLS) and the impact of these different approaches on the security. This is intended as a prelude for the upcoming next episodes about how TLS works.
Published:
Some notes about how to write a Frida script with the (somewhat classic) example of disabling certificate verification for TLS communications on Android applications.
Published:
In a previous post, I tried different solutions for tunnelling DNS over TLS. One of those solutions was using a dedicated DNS-over-UDP fake service replying to all queries with the truncate flag set: this was causing the stub resolvers to retry the query using a TCP-based virtual-circuit. This solution is interesting because it is dead simple (it fits in a few line of codes) but it is clearly a hack. Here, I am using a dedicated DNS forwarder aggregating all the incoming DNS-over-UDP requests over a single persistent TCP virtual-circuit.
Published:
You might want to use an open recursive DNS servers if your ISP's DNS server is lying. However, if your network/ISP is intercepting all DNS requests, a standard open recursive DNS server won't help. You might have more luck by using an alternative port or by forcing the usage of TCP (use-vc
option in recent versions of glibc) but it might not work. Alternatively, you could want to talk to a (trusted) remote recursive DNS server over secure channel such as TLS: by using DNS over TLS over TCP port 443 (the HTTP/TLS port), you should be able to avoid most filtering between you and the recursive server.
Page 1 of 1 | Previous page | Next page | JSON Feed | Atom Feed