reneg-bytes not disabled per default as stated in docs

[mangodan]

openvpn renegotiates keys after ~100Megabytes by default. The docs suggest this feature is disabled per default.

With this feature enabled whilst using authy 2FA plugin the connection fails after renegotiating keys which itself fails.

setting config option

reneg-bytes 0

resolves.

[Gert Döring]

reneg-bytes still defaults to 0, except if you're using a 64bit-block based cipher, like blowfish. In that case it's set to 64MB to counter SWEET32 attacks.

I can see how annoying this can be with 2FA - depending on the number of users and other factors, the best way to work around this is to migrate to --cipher AES-256-CBC . Alternatively you can decide to ignore that issue and force reneg-bytes 0 in the config - which we allow (after quite a bit of internal discussion) as a stopgap measure until migration to larger-block ciphers can be done in a given setup.

It's not explicit in the manpage, but the ChangeLog? for 2.3.13 mentions this...

- Enforcing a new default value for --reneg-bytes for known weaker ciphers
  
  Ciphers with cipher blocks less than 128 bits will now do a renegotiation
  of the tunnel by default for every 64MB of data.  This behaviour can be
  overridden by explictly setting --reneg-bytes 0 in the configuration file,
  however this is HIGHLY discouraged.

  This is to reduce the risk for SWEET32 attacks.  The general recommendation
  is to change the cipher to a stronger cipher.  For more information see:
  https://community.openvpn.net/openvpn/wiki/SWEET32

  OpenVPN will also complain a little bit more in the logs
  when such weaker ciphers is detected.

... seems we want to add a few words to the --reneg-bytes section of doc/openvpn.8, and also fix the wording of Changes.rst which is not very clear in the "Beavioural changes" section of 2.3.

[mangodan]

I did see this in the changelog, however the re-negotiating definitely happens at around 100MB rather than the 64 stated and thus i concluded it unrelated.

Some more details here : ​https://github.com/authy/authy-openvpn/issues/14

[David Sommerseth]

Please see my response to the same github ticket and Trac ticket #797.

[Gert Döring]

well, 100 MB would surprise me, but "64MB" is not a hard number - if I understand the explanations correctly, hitting 64MB will trigger the renegotiation, but data transfers will go on using the existing key. So if you transmit very fast, you might end up reaching 100MB before the "oh, btw, you need to reauth!" will hit.

@syzzer: right?

[Steffan Karger]

@cron2: right.

At 64MB, a renegotiation is triggered. The old keys are used until that succeeds. I already saw signs of a man page fix coming up, adding a note to the --reneg-bytes section.

[mangodan]

I can confirm that switching to the AES-256-CBC cipher has resolved the "connection hang" problem.

[David Sommerseth]

The following patches, updating Changes.rst and openvpn.8 man page have been applied:

release/2.3

commit 49e6ce5b9dea9b7beadb9a6e2586770090c5556b
Author: David Sommerseth <davids@openvpn.net>
Date:   Wed Dec 21 21:54:50 2016 +0100

    docs: Further improve --reneg-bytes and SWEET32 information
    
    There are still some support tickets related to SWEET32 and
    our defult enforced --reneg-bytes 64 when using weaker ciphers
    (less than 128-bits cipher blocks).  Try to clarify this even
    more.
    
    Also fix a few mistakes, saying less than 128-bits and not 128-bits
    and less.
    
    Signed-off-by: David Sommerseth <davids@openvpn.net>
    Acked-by: Steffan Karger <steffan@karger.me>
    Message-Id: <1482353691-27088-2-git-send-email-davids@openvpn.net>
    URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13662.html

release/2.4 + git master

commit a256aee8e70ceb7059b9da69bc3e7cccbd094916  master
commit 203d7c8b1fdab065aa0b2a522abe00dc39fa433a  release/2.4
Author: David Sommerseth <davids@openvpn.net>
Date:   Fri Dec 23 17:07:44 2016 +0100

    docs: Further enhance the documentation related to SWEET32
    
    The git master/2.4 code lacked some useful information about
    the changes to --reneg-bytes, SWEET32 and weak ciphers (less
    than 128-bits cipher blocks)
    
    v2 - Fixed a couple of grammar/typo issues
    
    Signed-off-by: David Sommerseth <davids@openvpn.net>
    Acked-by: Steffan Karger <steffan@karger.me>
    Message-Id: <1482509264-24550-1-git-send-email-davids@openvpn.net>
    URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13682.html

In regards to this statement:

 With this feature enabled whilst using authy 2FA plugin the connection fails after renegotiating keys which itself fails.

The authy plug-in should ideally implement support for sending --auth-token to the clients. Alternatively the server side can be upgraded to the v2.4 release and make use of the --auth-gen-token, which will do the --auth-token authentication inside the server code. The limitation of this approach is that the auth-plugin will not see any of the re-negotiations at all. I already opened a github issue in regards to this, with more details: ​https://github.com/authy/authy-openvpn/issues/15

And a final response to comment #6; switching to AES-256-CBC will keep --reneg-bytes being disabled unless explicitly enabled. --reneg-bytes will only be enabled by default and initially set to 64MiB on weak ciphers (using a cipher block size less than 128 bits), unless explicitly disabled with --reneg-bytes 0 (which is highly discouraged)

As I believe this issue is now resolved, I'm closing this ticket.