Missing config setting with tls-auth option - feature request



  • Hi

    I have discovered a tiny problem with out openvpn setup.
    We are omitting the optional 0/1 value at the end of the tls-auth parameter, but the openvpn (client) config gets created with the value "1" at the end. (as shown in the openvpn documentation: https://community.openvpn.net/openvpn/wiki/Hardening#Useof–tls-auth)

    And it is impossible for us (in any short timespan) to touch all clients an change this parameter.

    It would be nice to have a small check box like "omit client option for tls-auth" or something like that.

    The problem you will get is just a bit shot of an explanation.

    local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
    Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
    Local Options hash (VER=V4): '56f60c8f'
    Expected Remote Options hash (VER=V4): 'e1494645'
    

    And then the connection gets closed. Basically after a successful connection and authentication…

    My workaround is to go into the /var/etc/openvpn directory, change the parameter by hand, an restart the service.
    This is ok as a workaround, as I think, because the file just gets written after I change some config settings, witch should not happen very often :)

    best regards
    Daywalker


  • Rebel Alliance Developer Netgate

    Why are you omitting that value when the documentation recommends it be set for increased security?

    The  optional  direction parameter enables the use of 4 distinct
                  keys (HMAC-send, cipher-encrypt, HMAC-receive,  cipher-decrypt),
                  so that each data flow direction has a different set of HMAC and
                  cipher keys.  This has a number of desirable security properties
                  including  eliminating  certain  kinds of DoS and message replay
                  attacks.

    When the direction parameter is omitted, 2 keys are  used  bidi-
                  rectionally,  one  for HMAC and the other for encryption/decryp-
                  tion.

    You're just hobbling the feature by omitting the direction. Seems it would be much simpler to add the direction on the server side like it wants.


Log in to reply