I also have this is issue with v58 of chrome. v57 seemed to work fine. I have attached 2 logs one to http://github.com and the other to https://feedly.com (to ensure no issues with cdn etc.) Both experience several SOCKET_POOL_CONNECT timeouts. Resulting in the webpage not loading at all in both cases. 

Note: I am behind a corporate proxy, but I.E, Firefox and Safari all work fine. 

 

Deleted: chrome-net-export-log.json 370 KB

chrome-net-export-log.json 370 KB View Download

Deleted: chrome-net-export-log_feedly.json 516 KB

chrome-net-export-log_feedly.json 516 KB View Download

colinbul and twoshorts67:  You're both in the UK with proxies with the same IP (So you're presumably using the same ISP / corp network), and your logs do look fairly similar.  We see:

t=28569 [st=    0] +SOCKET_ALIVE  [dt=30171]
                    --> source_dependency = 1396 (HTTP_PROXY_CONNECT_JOB)
t=28569 [st=    0]    TCP_CLIENT_SOCKET_POOL_REQUESTED_SOCKET
                      --> host_and_port = "10.64.3.193:8080"
t=28569 [st=    0]   +SOCKET_POOL  [dt=83]
t=28652 [st=   83]      SOCKET_POOL_BOUND_TO_CONNECT_JOB
                        --> source_dependency = 1398 (TRANSPORT_CONNECT_JOB)
t=28652 [st=   83]      SOCKET_POOL_BOUND_TO_SOCKET
                        --> source_dependency = 1399 (SOCKET)
t=28652 [st=   83]   -SOCKET_POOL
t=28737 [st=  168]   +SOCKET_IN_USE  [dt=30002]
                      --> source_dependency = 1395 (SSL_CONNECT_JOB)
t=28738 [st=  169]      SSL_CONNECT  [dt=30001]
t=58739 [st=30170]   -SOCKET_IN_USE
t=58740 [st=30171] -SOCKET_ALIVE

Digging from the proxy socket layer to the socket layer, we have:

t=37516 [st=    0] +SOCKET_ALIVE  [dt=30079]
                    --> source_dependency = 732 (TRANSPORT_CONNECT_JOB)
t=37516 [st=    0]   +TCP_CONNECT  [dt=31]
                      --> address_list = ["10.64.3.193:8080"]
t=37516 [st=    0]      TCP_CONNECT_ATTEMPT  [dt=31]
                        --> address = "10.64.3.193:8080"
t=37547 [st=   31]   -TCP_CONNECT
                      --> source_address = "10.80.119.12:65137"
t=37548 [st=   32]   +SOCKET_IN_USE  [dt=30047]
                      --> source_dependency = 731 (PROXY_CLIENT_SOCKET_WRAPPER)
t=37548 [st=   32]     +HTTP_TRANSACTION_TUNNEL_SEND_REQUEST  [dt=0]
t=37548 [st=   32]        HTTP_TRANSACTION_SEND_TUNNEL_HEADERS
                          --> CONNECT github.com:443 HTTP/1.1
                              Host: github.com:443
                              Proxy-Connection: keep-alive
                              User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
t=37548 [st=   32]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> CONNECT github.com:443 HTTP/1.1
                              Host: github.com:443
                              Proxy-Connection: keep-alive
                              User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
t=37548 [st=   32]        SOCKET_BYTES_SENT
                          --> byte_count = 215
t=37548 [st=   32]     -HTTP_TRANSACTION_TUNNEL_SEND_REQUEST
t=37548 [st=   32]     +HTTP_TRANSACTION_TUNNEL_READ_HEADERS  [dt=46]
t=37548 [st=   32]       +HTTP_STREAM_PARSER_READ_HEADERS  [dt=46]
t=37594 [st=   78]          SOCKET_BYTES_RECEIVED
                            --> byte_count = 39
t=37594 [st=   78]       -HTTP_STREAM_PARSER_READ_HEADERS
t=37594 [st=   78]        HTTP_TRANSACTION_READ_TUNNEL_RESPONSE_HEADERS
                          --> HTTP/1.1 200 Connection established
t=37594 [st=   78]     -HTTP_TRANSACTION_TUNNEL_READ_HEADERS
t=37595 [st=   79]      SOCKET_BYTES_SENT
                        --> byte_count = 198
t=67595 [st=30079]      SOCKET_CLOSED
t=67595 [st=30079]   -SOCKET_IN_USE
t=67595 [st=30079] -SOCKET_ALIVE

So it looks like we're establishing a tunnel, then send the first part of the SSL handshake, and then never hear back from the server.

I'd tend to blame the proxy you're both behind, though both the logs on posts #1 and #2 contain successful SSL connections being established as well, but I defer to the SSL folks on next steps.

We didn't change anything between 57 and 58 on the SSL corner of the world, apart from removing the prestandard ChaCha20-Poly1305 ciphers. But IE, Firefox, and Safari all don't send those either.

Agreed that this would probably be best debugged at the proxy, since it's the one timing out our requests. It sounds like the original reporter at least is a corporate proxy. Do you have any logs? What proxy are you using?

Also, could you attach a log from Chrome 57 where it's working, so we can maybe compare?

I'll pass this info onto our network guru, and also get some v57 traces.
Cheers.

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here's the V57 trace as suggested

I've tried using a different HTTPS link and carried out the same test using both versions. 
I can't see much difference between the 2(Except the time outs).

Deleted: chrome-net-export-log v57 Siam 01.json 130 KB

chrome-net-export-log v57 Siam 01.json 130 KB View Download

Deleted: chrome-net-export-log v58 Siam 02.json 93.7 KB

chrome-net-export-log v58 Siam 02.json 93.7 KB View Download

HI
So our 3rd party outsoruced HelPful (not) support respond with Chrome is not supported. So I'm having to push to get any traction.
I have however discovered that running the working V57 version with \chrome.exe --cipher-suite-blacklist=0xcc14,0xcc13 causes the same problem. So there is a definite issue somewhere along the line of removing these 2 ciphers. I meant to mention that sometimes it will work on the new version(V58) but very infrequently.
Is there anyway I can run chrome with these 2 ciphers? Have you any suggestions I can try while waiting for the outsource support to look at this.
Cheers in advance guys I'm way out of my depth already lol
 

Oh and we're using a Bluecoat proxy I'm told

There isn't an option to restore the two ciphers in M58 I'm afraid. This is odd though, since other browsers don't advertise those ciphers either. (They were the precursors to RFC 7905.) I've reached out to a contact at Blue Coat to see if they might have thoughts.

Could you find out which Blue Coat product you all are using, and what version of software you have on it? Thanks!

Oh, another question: is this happening for you only on Google servers, or also other ones? Comment #2 reports issues with github.com as well, but I'm not sure if you're seeing the same thing.

I've asked for the Bluecoat info;
It happens on all HTTP sites. I've now some some more checks using fiddler and it seems to be timeouts mostly, with the odd connection actually working (1 in 10) once connected it works like a dream.
Here's a normal-ish test below.



1. Open Chrome and type https url.
2. Trys to create a tunnel which seems to time out after 30 seconds.
	Request
	Request Count:   1
	Bytes Sent:      235		(headers:235; body:0)
	Bytes Received:  112		(headers:112; body:0)
	Tunnel Sent:     208
	Tunnel Received: 0

	ACTUAL PERFORMANCE
	--------------
	ClientConnected:	09:09:41.480
	ClientBeginRequest:	09:09:41.481
	GotRequestHeaders:	09:09:41.481
	ClientDoneRequest:	09:09:41.481
	Determine Gateway:	31ms
	DNS Lookup: 		0ms
	TCP/IP Connect:	20ms
	HTTPS Handshake:	0ms
	ServerConnected:	09:09:41.536
	FiddlerBeginRequest:	09:09:41.536
	ServerGotRequest:	09:09:41.536
	ServerBeginResponse:	09:09:41.557
	GotResponseHeaders:	09:09:41.557
	ServerDoneResponse:	09:10:11.560
	ClientBeginResponse:	09:10:11.560
	ClientDoneResponse:	09:10:11.560

		Overall Elapsed:	0:00:30.079
