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:

  1. In the Chrome URL bar, enter chrome://flags and hit Enter
    chrome_flags_url
  2. Once on the chrome://flags page, find the setting for TLS 1.3
    chroms_tls13
  3. Change this setting to Disabled
    chrome_tls13_disable
  4. Relaunch Chrome
    chrome_relaunch

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.

  44 Responses to “ERR_SSL_VERSION_INTERFERENCE in Chrome 63 using the JS SDK”

  1. 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.

  2. 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?

  3. 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.

  4. It’s been a few months, so I just wanted to check-in and see if you had any updates on this. Thanks!

  5. Works to perfection,Thanks!!!

  6. Any update on this issue? The “solution” outlined above is not very good from a security perspective…

  7. This did not work for us – we’re using Chrome on a Mac OS. Other suggestions PLEASE?

  8. 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.

  9. thank u sir thats work 4 me

  10. 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

  11. Experiencing this issue as well.

  12. 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

  13. 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

  14. 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

  15. 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

  16. Any ETA on the release?

  17. Thank u so much !!
    That really worked!!

  18. Hi Ron, any update on when a new release will be out there with this fix?

  19. work, thanks
    what’s the impact after disabled?

  20. Hi Ron, any news regarding this new release?

  21. Thank you, I followed all the steps and it worked

  22. brilliant,,easy to follow instructions and it worked, thanks

  23. Thanks, its working i was scared earlier

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)