Can you describe the issue you're seeing? Also, can you include a net-internals log (https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details)? Thanks

Certificate chain looks OK from a cursory look.

I suspect this is a case of ERR_SSL_VERSION_INTERFERENCE.

On Stable Chrome (63.0.3239.84), the site will fail to load depending on the TLS13Variant.

@juleen09: Does this describe your problem? (You can change this at chrome://flags/#tls13-variant).

@davidben/svaldez: NetLog with bytes attached. Fails when run with "Experiment 2". Works when using "Draft 22" on Canary.

Deleted: tls-version-interference.json 194 KB

tls-version-interference.json 194 KB View Download

Removing Needs-Feedback since it sounds like eroman@ got a netlog.  Explicitly ccing the people mentioned in c#2 (who are all OOO at the moment, so not surprising they aren't responding).

The issue seems to be out of TE-scope as it is related to building installer using the url: https://help.globalresultsonline.com/. Hence, adding TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

> @davidben/svaldez: NetLog with bytes attached. Fails when run with "Experiment 2". Works when using "Draft 22" on Canary.

eroman: You sure? I'm not managed to reproduce this. That would also be rather strange since Experiment 2 and Draft 22 are basically the same. (Experiment 2 is what Draft 22 was based around.)

Indeed you are right.
I re-tested and I can reproduce on both Draft 22 and Experiment 2.

I believe the reason I came to that conclusion earlier was a failure to use an incognito window when testing on Canary, and it seems that matters to reproduce.

Here are the exact steps I am using to reproduce on Canary (or Stable).

(1) Launch Chrome with fresh profile:

$ rm -rf ~/tmp/chrome-profile
$ "/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary" --user-data-dir="$HOME/tmp/chrome-profile"

(2) Set "Enabled (Draft 22)" at chrome://flags/#tls13-variant, and click Relaunch Now button.

(3) In the regular Chrome window, load https://help.globalresultsonline.com/. This works fine. I force-reload a couple of times to confirm it isn't flaky, and it loads each time.

(4) Open an incognito window, and load https://help.globalresultsonline.com/. It partially loads this time and is mostly blank.

(5) Force-reload the incognito version. It now fails with ERR_SSL_VERSION_INTERFERENCE.


Interestingly I can only get the failure if I load on both incognito AND non-incognito. Doing all the loads in just one of them prevents repro.

I also confirmed that it reproduces this way on Linux.
Important part is doing loads on both incognito and non-incognito.

svaldez: Could you take a look at diagnosing this? I've backed up with no end of paperwork.

It looks like there's a problem with the TLS stack that ScreenConnect is using that's causing issues, and TLS 1.3 is hitting the codepaths that makes this come up more frequently.

Do you know what library ScreenConnect is configured to use for SSL? From the help forums, it looks like nginx/Mono/etc are possible options?

It looks like the library being used improperly implements session resumption (which is why the initial connection works, and followup connections fail/have errors).

If you have a support contract with ScreenConnect, opening a bug with them, and possibly linking them here would be helpful.

It's not quite that they improperly implement session resumption. Even the first connection is wrong. We just don't notice it until the second connection. (We should fix that so this failure is deterministic.)

Specifically, it appears that Mono's legacy TLS-1.0-only library, back when they only supported TLS 1.0, have a bug in there where they echo back session IDs they've never seen before. This is non-compliant behavior. I believe newer versions of Mono include support for TLS 1.2 and with a new backend that does not have this bug. Please ask ScreenConnect to switch their bundled Mono implementation to that. TLS 1.0 also has known weaknesses, so they should fix this anyway.

TLS 1.3 will likely be reenabled again sometime in March, so they'll need to fix things by then.

If the Screen Connect folks have any questions, please ask their engineers to contact us. Thanks!

The following revision refers to this bug:
  https://boringssl.googlesource.com/boringssl/+/0ab3f0ca2575284525acb77672139058a6eb8e97

commit 0ab3f0ca2575284525acb77672139058a6eb8e97
Author: David Benjamin <davidben@google.com>
Date: Fri Jan 26 21:53:27 2018

Notice earlier if a server echoes the TLS 1.3 compatibility session ID.

Mono's legacy TLS 1.0 stack, as a server, does not implement any form of
resumption, but blindly echos the ClientHello session ID in the
ServerHello for no particularly good reason.

This is invalid, but due to quirks of how our client checked session ID
equality, we only noticed on the second connection, rather than the
first. Flaky failures do no one any good, so break deterministically on
the first connection, when we realize something strange is going on.

Bug: chromium:796910
Change-Id: I1f255e915fcdffeafb80be481f6c0acb3c628846
Reviewed-on: https://boringssl-review.googlesource.com/25424
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>

[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/ssl/handshake_client.cc
[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/crypto/err/ssl.errordata
[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/ssl/test/runner/runner.go
[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/include/openssl/ssl.h
[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/ssl/test/runner/common.go
[modify] https://crrev.com/0ab3f0ca2575284525acb77672139058a6eb8e97/ssl/test/runner/handshake_server.go