3. Trys again for a tunnel. Times out again.
	Request Count:   1
	Bytes Sent:      235		(headers:235; body:0)
	Bytes Received:  112		(headers:112; body:0)
	Tunnel Sent:     208
	Tunnel Received: 0

	ACTUAL PERFORMANCE
	--------------
	ClientConnected:	09:10:11.714
	ClientBeginRequest:	09:10:11.715
	GotRequestHeaders:	09:10:11.715
	ClientDoneRequest:	09:10:11.715
	Determine Gateway:	31ms
	DNS Lookup: 		0ms
	TCP/IP Connect:	21ms
	HTTPS Handshake:	0ms
	ServerConnected:	09:10:11.768
	FiddlerBeginRequest:	09:10:11.768
	ServerGotRequest:	09:10:11.768
	ServerBeginResponse:	09:10:11.789
	GotResponseHeaders:	09:10:11.789
	ServerDoneResponse:	09:10:41.791
	ClientBeginResponse:	09:10:41.791
	ClientDoneResponse:	09:10:41.791

		Overall Elapsed:	0:00:30.076
4. Trys 3rd Time for a tunnel. Mostly times out again however sometimes just sometimes it works This one worked.
	Request Count:   1
	Bytes Sent:      235		(headers:235; body:0)
	Bytes Received:  39		(headers:39; body:0)
	Tunnel Sent:     8,338
	Tunnel Received: 52,101

	ACTUAL PERFORMANCE
	--------------
	ClientConnected:	09:10:46.834
	ClientBeginRequest:	09:10:46.834
	GotRequestHeaders:	09:10:46.834
	ClientDoneRequest:	09:10:46.834
	Determine Gateway:	62ms
	DNS Lookup: 		0ms
	TCP/IP Connect:	20ms
	HTTPS Handshake:	0ms
	ServerConnected:	09:10:46.877
	FiddlerBeginRequest:	09:10:46.877
	ServerGotRequest:	09:10:46.877
	ServerBeginResponse:	09:10:46.898
	GotResponseHeaders:	09:10:46.898
	ServerDoneResponse:	09:10:46.898
	ClientBeginResponse:	09:10:46.898
	ClientDoneResponse:	09:10:46.898

		Overall Elapsed:	0:00:00.064

		
	This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
	To view the encrypted sessions inside this tunnel, enable the Tools > Fiddler Options > HTTPS > Decrypt HTTPS traffic option.

	A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.

	Version: 3.3 (TLS/1.2)
	SessionID:	E9 1A 29 7B 33 2B 05 9B 4F 92 12 65 05 F6 5D 05 4D 2A 2D 3A 07 59 6F B6 98 0C B9 67 D9 AE D5 D5
	Random:		24 34 CD 6E DA 31 00 39 2F 82 D5 04 FF 01 0C 7E EC D3 F7 A8 89 24 EA D6 93 9E 13 94 27 DA 1C 56
	Cipher:		TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [0xC02F]
	CompressionSuite:	NO_COMPRESSION [0x00]
	Extensions:
			renegotiation_info	00
			server_name	empty
			elliptic_curves	secp256r1 [0x17]
			ec_point_formats	uncompressed [0x0]

As soon as the tunnel for this site is connected it carries on working for all requests to that HTTPS site even on new tab creation. 

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Are there other firewalls, proxies, etc., on your network? From chatting with Blue Coat folks, it doesn't sound like any of their products would have the behavior you're describing. (Though the particular product and version you have would certainly help narrow the search to confirm.)

Thanks!

HI
We've just had a tech knowledgebase from Bluecoat advising that Chrome new version wasn't using TLS 1.3 by default(due to problems in the field).
So we changed the the setting from default to 1.3 in the TLS version dropdown.
Instructions below.
Browse to "chrome://flags/#ssl-version-max"
Then change the TLS version dropdown from Default to  TLS 1.3. Then restart Chrome.
This has effectively resolved the connection issues.
I would like to thank you guys and gals for assisting me to fix this major headache for our corporation. No thanks to our outsourced IT .
Thank you 
John

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Huh?? Enabling TLS 1.3, a draft unfinished protocol that we can't deploy right now due to buggy middlebox problem, unbreaks your buggy middlebox? Fascinating! That makes no sense. :-)

I had assumed the old ChaCha20 ciphers were because something fingerprinting Chrome, but perhaps this was actually logic sensitive to cipher suites they don't understand? I'll circle back with the Blue Coat folks if that rings more of a bell.

Can you please find out what version of the Blue Coat product you have? Also are there other such products on your network?

