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.

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.

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.

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"]);

curl_exec($ch);

This code is broken, can you tell how?

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.

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.

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%).

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.

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.

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.