I would have preferred that my Android 1.6 device supported OpenVPN out of the box. Unfortunately, this is only available for rooted devices and a bit of suffering. Instead, I went for configuring IPsec inside L2TP VPN server. All of it stuffed into an old and low-end Soekris net4511 board running Voyage Linux.

First, I will just redirect you to the well-documented, lengthy but primary resource:

Using a Linux L2TP/IPsec VPN server

On the client side, this post is quite complete:

Adding VPN connections to Android 1.6 (Donut)

If you’re feeling impatient and brave, perhaps you’ll succeed with the configuration files that follow (they worked for me)… since those are highly dependant on your network setup, YMMV, a lot.

Before jumping right into the meat and to avoid confusion, let’s see what is the game all these evil daemons are going to play:

1. A client (my android phone), connects to the server on port 4500.
2. IPsec server (OpenSWAN) responds and asks for the PSK.
3. If the previous “gatekeeper” is ok with you, control is handed over L2TP, the other “tunnel keeper” who will ask for another password.
4. If L2TP is satisfied with your answer, PPPD, the ancient UNIX beast will be waken up and ask for… your user and password !
5. Congrats ! You’re survived the gates, now you’re on your home network from your smartphone, ain’t it cool ?

Continue reading →

In one single day I had to deal with two nasty tricks to get the following e-administration to work properly:

1. My swedish e-legitimation BankID software token.
2. My spanish digital certificate renewal request.

The first one failed to authenticate (silently!) because the (propietary) software, BankID, refused to work properly on 64-bit Ubuntu. Adding a wrapper solved the issue:


sudo apt-get install nspluginwrapper
sudo nspluginwrapper -i /usr/local/lib/personal/libplugins.so


On the other hand, the spanish counterpart, complained like this:

"Su certificado no ha permitido generar una firma válida"

Pasting the error on google sufficed to find the solution as well.

Now I wonder how our mums can cope with these big user annoyances :-S

Hopefully not everything is a lost cause here… openness and common sense in security seem to start making their way on Spain regarding DNIe: PKCS11 sources have been recently released !.

Just had a conversation with one good friend, rambling on the possibility of having a server-side crypted Maildir INBOX.

It seems that dovecot has a nice server-side mail compression plugin… how come there are no implementations of a session-based cyphering of mail storage based on this same principle ?

The use case is quite simple to imagine:

1. Mails keep coming to the MDA, on plain text, as usual.
2. User logs into the IMAP server with her credentials.
3. A keypair stored on user’s maildir, for instance, is unlocked using the login password.
4. New mails are cyphered and all subsequent read/write operations are performed through this (de)cyphering mechanism.
5. User logs out and the key is forgotten, shrinking the window of opportunity on possible sneakers or forensic forces.

EDIT: Of course, keeping just the public key on the server is way smarter in this case:

1. The user’s GnuPG public key is stored on her maildir.
2. All incoming emails are cyphered as they arrive with the previous public key.
3. The user logs in and sees all her mailbox cyphered, ready to be decyphered with his private key residing on her mail client.
4. Forensic analysis/spying on emails gets just a little bit harder .

He argued that just a quick UNIX pipework (using qmail) should be sufficient, but I rather preferred to keep the MTA out of the equation. The reason is that the MTA just “sinks” mail to the mailbox, while the MDA usually has both read and write access to emails, so to me it makes more sense to keep this “plugin” on the MDA side…

Is the idea clear at this point ? Is this already invented and passed under my radar ? Anyone has suggestions on top of that ?

Un altre post encuat que feia un temps volia comentar (del Gener :-S): Coloqui tècnic sobre seguretat a Praga

Després de l’spam que es va currar en Pof al passat 24C3, aquest cop em tocava a mi fer una mica d’spam sobre radare ;P