New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 619273 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

L2TP VPN: Use stronger Phase 1 ciphersuites

Project Member Reported by cernekee@chromium.org, Jun 11 2016

Issue description

Currently our L2TP client only proposes 3des-sha1-modp1024 and aes128-md5-modp2048 for IKE.  We should prefer the stronger aes128-sha1-modp2048 and 3des-sha1-modp1536 ciphersuites (while retaining support for the first two).

Note that we are still running strongSwan 5.0.2 (2013).  On 5.4.0+ the default is aes128-sha256-modp3072, which doesn't seem to work correctly on 5.0.2.  Long-term we should try to enable the sha256 ciphersuites.  This will require porting a number of local patches to 5.4.0.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Jun 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/30e70e3b5d5c51a5512721f6ceffdaa94db766aa

commit 30e70e3b5d5c51a5512721f6ceffdaa94db766aa
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed Jun 08 20:56:12 2016

vpn: Enable stronger Phase 1 ciphersuites

Prefer aes128-sha1-modp2048 and 3des-sha1-modp1536 to 3des-sha1-modp1024.
This allows both Phase 1 and Phase 2 to negotiate aes128 + sha1, the bare
minimum allowed under the UK CESG security guidelines.  Without this
patch, our client only proposes 3des-sha1-modp1024 and
aes128-md5-modp2048 for Phase 1.

Note that we are still running strongSwan 5.0.2 (2013).  On 5.4.0+
the default is aes128-sha256-modp3072, which doesn't seem to work
correctly on 5.0.2.  Long-term we should try to enable the sha256
ciphersuites.

BUG= chromium:619273 
TEST=manually connect to test VPN
TEST=`FEATURES=test emerge-link vpn-manager`
TEST=test_that IP network_VPNConnect.l2tpipsec_{psk,cert}

Change-Id: Iec02a85b0ad2ae3cf1842b1df1fff484f8273f08
Reviewed-on: https://chromium-review.googlesource.com/350862
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Justin Schuh <jschuh@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@google.com>

[modify] https://crrev.com/30e70e3b5d5c51a5512721f6ceffdaa94db766aa/vpn-manager/l2tpipsec_vpn.cc

Cc: mnissler@chromium.org
Checking each local patch that we apply to our current strongSwan 5.0.2 package against upstream, I see that nearly all of them have landed in strongSwan releases <= 5.5.0:

strongswan-4.4.0-5.3.3_eap_mschapv2_state.patch - 5.3.4
strongswan-5.0.0-5.0.2_enforce_remote_auth.patch - 5.3.2
strongswan-5.0.2-asn1_unwrap.patch - 5.1.2
strongswan-5.0.2-Check-return-value-of-ECDSA_Verify.patch - 5.0.4
strongswan-5.0.2-compare_dn.patch - 5.1.1
strongswan-5.0.2-handle_fragment.patch - 5.1.1
strongswan-5.0.2-ignore-spurious-quick-mode.patch - 5.0.3
strongswan-5.0.2-initgroups.patch - NOT UPSTREAM
strongswan-5.0.2-is_asn1.patch - 5.1.0
strongswan-5.0.2-lenient-encryption.patch - 5.2.0
strongswan-5.0.2-modp_custom.patch - 5.2.2
strongswan-5.0.2-quick-mode-select-proposal-subset.patch - 5.0.3
strongswan-5.0.2-reject-create-child-sa-exchange.patch - 5.1.3
strongswan-clang-fortify-fix.patch - not needed per http://crosreview.com/408719

The context around the old initgroups patch has changed a little bit, possibly indicating that improvements were made in this area.  Without any patch applied I see this in net.log:

2016-11-09T15:35:28.225465-08:00 INFO charon[10633]: 00[LIB] dropped capabilities, running as uid 212, gid 212

According to /proc/pid/status:

Name:	charon
State:	S (sleeping)
Tgid:	10633
Pid:	10633
PPid:	10622
TracerPid:	0
Uid:	212	212	212	212
Gid:	212	212	212	212
FDSize:	64
Groups:	208 212 1001 

The supplementary groups are: pkcs11, ipsec, chronos-access

So I'll drop the initgroups patch unless there are objections.

Project Member

Comment 3 by bugdroid1@chromium.org, Nov 10 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/080886e5ad737a76111898d719d765066ea9f4d9

commit 080886e5ad737a76111898d719d765066ea9f4d9
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Wed Nov 09 23:21:51 2016

vpn: Simplify the updown script and avoid relying on $PATH

Recent versions of strongSwan scrub the environment so the only defined
variables are the PLUTO_* vars, which broke `touch /var/run/ipsec/up`.
Simplify the script by using the >> redirection operator, and change
/var/run to /run.

BUG= chromium:619273 
TEST=manually run with strongSwan 5.5.0 and verify that L2TP/PSK can
     connect to a test VPN

Change-Id: I9a97bb0330806d7d0c5cfe91afdd9fc56107e1be
Reviewed-on: https://chromium-review.googlesource.com/409614
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/080886e5ad737a76111898d719d765066ea9f4d9/vpn-manager/bin/pluto_updown

Project Member

Comment 4 by bugdroid1@chromium.org, Nov 19 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/a730961efad58bb9b2dfad8525e99925d5196f7b

commit a730961efad58bb9b2dfad8525e99925d5196f7b
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Thu Nov 10 00:56:56 2016

net-misc/strongswan: Update to 5.5.0 from portage

