Let’s Encrypt was officially released to the open public today. That means the Internet can finally get free, trusted SSL/TLS certificates. This quick guide shows how to set up Let’s Encrypt with auto-renewal through a cronjob — using the simp_le client, an alternative client developed by one of the same authors who develop the official client.
Many of us developers or system administrators use OpenSSH’s public key authentication (aka password-less login) on a daily basis. The mechanism works based on public key cryptography: By adding a RSA/DSA public key to the authorized_keys file, the user with the matching private key can login without a password. The mechanism works great for a couple of hundred, thousands and even 100k thousand users (tested, login takes ~2sec).
But what if there are more keypairs, say, a million users, or a more flexible approach is desired? Maybe with an LDAP or a database backend? Think of GitHub and how they do their ssh firstname.lastname@example.org ... login! This blog post shows you how to do that by patching OpenSSH’s AuthorizedKeysCommand option to support an additional fingerprint argument.
These days, ISPs are often forced to block the access to certain sites, because their government considers these sites dangerous and/or illegal. While one could certainly discuss the usefulness of such measures in great detail, this tiny post focuses on the more interesting subject of how to circumvent these blockages. It’s not a lenghty post, and it doesn’t show all the ways there are, but I’ll show two simple ways to circumvent Internet non-DNS-based filters.
The recent POODLE attack (Padding Oracle On Downgraded Legacy Encryption) exploits a vulnerability of an older version of SSL (SSLv3) by performing a padding oracle attack — and thereby allowing a man-in-the-middle scenario.
To be vulnerable, both client (browser) and server have to support SSLv3. If either one does not support or has disabled the protocol, this vulnerability cannot be exploited. This tiny article shows you how to disable SSLv3 in Firefox — thereby effectively making your browser POODLE-safe.
If you have a little bit of cryptography know-how, you’ve heard of GCM, EAX and other Authenticated Encryption with Associated Data (AEAD) block cipher modes of operation. If you haven’t, AEAD modes not only encrypt data, but also authenticate it so that the ciphertext cannot be tampered without detection. In addition to that, AEAD modes can addionally authenticate additional (unencrypted) data — header data for example.
Java’s cryptography interface abstracts the underlying cipher very neatly. If you don’t have any associated data, using an AEAD mode is just like using a mode that doesn’t protect ciphertext integrity: Independent of the actual cipher and mode you are using, the Cipher class behaves identical once it has been initialized. For stream processing, the JDK additionally offers a CipherOutputStream and CipherInputStream. Input and output streams are very easy to nest so that one can compress, encrypt and sign data just by chaining different streams.
So far so good. So what’s the problem? The problem is that the CipherInputStream is terribly broken when used with an AEAD mode. In this post, I’d like to demonstrate how.
Many many moons ago, I started Syncany, a small open source file synchronization project that allows users to backup and share certain folders of their workstations using any kind of storage, e.g. FTP, Amazon S3 or Google Storage.
At the time of the initial annoucement of the project (May 2011), there was a big hype around it. I received many e-mails and lots of support from people around the world. People were excited because the features Syncany offers are great: File synchronization à la Dropbox, paired with storage flexibility (use-your-own), client-side encryption (sorry about that, NSA!), and intelligent versioning.
At the time, I didn’t actually release a runnable version of Syncany. The sole purpose of the announcement (on WebUpd8 and on the Ubuntu Podcast) was to get developers excited about the project in order to get help for the last steps of creating a somewhat stable release. Unfortunately, I was further away from this “stable release” than I could have imagined.
In this blog post, I’d like to recap the idea behind Syncany, what went wrong with the development, and how I brought the project back on track (or so I believe). I’ll also talk about what I plan to do with Syncany and how people can help (if they still want).
I recently demonstrated how to perform a man-in-the-middle attack on HTTP(S) connections using mitmproxy. While mitmproxy works just great for HTTP-based communication, it does not understand other TLS/SSL-based traffic such as FTPS, SMTP over SSL, IMAP over SSL or any other protocol wrapped in TLS/SSL.
SSLsplit is a generic transparent TLS/SSL proxy for performing man-in-the-middle attacks on all kinds of secure communication protocols. Using SSLsplit, one can intercept and save SSL-based traffic and thereby listen in on any secure connection.
The Domain Name System (DNS) is one of the fundamental services of the Internet. By resolving domain names to IP addresses, it makes routing of IP packets possible and thereby lets browsers and other clients connect to remote servers using all kinds of protocols. By blindly connecting to the IP address returned by the DNS server, however, users put a lot of trust into DNS, because by default, DNS responses are not validated or verified.
In this blog post, I’d like to demonstrate how to easily set up a DNS server that allows you to easily forge certain entries manually — thereby allowing you to either block certain domains from your network or to pretend that you are a certain website. This scenario is commonly referred to as DNS forgery or DNS spoofing.
WhatsApp is a very popular SMS-like messenger for smartphones, but it’s unfortunately only available for smartphones right now. If you want to use other tools or write web applications that send or receive WhatsApp messages (e.g. WhatsAPI), you have to find a way to sniff the WhatsApp password from your smartphone. Until recently, this password was just an MD5 hash of your IMEI (or MAC address), but that has changed when that was uncovered. Since then, the WhatsApp server assigns a password to each device/account when it first registers.
This tutorial demonstrates how to capture the WhatsApp password of your WhatsApp account using the SSL/TLS proxy mitmproxy. Once you have this password, you can use it to communicate with the WhatsApp servers directly or via a framework. This is the first part of a two-part tutorial. The second part demonstrates how to send and receive WhatsApp messages via PHP.