January 26, 2016

The Wrong Number Attack

XMPP is federated, similar to email, which means different domains can connect to each other. Back in the early days, when a server initiated a connection to a server, the initiating server could be reasonably sure it connected to the right place as it resolved the DNS records (remember, it’s 1999). But the receiving server has no guarantee on whether the incoming connection was actually from the domain it claimed.

Read more
December 28, 2015

Common DH groups

To deal with the logjam attack, I was looking for a set of all “common” Diffie-Hellman parameters to update xmpp.net, yet I wasn’t able to find those easily. Even just searching for the hexadecimal representation of commonly encounted primes often didn’t lead to the document they were specified. Here I’m documenting those that I found and where they are from.

Read more
December 18, 2015

Out with octopress, in with Hakyll

As you can see, the layout of this blog has changed. I was updating this blog so little, every time I did Ruby had broken everything (or so it felt like). I don’t like the idea of having to learn Ruby or gem to blog, so I’ve decided to switch to something else.

Read more
April 17, 2015

Validate the encoding before passing strings to libcurl or glibc

Lets start with a simple example in php:

setlocale(LC_ALL, "nl_NL.UTF-8");

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $_GET["url"]);


This code is broken, can you tell how?

Read more
January 23, 2015

Multi-end to multi-end encryption

It’s a week until the XMPP Summit in Brussels, which I won’t be able to attend. How­ever, I do have some thoughts about two of the subjects that are on the agenda that I wanted to share.

Carbons/MAM and e2e-encryption seem to be moving in two completely opposite directions: MAM wants to store messages server-side, while e2e protocols like OTR want to ensure those stored messages are useless. But I don’t think they’d have to be mutually exclusive. I think it would be possible to find a solution that unifies the two concepts.

Read more
August 7, 2014


In part 1 I looked at BEAST and concluded that it would not be possible for XMPP. In this part, I’ll look at compression based attacks, similar to CRIME and BREACH for HTTPS.

Read more
June 2, 2014

CVE-2014-1361: SecureTransport buffer overflow

Today, Apple released a fix to CVE-2014-1361 in SecureTransport. The essence of this bug is this: the TLS record parser would interpret a DTLS record even when using normal TLS, causing a buffer overflow when parsing a record header. I reported this issue to Apple on May 28th.

To summarize, the impact of this bug is small: it can disclose 2 specific bytes of plain text to an attacker. Doing this will also cause the connection to be closed. It can also give an attacker the ability of carrying out a replay attack, with a probability of success of 2-16 (~0.0015%).

Read more
April 2, 2014

Breaking Half of The Telegram Contest

The Telegram contest has ended without anyone having claimed the prize. The contest has received a lot of criticism from cryptographers due to not creating a realistic scenario: the contest only gave read access to the communication, with no way to influence the packets sent.

Read more
February 14, 2014

HTTPS Attacks and XMPP 1: BEAST

In the past couple of years, a number of attacks have been found on “TLS”, but often those attacks were only shown with HTTPS. The majority of TLS encrypted traffic is probably HTTPS, but it’s important to understand which of these attacks can be translated to other protocols. I’ll use XMPP, but I’ll try to get the attacks down to the core features the used protocol needs to support to help others determine which other protocols are also vulnerable.

Read more
January 17, 2014

Misconceptions about forward-secrecy

Lately, there has been a lot of interest in forward-secrecy, mostly in the context of TLS/HTTPS. Some people seem to think it’s a magic bullet that will thwart all the NSA’s efforts. I am not against forward-secrecy, to the contrary, I think any encrypted communications protocol should use it, but I think it is important that people keep realistic expectations about what forward-secrecy protects them against. The worst security is security that you assume you have, but don’t actually have.

Read more