This site can’t be reached: “mail.google.com is currently unreachable”
up vote
8
down vote
favorite
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?
google-chrome https
add a comment |
up vote
8
down vote
favorite
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?
google-chrome https
4
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
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?
google-chrome https
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?
google-chrome https
google-chrome https
edited Jun 8 '17 at 12:23
asked Jun 8 '17 at 12:17
ReynierPM
1901215
1901215
4
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24
add a comment |
4
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24
4
4
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 at 12:21
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24
add a comment |
5 Answers
5
active
oldest
votes
up vote
14
down vote
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!
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 '17 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 '17 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 '17 at 12:21
add a comment |
up vote
7
down vote
For me. I just disable the tls 1.3 and google mail works again. @_@
Yep that worked for me. Glad there was another answer mentioningchrome://flags
though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38
Ooowh....I forgot to mentionchrome://flags
... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
add a comment |
up vote
2
down vote
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.
1
Please provide more specifics.
– Ramhound
Jun 12 '17 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 '17 at 16:59
add a comment |
up vote
0
down vote
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.
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 '17 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 '17 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 '17 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 '17 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 '17 at 19:08
add a comment |
up vote
0
down vote
See if you can fix this error by applying three solutions:
- Reverse your recent changes in the proxy settings
- Disable TLS 1.3 from chrome flag settings
- Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection
One of above solution will surely fix ssl version error on your pc.
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
add a comment |
protected by Community♦ Nov 22 at 12:11
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
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!
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 '17 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 '17 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 '17 at 12:21
add a comment |
up vote
14
down vote
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!
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 '17 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 '17 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 '17 at 12:21
add a comment |
up vote
14
down vote
up vote
14
down vote
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!
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!
answered Jun 9 '17 at 19:10
David Benjamin
1412
1412
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 '17 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 '17 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 '17 at 12:21
add a comment |
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 '17 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 '17 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 '17 at 12:21
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 '17 at 12:20
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 '17 at 12:20
1
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 '17 at 16:15
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 '17 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 '17 at 12:21
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 '17 at 12:21
add a comment |
up vote
7
down vote
For me. I just disable the tls 1.3 and google mail works again. @_@
Yep that worked for me. Glad there was another answer mentioningchrome://flags
though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38
Ooowh....I forgot to mentionchrome://flags
... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
add a comment |
up vote
7
down vote
For me. I just disable the tls 1.3 and google mail works again. @_@
Yep that worked for me. Glad there was another answer mentioningchrome://flags
though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38
Ooowh....I forgot to mentionchrome://flags
... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
add a comment |
up vote
7
down vote
up vote
7
down vote
For me. I just disable the tls 1.3 and google mail works again. @_@
For me. I just disable the tls 1.3 and google mail works again. @_@
answered Dec 12 '17 at 2:27
Hyosoka Poipo
17912
17912
Yep that worked for me. Glad there was another answer mentioningchrome://flags
though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38
Ooowh....I forgot to mentionchrome://flags
... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
add a comment |
Yep that worked for me. Glad there was another answer mentioningchrome://flags
though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38
Ooowh....I forgot to mentionchrome://flags
... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
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 '17 at 19:38
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 '17 at 19:38
Ooowh....I forgot to mention
chrome://flags
... :)– Hyosoka Poipo
Dec 13 '17 at 2:10
Ooowh....I forgot to mention
chrome://flags
... :)– Hyosoka Poipo
Dec 13 '17 at 2:10
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09
add a comment |
up vote
2
down vote
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.
1
Please provide more specifics.
– Ramhound
Jun 12 '17 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 '17 at 16:59
add a comment |
up vote
2
down vote
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.
1
Please provide more specifics.
– Ramhound
Jun 12 '17 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 '17 at 16:59
add a comment |
up vote
2
down vote
up vote
2
down vote
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.
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.
answered Jun 12 '17 at 20:13
user737958
311
311
1
Please provide more specifics.
– Ramhound
Jun 12 '17 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 '17 at 16:59
add a comment |
1
Please provide more specifics.
– Ramhound
Jun 12 '17 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 '17 at 16:59
1
1
Please provide more specifics.
– Ramhound
Jun 12 '17 at 20:40
Please provide more specifics.
– Ramhound
Jun 12 '17 at 20:40
1
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 '17 at 16:59
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 '17 at 16:59
add a comment |
up vote
0
down vote
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.
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 '17 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 '17 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 '17 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 '17 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 '17 at 19:08
add a comment |
up vote
0
down vote
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.
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 '17 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 '17 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 '17 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 '17 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 '17 at 19:08
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
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.
edited Dec 9 '17 at 11:17
answered Dec 9 '17 at 11:05
Miguel A. RO
11
11
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 '17 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 '17 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 '17 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 '17 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 '17 at 19:08
add a comment |
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 '17 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 '17 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 '17 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 '17 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 '17 at 19:08
1
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 '17 at 3:00
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 '17 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 '17 at 8:11
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 '17 at 8:11
1
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 '17 at 17:34
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 '17 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 '17 at 18:03
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 '17 at 18:03
1
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 '17 at 19:08
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 '17 at 19:08
add a comment |
up vote
0
down vote
See if you can fix this error by applying three solutions:
- Reverse your recent changes in the proxy settings
- Disable TLS 1.3 from chrome flag settings
- Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection
One of above solution will surely fix ssl version error on your pc.
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
add a comment |
up vote
0
down vote
See if you can fix this error by applying three solutions:
- Reverse your recent changes in the proxy settings
- Disable TLS 1.3 from chrome flag settings
- Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection
One of above solution will surely fix ssl version error on your pc.
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
add a comment |
up vote
0
down vote
up vote
0
down vote
See if you can fix this error by applying three solutions:
- Reverse your recent changes in the proxy settings
- Disable TLS 1.3 from chrome flag settings
- Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection
One of above solution will surely fix ssl version error on your pc.
See if you can fix this error by applying three solutions:
- Reverse your recent changes in the proxy settings
- Disable TLS 1.3 from chrome flag settings
- Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection
One of above solution will surely fix ssl version error on your pc.
answered Nov 10 at 8:36
JUNED MEMON
11
11
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
add a comment |
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37
add a comment |
protected by Community♦ Nov 22 at 12:11
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4
May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 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?
– djsmiley2k
Jun 8 '17 at 12:21
Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21
@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24