I reworked the local address binding and connecting part of my anti censorship tools crash and psc, so it is now possible to use SOCKS5 client side connects by using -x (similar to curl) and to let the SOCKS5 proxy resolve DNS names (-N) in order to allow browsing with chrome (but check README).
You can also check out @fullspectrumdev's blog writeups on pentest use-cases and cross-compilation.
Interestingly, OpenSSH now also supports traffic blinding, which is included in crash since years.
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!
Posts
All Comments