Drop all local patches per the reasons in  crbug.com/619273 .  Retain
local ebuild modification for installing /etc symlinks.

BUG= chromium:619273 
TEST=manually connect to L2TP PSK test VPN and verify ping
TEST=run autotests: network_VPNConnect.l2tpipsec_{psk,cert,xauth}
CQ-DEPEND=CL:412008

Change-Id: I73feacc2fffd83acc99e8c9a5df3f1ce08e241be
Reviewed-on: https://chromium-review.googlesource.com/409711
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>

[modify] https://crrev.com/a730961efad58bb9b2dfad8525e99925d5196f7b/net-misc/strongswan/Manifest
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-Check-return-value-of-ECDSA_Verify.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-is_asn1.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-compare_dn.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-reject-create-child-sa-exchange.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-ignore-spurious-quick-mode.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-4.4.0-5.3.3_eap_mschapv2_state.patch
[modify] https://crrev.com/a730961efad58bb9b2dfad8525e99925d5196f7b/net-misc/strongswan/files/ipsec
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-asn1_unwrap.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.0-5.0.2_enforce_remote_auth.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-lenient-encryption.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-handle_fragment.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/strongswan-5.0.2-r20.ebuild
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-quick-mode-select-proposal-subset.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-modp_custom.patch
[delete] https://crrev.com/323da7d122448814fe3eb865e13f7969d20681bc/net-misc/strongswan/files/strongswan-5.0.2-initgroups.patch
[rename] https://crrev.com/a730961efad58bb9b2dfad8525e99925d5196f7b/net-misc/strongswan/strongswan-5.5.0.ebuild
[modify] https://crrev.com/a730961efad58bb9b2dfad8525e99925d5196f7b/net-misc/strongswan/metadata.xml

Project Member

Comment 5 by bugdroid1@chromium.org, Nov 19 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/e0d4dc62a3e5119ec0902076150dc45ab9eb7376

commit e0d4dc62a3e5119ec0902076150dc45ab9eb7376
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Thu Nov 17 03:00:17 2016

network_VPNConnect: Explicitly specify ike, esp, transport mode params

These defaults changed from strongSwan 5.0.2->5.5.0.  The client side
explicitly specifies the options but the server (autotest) side does not.
So post-upgrade, they get out of sync and the tests fail.  Fix this by
specifying appropriate settings on the server side.

BUG= chromium:619273 
TEST=run autotests: network_VPNConnect.l2tpipsec_{psk,cert,xauth} against
     a system running strongSwan 5.0.2 and a system running 5.5.0

Change-Id: I4aaae581fa2fb43933bb5847ef7c34b454024d5f
Reviewed-on: https://chromium-review.googlesource.com/412008
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>

[modify] https://crrev.com/e0d4dc62a3e5119ec0902076150dc45ab9eb7376/client/cros/vpn_server.py

Project Member

Comment 6 by bugdroid1@chromium.org, Nov 28 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/08f05d30ec7e09a4baf76c5b610ac74a19f27120

commit 08f05d30ec7e09a4baf76c5b610ac74a19f27120
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Fri Nov 25 22:55:26 2016

vpn: Enable sha256 and aes-gcm ciphers for IPsec

Allow Phase 1 + Phase 2 to use sha256 instead of the compromised sha1
algorithm.

BUG= chromium:619273 
TEST=rerun network_VPNConnect.l2tpipsec_{psk,cert,xauth} autotests
TEST=connect to test VPN using each new algorithm
TEST=connect to existing IPsec setup in lab

Change-Id: Ic5702b139437ed6275ca464892de58efa2bc6d69
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414924
Reviewed-by: Mattias Nissler <mnissler@chromium.org>

[modify] https://crrev.com/08f05d30ec7e09a4baf76c5b610ac74a19f27120/vpn-manager/l2tpipsec_vpn.cc

Project Member

Comment 7 by bugdroid1@chromium.org, Nov 30 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/e247a6915546710f2792c38c397637abbb942846

commit e247a6915546710f2792c38c397637abbb942846
Author: Kevin Cernekee <cernekee@chromium.org>
Date: Fri Nov 25 23:17:28 2016

vpn: Extend l2tp/ppp timeout from 10s to 60s

The existing logic assumes that l2tp+ppp will finish connecting within
10 seconds of the ESP SA being established.  This is fairly aggressive,
and it does not cope well with slow links / packet loss / buggy gateways.

Enable redial in xl2tpd so that it can retry a couple of times if the
initial attempt fails, and extend the default ppp_setup_timeout to 60s
(as shill does not override this parameter).

BUG= chromium:619273 
TEST=connect to a "slow" server

Change-Id: I2a14766e349e6a99763760bce47207120fd11d30
Reviewed-on: https://chromium-review.googlesource.com/414925
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>

[modify] https://crrev.com/e247a6915546710f2792c38c397637abbb942846/vpn-manager/l2tp_manager.cc
[modify] https://crrev.com/e247a6915546710f2792c38c397637abbb942846/vpn-manager/l2tpipsec_vpn.cc
[modify] https://crrev.com/e247a6915546710f2792c38c397637abbb942846/vpn-manager/l2tp_manager_test.cc

Status: Fixed (was: Started)

Comment 9 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58

Comment 10 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59

Comment 11 by dchan@google.com, May 30 2017

Labels: VerifyIn-60
Labels: VerifyIn-61

Comment 13 by dchan@chromium.org, Oct 14 2017

Status: Archived (was: Fixed)

Sign in to add a comment