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().
I added some new features and workarounds to some of my projects:
* New features for crash, namely TCP and UDP port forwarding similar to psc and some other neat stuff
* better support for brainkey personas in opmsg, as well as workarounds for a recent OpenSSL regression that does not allow to set ECDH privkeys to NULL any longer when doing the PFS Kex
Posts
All Comments
