Dec 122017
Hello everyone,
Chrome recently released an update to Chrome (version 63) that includes experimental support for TLS 1.3. Unfortunately, this is causing problems with our client-side web service that powers the JavaScript SDK. We are currently looking into this issue but in the meantime, there is a workaround available. The following steps need to be performed on affected versions of Chrome:
- In the Chrome URL bar, enter chrome://flags and hit Enter
- Once on the chrome://flags page, find the setting for TLS 1.3
- Change this setting to Disabled
- Relaunch Chrome
Once Chrome restarts, you should no longer receive the ERR_SSL_VERSION_INTERFERENCE error. We will update this post as we continue to research this issue.
To whom it may concern,
We (the Chrome development team) are sorry that this negatively impacted you. We have tried to reproduce this issue by installing XXX but were unable to observe this failure. If you can give instructions for how to reproduce the problem, we can likely give a more detailed explanation.
Our best guess is that you might be using the BSAFE library to implement TLS. We discovered yesterday that this library contains support for an unofficial TLS extension called extended_random. BSAFE decided to give this extension number 40, but that was never registered with IANA. Extension number 40 is in the process of being assigned to the TLS 1.3 key_share extension.
Thus any TLS 1.3 capable browsers (such as Chrome 63, until Dec 19th) will refuse to connect to servers that use BSAFE because they will interpret the key_share extension as extended_random, answer based on that assumption, and cause a fatal TLS error.
At the moment, Chrome users (with Chrome 63) and some Firefox users cannot connect to such the web services because of this.
We will inform the IETF of this problem and they may reassign key_share to avoid this issue. But, if you are using BSAFE, we recommend that you disable support for extended_random and release updated software for your users as the renumbering may not happen.
we are getting error on many websites, its comes for 1 or 2 second and then open website. I tested with https://www.ifloristdelhi.com should we do any thing on website?
hello Bharat,
I am not sure I understand your issue… can you give me some detail?
Ron
We have started getting an SSL error: “Failed to load Resource. An SSL error has occurred and a secure connection to the server can not be made.” After that we get a “Reference error: Cannot find label”
I suspect the second error is happening because of the first, but I’m not sure. We haven’t changed anything, so not sure what’s happening.
Hi Cindy,
What browsers does this issue happen on? What version of DLS are you running on the client?
Ron
It’s been a few months, so I just wanted to check-in and see if you had any updates on this. Thanks!
Works to perfection,Thanks!!!
Any update on this issue? The “solution” outlined above is not very good from a security perspective…
This did not work for us – we’re using Chrome on a Mac OS. Other suggestions PLEASE?
I am getting this error on multiple pages; have to reset page dozens of times before it will load. Disabling TLS 1.3 did not resolve the issue.
thank u sir thats work 4 me
Hello there! I see this post has a few month now. Are there any plans to fix this problem besides the workaround?
It’s very hard to make our Dymo integration work for all our users by making sure they apply this workaround.
Thank you,
Ari
Hi Ari,
I feel your pain… there is not much we can do about this issue. We need Google to fix Chrome.
Ron
Do you actually have Chrome engineers looking at your issue?
My understanding is that the TLS Working Group concluded Dymo’s problem is probably due to hardware which hijacks a reserved identifier. ie the hardware (presumably from one of Dymo’s suppliers) is faulty. If this was the problem Draft 23 works around it. If this was NOT the problem, you probably needed to highlight that a month or more ago, as TLS 1.3 is now on track for publication, meaning you’ll see the same errors, with no way to turn them off, in every shipping web browser by about mid-2018. There are no further “wire” changes after Draft 23, so if it still doesn’t work it never will.
Hi Nick,
Thanks for all of that information! Where did you learn that the TLS Working Group concluded Dymo’s problem is due to hardware?
Ron
David Benjamin of the Chromium team at Google told the TLS Working Group
https://www.ietf.org/mail-archive/web/tls/current/msg25168.html
“Dymo (the label-printer manufacturer) is experiencing a similar[2]
issue with some of their software. We have not been able to reproduce
but one guess is that they are also using BSAFE.”
By “a similar issue” and “they are also using BSAFE” they’re referring to a problem, fixed in Draft 23, where the BSAFE hardware RSA implementation uses a code which was reserved for future use in IETF standards, instead of its own unique code. The Draft 22 TLS version picked the next available code from those reserved – running into a conflict with these unauthorised BSAFE uses. Although “Do nothing” would be permissible, the IETF prefers to avoid needless problems, so they picked a different reserved code in Draft 23.
However, if the fault Dymo see was NOT this misuse (“hijacking”) of a reserved code, but some other incompatibility, the changes in Draft 23 wouldn’t fix it.
I am pleased to see in your later post that you will have a solution for customers, that’s great news for your customers, and for adoption of future TLS versions.
Hey Nick,
I did find out that we are working on the issues with TLS. Our next version of DLS and the javascript SDK will have a solution to this issue. The release is currently in the QA cycle.
Regards,
Ron
Experiencing this issue as well.
Has anybody else noticed very slow printing starting this morning 4/32/2018? I see this on multiple machines or all browsers. The sample online take 5 seconds to print as well. http://www.labelwriter.com/software/dls/sdk/samples/js/PrintLabel/PrintLabel.html
I tried updating to DLS8Setup.8.7.exe but this does not seem to resolve the issue.
Hi Scott,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
Hello, I am experiencing very slow print times using the javascript API. Actually the issue is starting to trickle in from my customers. 15-20 seconds from the point I call Label.print()…
Others are experiencing the same. Please refer to
https://stackoverflow.com/questions/49987169/dymo-label-web-service-printing-slow
Having the same issue. Fetching the label takes 15 seconds through the DLS web service tool. But if I browse to the label on our site manually in the browser it loads in less than a second. All PCs in our shipping department are having the same issue starting today. OpenLabelFile is taking all the time (15+ seconds). GetPrinters and PrintLabels are very fast as normal.
Hello Kevin,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
I am having the same problem start this morning all of the machines are having the same problem they were working fine on Friday.
Hello Joseph,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
I broke out Procmon and got to the bottom of this.
It appears to be due to the Dymo Label Service querying 128.30.52.100 (hans-moleman.w3.org) every time it was fed a label to validate its schema. We were not being rate limited by this service until today.
Setting an outbound firewall rule against this IP address for the DLS service executable fixed the issue.
Thanks Sammuel,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
seems every call is being validated to w3.org – rejecting outbound TCP traffic to 128.30.52.100 ( https://hans-moleman.w3.org/ ) solves the issue for now
Thanks Derk,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
We have also this problem. We work with more than 10 labelwritters for our back office and today all the printers need 16 secon to print a label from our backoffice. Make a aptch ! Urgent
Hello Eskimo,
We have identified the issue and are currently working on a fix. We will be releasing the fix ASAP.
Until the actual fix goes out, users can alleviate this slowdown by preventing this call. We have seen success with two methods thus far.
1: Prevent connections to 128.30.52.100 (hans-moleman.w3.org).
2: Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.
Regards,
Ron
Hi, I’m having the same issues than Wessel over here. 15 to 20 secons to print any labels. I tried to block the IP 128.30.52.100 via our firewall, apparently this IP is called each time and is not valid any more _ invalid certificate, but it doesn’t tackle my problem. The problem has started yesterday on the 4/23. Any solutions yet ?
Thx
Any ETA on the release?
Also, perhaps open a new post with this issue?
Instead of continuing it on the post of another issue…
thanks
We are working on it now…
Thank u so much !!
That really worked!!
Hi Ron, any update on when a new release will be out there with this fix?
We are working on the release now… expecting a release this month.
Regards,
Ron
work, thanks
what’s the impact after disabled?
Hi Ron, any news regarding this new release?
Hi Ari,
The release went out yesterday. You should be good to go!
Ron
Thank you, I followed all the steps and it worked
brilliant,,easy to follow instructions and it worked, thanks
Thanks, its working i was scared earlier
Great! It work!
program will not recognize the dymo ive installed and restarted 6 times and nothing
Hi Brett,
Does your printer show up in the control panel under Printers and Devices?
Ron
The extension stopped working all of a sudden. Any known fix to this? I ‘m on chrome mac os. have tried the fixes up. thanks for any help
Hi Vinny,
What version of DLS are you running on your Mac? What version of the javascript SDK are you using?
Ron
I don’t know. how can I check what dls and javascript i’m running?
Hi Vinny,
Are you a software developer that is having trouble with your own application? Or, are you a user of a custom application that is experiencing some issues?
Ron
im just an end user. I’m on mac os using chrome extension.
Hi Vinny,
You should contact whoever provided the software to you. I don’t know how their software works, so I am unable to help you.
This blog is meant to help software developers create products that interface with our printers.
Ron
Okay so where can I obtain help for the end user? My chrome extension stopped working. What do you suggest the end user try / update to troubleshoot this issue?
Hi Vinny,
You should contact the provider of the chrome extension.
Ron
Help all of a sudden the extension stopped working. I’ve tried the fix above but nothing, I’m clicking on the icon and it’s not even opening up. MAC os sierra Chrome with Dymo Labelwriter 450 turbo.
Thanks in advance,
Please answer asap thanks Susan
Hi Susan,
Can you give me some more information about your situation? What version of DLS are you using? What version of the Javascript SDK are you using? What do you mean by “the extension stopped working”?
Thanks,
Ron
this is the same issue i am having. when clicking on the extension, no new tab pops up.
Thanks Ron but not sure what the abbreviations mean..even thought I’m on the computer I don’t know much about it lol I don’t know where ot look for those answers
Exactly Vinny was fine last week, now nothing..and I go to the website and have already done their fix still not working..very frustrating..never had it out this long always found a step by step answer for me computer for dummies!
Hi Susan,
Are you a Software Developer or a user? If you are having an issue with a custom application that was written by a third party, it would be best to contact the third party.
Ron
This worked for a while, but the newest versions of chrome for macos don’t have this option. I’m using the version 3.0 of the JS library, the latest service version, and am still getting ERR_SSL_VERSION_INTERFERENCE for all requests on multiple machines.
Hi Ben,
The most likely source of this issue is a mismatch between the version of the javascript library and the client side DLS install. Unfortunately, the user must have the latest version of DLS installed too.
Ron
This issue is also affecting us on Chrome 75.* and OSX Mojave. It works in Safari straight away when running the Diagnose function form the widget. We’ve googled all the intended fixes but nothing has worked so far, can you please advise asap on a fix to allow Chrome to access the localhost:port for the 450 printers.
Hi Mick,
What version of the javascript SDK are you using? What version of DLS on the client?
Ron