Chromium

[Empty comment from Monorail migration]

Works fine for me on Windows 7,latest stable:38.0.2125.111 and on latest canary:40.0.2212.0 (Official Build) canary.

Cc'ing agl@ for further investigation of this.

This is a ClouldFlare ECDSA site and so it don't work in Windows XP: XP is too old to process ECDSA certificates.

This is not an XP problem. the site opens in IE and FireFox, only Chrome has issue. Thank you anyway.

Firefox doesn't use the operating system's certificate verifier, so that's expected. That it doesn't work in IE is somewhat odd. Perhaps Cloudflare is fingerprinting IE somehow and providing a different certificate? They might not have accounted for Chrome on XP also being unable to process ECDSA certificates.

We do strike ECDSA cipher suites from the cipher list on XP (hence the connection failing as it does), so it should be detectable on their end.

[Empty comment from Monorail migration]

Please see my additional comments on the other page and re-open these tickets because either 1. We're correct and it's a problem with the changes made to the last update of Chrome 38 and the release of Chrome 39

OR

2. You're right and Chrome will no longer work with Windows XP. To repeat what I said on the other page: If the two are no longer compatible, then Google needs to stop advertising that Chrome works with Windows XP.

Of course, that will then mean the loss of thousands of users worldwide who will switch to Firefox and IE since, amazingly, those browsers have no difficulty bringing up these pages AND aren't pieces of bloatware.

BTW: Cipher Mismatch isn't the only broken page message. I've had two others, but I didn't record them when they happened. So... again, you might want to rethink the issue before marking it WontFix.

Lastly, here are the forum posts about Aw Snap that started with the last update of 38 and increased with the update to 39: https://productforums.google.com/forum/#!searchin/chrome/aw$20snap%7Csort:date

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Davidben: I forgot that you're only CC'd on this page. Please see comments from earlier today on the other page. Here is an update to those comments:

I uninstalled/re-installed Chrome. That action had zero effect on the Cipher Mismatch error.  

I did though figure out what's causing the Aw Snaps:

When Google forced the HTML5 player down users' throats, a lot of people had to use a workaround because the HTML5 player causes crackling, popping and lagging for some users when watching YouTube videos. The workaround involved changing the name of the ffmpegsumo.dll file so that HTML5 would be shut off on YouTube for those of us who can't use it.

So, now...

...I can load Gmail, YouTube, etc. without Aw Snaps errors and crashes, BUT I still can't use YouTube because the videos crackle, pop and lag.

As a result, this proves that the issue is a problem with Chrome because this a Chrome file that has repeatedly failed to create the same experience for everyone using the browser.

Worse yet, with (I have to assume) the last version of 38, some change was made to this file as the workaround "worked" fine until the last update of 38 when the Aw Snaps started and then, there must have been another change, because the update to 39 made things worse.

Users have been complaining for more than half a year about the HTML5 issue (possibly a year or longer - I can't recall), but here we are with HTML5 causing problems for those of us who can't use it, and really don't even want it.

So far... with these issues... I've lost a combined many, MANY hours of my life -- not counting the hours I lost after 38 was last updated. Yay.

I'm not creating any additional tickets. I'm fairly certain you'll find a ticket created earlier this year or last year about the ffmpegsumo.dll and HTML5 player issues. I'd be very interested in knowing how many people who are currently complaining about Aw Snap in the Google Chrome product forum are also people who, because they can't use HTML5 and watch YouTube, had to rename the file to prevent the HMTL5 player from being the default player.

If you know of any way to strip out that HTML5 functionality, it would be greatly appreciated.

I have to say that Google Chrome went from being this wonderful, fast alternative to Internet Explorer back around v30 or lower to being this absolutely awful, slowly, buggy product that fails in some way or another on an almost daily basis.

Lastly, I have to ask the following:

When you respond, please do not tell me that the developers purposely programmed the browser to crash pages to stop people from blocking the HTML5 functionality. I have no desire to know if this was purposely done because if I seem frustrated and irritated right now, you have no idea about the public backlash I will help spearhead if this was done on purpose to force HTML5 on users who literally can't use it because it doesn't work for everyone.

I have lost far too much work and personal time to these issues to hear that this was some sort of tactic. I mention this possibility because back when the developers took forever to fix the drop-down menu spacing and viewing issues, that they created with an update, users found a workaround, the next update made it impossible to use the workaround and  users found out that the workaround was purposely blocked.

So... whatever you say next, please don't mention 1) My creating any sort of ticket 2) Anything other than a possible workaround for HTML5 and a solution to the http/https/SSL/whatever that's causing some pages to not load and display a page broken icon.

I don't mean to say that you personally are causing any of these issues, but I had a working browser before the last 38 update. It wasn't perfect by any stretch of the imagination, but it worked. Now... it's a huge memory-sucking, error-filled nightmare.

Update:

1) CIPHER MISMATCH: Not fixed.

2) Aw Snaps and HTML5: I went ahead and posted an update in Chrome product forum to help people having the Aw Snaps problem. Thankfully, one of them gave me information about an extension that helps. Obviously, the extension doesn't fix the overall HTML5 Player issues that force many of us to look for workarounds, or whatever changes were made that caused the Aw Snaps when ffmpegsumo.dll was edited, but at least I can now listen to YouTube and other videos without a ton of lagging and crackling.
 

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

At least Mozilla gave Firefox users a heads up about this issue on their blog and they're permitting access through the end of 2015 -- giving website creators AND XP users time to upgrade.

[Empty comment from Monorail migration]

I have my own experience with apparently this same bug, and I think I had google chrome giving me no problems with the same sites I am having trouble now, in some earlier google chrome versions then maybe around november or even october 2014 (as this bug hints) the problems started that I was no longer able to visit the sites https://minilock.io  and   https://nadim.computer   any more, although Firefox (any recent version since I came across those sites) on WindowsXP 32bit was alway able to browse those sites.

I always had thought that Google Chrome was also somehow using the mozilla tls layers or something, but maybe I was wrong. Too bad that apparently google chrome is able to use tls 1.2 and certain kind of newer more recent tls and related security means and technology such as for example sni and much other stuff, but fails with these things described in this bug as certificate check and all on WindowsXP OS.

Is there any chance of ever getting this fixed? Thanks.

Same problem here. I am stopping using chrome for now. Waiting for solution.

I too received this error today (ERR_SSL_VERSION_OR_CIPHER_MISMATCH) when trying to access a site I visit often.  First time I've seen it occur so I cleaned history, all privacy remnants and ran my antivirus but that did not work.

If you're starting to see this today, it's likely different. Chrome 40 disables SSL 3.0 support (issue #451311). Especially if you're not using Windows XP, please file a separate ticket and we can help you track it down. (Be it a problem with some site or antivirus software or perhaps it's not SSL 3.0 and some other bug in Chrome itself.) Thanks!

If this is happening on something other than XP or is new in Chrome 40, it's a different issue. Please file a separate ticket and we can help you diagnose more specifically. (Almost certainly issue #451311, which is also working as expected, but one that the website operator should be able to fix fairly easily by updating their software.)

I'm going to lock down comments on this issue to avoid confusion since an SSL 3 server will hit the same error message.

(The original XP ECDSA problem isn't likely to get fixed anytime soon I'm afraid. We'll need to build a new certificate verifier, which we are working on for other purposes, but it will take time before or if we can use it to replace the system one on XP.)

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/431176?no_tracker_redirect=1

[Monorail mergedwith: crbug.com/chromium/436052, crbug.com/chromium/463739]
[Monorail components added to Component Tags custom field.]