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 email@example.com ... 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.
For my open source file sync software Syncany, I use the embedded web server and web socket server Undertow to provide a websocket and REST based interface by the Syncany daemon. Syncany clients (such as the GUI, or potentially a web interface) connect to this daemon, send requests and receive asynchronous events. Syncany’s GUI client also uses the Undertow websocket client to connect to the above mentioned daemon.
To authenticate the websocket client with the daemon, the simple HTTP basic authentication mechanism over HTTPS is used. This tiny post shows you how to authenticate against a websocket server with HTTP basic auth using the Undertow websocket client.
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.
I recently published a blog post about my open source file sync project Syncany. I explained the main idea of the project and also went into some of the details about where the development is headed. The post was the first of a series I am planning to write — showing what the project is about from different angles.
While the first post had a few technical elements, it mostly discussed the project’s process and its high level goals and ideas. In this second article, I’d like to go beyond the high level concepts and go a lot deeper into the different packages and modules of the software. Why, you ask? Because I think it might be interesting of others and because I believe that supporters and other developers will benefit from it.
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.