Hi, 
we have BlueCoat SG9000-20 running SGOS version 6.5.10.1
In addition we are currently preparing to patch a test proxy to 6.5.10.3 which is the version that should fix the http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878 
 

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Blue Coat folks ask if you have SSL interception enabled, or if you are just trying to tunnel the traffic through the proxy.

Thanks a lot for your patience and help here, by the way. I suppose you now have a fix/workaround, but I'd like to figure out what's actually going on. Things should work fine with TLS 1.3 off too.

They also ask if it'd be possible to get a packet capture showing the problem. Getting it on ProxySG itself (so they can see both the client and server side) would be especially helpful.

From the network boys.
"But we assume not the Blue Coats as root cause as we are having the desired work around since 6 years in place (for other reasons of course). That means, that we are not having “detect protocol” active and are not using the internal SSL proxy. We are simply tunneling SSL requests on layer 4 on the Blue Coats."
I'll ask about a packet capture but obviously have to be careful re security.
I'll help as much as I can guys. I'll see if I can get the network guys on here.

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> I'll ask about a packet capture but obviously have to be careful re security.

If you prefer not to post a packet capture on this (public) bug, feel free to email it to me directly. I can then pass it along to the Blue Coat folks.

[Deleted original "hey, me too!" comment 29 because see below :) ]

Judging from the IP addresses taken from the files provided by twoshort and colin I am one of the "network boys" they referred to.

In our tests we did not have this issue with every HTTPS connection but with a lot of them. Like already mentioned enabling TLS 1.3 helps. Also repeatedly hitting reload will at some point load the site. Setting "detect protocol" to "no" for a specific URL and all protocols on the BC also seems to help.

In the captures we can see that while having "ssl-version-max" at "Default" the BC waits for nearly 30 seconds before initiating the connection to the destination webserver (frame 15 below):

