Assigning the issue to svaldez@ owner from similar bugs  819598 ,  823165  and   820297 .

svaldez@: Requesting to please have a look into the issue and help further.

Thanks...!!

Do you know if you have any other antivirus/proxy on path? Does the problem go away if you bypass the proxySG and SSLv devices? There were previously issues with Bluecoat, though they should have been resolved with the SGOS version you are using.

It would be helpful to get a net-internals log when you reproduce the issue, see details here:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Note that all flags to disable TLS 1.3 are temporary. TLS 1.3 is a big performance and security improvement for the Internet as a whole. While Chrome is an early adopter, you can expect it to be deployed in major browsers and servers very rapidly over the coming years.

Unfortunately, its deployment the past year was hampered by a number of non-compliant middleware products, including Blue Coat devices, which did not implement TLS 1.2 correctly, an 8 year old specification. While we have managed to work around the majority of the many bugs in these devices, it is ultimately on the vendors to implement protocols correctly and keep up with developments in the protocols they implement.

It seems you may have come across a new failure mode in ProxySG or SSLV that we were unaware of. This is disappointing. Blue Coat have been aware of TLS 1.3 and potential issues with some of their products since as early as 2016 when we informed them of the upcoming standard.

If newer versions of SGOS do not resolve the issue for them, please contact Blue Coat support and emphasize to them the importance of deploying a proper fix for this problem.

So question 1: The full path is as follows:

Client -> SSLv -> FireEye -> SSLv -> ProxySG -> SSLv -> Internet

So yes there is another device, but since we are not decrypting SSL traffic purely looking at the headers, the FireEye will do nothing with it.

I have another similar setup, which doens't yet have the FireEye involved, and has an even later revision of SGOS, 6.7.3.6, which I will try today to see if this happens with this too.

If I use no proxy, it works fine.

Please find attached the net-export-log file.

I'll add a new comment later today.

Deleted: chrome-net-export-log.json 1.0 MB

chrome-net-export-log.json 1.0 MB View Download

Devices that look at TLS traffic without terminating and decrypting it can also cause problems if their TLS processing logic is non-compliant. Actually most of the problems we've seen have been in that kind of device. (Or in devices which decrypt the traffic, but do so in a complicated way that makes them effectively hybrids.)

I'll add more next week, but a short update.

Using the other proxy I mentioned, which is setup the same as the one I originally tested, I've reproduced the same error.

This time though, I'm not even inspecting the headers. The proxy is configured to just pass the traffic to the SSLv. On the SSLv I have 1 rule, to only decrypt ssllabs.com (same as the other system). 

On installation of these, there is a default rule, which cuts through all traffic to start with. I then disabled the rule for ssllabs, re-enabled the pass through rule, and tested again. This time it works fine to google mail.

So I'd say this is not the proxy, but the SSLv that is causing the issue. I'm away for a few days, will investigate more Tuesday next week and provide another trace.

Cheers,

Richard

To verify, are all the SSLv devices running at 4.0 or better?

It looks like Symantec had some bugs on older SSLv devices (https://support.symantec.com/en_US/article.ALERT2338.html) that might have caused issues. Its possible one of your devices isn't updated, or else they may have a regression in a newer version of their SSLv.

Reporter: Ping. Can you address comment #9?

ricwhelan@gmail.com: another ping, could you reply to comment #9?

Hi guys, sorry for the delay. Yes they were running a 4.x version. However, not the latest 4.x 

I've since updated to version 4.2.5.1, which has the following in the details:

SSL Visibility v4.2.5.1

This maintenance release adds support for TLS 1.3 drafts 25 through 28, and also includes important defect fixes.

...

I can now get to the same sites, but with TLS1.3 enabled. So it seems they are still fixing all their issues. :)

Cheers,

Richard

That's good. I'll mark this closed then.

Unfortunately, if they had to add support for each draft individually, that may suggest they're not handling unknown versions right, and may continue to break in the future. They need to follow all the requirements of the TLS specification, including these here:

https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.3