"CURL" web connection issues on some computers

[Fender19]

I use CURL to send license codes (text) from my plugins to my server to validate and register the license codes. It works perfectly here - and for the vast majority of customers on both Mac and PC - but occasionally it does not work for some specific user.

Since I can't access the customer's computer to debug this I don't know how to solve this. The only thing I can think of is that their computer has an antivirus app or perhaps a firewall that is blocking the curl web connection. Unfortunately I did not put any code in the plugins to display fault information but the problem seems to be in the sending direction as the code is not received/logged at the server.

Any ideas why curl would work for most but fail for a select few? Since I can't see the problem how can I solve it?

[BertKoor]

Unfortunately I did not put any code in the plugins to display fault information but the problem seems to be in the sending direction

So you know what to do already: show the faulty status info to the user, so it can be reported back to you, so you can deal with it.

[Fender19]

Unfortunately I did not put any code in the plugins to display fault information but the problem seems to be in the sending direction

So you know what to do already: show the faulty status info to the user, so it can be reported back to you, so you can deal with it.

Yes, understood, but easier said than done. Even if it reports back "connection error, etc." how is that going to help? I already know there is some kind of connection error but without being able to run a debugger on a user's computer how do I solve this? It works perfectly here (of course) on every computer I have tried, both Mac and PC.

So I was just asking, in the meantime, if there are any known/common causes of curl failure. It works for the vast majority but not a select few. Why? What can block it?

[BertKoor]

You don't have any information, so every little bit extra definitely will help: http status code, raw response body, anything you can grab.

You can also let these customers execute a "curl -v" (or -i) from a command prompt to your server on an endpoint that is open for GET requests to obtain the same information.

[mystran]

So I was just asking, in the meantime, if there are any known/common causes of curl failure. It works for the vast majority but not a select few. Why? What can block it?

I'd guess the most likely cause is an application level firewall where at some point in the past the user has denied the application (host in case of a plugin) access to the internet.. and perhaps forgotten about it (and probably doesn't understand that blocking a host also blocks plugins, and most certainly insists they haven't done it even after they find the list where it says the application is blocked). If you're happy with a one-time validation, then you could make a separate program to perform the license check in hopes of perhaps encouraging the application-level firewall to popup a dialog to allow/deny.

In corporate (or perhaps even academic) environments, there could be various other policies or firewall rules (and perhaps proxies for regular browsers) that could prevent you from connecting, but then it's the relevant corporate IT support that needs to fix it.

