Access denied

[stigc]

Seems like Garmin has changed protocol, I get an Access denied. Anyone else?

I'm using newest code v 1.7

[nosi1011]

Yes. Since 4days. I also use the current code from v1.7. (Error-Msg: "Oops: Authentication failed - please check your credentials" - but i'm really sure, they are right! ;))

[LEstefano]

It was already solved: #51

[stigc]

Thanks

[stigc]

hmm.. this fix is contained in v 1.7 but still get an error. Anyone else? Is this another protocol change?

[nosi1011]

Updating my system solves the problem for me.

sudo apt-get update
sudo apt-get upgrade

[DaveWilcock]

In the original report of this issue, myself and a couple of others worked to try and debug some oddities like this. I think it was finally put down to different openssl versions on the host OS treating the requests differently. 1.1.1.1f appeared to work for me, but older versions did not. Possibly related to the TLS version presented by openssl to Garmin. Could be resolved by getting the latest version of openssl (if possible)

…

On Tue, 25 May 2021, 21:52 nosi1011, ***@***.***> wrote: Updating my system solves the problem for me. sudo apt-get update sudo apt-get upgrade — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADHRHXM7MGFATPETCLADOLTPQEXDANCNFSM45NJHPNA> .

[stigc]

Thanks again

very old version on my host

openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017

[fulmar2]

My configuration is using OpenSSL 1.1.1k and it doesn’t work either, so I’m not 100% sure it is the version of OpenSSL.

[stigc]

I have now tried with OpenSSL/1.1.1k as well. I still get

Authentication failed - please check your credentials

[fulmar2]

I'm wondering if garmin has blacklisted certain IP addresses. I was working on trying to solve this on my own configuration - and finally looked at the cloudflare troubleshooting and saw this for error 1020:

Assess the cause of the block and either update the Firewall Rule or allow the visitor’s IP address in IP Access Rules.

[keosion]

Same problem here, in Ubuntu 18.04.
Setting CURLOPT_SSLVERSION to 6 into the default config in the Connector seems to be enough to fix it. Does someone else want to try and confirm ?

[stigc]

I'm wondering if garmin has blacklisted certain IP addresses. I was working on trying to solve this on my own configuration - and finally looked at the cloudflare troubleshooting and saw this for error 1020:

Assess the cause of the block and either update the Firewall Rule or allow the visitor’s IP address in IP Access Rules.

I think this cannot be the case. Mobile app and Garmin Connect website still accept login on my account from the same IP.

[fulmar2]

@keosion - Thank you for your suggestion. I just tried that and still receive the "1020" error.

@stigc - When it doesn't work for you, do you get an error that says, "Error reference number: 1020" from Garmin? This is what I see:

Access denied
This website is using a security service to protect itself from online attacks.

Ray ID: 6572f7ec0ae41833
Timestamp: 2021-05-29 21:55:42 UTC
Your IP address: 162.241.252.xxx
Requested URL: sso.garmin.com/sso/login?service=https%3A%2F%2Fconnect.garmin.com%2Fmodern%2F&webhost=https%3A%2F%2Fconnect.garmin.com&source=https%3A%2F%2Fconnect.garmin.com%2Fen-US%2Fsignin&clientId=GarminConnect&gauthHost=https%3A%2F%2Fsso.garmin.com%2Fsso&consumeServiceTicket=false
Error reference number: 1020
Server ID: FL_27F302
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

I wonder if you are receiving the same error number as I am because when I looked up 1020, it seems as if that is related to their firewall blocking an IP. Perhaps we're having different issues? As an aside, I did apply for access to their API, but they declined my application. :(

[stigc]

Yes I also get the 1020 error number

This website is using a security service to protect itself from online attacks.

• Ray ID: 657317c5abab4e0e
• Timestamp: 2021-05-29 22:17:26 UTC
• Your IP address: 157.90.***.***
• Requested URL: sso.garmin.com/sso/login?service=https%3A%2F%2Fconnect.garmin.com%2Fmodern%2F&webhost=https%3A%2F%2Fconnect.garmin.com&source=https%3A%2F%2Fconnect.garmin.com%2Fen-US%2Fsignin&clientId=GarminConnect&gauthHost=https%3A%2F%2Fsso.garmin.com%2Fsso&consumeServiceTicket=false
• Error reference number: 1020
• Server ID: FL_71F621
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

[fulmar2]

@stigc - and just to be sure: is "157.90.." the same IP address from which your Mobile App and Garmin Connect requests originate? The reason I'm asking you to double check is because their "Community Tip" indicates that the 1020 error means we have "Violated a firewall rule":

https://community.cloudflare.com/t/community-tip-fixing-error-1020-access-denied/66439

It seems that this code is working for some people, and not others. I'm thinking that the inconsistent nature of the problem could be related to inconsistent blocking of IPs....

[DaveWilcock]

Hey all - have you had a look at issue #51? We suspect that this 1020 error is triggered due to the TLS handshake being presented to Garmin with the incorrect version, and that it might be related to the version of OpenSSL on your PHP host OS. It would be good to understand the various versions of software on problem systems if possible. Ideally:

PHP version
CURL version
OpenSSL version

Also what PHP modules are installed (php -m) could be useful

Regarding the 1020 error relating to a firewall rule - I believe this to be a symptom rather than a cause. An incomplete (or incompatible) request is being made, and Cloudflare are declaring that this is breaching a Firewall rule. If you can login to connect.garmin.com via a web browser, you should be able to do it via a PHP script on the same IP address.

[stigc]

@stigc - and just to be sure: is "157.90.." the same IP address from which your Mobile App and Garmin Connect requests originate? The reason I'm asking you to double check is because their "Community Tip" indicates that the 1020 error means we have "Violated a firewall rule":

https://community.cloudflare.com/t/community-tip-fixing-error-1020-access-denied/66439

It seems that this code is working for some people, and not others. I'm thinking that the inconsistent nature of the problem could be related to inconsistent blocking of IPs....

Yes, you are right, I forgot my PHP code was running from another server, and therefore the IP is not the same.

[DaveWilcock]

I had a 1020 error from my machine until I applied the patches in the latest release. This doesn't feel like an IP address related issue.

[fulmar2]

@dawguk - The 1020 error could presumably "catch-all" types of firewall errors. In your case, it had to do with the TLS handshake, but for me (and likely @stigc ) the 1020 error could be related to IP blocking as suggested in the cloudflare documentation. Like @stigc , my implementation of the code is also running on a different server than what I use for my mobile/connect.garmin.com (in my case, it is shared hosting). My tool allows for multiple concurrent connections. Presumably, it would be unusual for several Garmin users to log in from the same IP address at the same time... and that is something that could be detected and filtered by a firewall. It is just speculation, though. I can't think of a way to temporarily change the originating IP and keep the same environment for an experiment.

For What it is worth, the server running the PHP code has the following configuration:
PHP version: 7.4.19
CURL version: 7.76.1
OpenSSL version: 1.1.1k

Thank you for taking the time to think about it - even if it is something beyond our control!

[stigc]

PHP 7.4.16
cURL 7.74.0
OpenSSL 1.1.1k

[uniquexor]

I have the same problem. Whenever I try connecting through website - everything is fine, when I try to use php-garmin-connect I get the 1020 error. I am running a Windows machine, php 7.4.19. I updated php-garmin-connect to 1.7 version, but that did not fix the issue.

[keosion]

In my case, 1.7 alone did not fix the problem (same 1020 error number). Verified with 2 differents IPs on 2 servers with same old OS, PHP, Curl and OpenSSL versions (PHP 7.3.28, Curl 7.58.0, OpenSSL 1.1.1j).

Setting CURLOPT_SSLVERSION to 6 fixed it. It forces curl to use at least TLS V1.2. When set to use at least TLS1.1 or SSL, it does not work. It confirms what @dawguk says.

Php modules : apcu, bcmath, bz2, calendar, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, geoip, gettext, hash, iconv, imagick, imap, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, Phar, posix, readline, Reflection, session, shmop, SimpleXML, sockets, sodium, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zip, zlib.

[DaveWilcock]

Thanks for testing that @keosion - are you able to run this test for me?

Remove CURLOPT_SSLVERSION
Set CURLOPT_VERBOSE to true

Then run

 php examples/example.php 2>&1 | grep TLS

And give me your output? On my machine, with the CURLOPT_SSLVERSION removed entirely, I get this output:

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

[DaveWilcock]

Should also be able to see which TLS versions your OS supports by running

openssl ciphers -v | awk '{print $2}' | sort | uniq

My output is

SSLv3
TLSv1
TLSv1.2
TLSv1.3

Edit: Sorry Windows users, I'm sure there is an alternative.

[DaveWilcock]

For future reference, here is a handy command that allows you to probe a given domain and output it's SSL cipher enumerations:

nmap --script ssl-enum-ciphers -p 443 garmin.com

Example output here is

Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-01 11:40 BST
Nmap scan report for garmin.com (162.159.138.86)
Host is up (0.024s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256-draft (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256-draft (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.61 seconds

[keosion]

With version 1.7, php examples/example.php 2>&1 | grep TLS returns

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

With CURLOPT_SSLVERSION set to 6, it returns :

* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305

Both ciphers are in my list returned by nmap --script ssl-enum-ciphers -p 443 garmin.com

openssl ciphers -v | awk '{print $2}' | sort | uniq returns

SSLv3
TLSv1
TLSv1.2
TLSv1.3

[DaveWilcock]

Thanks for the output. This is very interesting!

Your initial unchanged output is identical to mine, yet yours fails and mine is OK. I wonder if there is some additional automatic handshaking that my OS does, when it presents TLS v1.3 to Garmin...

Either way, in all cases I can get my connection to work fine when setting the SSLVERSION to 6, so I will include that shortly in a patch release (look for v1.7.1 this evening). This patch may not resolve this problem for everyone, but it will go some way for many, it seems.

[Raistlfiren]

We are running into the same issue as well. I am running the PHP 7.4 CLI alpine image. I will try to troubleshoot it some more as well. I updated the connector to include CURLOPT_SSLVERSION = 6, but still running into the 1020 issue.

PHP - 7.4.20

[PHP Modules]
Core
ctype
curl
date
dom
fileinfo
filter
ftp
hash
iconv
json
libxml
mbstring
mysqlnd
openssl
pcre
PDO
pdo_sqlite
Phar
posix
readline
Reflection
session
SimpleXML
sodium
SPL
sqlite3
standard
tokenizer
xdebug
xml
xmlreader
xmlwriter
zlib

[Zend Modules]
Xdebug

Curl - 7.77.0

OpenSSL - 1.1.1k

[Raistlfiren]

I bypassed the issue by running Ubuntu for the Docker image instead of Alpine linux.

[jpgnz]

+1 for CURLOPT_SSLVERSION = 6 working around this issue in my setup.

[stigc]

Where is the "CURLOPT_SSLVERSION = 6" release or commit?

[jpgnz]

No commit, not sure it's the proper fix for everyone, would need @dawguk to comment.

But, you can resolve it yourself by adding that config variable to the curlOptions array here

[fulmar2]

FWIW, I have tried the "CURLOPT_SSLVERSION = 6" to no avail. Interesting that this fixes for some, but not others.

[stigc]

No commit, not sure it's the proper fix for everyone, would need @dawguk to comment.

But, you can resolve it yourself by adding that config variable to the curlOptions array here

Thanks, tried it but didn't change anything here.

[oscarcopado]

Hello guys, i have finally found the solution!
Just edit class GarminConnect.php and go to line 145:

$strResponse = $this->objConnector->post("https://sso.garmin.com/sso/login", $arrParams, $arrData, true, $strSigninUrl);

and just change "login" with "signin"

$strResponse = $this->objConnector->post("https://sso.garmin.com/sso/signin", $arrParams, $arrData, true, $strSigninUrl);

And it works again!

EDITED: This solution worked for my home environment, but when i tried on prod environment it failed. This is so weird

[uniquexor]

Didn't work for me. I've tried running signin requests through a chrome plugin ARC and still got the same error, which leads me to believe, that the error has nothing to do with Curl. One theory I have is, that maybe if this is some sort of dos attack prevention system, there needs to be additional requests to some of the script files or other files?..

EDIT: does not seem to be the case... Tried blocking every other request in the browser and it still logs on successfully... :/

[ghost]

I´m use PHP 5.6, have the same error, do You have any solutions to this version of PHP ?
Could be 2 factor authentication the cause of this error ?