Chrome Version: 49.0.2623.112
Chrome OS Version: 7834.70.0

Please specify Cr-* of the system to which this bug/feature applies (add
the label below).
Cr-OS-Systems-Network

Steps To Reproduce:
(1) Connect to network that does SSL inspection of www.google.com host (many EDU networks do this in order to filter Google Search queries). Network should be doing SSL whitelisting as defined at https://support.google.com/chrome/a/answer/6334001. Note that www.google.com is NOT one of the URLs we require for SSL whitelisting.
(2) CTRL+ALT+T to open crosh shell
(3) run network_diag (no parameters except maybe --proxy http://192.168.1.1:8888)

Expected Result:
Tests should succeed.

Actual Result:
Tests fail because we see customer's private certificate for www.google.com TLS.

What is the impact to the user, and is there a workaround? If so, what is
it?
Confusing to admin. We don't actually require www.google.com to be SSL whitelisted but this test uses it by default.

Please provide any additional information below. Attach a screen shot or
log if possible.
We should switch to using clients3.google.com instead of www.google.com as the default host. clients3.google.com is documented as requring SSL whitelisting at:
https://support.google.com/chrome/a/answer/6334001

Here's the crosh output for network_diag on current beta channel. Note that 192.168.86.31 is a proxy doing SSL inspection on all hosts except those in the whitelist help article above (so it does do SSL inspection for www.google.com but not for clients3.google.com)

Running against www.google.com default:

crosh> network_diag --proxy http://192.168.86.31:8888
Trying to contact https://www.google.com ... (waiting up to 10 seconds)
Trying to contact http://www.google.com ... (waiting up to 10 seconds)
PASS: Loaded www.google.com via HTTP (ignore any tlsdate failure below)
Entering diag_date www.google.com http://192.168.86.31:8888
Local time of day: Thu Apr 21 09:32:38 EDT 2016
FAIL: Unable to get date via tlsdate from www.google.com: V: tlsdate version 0.0.5
V: We were called with the following arguments:
V: validate SSL certificates host = www.google.com:443
V: time is currently 1461245558.850174543
V: time is greater than RECENT_COMPILE_DATE
V: using TLSv1_client_method()
V: opening socket to 192.168.86.31:8888
certification verification error: 20
child process failed in SSL handshake
PASS: Current LinkMonitor latency for /device/wlan0 is 2ms

If we manually run against clients3.google.com instead:

crosh> network_diag --proxy http://192.168.86.31:8888 clients3.google.com
Trying to contact https://clients3.google.com ... (waiting up to 10 seconds)
PASS: Loaded clients3.google.com via HTTPS
Entering diag_date clients3.google.com http://192.168.86.31:8888
Local time of day: Thu Apr 21 09:35:16 EDT 2016
PASS: Time appears to be correct
PASS: Current LinkMonitor latency for /device/wlan0 is 2ms

Already have patch ready, filing bug to justify patch :-)