Rework NCP compability logic and drop BF-CBC support by default

Rework NCP compability logic and drop BF-CBC support by default

This reworks the NCP logic to be more strict about what is
considered an acceptable result of an NCP negotiation. It also
allows us to finally drop support for BF-CBC as default cipher.

All new behaviour is currently limited to server/client
mode with pull enabled. P2p mode without pull does not change.

New Server behaviour:
- when a client announces its supported ciphers through either
  OCC or IV_CIPHER/IV_NCP we reject the client with a
  AUTH_FAILED message if we have no common cipher.

- When a client does not announce any cipher in either
  OCC or NCP we reject it unless data-ciphers-fallback is
  specified in either ccd/ or config.

New client behaviour:
- When no cipher is pushed (or a cipher we refused to support)
  and we also cannot support the server's cipher announced in
  OCC we fail the connection and log why

- If there is no cipher in OCC but data-ciphers-fallback is
  specified we will use the fallback cipher instead of failing the
  connection

Both client and server behaviour:
- We only announce --cipher xyz in occ if we are willing
  to support that cipher (always announce the cipher if
  NCP is disabled or not in --client mode)

  It means that we only announce the fallback-cipher if
  it is also contained in --data-ciphers

Compatibility behaviour:

In 2.5 both client and server will use a --cipher xyz present
in the config to automatically set --data-ciphers-fallback xyz
and also append this cipher to the end of data-ciphers.

We log a warning about this and point to --data-ciphers and
--data-ciphers-fallback This also happens if the configuration
contains an explicit --cipher BF-CBC.

If --cipher is not set, we only warn that previous versions
allowed BF-CBC and point out how to re-enable BF-CBC. This will
break configs where someone connects a 2.3 client (or older)
to a 2.5 server AND has no explicit --cipher setting in the
server config.  We still do it, because at some point we need
to drop the BF-CBC default - and affected users already had the
scary SWEET32 warning in their logs for a long time.

In short: If --cipher is explicitly set then 2.5 will work the
same as 2.4 did. When --cipher is not set, BF-CBC support is
dropped and we warn about it.

Examples how breaking the default BF-CBC will be logged:

Client side:
 - Client connecting to server that does not push cipher but
   has --cipher in OCC

    OPTIONS ERROR: failed to negotiate cipher with server.  Add the
            server's cipher ('BF-CBC') to --data-ciphers (currently
            'AES-256-GCM:AES-128-CBC') if you want to connect to this server.

 - Client connecting to a server that does not support OCC:

    OPTIONS ERROR: failed to negotiate cipher with server. Configure
            --data-ciphers-fallback if you want connect to this server.

Server Side:
- Server has a client only supporting BF-CBC connecting:

  styx/IP PUSH: No common cipher between server and client. Server
          data-ciphers: 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-256-CBC:AES-128-CBC', client supports cipher 'BF-CBC'.

 - Client without OCC:

   styx/IP PUSH:No NCP or OCC cipher data received from peer.
   styx/IP Use --data-ciphers-fallback with the cipher the client is using
           if you want to allow the client to connect

In all cases the client is rejected with this message:

   AUTH: Received control message: AUTH_FAILED,Data channel cipher
         negotiation failed (no shared cipher)

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Patch V2: rename fallback-cipher to data-ciphers-fallback
          add all corrections from Steffan
          Ignore occ cipher for clients sending IV_CIPHERS
          move client side ncp in its own function
          do not print INSECURE cipher warning if BF-CBC is not allowed

Patch V3: fix minor style, add null check when client sends no peerinfo at
          all

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200809141922.7853-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20656.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>