Frame   Time        Source            Destination       Proto    Len    Info
----------------------------------------------------------------------------------------------------------------------------------------------------------
      1 0.000000    192.168.30.103    192.168.79.30     TCP      66     32451 → http-alt(8080) [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
      2 0.000011    192.168.79.30     192.168.30.103    TCP      62     http-alt(8080) → 32451 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1
      5 0.004355    192.168.30.103    192.168.79.30     TCP      60     32451 → http-alt(8080) [ACK] Seq=1 Ack=1 Win=64860 Len=0
      7 0.004415    192.168.30.103    192.168.79.30     HTTP     283    CONNECT enabled.tls13.com:443 HTTP/1.1 
     10 0.042785    192.168.79.30     192.168.30.103    HTTP     93     HTTP/1.1 200 Connection established 
     12 0.047288    192.168.30.103    192.168.79.30     TLSv1.2  259    Client Hello
     14 0.121938    192.168.79.30     192.168.30.103    TCP      54     http-alt(8080) → 32451 [ACK] Seq=40 Ack=435 Win=65535 Len=0
     15 29.013666   10.64.18.42       104.16.125.34     TCP      66     8586 → https(443) [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
     17 29.033529   104.16.125.34     10.64.18.42       TCP      66     https(443) → 8586 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1380 SACK_PERM=1
     18 29.033535   10.64.18.42       104.16.125.34     TCP      58     8586 → https(443) [ACK] Seq=1 Ack=1 Win=65535 Len=0
     23 30.048992   192.168.30.103    192.168.79.30     TCP      60     32451 → http-alt(8080) [FIN, ACK] Seq=435 Ack=40 Win=64821 Len=0
     24 30.048997   192.168.79.30     192.168.30.103    TCP      54     http-alt(8080) → 32451 [ACK] Seq=40 Ack=436 Win=65535 Len=0
     26 30.049065   10.64.18.42       104.16.125.34     TLSv1.2  263    Client Hello
     28 30.049075   10.64.18.42       104.16.125.34     TCP      58     8586 → https(443) [FIN, ACK] Seq=206 Ack=1 Win=65535 Len=0
     29 30.069244   104.16.125.34     10.64.18.42       TCP      64     https(443) → 8586 [ACK] Seq=1 Ack=206 Win=30016 Len=0
     37 30.070862   192.168.79.30     192.168.30.103    TLSv1.2  1414   Server Hello
     38 30.070864   192.168.79.30     192.168.30.103    TCP      74     http-alt(8080) → 32451 [PSH, ACK] Seq=1400 Ack=436 Win=65535 Len=20
     39 30.070875   192.168.79.30     192.168.30.103    TLSv1.2  1414   Certificate, Certificate Status
     40 30.070875   192.168.79.30     192.168.30.103    TLSv1.2  98     Server Key Exchange, Server Hello Done
     41 30.070886   192.168.79.30     192.168.30.103    TCP      54     http-alt(8080) → 32451 [FIN, ACK] Seq=2824 Ack=436 Win=65535 Len=0
     42 30.071156   104.16.125.34     10.64.18.42       TLSv1.2  1438   Server Hello
     43 30.071176   104.16.125.34     10.64.18.42       TLSv1.2  1438   Certificate, Certificate Status
     44 30.071180   10.64.18.42       104.16.125.34     TCP      58     8586 → https(443) [ACK] Seq=207 Ack=2761 Win=65260 Len=0
     45 30.071182   104.16.125.34     10.64.18.42       TLSv1.2  82     Server Key Exchange, Server Hello Done
     46 30.071183   104.16.125.34     10.64.18.42       TCP      64     https(443) → 8586 [FIN, ACK] Seq=2785 Ack=207 Win=30016 Len=0
     47 30.071186   10.64.18.42       104.16.125.34     TCP      58     8586 → https(443) [ACK] Seq=207 Ack=2786 Win=65235 Len=0
     53 30.072668   192.168.30.103    192.168.79.30     TCP      60     32451 → http-alt(8080) [RST, ACK] Seq=436 Ack=1400 Win=0 Len=0

192.168.30.103 -> PC running Chrome
192.168.79.30  -> Blue Coat client side
10.64.18.42    -> Blue Coat internet side
104.16.125.34  -> enabled.tls13.com

After enabling TLS 1.3 support in chrome it works fine. 

With TLS 1.3 support enabled we can see changes in the cipher list in the ClientHello and of course TLS 1.3 specific TLS extensions like "supported_versions":

Cipher Suites "Default" (14 suites)			   Cipher Suites "TLS 1.3" (17 suites)
===================================			   =========================
Reserved (GREASE) (0x9a9a)				   Reserved (GREASE) (0xaaaa)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)     TLS_CHACHA20_POLY1305_SHA256 (0x1303)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)       TLS_AES_128_GCM_SHA256 (0x1301)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)           TLS_AES_256_GCM_SHA384 (0x1302)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)             TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)           TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)             TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)                TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)                TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)                   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)                   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)                	   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)                	   TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)                	   TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
							   TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
							   TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
							   TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)


At first we suspected that BC has some kind of weird problems with cipher 0xcca9 and/or curve X25519 (0x001d) although it only "sees" it in the packet, but we saw successful connections using 0xcca9 with X25519 when "ssl-version-max" was set to "Default".

If you still need a capture file I'll email you the file with the above shown connection.

We have also opened a case with BC.

Regards

I did some testing with Chromium 57.0.2987.0. Apart from the old ciphers 0xcc13 and 0xcc14 (mentioned above) still being advertised, I noticed, that with "ssl-version-max" at "Default" in Chromium 57 TLS 1.3 support was enabled whereas in Chrome 58 and 59 with "Default" TLS 1.2 is the maximum. Could it be that this isn't a new issue but an older one which got masked/autofixed by having TLS 1.3 support in the "Default" setting prior to v58? 

No, TLS 1.3 is gated by an experiment flag and was not on for long for any stable release of Chrome (due to different middlebox bugs!). What you're seeing with an unbranded Chromium build is probably this business:
https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/ECWC57W7E0k/9Kc5UAmyDAAJ

The Blue Coat folks said the full packet trace for that one would indeed be useful. They also aren't able to find your support ticket and want to know the SR (service request) number.

(Feel free to email either of those to me privately to forward to Blue Coat if you prefer not to post it on this public bug.)

(BlueCoat folks have made progress isolating the problem on their end. Marking this ExternalDependency and clearing the Needs-Feedback label so bug triagers don't get confused.)

BlueCoat have an article describing the problem and a workaround. Closing this on our end.
https://support.symantec.com/en_US/article.TECH246796.html

Fantastic news. Thanks  davidben@chromium.org for all the help and assistance and sticking by me on this. really appreciated.