Algo: Figure out how to load certificates onto ChromeOS

[dguido]

It looks like Google Chromebooks only support L2TP, oddly:
https://support.google.com/chromebook/answer/1282338?hl=en

However, the Cisco AnyConnect client is available for Chromebooks and it supports IKEv2. It says that it can only be used with Cisco ASA devices but somehow I doubt that is an enforced technical control.
https://chrome.google.com/webstore/detail/cisco-anyconnect/jacdijibdjifphcecdielmekkmfdpgee?hl=en-US

Does anyone have a Chromebook that they can test on?

[computerality]

L2TP with a PSK or a cert seem supported in the GUI.

On my older chromebook, I can import both certs but get the following error:
User certificate must be hardware-backed.

When choosing "Import and Bind to Device" the user cert doesn't process and it returns Unknown error.

[andy11]

I get the same error as @computerality -- I'm on the beta channel (not sure if that's relevant)

[dguido]

Did you try the Cisco app? I didn't think ChromeOS by itself would work.

Using hardware backed storage for certificates actually sounds great. I just wonder how you load the certs on the device in the first place... It would suck if they have to be generated on device.

[computerality]

The Cisco AnyConnect app (after taking a very, very long time to initialize) requires the certificates be imported into the ChromeOS in order to use them. So it has the same problem.

There is some extension API that might be useful but it would be kid of awkward to have to make an extension to install a cert. https://support.google.com/chrome/a/answer/6080885 / https://developer.chrome.com/extensions/enterprise_platformKeys#method-importCertificate

[dguido]

ChromeOS might support IKEv2 if configured via an ONC file. It's uncertain, but we think their IPSEC support actually comes from StrongSwan.

The file format spec is here and IKEv2 is explicitly mentioned.
https://www.chromium.org/chromium-os/chromiumos-design-docs/open-network-configuration

[dguido]

ONC files will almost definitely work but I don't have a Chromebook to test with.

Here's a short walkthrough for creating an ONC file for OpenVPN:
https://docs.google.com/document/d/18TU22gueH5OKYHZVJ5nXuqHnk2GN6nDvfu2Hbrb4YLE/pub

The ChromeOS source has a bunch of test cases for various ONC configurations, though none for IKEv2. Here's one for L2TP:
https://cs.chromium.org/chromium/src/chromeos/test/data/network/valid_l2tpipsec.onc?sq=package:chromium&type=cs

[dguido]

Here's my totally blind reading of the spec so far:

{ "GUID": "{someguid-asdf-asdf-asdf}",
  "Type": "VPN",
  "Name": "Algo IKEv2 VPN",
  "VPN": {
    "Type": "IPsec",
    "Host": "{{ ip_address }}",
    "IPsec": {
      "AuthenticationType": "Cert",
      "ClientCertType": "Ref",
      "ClientCertRef": "GUID for client cert below"
      "ServerCARef": "GUID for server cert below",
      "IKEVersion": 2,
    },
  },
  "Certificate": {
    "GUID": "{some-guid1}",
    "PKCS12": "base64 of client.p12 (with no passphrase)",
    "Type": "Client",
  },
  "Certificate": {
    "GUID": "{some-guid2}",
    "X509": "ca.crt in PEM format",
    "Type": "Server? Or maybe Authority?",
    "TrustBits": [ "something? Maybe not be necessary? Need to look in ChromeOS src" ],
  }
}

This is one half of the puzzle. After we figure out the right format, we need to figure out how to encrypt the ONC file with a passphrase. This is done with AES256-CBC with a static passphrase (processed by salted PBKDF2 with at least 20,000 iterations) and a SHA-1 HMAC appended to it. The end result looks something like this:

{
"Cipher": "AES256",
"Ciphertext": "eQ9/r6v29/83M745aa0JllEj4lklt3Nfy4kPPvXgjBt1eTByxXB+FnsdvL6Uca5JBU5aROxfiol2+ZZOkxPmUNNIFZj70pkdqOGVe09ncf0aVBDsAa27veGIG8r "HMAC": "3ylRy5InlhVzFGakJ/9lvGSyVH0=",
"HMACMethod": "SHA1",
"Iterations": 20000,
"IV": "hcm6OENfqG6C/TVO6p5a8g==",
"Salt": "/3O73QadCzA=",
"Stretch": "PBKDF2",
"Type": "EncryptedConfiguration"
}

