Issue logging into CLI via Firefox

When attempting to login to balena CLI with the Web authorization (the recommended method), it fails when it opens the authorization tab in Firefox (71.0 (64-bit)). It opens the tab, I click the Authorize button, and then it can’t load the page. The error it gives is
Secure Connection Failed: An error occurred during a connection to SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

The other two authorization methods (Credentials and Auth token) work fine. When I have the auth tab open in Chrome (Version 79.0.3945.88 (Official Build) (64-bit)), it works as intended.
My OS is Ubuntu 18.04.3 LTS. I’m using wifi, and I have had this working in the past. My balena CLI version is 11.21.0, which is the most recent.

Hi @mschacht taking a look for possible cause I came across one potential fix you might want to try:
Disabling SSL 1.3 in Firefox:

  • Write to your address bar: about:config
  • Search for: security.tls.version.max
  • Change the value from 4 to 3.
  • Click ok and you should be good to go!
    4 stands for TLS 1.3 and 3 for TLS 1.2

Otherwise this seems to be an issue with SSL negotiation between the browser and the balena cli which I would need the engineer in charge to to look into.

Hi samothx, thanks for the quick reply.
I tried your suggestion, but I still cannot authenticate via Web auth. I checked with a coworker who has no problem doing Web auth via Firefox, and their TLS version is 4. They are running the same OS.

@mschacht It appears that this is quite common error message with several different causes.
Another potential cause I came across is related anti virus software interacting with / interceptiing the ssl connection to localhost. If you have an AV software installed on the device you might want to give it a try with AV disabled.
I will also forward your request to the engineer in charge of the balena cli.

I don’t believe I have any.

@MasterSpecter, I have tested it on Ubuntu 18.04.3 LTS as well, with CLI version 11.21.0 (standalone zip installation) and Firefox versions 69.0 and 72.0.1, and I could not reproduce the error – and as you had pointed out, neither could your coworker. So I think we need to gather some more data from your machine, and figure out where it differs.

Looking at the CLI source code (this file), I gather that the CLI creates a local HTTP server at when web authorization is chosen, so that the local web browser can then connect to the CLI to transfer the authentication token. But as far as the CLI is concerned, the server uses the plain HTTP protocol, not HTTPS/SSL/TLS. Inspecting Firefox’s network activity (Firefox menu Web Developer > Inspector), I see however that Firefox adds the Upgrade-Insecure-Requests header, and then displays a green padlock with the hover tip “The connection used to fetch this resource was secure.” See screenshot:

So I think that’s how the SSL_ERROR_RX_RECORD_TOO_LONG error could come into play. Google Chrome seems to do the same, but you’ve pointed out that it works OK with Chrome.

I suggest you run the Firefox Inspector as well, open the Network tab and try to repeat the web authorization. It should fail, but perhaps you would find some additional information about the problem. Perhaps you could share your own screenshot of the Network tab.

Some other things to try/consider:

  • Run the CLI in debug mode with:
    DEBUG=1 balena login
  • Try opening on Firefox (the same browser where CLI authentication fails) and Sign Out. Then try the CLI web authorization again (balena login). Do you use social login with Github or Google? Or do you use a username and password? I’m not sure it matters, but in my own test I was using social login with Github.
  • Try deleting the CLI’s ~/.balena cache/config folder:
    rm -r ~/.balena.
    Note however you might want to make a copy of ~/.balena/secrets.yml file, if you had created one.
  • Try bypassing Firefox’s cache as suggested in this thread.
  • Try with Firefox 72.0.1 (I couldn’t get hold of Firefox 71.0).

Let us know what you uncover! And thanks for reporting this issue.

Following your instructions, I opened the Inspector when trying to authenticate. This is what I got.

I see that the Upgrade-Insecure-Requests was used, as it was in your example. Clicking on the Learn More link led me to this page, which told me that

In many cases, it is caused by a browser plugin (e.g. an ad blocker or privacy protector) blocking the request.

So as a precaution, I disabled all my browser plugins (I use a couple ad-blockers/security ones), then attempted to authenticate again. The only difference I could see was the lack of the second error message. I also noticed that my Request URL is https, whereas yours was not, despite both being subject to Upgrade-Insecure-Requests.
I use a username and password for the balena dash. Signing out and then trying to authenticate just made me sign in (makes sense), but then it didn’t try to authenticate the CLI. Deleting the Balena cache folder did not seem to make a difference.

The problem seems to be that your browser tries to use https on
The temporary server listening here listens for http requests only, not https.
I can reproduce this issue by changing the cli code to not close the temporary server it creates on and manually connecting to it via
Something in your browser changes the requested url to https.
Could you try cleaning the browser’s cache and disabling all extensions ?

I had previously disabled all extensions/add-ons, and that didn’t make a difference. I then cleared my browser’s cache, and that worked! I was using an extension that forced HTTPS, so I’m wondering if that result was cached and was causing this issue.

I was using an extension that forced HTTPS, so I’m wondering if that result was cached and was causing this issue.

Yes, most probably