pzbowen@ Thanks for the issue.

Tried accessing the link https://www.blunkmicro.com/tls.htm, but couldn't access the site and could see the error Site can't be reached.

CC'ing davidben@ from similar issues, as this is related to ERR_SSL_VERSION_INTERFERENCE error and requesting to check and help in further triaging.

Thanks..

[Note for triagers: this is *NOT* related to the rest of the ERR_SSL_VERSION_INTERFERENCE errors that have come up of late.)

Re your list of ciphers, we still support (a-c) for now, though the server seems to have a more modern config now. I also wasn't able to reproduce it. I'm assuming blunkmicro.com has since been updated? Do you have another sample link?

It was never the blunkmicro.com site; it is a piece of hardware running their TargetOS RTOS.

I have access to the device that is broken, but it is on a private network.  I can run tests against it as needed.

Ah, I see. Diagnosing one remotely is tricky since usually it's a bit of a trial-and-error thing to figure out what exactly is upsetting it. (Usually the server just shuts off the connection on us.)

I suppose, to start with, could you gather a NetLog of you talking to the device? If you pass --user-data-dir to Chrome, you can make a separate Chrome instance disconnected from your main one.
https://dev.chromium.org/for-testers/providing-network-details

Thank you for providing more feedback. Adding the requester to the cc list.

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

I see https://www.blunkmicro.com/tls.htm claims the device is "Royalty-free. Includes source code, sample applications, and one year of technical support".

So I guess another option is for you to go spelunking in the source? :-) Since it's a server, it would just be ClientHello intolerance. Some possibilities:

- ClientHello is too big for it
- Inclusion of TLS 1.3 ciphers is somehow upsetting it
- Inclusion of TLS 1.3 extensions is somehow upsetting it
- Inclusion of the fake session ID for middlebox shenanigans is somehow upsetting it

I've also been working on a tool like der-ascii (https://github.com/google/der-ascii), but for TLS. I could privately send you a preview of it. It still needs a *ton* of features, but it should be good enough at this point for you to generate ClientHellos and play with it...

Chrome Canary 71.0.3578.8 (Official Build) canary (64-bit) does not have the same error.  Chrome Beta Version 70.0.3538.54 (Official Build) beta (64-bit) does show the error.

Is there something intentionally different in canary builds which would bypass this error or does this imply a fix in 71?

Thank you for providing more feedback. Adding the requester to the cc list.

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

You may just have gotten rolled into a control group. If you go to chrome://flags/#tls13-variant, you can try out the various draft versions. But since this device only speaks TLS 1.0 and 1.1, I can think of nothing different between draft23 and final that would make a different here.

PS: Given the device doesn't even speak the 10-year-old TLS 1.2, this blog post may be of interest to you:
https://security.googleblog.com/2018/10/modernizing-transport-security.html

As per comment #2, on navigating to the site https://www.blunkmicro.com/tls.htm, can navigate to the site now on the latest Canary 72.0.3581.0 and cannot observe any ERR_SSL_VERSION_INTERFERENCE error.
As this issue is not reproduced at TE end, removing 'Needs-Bisect' label and requesting 'Internals>Network>SSL' team to look into the issue and help in further triaging.

Thanks..

TE folks: please leave this bug alone. The device in question is one only the bug reporter can access.

Does it only break when you set draft23 and/or the final RFC? It seems incomprehensible that a pre-1.2 server would be intolerant to one and not the other. I strongly suspect you hit a control group.

It looks like I did hit a control group.  Both draft23 and final trigger the intolerance.  

Interestingly, OpenSSL with TLS 1.3 works:

$ /usr/local/Cellar/openssl\@1.1/1.1.1/bin/openssl s_client -msg -connect 10.60.XXX.XXX:443
CONNECTED(00000005)
>>> ??? [length 0005]
    16 03 01 01 36
>>> TLS 1.3, Handshake [length 0136], ClientHello
    01 00 01 32 03 03 26 65 06 96 3c 39 c3 7f bf 76
    48 6c 32 2c 95 93 15 23 9c 08 25 72 c4 be e3 9e
    78 5a 89 6b 43 72 20 67 32 e4 cf e1 54 d7 9e 88
    aa 3b dd 39 8a 4d d3 0a bf eb 1b 3d f1 ef c3 76
    aa 71 59 13 d8 f8 69 00 3e 13 02 13 03 13 01 c0
    2c c0 30 00 9f cc a9 cc a8 cc aa c0 2b c0 2f 00
    9e c0 24 c0 28 00 6b c0 23 c0 27 00 67 c0 0a c0
    14 00 39 c0 09 c0 13 00 33 00 9d 00 9c 00 3d 00
    3c 00 35 00 2f 00 ff 01 00 00 ab 00 00 00 12 00
    10 00 00 0d 31 30 2e 36 30 2e 32 32 38 2e 32 30
    30 00 0b 00 04 03 00 01 02 00 0a 00 0c 00 0a 00
    1d 00 17 00 1e 00 19 00 18 00 23 00 00 00 16 00
    00 00 17 00 00 00 0d 00 30 00 2e 04 03 05 03 06
    03 08 07 08 08 08 09 08 0a 08 0b 08 04 08 05 08
    06 04 01 05 01 06 01 03 03 02 03 03 01 02 01 03
    02 02 02 04 02 05 02 06 02 00 2b 00 09 08 03 04
    03 03 03 02 03 01 00 2d 00 02 01 01 00 33 00 26
    00 24 00 1d 00 20 7a 46 75 c3 24 db 62 09 6c e4
    65 e6 c8 ae c9 d4 b3 64 17 55 63 f4 92 4e 94 50
    2e 98 44 28 b8 3e
<<< ??? [length 0005]
    16 03 02 00 4a
<<< TLS 1.3, Handshake [length 004a], ServerHello
    02 00 00 46 03 02 32 69 b2 ac e4 d7 88 eb 9e c8
    65 dd 7b 8b b4 25 54 c0 7c d7 7f 83 5b ad 80 7e
    b0 fc 91 a7 67 57 20 53 57 c2 62 e0 2b 26 c9 c2
    ee 81 00 b3 3f 56 a9 ae a7 20 9e de f2 c0 28 69
    31 8a e9 de 8b 2d 7e 00 35 00
<<< ??? [length 0005]
    16 03 02 03 55
<<< TLS 1.1, Handshake [length 0355], Certificate
    0b 00 03 51 00 03 4e 00 03 4b 30 82 03 47 30 82
    02 b0 a0 03 02 01 02 02 03 00 c3 80 30 0d 06 09
    2a 86 48 86 f7 0d 01 01 05 05 00 30 81 ac 31 0b
    30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06
    03 55 04 08 13 02 43 41 31 13 30 11 06 03 55 04
[snip]

Thank you for providing more feedback. Adding the requester to the cc list.

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

As per comment #14, the issue seems to be out of TE-scope and already the issue is being investigated from dev team. Hence, adding label TE-NeedsTriageHelp to push the bug out of TE triaging bucket.

Thanks...!!

pzbowen and I talked over email earlier. It seems the server is intolerant to large ClientHellos, and our TLS 1.3 ClientHellos get padded up to 512 bytes, to work around a different buggy server from way back in the day.

(Er, not sure why TE-NeedsTriageHelp disappeared when I commented. Is that supposed to happen?)

As per comment #20, adding 'TE-NeedsTriageHelp' back to push the bug out of TE triaging bucket.

Thanks..