connection issue with PKCS#11 support

[eworm]

For the Arch Linux OpenVPN package [0] I enabled PKCS#11 support recently [1]. The new package has issues connecting to servers that worked before. The issue has been reported in downstream bug tracker [2]. Note the affected connections do not use PKCS#11 at all, support has just been enabled in the package.

[0] ​https://www.archlinux.org/packages/?name=openvpn
[1] ​https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/openvpn&id=d45bef7c0674e760f30cca45db1fad65c9568b1e
[2] ​https://bugs.archlinux.org/task/50090

[Gert Döring]

Since this seems to happen *only* with PIA, maybe something on their side is reacting differently to builds with/without --enable-pkcs11?

@dazo, any idea how to tackle this?

[David Sommerseth]

Please open up a support ticket with PIA instead. As this works well with non-PIA servers, it's a strong indication something is happening in the way PIA have configured their servers. And we would need to see server logs to come further. I've looked through comments and log files from ​https://bugs.archlinux.org/task/50090, so I fail to see this being an upstream issue.

For now, closing this issue as "notabug". If there are new evidence making this an upstream issue, we can re-open this issue.

[eworm]

We know the details now. The server is running an OpenVPN instance without PKCS#11 support. Password length is limited to 128 chars (see src/openvpn/misc.h, line 203 and below) there. However PIA accepts to set longer passwords.

A client without PKCS#11 support connects without issues. The password is truncated to 128 chars on both sides.

A client with PKCS#11 support uses longer passwords (up to 4096 chars) and fails to connect. If you manually truncate the password to 128 chars the connection is established successfully.

We have an easy workaround now, but how to handle this in openvpn correctly?

[David Sommerseth]

PATCH] Have the same username/password length regardless of PKCS#11 enablement

[David Sommerseth]

I just sent the attached patch to the mailing list for review (haven't appeared on the ML yet - Message-Id: <1474538677-23301-1-git-send-email-davids@…>)

commit f514b9d2ed9865be191b18d53c466098823208d8
Author: David Sommerseth <davids@openvpn.net>
Date:   Thu Sep 22 12:01:37 2016 +0200

    Have the same username/password length regardless of PKCS#11 enablement
    
    If running an OpenVPN client with --enable-pkcs11 and a server without
    and having a username and/or password with more than 128 characters,
    the authentication will fail as the server truncates the password
    to 128 bytes.
    
    This makes things easier and more predictable.  Username/passwords
    can be up to 4096 bytes, regardless of the --enable-pkcs11 state.
    
    Signed-off-by: David Sommerseth <davids@openvpn.net>

I see I forgot to add the Trac reference to the commit, I'll ensure that happens during the commit if it gets approved.

[David Sommerseth]

There it is: ​https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12535.html

[David Sommerseth]

After some discussions on #openvpn-devel, we are not too happy about this approach either. The memory usage due to this change is extended with at least 11.5KB which really isn't needed in most cases. That amount isn't much on a common computer these days, but as OpenVPN is used on embedded systems that amount of additional memory usage can definitely be noticed.

So first question is: How long usernames/passwords do you expect to handle?

Another thing we need to investigate is how this will impact the PKCS#11 implementation if we decrease the 4KB to something a lower value. We want client and server to have equally large buffers, regardless of --enable-pkcs11; to avoid situations like this bug ticket.