But we can figure out the encrypted part later...

[dguido]

We put a $500 bounty on this issue. Configure an IKEv2 VPN on ChromeOS with an ONC file to claim it! Partial solutions will be considered too.

[jackivanov]

This one works well, but I have no way to test on real Chromebook. (I tested on CloudReady only, but it does not support TPM backend)

{
         "Type":"UnencryptedConfiguration",
              "Certificates": [ {
              "GUID": "{3b1b2fb1-a83b-c0d8-9da1-35e191ca06b7}",
              "Type": "Authority",
              "X509": "bla-bla"
           },
            {
              "GUID": "{d26332d8-b967-43f6-91e9-cd16ee8a3f42}",
              "Type": "Client",
              "PKCS12": "bla-bla"
           }
            ],
            "NetworkConfigurations": [ {
              "GUID": "{024ed7e9-0c87-8ed2-a6c6-a1c10a516386}",
              "Name": "algoovpn",
              "Type": "VPN",
              "VPN": {
                "Type": "IPsec",
                "Host": "{{ IP_subject }}",
                "IPsec": {
                  "AuthenticationType": "Cert",
                  "ClientCertType": "Ref",
                  "ClientCertRef": "{d26332d8-b967-43f6-91e9-cd16ee8a3f42}",
                  "ServerCARef": "{3b1b2fb1-a83b-c0d8-9da1-35e191ca06b7}",
                  "IKEVersion": 2
                }
              }
                                       } ]
}

[cernekee]

When choosing "Import and Bind to Device" the user cert doesn't process and it returns Unknown error.

AIUI most existing Chromebook TPM hardware does not support ECC certs so you would want to use "Import" for ECC.

Here are the use cases that I tested:

• Generate RSA PKCS#12 cert off-device, use Import+Bind under chrome://settings/certificates to install, then use the "rsaSign" parameter from chrome.platformKeys to allow a VPN app to utilize the private key in TLS client auth.
• Generate ECC PKCS#12 cert using the algo script, use Import to install onto a Chromebook, then use the "ecdsaSign" parameter from the VPN app to get a handle for the key. Did not test signing.
• Generate RSA private key locally using <keygen> (which, sadly, is deprecated), import the signed cert through the UI, and then use "rsaSign" from the VPN app to utilize the private key in TLS client auth.

I suspect that what's missing here is support for ECC in AnyConnect, as the latest version of the app only passed "rsaSign" to chrome.platformKeys. Therefore your algo-generated ECC certs will not even show up in the list.

It looks like Google Chromebooks only support L2TP

I have not tested "straight" IPsec but this is probably true. A lot of corporate networks seem to be set up to negotiate IPsec/ESP/PSK for privacy, then perform user login over L2TP/PPP/CHAP (often using an OTP).

So maybe a solution looks something like:

