-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/09/16 18:43, Selva Nair wrote: > Hi, > > On Thu, Sep 22, 2016 at 6:04 AM, David Sommerseth > <dav...@openvpn.net <mailto:dav...@openvpn.net>> wrote: > > 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. > > > In spite of this change, in most usage scenarios, username, > password and even pkcs11-id are limited to a much smaller length > (more like ~256 bytes) for other reasons: > > The pkcs11-id is the only string that probably needs such a long > length, but its limited to ~240 bytes when read from the config > file because of max line length of 256 bytes + 1 for NUL (in some > code paths 255?). Even if the max line length is increased, the max > size of an option parameter is 256 bytes (+ 1 for NUL). > > The 256 byte limit on parameters in response received from > management (pointed out by Jonathan) is also somewhat related to > the above: Input from management goes through the same parsing code > as the lines read from the config file for handling escapes, > embedded whitespace etc. and a limit of 256 bytes per option > parameter is imposed > > Also usernames > 64 bytes will break --username-as-common-name as > CN is limited to 64 bytes (could 64 code points, but it seems > openvpn interprets that as 64 bytes). > > So for most practical purposes, pkcs11-id appears to be limited to > ~240 bytes characters in the current code. Changing USER_PASS_LEN > to, say, 256 may be more sensible. That shouldn't break any > existing configs but may break some use cases where a long id is > supplied from the command line.
Thank you for a thorough check-up! I have spotted a few places where 'struct userpass' have been declared as global variables, like in socks.c, proxy.c and ssl.c. For simplicity this can be okay, code wise. But considering these buffers is not be used in all configurations (probably not even the majority of configurations), this seems like wasted memory. I also do not have complete overview of the management code yet, as struct user_pass is used inside some other management related structs, where some might also be global. I have no issues to set USER_PASS_LEN to 256 or 1024 or in between as long as we are confident we don't break anything. But I think we could clean up several of these global variables too. - -- kind regards, David Sommerseth OpenVPN Technologies, Inc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJX5BhuAAoJEIbPlEyWcf3yO8QP/2TJzxlf1nE9XuLZmWuZYLnu 76wUBd+MsPnSGu0Jv8bAqBA2O7kLPH+G6n265x11FLerJk7cbAJqq8j/PXoHP51U lUSPVuWv2TKdizPjy3zoCxP30YKgvs7mWg4JCyyWvcrC2L/MDLRABFALa7PvhyOQ OtjIi+9PW5gP3BQ207b1bIXyVCFUgPzlU4V+tE09OXFI2vT7/k+gAkFai0jxI4fb +6pEhIui3S20CdZlsIUj4jrHWk/bwLPH8JZ7JP+EKxu3XNDN28exP84ngOKjnntt A/SaKLp2pbtQGeyB1h2Pv07u7vmVwp6bXmxYUhuc6E3POEh1mg+uL2e3Dd3f+2oW BcZkMN75LpCTQYk3PqwV6UpjJ6jLurTMzAEnQ0Rf6EUFf6Vzeti2QyAoiTynGjGh zer7lYY918K3+kiFUJ/fvdMhFbnIFcBc3579Hpgahp1V5KhKnGN5t1fnWKAy+7sm se4pq4Be+SPV/EI6nFvab6dik9MJorSqmWRrfZeTyIV0+3BKtZc8g415litglh6x gT/Atf4G4BLxe4I3G66flSZBG7rLGi8DZnnsPz2SYcPMQyEz9PbkRA+Dumi7QFRg i1ghdI6bkT8Fnw3wx4/hHcIr1Tu76xxl6PGKqCp8u3SeXhXv9kzWX29q65Ie1hLB VNbRKmRCJFMEnV/9g7uG =Cjnn -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
