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.

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

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

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

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

  4. Works to perfection,Thanks!!!

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

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

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

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

  9. Any ETA on the release?

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

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

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

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

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

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

 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)