1. Allow non-HW-backed ECC certs to be used with strongSwan (don't know if this means reworking the code to bypass chapsd entirely, or if it is just a matter of deleting a check)
2. If the L2TP username is blank, assume no L2TP/PPP/PAP because the server is using straight certificate (or PSK :frowning:) auth to control access. Currently the UI won't let you specify an empty username.

[augs]

You can also use the verified access API to generate key material in the TPM and then validate that it is hardware backed: https://docs.google.com/document/d/1j6QoOwMja77Of151tF8vyN55dFhhKLp_xnRhYHr4glA/edit

You could just hand off the pubkey and then synthesize a cert and ONC config to hand back to the CrOS device.

Confirming my statement in that other bug, the TPMv1.2 standard and hardware don't support ECC and I do not believe there are any current CrOS models sporting TPMv2.0.

Is ECC a hard requirement for Algo, or is it just convenient to not support 2 cipher types for client identity?

[cernekee]

You can also use the verified access API to generate key material in the TPM

Hmm, not sure if there is a way to enable chrome.enterprise.platformKeys for unmanaged devices?

Is ECC a hard requirement for Algo

The README says: "Does not support legacy cipher suites or protocols like L2TP, IKEv1, or RSA" :frowning_face:

Regarding the possible use of the Chrome OS builtin IPsec client:

I have a change out for review which enables more secure ciphersuites. (Not the exact ones used in this project, though.)

IKEv2 is supported by the version of strongSwan in Chrome OS, but it will require some additional plumbing in chrome, vpn-manager, and maybe shill.

Allow non-HW-backed ECC certs to be used with strongSwan (don't know if this means reworking the code to bypass chapsd entirely, or if it is just a matter of deleting a check)

FWIW, I tried deleting the check but this was insufficient. Chrome passed a UserNSSDB handle to shill->vpn-manager->strongSwan, but the libchaps PKCS#11 library only knows how to look up "User TPM token" keys. I'm asking around to see if there is an easy solution.

(The lack of ECDSA support bugs me, but according to usage stats, >95% of IPsec users on Chrome OS are using PSK rather than certs anyway.)

If the L2TP username is blank, assume no L2TP

This would require reworking some of the shill VPN code so that it doesn't expect to have a ppp0 interface (with its own routes, DNS servers, etc.) associated with the VPN service.

One other nice thing about L2TP/PPP is that it lets the gateway push down a list of (presumably enterprise) DNS servers that know how to look up internal hostnames, and an internal IP address. For a personal VPN that is only used to access sites on the public internet, that is less important.

If you wanted to write a third party VPN client instead, nacl_sdk + webports + charon + openconnect's userland ESP code might be a starting point.

[dguido]

If the user selects it, I'll allow Algo to generate RSA certs. We will have to do the same for Windows too anyway. Only macOS/iOS and Linux support ECC certificates.

[ghost]

I've been trying this on a Chromebook Pixel and when I import the ONC it appears to crash a ChromeOS component. Upon examining the debug logs, I see:

ERR shill[325]: [ERROR:error.cc(146)] [vpn_provider.cc(76)]: Missing VPN type property

After looking over my config block several times I am almost certain it is correct. I based it off the config provided by @gunph1ld.

I've rummaged around the ChromeOS source and at a glance it appears as though the "IPsec" VPN type isn't fully implemented. I can only see unit tests for OpenVPN and L2TP/IPsec. I may be mistaken about this, though.

Here's what I've got in my ONC:

    {
         "Type":"UnencryptedConfiguration",
            "NetworkConfigurations": [ {
              "GUID": "{776f04b2-40bc-4d05-96dc-144a08f860ee}",
              "Name": "friendlyname",
              "Type": "VPN",
              "VPN": {
                "Type": "IPsec",
                "Host": "myhostname",
                "IPsec": {
                  "AuthenticationType": "Cert",
                  "ClientCertType": "Ref",
                  "ClientCertRef": "{7ac8af9e-321c-4a0d-9449-0be6e0285946}",
                  "ServerCARef": "{c7d834b4-891f-4bc5-966e-d39868f767f1}",
                  "IKEVersion": 2
                }
              }
           } ]
              "Certificates": [ {
              "GUID": "{c7d834b4-891f-4bc5-966e-d39868f767f1}",
              "Type": "Authority",
              "X509": "-----BEGIN CERTIFICATE-----servercert-----END CERTIFICATE-----"
           },
            {
              "GUID": "{7ac8af9e-321c-4a0d-9449-0be6e0285946}",
              "Type": "Client",
              "PKCS12": "base64_of_client_cert"
           }
            ]
}

Happy to do further testing.

[ghost]

Also I can confirm the Cisco Anyconnect client is not compatible. The strongSwan server reports unknown messages on connection attempts from it.

[jabyrd3]

Any progress on this? I'm interested in using algo dnsmasq for a remote dev environment accessed via chromebook.

[jabyrd3]

Update: i was able to import CA cert and user cert and at least begin initiating a connection.

there are four fields in the GUI i'm not sure about: username, password, OTP and Group Name.

Of those 4 only Username and Password are required. I've tried supplying the only PW value I've seen in the config files, that failed out with 'Internal Error'.

More notes: I'm on beta channel. The VPN setup GUI field for provider type is 'L2TP/IPsec + user certificate'. I bound the user cert to the hardware.

[ghost]

This is using IKEV2/IPsec, not L2TP, which will be why your connection is failing.

[git-sgmoore]

My solution: After using algo to setup a new server, I logged into that new server and ran the script from the following Github repo "https://github.com/hwdsl2/setup-ipsec-vpn". This gave me the information to use L2TP with my chromebook. I chose this option because of Algo's additonal OS hardening and etc.. However, I am unsure of any vulnerabilities I have created, besides using L2TP in general, by doing this.

Could anyone let me know running this script on top of algo is a bad idea?

[andy11]

My Samsung Chromebook 3 is listed here and here as one of the Chromebooks that support Android App installation through the Play Store. I tried installing the StrongSwan Android App from the Play Store in the hopes a connection there would affect ChromeOS as a whole.

I'm able to connect to my Algo server without any issues, but the VPN connection is only used in other Android apps installed from the Play Store. It does not seem to affect the "native" ChromeOS Chrome browser. This is true even if you scroll down into the advanced "Split Tunneling" features of the StrongSwan Android App and check the "Block IPv4/6 traffic not destined for the VPN" boxes.

I'm not familiar with ChromeOS's internals, so if anyone has any ideas for ways to re-route things outside of the Android apps, I'm happy to try them out. Please let me know!

[cernekee]

It does not seem to affect the "native" ChromeOS Chrome browser.

This part is still under development. It requires hooking up the datapath, UI, etc. between both OSes. See here.

I tried installing the StrongSwan Android App from the Play Store

Interesting. I assume this only implements UDP encapsulated ESP, because straight ESP (IP protocol 50) is likely to run into several roadblocks in this configuration.

[dguido]

We should file a bug for this on ChromeOS's bug tracker. It has been way too difficult to get to this point and it shouldn't have been: https://bugs.chromium.org/p/chromium/issues/list

[cernekee]

The bug for Android support is bug 696865.

The other three items concerning the builtin Chrome OS client are:

• IKEv2 support. This has been discussed internally and is generally considered a good idea; but so far algo is the only "customer" for it. I filed bug 715622.
• ECDSA certs. I think there is some ongoing work on chapsd that will make this possible. See bug 583784.
• IPsec without L2TP. Not currently planned.

[tamsky]

@andy11

I'm able to connect to my Algo server without any issues, but the VPN connection is only used in other Android apps installed from the Play Store. It does not seem to affect the "native" ChromeOS Chrome browser.

Commits to make this work are flying at:

Tunnel Chrome traffic through Android VPNs:
https://bugs.chromium.org/p/chromium/issues/detail?id=696865

[cernekee]

Tunnel Chrome traffic through Android VPNs:
https://bugs.chromium.org/p/chromium/issues/detail?id=696865

This feature is now live in canary channel. Anyone want to try the strongSwan app and report back?

[qirtaiba]

I upgraded to Canary channel on my Chromebook and it didn't work for me, but maybe I was doing something wrong. Is anything else required besides running the Android app and restarting Chrome?

[qirtaiba]

Duh I'm sorry, turns out it hadn't fully updated before. I had to do one more restart before it was running the latest Canary. After doing that, it works fine! I can access the Internet through the VPN while running the native Chrome browser but the Android VPN app. Yay!

[Xyc0]

@qirtaiba did you happen to grab the canary version this was introduced?

[qirtaiba]

9964.0.0 / 63.0.3222.0

[axiomdata]

Fyi the wireguard Android app happens to work very well on ChromeOs. Maybe certs are no longer necessary? Just use wireguard?

[zx2c4]

Indeed ChromeOS's Android layer has excellent support for the VPN APIs, so the WireGuard app "just works". Hopefully we'll have a Web Assembly ChromeOS client at some point too.