Proxies I guess could be a thing somewhere else too... with worst (and most likely) case being a PAC (proxy auto-config) file which is how you usually do those these days and which CURL apparently does not support.. in which case the solution would be something like taking the PAC file, looking at the contents (it's javascript) and extracting the relevant proxy to pass to CURL.

But... seriously, the most likely case is just an application-level firewall rule blocking the application (host in case of a plugin) from accessing the internet and the fix is to open the firewall's (or anti-virus, since those are usually the same) settings, navigating to the blocked list of applications "somewhere in the settings" and allowing access.

ps. If you want to regularly check for licenses (eg. to avoid revocation or whatever) then something that MIGHT lessen your support load might be to separate the license check into a separate program (eg. "myplugin-license-validator.exe" or whatever other descriptive name), then run that program as a slave process from a plugin. That way some "anti-virus" products might prompt for access for the separate process even if the host is blocked (if you're lucky and they aren't blocking the whole process tree)... and the user gets a better prompt with your product in it, rather than something vague related to the host.

[Fender19]

You don't have any information, so every little bit extra definitely will help: http status code, raw response body, anything you can grab.

Yes, absolutely. I do need more info about what's happening. But it's a bit complicated to get that info as there is currently no means to display the curl response on my UIs should it fail. My code currently only reads and proceeds following a "CURL OK" response as any other response is a failure. To the user it simply appears as pass/registered or fail/not registered - which I agree now is not enough.

You can also let these customers execute a "curl -v" (or -i) from a command prompt to your server on an endpoint that is open for GET requests to obtain the same information.

What you suggest here would work provided the user has CURL on their machine. I understand it's standard on Macs but not necessarily available on PC. Which has me thinking...

...I am building my plugins on Xcode and MSVC using the libcurl static libraries - which I understood should be completely self-contained (vs. the dll link method). But is it possible this "static" code still requires some associated system file that may be missing on some user's computers? I am going to single-step through the debugger to see exactly what CURL is doing.

Again, what has me so baffled is why it works 99% of the time but not that 1%. If my code was blatantly bad or wrong why does it work for most?

Thank you for your input.

[Fender19]

But... seriously, the most likely case is just an application-level firewall rule blocking the application (host in case of a plugin) from accessing the internet and the fix is to open the firewall's (or anti-virus, since those are usually the same) settings, navigating to the blocked list of applications "somewhere in the settings" and allowing access.

That's what I suspected as the most likely cause as well. I have suggested to user's having the issue that they check their firewall to make sure our URL isn't on the blacklist - and they say it's not. I've asked them to try opening our website and they say they can so I guess the firewall is NOT the problem - unless CURL is recognized differently by the server than a direct URL? IDK.

I am certainly no CURL expert but I honestly didn't expect this much trouble using standard code and libraries. As I said, it works properly for the vast majority of users - and, of course, it works here!

Thank you for your input.

[BertKoor]

What you suggest here would work provided the user has CURL on their machine. I understand it's standard on Macs but not necessarily available on PC. Which has me thinking...

Just give it a try. If users have kept their machine up to date, it will be there:
https://curl.se/windows/microsoft.html

On December 19 2017, Microsoft announced that since insider build 17063 of Windows 10, curl is a default component.

Again, what has me so baffled is why it works 99% of the time but not that 1%. If my code was blatantly bad or wrong why does it work for most?

The internet is not as "free" as you might think. I've experienced company proxies being a man-in-the-middle, intercepting all https traffic and presenting the client with a self-signed certificate.
If your app does plain http, the request content might inspected and flagged as suspicious.

I am going to single-step through the debugger to see exactly what CURL is doing.

Well, good luck with that, but I think you're wasting your time.
Let your users give you more info than "it does not work". Even knowing whether it crashes or you get a response (or timeout) is invaluable to get any further. Is it happening on all OSses, all versions, all locations, all networks, all virus scanners? I don't think so...

[BlitBit]

In case that you do not want to change your plugins then another option might be to compile a small command line application that also links the static curl library that you are using and that also attempts to reach your server. This application could then simply print the result to the console which the users could send to you.

[Fender19]

In case that you do not want to change your plugins then another option might be to compile a small command line application that also links the static curl library that you are using and that also attempts to reach your server. This application could then simply print the result to the console which the users could send to you.

That might work and is easy to put together. Thank you for the suggestion!

[Fender19]

Deleted

[Fender19]

You don't have any information, so every little bit extra definitely will help: http status code, raw response body, anything you can grab.

OK, I have updated my plugins to now display curl errors and the one that keeps popping up is error code 35, "SSL connect error". It does not happen ALL the time, just SOME of the time on both Mac and Windows.

Now that I have this info what does it mean and - more importantly - how do I fix it?

BTW - the URL used in my curl address path is a secure, i.e., "https", address which my server, AFAIK, connects with SSL. So something here must be the cause but what and why does it work MOST of the time?

[mystran]

Maybe a certificate check fails for whatever unknown reason? Does CURL from the command line work on the same server? If it's a CA thing.. then a browser might still work, 'cos if I'm not mistaken those ship their own lists of CA?

[BertKoor]

Now that I have this info what does it mean and - more importantly - how do I fix it?

It means an error occurred during execution of the TLS/SSL handshake protocol while establishing a secure connection. There can be several causes:

* Client & server cannot agree on TLS protocol version. Not likely, since you supplied the client, although you might give the client a flag to force it into eg TLS 1.2.
* Server might require an encryption algo not supported by client?
* Client cannot verify the Certificate Authority presented in the certificate chain presented by your server.

About 15 years ago there were ca a hundred root certificates which were trusted. That list has almost doubled in size. So if your certificate is rooted (via the certificate chain) by a new organisation, a client not knowing about it will dismiss it and give this error.

You can supply the CA root certificate (in java an extra 20-30 lines of messy code plus putting public part of certificate in your resource bundle) but this is not guaranteed to work blindly. There still can be a man in the middle changing certificates.

Some ideas:
* Supply flag VERBOSE to libcurl, capture the debug log and print it in case of errors. This gives more detailed info on what exactly went wrong so you know better what to fix.
* Back to plain http. What is more important here: a secure line or robustness? You can do encryption yourself instead of relying on https. Less messy, less code, less headaches, always works. You then help clients with this error, but also help hackers trying to break your validation routine.

[Fender19]

Now that I have this info what does it mean and - more importantly - how do I fix it?

It means an error occurred during execution of the TLS/SSL handshake protocol while establishing a secure connection. There can be several causes:

* Client & server cannot agree on TLS protocol version. Not likely, since you supplied the client, although you might give the client a flag to force it into eg TLS 1.2.
* Server might require an encryption algo not supported by client?
* Client cannot verify the Certificate Authority presented in the certificate chain presented by your server.

About 15 years ago there were ca a hundred root certificates which were trusted. That list has almost doubled in size. So if your certificate is rooted (via the certificate chain) by a new organisation, a client not knowing about it will dismiss it and give this error.

You can supply the CA root certificate (in java an extra 20-30 lines of messy code plus putting public part of certificate in your resource bundle) but this is not guaranteed to work blindly. There still can be a man in the middle changing certificates.

Some ideas:
* Supply flag VERBOSE to libcurl, capture the debug log and print it in case of errors. This gives more detailed info on what exactly went wrong so you know better what to fix.
* Back to plain http. What is more important here: a secure line or robustness? You can do encryption yourself instead of relying on https. Less messy, less code, less headaches, always works. You then help clients with this error, but also help hackers trying to break your validation routine.

Thank you for all the info and suggestions. I checked my SSL certs and passwords on my server and found several outdated ones so maybe something was getting tangled up there, IDK. I cleaned out the old ones and it seems to have made a difference. I ran a check on Mac OS Sonoma and Win10 this morning and I did not get any "SSL errors" returned. It worked perfectly as intended.

About 15 years ago there were ca a hundred root certificates which were trusted. That list has almost doubled in size. So if your certificate is rooted (via the certificate chain) by a new organisation, a client not knowing about it will dismiss it and give this error.

I did have one customer report the SSL connect error yesterday (before I did the cert changes) and he is running Windows 7. Is it possible that Win 7 is just too old at this point? Otherwise, he must have a firewall or AV blocking this. That's the only thing I can think of.