In order to properly proxy messenger apps from censored networks to outside, I added the -X switch to crash and documented on how you would configure your setup within the contrib folder.
It is already field-tested in certain countries. Nevertheless, if you have deeper knowledge on censorship equipement or extra tips for better connectivity and can battle test the setups, just let me know.
I re-polished a 10y old project that is one of the most complete tunneling solutions available for ICMP, ICMPv6, DNS over IP and DNS over IPv6 when it comes to setting up connectivity in restrictive environments. I added some fixes so it now properly also works behind NAT.
Probably the last post in 2022.
I fixed SOCKS5 handling in psc and crash so that it is now possible to use it with curl and IPv6. Also added DTLS (read: TLS over UDP) support for crash in order to make it possible to use anti censorship SOCKS proxies in countries that block outgoing TCP connections such as in Iran (see previous post).
When I read about LibreSSL having QUIC support, I tried to use this, but their bold announcement was a spoiler. They only "support" the QUIC handshake to obtain keying materials by means of TLS integration. I wouldn't really call this "QUIC support", although I love LibreSSL much more than OpenSSL (due to their permanent API changes). As DTLS has only reliability for its handshake, I had to add my own TCP-style data flow mechanisms to handle packet loss and re-orders. OpenSSL also wants to add QUIC support, so lets see in a couple of years how far this goes (hopefully with full proto and API support and not just the handshake) to finally have a usable QUIC lib.
Crash also switched from TLS v1.2 to v1.3 being mandatory, i.e. it is not proto compatible to the 2.x versions anymore. As soon as DTLS v1.3 will be widely deployed, it will also switch to DTLS v1.3. Due to all these new features and compat things the crash-3 versions are dubbed experimental (although working stable).
Wish you a nice rest of 2022 and a Guten Rutsch for 2023!
We at c->skills know how the Hase läuft and therefore made a writeup on SNI probing and blocking.
Since a parallel version of nftw() already existed inside my greppin project, it was only little effort to add a parallel find: spot
I commited some changes to some of my gh projects:
psc is now using an embedded AES and SHA-512 implementation, in order for easier builds for embedded systems w/o proper SDK support. E.g. it is now super easy to have Android binaries built with it, w/o messing with BoringSSL builds. It also contains a base64 en/decoder on the remote side callable via pscr -E or pscr -D for convenience. Last not least, you can script psc sessions via pscsh. Something similar you propably know from screen with shared sessions.
For harddns, my DoH solution - that was one of the first Open Source DoH implementations available at all - I added NXDOMAIN replies for PTR queries, in order to keep up with newer net-utils packages on current distributions which always try to reverse-resolve obtained A records to PTR records. I also updated the shipped default config to remove the PowerDNS DoH servers, as they recently have shutdown this service :(
Some of you probably already noticed in past, but almost exactly one year ago, I founded my own company:
You can find more details about the exact services at our gh landing page. In order to celebrate our 1y, I pushed new commits to our performance flagship greppin. It is now basically lock-free and runs faster than ripgrep.
Thanks to our clients who made this possible! If things go well as before, I will also alloc() a merchandise budget, so you may ask me for free tee-shirts at the conferences.
I refactored opmsg for the new OpenSSL 3.0.0 API and put it into the openssl3-dev branch. Master branch is still the main development branch and both branches produce 1:1 identical output of messages, so one can cross-over test them. Over the long run it is probably necessary to switch to OpenSSL 3.0, but the downside is that it will lose compatibility with the LibreSSL API.
On the plus side, I learned a lot of the inner workings of OpenSSL while refactoring my own code. Including misleading man pages.That will definitely give me an adavantage for the next crypto project code review. :)
Wish you a nice pre-xmas time!
I have added patches to opmsg to implement PQC during the transitioning phase. Adding PQC sounds easier than it actually is, as there are several (administrative) problems:
* So far, no PQC algo has been standartized. Everything is still floating and in progress.
* Several PQC open-source projects exist, such as OpenQuantumSafe which implement the candidate algos, but which recommend to not use their impl in production code.
* Some patches for OpenSSL 1.1.0 exist such as for NTRU, but only cover the 1.1 API which will soon be denounced.
* OpenSSL 3.0 on the rising, changing the ENGINE API in favor of "Providers", but I didn't see any PQC code in it.
* Big tech companies making their own PQC patches and tests for marketing reasons but these are not usable for opmsg as they only cover TLS handshakes for their own good.
Sounds to me like I could only bet on the wrong horse by making any decision.
Therefore, I decided to agnostically add PQC support by following recommendations of the BSI when migrating crypto to PQC for the time being. That means extending opmsg Brainkey Personas by a second type "brainkey2" which adds a symmetric salt in the ECDH Kex. This is transparent to the user. At the same time, I ban non-AEAD symmetric algorithms for future encrypts (decrypts still work for compat) and extend the coverage of the AEAD to the entire message, including the header. That means that the entire opmsg is not only integrity protected by the ECDSA signature, but also by the AES-GCM MAC. The PFS property and everything else stays the same. The new default calgo is now "aes256gcm".
I am sorry I had to kick bf, cast5 and ripemd160 from newly encrypted messages, but these algos are outdated anyway. It should still be possible to decrypt all previous messages, despite of ciphers and persona types.
I have to check how OpenSSL develops, as I want to keep compatibility with LibreSSL API. So I have to be careful when adding new symmetric ciphers with AEAD capability such as EVP_aria_256_gcm().
Posts
All Comments
