(Change announced on Jul-18) |
|||
Line 19: | Line 19: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= | = New default cipher in OpenVPN <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == |
Revision as of 08:06, 25 July 2017
New default cipher in OpenVPN
Summary
Since the discovery of the SWEET32 flaw, ciphers using cipher-blocks smaller than 128-bits are considered vulnerable and should not be used any more. OpenVPN uses Blowfish (BF-128-CBC
) as the default cipher, which is hit by the SWEET32 flaw. This proposal changes the default cipher to AES-256-GCM
while in parallel allowing clients to connect using AES-256-CBC
, AES-128-CBC
or the deprecated BF-CBC
,
This proposal will make use of that possibility by modifying the openvpn-server@.service unit file slightly.
Owner
- Name: User:dsommers David Sommerseth
- Email: davids@openvpn.net
- Release notes owner:
Current status
- Targeted release: Fedora 27
- Last updated: 2017-07-25
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
There have been two independent security audits of OpenVPN recently, performed by QuarksLab SAS and Cryptography Engineering. Both recommeds moving away from the default Blowfish cipher (BF/BF-CBC) to a stronger cipher.
The concept is fairly simple. In today's openvpn-server@.service systemd unit file the following command line is used to start OpenVPN:
ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
By adding --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC
before the --config
option, the default cipher will be modified. The --ncp-ciphers
list allows clients to use any of the listed ciphers as well. The new line will look like this:
ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf
This will result in the following:
- OpenVPN 2.4 based clientswill automatically upgrade to AES-256-GCM, regardless if they have
--cipher
in their configuration file or not. For OpenVPN v2.4 configurations not wanting this cipher upgrade, the client configuration needs to deploy--ncp-disable
. - OpenVPN 2.3 based clients and older (and v2.4 clients using
--ncp-disable
in the client configuration) can connect to the server using any of the--ncp-ciphers
list; this is what is called "poor man's cipher negotiation" by the upstream OpenVPN developers. - Any client not providing
--cipher
defaults to BF-CBC. These clients should still be able to connect to the server as the server allows BF-CBC through--ncp-ciphers
.
If an already configured OpenVPN v2.4 based server configuration deploys --cipher
and/or --ncp-ciphers
, the options in the configuration file will override command line options set before --config
. This should not break any existing configuration.
The log files will still complain about the use of BF-CBC if a client uses that. But the advantage is that OpenVPN v2.3 and older clients can be updated one-by-one, by adding the recommended --cipher AES-256-CBC
option in the client configurations in their own pace, independent of the server - or upgrade to OpenVPN v2.4 or newer.
Benefit to Fedora
This enhances the default OpenVPN configurations by allowing users to seamlessly upgrade to a stronger cipher in a controlled way without breaking existing client connections.
Scope
- Proposal owners: Patch the openvpn-server@.service unit file which adds the
--cipher
and--ncp-ciphers
options.
- Other developers: N/A (not a System Wide Change)
- Release engineering: #6908 (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
This change should not require any initial configuration changes for users or server admins. After this change, clients using OpenVPN v2.3 or older should consider to add --cipher AES-256-CBC
to their client configuration files to enable a stronger and safer cipher. But this is not required and old existing client configuration files should continue to work.
N/A (not a System Wide Change)
How To Test
Generic test script:
- Create a simple CA (using easy-rsa, XCA, TinyCA, etc) and issue a server certificate and at least one client certificate
- Prepare a simple server and client configuration file, utilizing
--ca
,--cert
,--key
. Also use a--verb
level between 2 and 4 to get enough details about the established connections. - Put the server configuration into
/etc/oepnvpn/server
and the client configuration on a different host into/etc/openvpn/client/
(unless the client us a non-systemd based client, eg Windows client) - Start the server by running
systemctl start openvpn-server@$CONFIG_NAME
- Start the client
Depending on the version of OpenVPN clients, the result should be that a tunnel is successfully established. But the cipher being used may be different. This can be observed in the log files.
[root@host ~]# journalctl -u openvpn-server@vpn0 --since today | grep -E "Data Channel (En|De)crypt: " Jun 28 12:15:42 host.example.org openvpn[1234]: client.example.org/10.99.88.1:48593 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Jun 28 12:15:42 host.example.org openvpn[1234]: client.example.org/10.99.88.1:48593 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
- A 2.4 client should by default end up using AES-256-GCM, regardless of what the
--cipher
option is set to. - A 2.4 client using
--ncp-disable
should end up with BF-CBC (with 128 bit key size) - Any 2.3 client or older should end up with BF-CBC (with 128 bit key size)
- Any 2.3 client or older (or v2.4 with
--ncp-disable
) using--cipher AES-256-CBC
(or AES-128-CBC or BF-CBC) should be able to connect. - Any 2.3 client or older (or v2.4 with
--ncp-disable
) which is configured to use BF-CBC (either not listing--cipher
at all, or explicitly setting it to BF-CBC) and uses--keysize 256
should be able to connect to the server as long as the server configuration also uses--keysize 256
.
All other scenarios is expected to fail, and those scenarios should fail even without this change. To test other ciphers, look at the output of openvpn --show-ciphers
.
User Experience
End users should not notice any thing, but if they run OpenVPN clients older than v2.4 (also non-Fedora packaged versions) they can independently change --cipher
to AES-256-CBC
or AES-128-CBC
without breaking their tunnel.
Dependencies
There are no changes of dependencies.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), No
- Blocks product? N/A
Documentation
This builds upon the Negotiable Crypto Parameters (NCP) features found in OpenVPN v2.4. For more information, look at the --ncp-ciphers
and --ncp-disable
options in the man page.
Release Notes
OpenVPN configurations utilizing the newer openvpn-server@.service unit file will use a stronger cipher for the VPN tunnel by default. The default is changed from the Blowfish algorithm using 128 bit keys to the newer AES-GCM algorithm with 256 bit keys. To ensure backwards compatibility, this new default also enables clients still using the not recommended Blowfish algorithm to connect by utilizing the --ncp-ciphers
feature being available in OpenVPN v2.4. To facilitate an easy migration path away from Blowfish to clients not supporting AES-GCM, these clients can now add or change the --cipher
option in the client configuration to either AES-256-CBC or AES-128-CBC without needing to do any other server changes.