9

I am having a weird issue with my Chrome browser and I can't find how to fix it. Each time I try to access my Gmail email I got the following message:

This site can’t be reached

mail.google.com is currently unreachable.

Try:

Checking the connection Checking the proxy and the firewall

ERR_SSL_VERSION_INTERFERENCE

I have tried the following:

  • Settings > Advanced > Reset
  • Settings > Advanced > Clear Browsing Data (from the beginning of the times)

None of them works and I got exactly the same issue after give it another try.

This is a work connection and does not affect any other browser. I have tried Firefox and the email works properly. At first I blame the connection but now seeing that it works on Firefox I can't do that. I am not behind any proxy.

Can any help me?

Improve this question
4
  • 4
    May be interesting: chromium.googlesource.com/chromium/src.git/+/…
    – Dave
    Jun 8, 2017 at 12:21
  • What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
    – djsmiley2kStaysInside
    Jun 8, 2017 at 12:21
  • Does it affect other browsers?
    – Dave
    Jun 8, 2017 at 12:21
  • @Dave I've edit the OP take a look again ... thx
    – ReynierPM
    Jun 8, 2017 at 12:24

4 Answers 4

Reset to default
15

I'm one of the people working on SSL/TLS for Chrome.

We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.

Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.

Thanks!

Improve this answer
3
  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12, 2017 at 12:20
  • 1
    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12, 2017 at 16:15
  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19, 2017 at 12:21
8

For me. I just disable the tls 1.3 and google mail works again. @_@ enter image description here

Improve this answer
3
  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12, 2017 at 19:38
  • Ooowh....I forgot to mention chrome://flags... :)
    – Maryadi Poipo
    Dec 13, 2017 at 2:10
  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5, 2018 at 18:09
3

I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.

Improve this answer
2
  • 1
    Please provide more specifics.
    – Ramhound
    Jun 12, 2017 at 20:40
  • 1
    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14, 2017 at 16:59
0

Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.

Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.

TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).

It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.

Improve this answer
5
  • 1
    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10, 2017 at 3:00
  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11, 2017 at 8:11
  • 1
    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11, 2017 at 17:34
  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12, 2017 at 18:03
  • 1
    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13, 2017 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .