Security alert

[raresn]

We are having this trouble now and then with our app:
One of our clients got
It says "Name of the certificate certificate name does not corespond to the entry"

The name of the certificate here is different from our certificate btw, which I find super strange.
This one happened friday/saturday.

And we got:

This was on our test devices after leaving the app running over the weekend on a windows pc.

@ajwfrost do you have any idea why this is happening?

[raresn]

I instructed the client to delete the app and reinstall, she now gets:

[Devin-Licastro]

That's interesting. One of my staff has gotten the following 2 when opening the app recently.

We don't call either of these websites... I figured it was some weird device issue he was having related to VPN or something.

[raresn]

@Devin-Licastro do you happen to have a huawei router? :)
Do you get your certificate from amazon?

[raresn]

For our users who are on windows and got this in the past we asked them to do this:

And it suppressed the error, the rest of the stuff remains.

[ajwfrost]

Hi @raresn

Presumably these messages are coming up in response to a URL request that you're making within the application?

The name of the certificate here is different from our certificate btw, which I find super strange.

So the certificate error reported here is where you've initiated a connection to your server, via HTTPS, and iOS would expect the certificate subject's "common name" to match the domain name of the URL; if there's a mismatch, we display this pop-up.

I see this on my own iPhone from time to time if I'm connecting to a public wifi that requires a logon, where it redirects all of the URL requests to their own "login" screen (hence the certificate name shows as the provider of the wifi login system, even though the application e.g. Mail would have been expecting the certificate name from the email provider, resulting in a security failure). So it may be worth just checking they can open a web browser on the device and hit google/whatever without getting redirects or security issues.

Other than that, do you recognise any of the URLs? Do you have any analytics/advertising components that might be reaching out to some of these URLs? (am wondering if one of those is doing a redirect, or similar).

I think the Windows error - not being able to find the certificate revocation list - is different from getting a certificate that doesn't match the URL request. The former just means you don't know whether someone had cancelled your certificate; the latter is a sign of MITM attack or similar security flaw..

thanks

[Devin-Licastro]

@Devin-Licastro do you happen to have a huawei router? :) Do you get your certificate from amazon?

No the router of the colleague in question is a china-mobile one.
I'm not sure about the certificate to be honest

[raresn]

hi, @ajwfrost
That is the strange thing. Just like the example @Devin-Licastro shared, that domain has nothing to do with ours. the domain where the trust failed happened is dr.ordoline.com - which has absolutely nothing to do with our app, nor does the client recognize that name.
We don't use anything that could call to other domains names other than our own.
Sorry i can't be more helpful here, but if you have any idea, I would be glad to test.

[Devin-Licastro]

hi, @ajwfrost That is the strange thing. Just like the example @Devin-Licastro shared, that domain has nothing to do with ours. the domain where the trust failed happened is dr.ordoline.com - which has absolutely nothing to do with our app, nor does the client recognize that name. We don't use anything that could call to other domains names other than our own. Sorry i can't be more helpful here, but if you have any idea, I would be glad to test.

Yeah, to confirm, the domains have nothing to do with our app, and my colleague who saw the error message had never heard of the websites either. No third-party contacting tools are being used at this point in our app flow either (and the only one we use is the flurry ane). So there should be absolutely no traffic from the app to the outside except potentially to our very secure and isolated API.

Does it also happen to your user on app startup @raresn ? I was wondering if adobe air is reaching out to anything at startup? Maybe to some old adobe servers who's ip's are no longer connected to them and now lead to random websites? (probably totally wrong but just a thought)

[Adrian-S]

I work with @raresn and I can answer a few things.

@Devin-Licastro, Yes it happens on start and on every repeat call to our server. Since it has constantly pool data, it's called every 5 seconds and "Trust Failed" shows again every 5 seconds. This only happened to our client on Wi-Fi, and it worked fine on mobile data. Also the domain changed for the client from a random site to another. The only thing in common with our site, is that both are hosted on Amazon Web Services in Frankfurt, but the entire IP range is different.

We use a bunch of ANEs but all from AIR Package Manager, and I think they are all save.

@ajwfrost, the error on Windows may be related to something else, or the same. They happened over the weekend and I don't have an exact timeframe. Error for the client persisted until Monday and when we got a new screenshot with another domain. Also over the same weekend some Android phones, with a different air apps, misbehaved. It connects to the same server to pool data, and I suspect an internal error that we didn't caught.

• Autodesk has a small idea how to fix it here, but it's far from a solution. It's just suppressing the error at the OS level.
• AWS has this documentation. We gave it to our server guy since we don't understand much of it.

[ajwfrost]

A couple of questions:

1. can you please confirm the version(s) of AIR SDK that you're seeing this happening? And any idea if it's version-specific or not?
2. are any of these servers (that you are using, not the wrong/weird ones) using self-signed certificates?

We have just been discussing this issue. A fair while ago, we added the certificate handling where a warning will be displayed if there's a certificate problem detected by iOS (previously, the connection was just abandoned, but now there's an option to continue). There was a change in 50.2.2.5 that moved the set-up of the notification into a different thread, and the only way we can explain this weird behaviour is if there is a change in the underlying error object for which we're holding a reference. i.e. we get notification that there's a certificate problem, but then it could be a few ms later before the message is created for the user, and it could be that the storage used for this message has since been re-used for some other connection that may be happening.

So we can pull back the creation of the error message so that it's happening within the initial handler for the certificate problem. Which hopefully means it doesn't show incorrect server details. But, it would still display some sort of message to the user, e.g. "cannot determine trust for this certificate" or something like that.

(We'll also be creating a mechanism so that you can handle/ignore such cases within ActionScript if you wanted to...)

thanks

[Adrian-S]

1. I'm fairly confident this is not version related, we had it happen over the years and even before Harman.
2. Our server is using certificates generated by AWS in a load balancer. I think they have their own authority or something.

My guess this happens when certificates expire for real but they are still in a cache. Some routers may cache certificates too. We still weren't able to determine what router model our client had. Still, I suspect there is something wrong with certificates, but we don't know how to fix it. Also this happened 2-3 months after the certificates on the site were renewed and for me I only saw this once every multiple months.

If you are creating a mechanism to handle this it would be great to ignore or self correct the problem. Unless the problem can't correct itself, than give an error.

• For our client error persisted a few days and was not able to communicate with server.
• For me the problem gave two errors and corrected itself.
  ActionScript wise, maybe add a new IOErrorEvent for this problem, and not show it unless we are looking for this problem.

One other problem we observed, no events are called on URLLoader when running the app continuously for a night or a few days. We pool our server every 30 seconds and sometimes we saw no responses. We have a specific load routine, that will not allow calling it again unless the previous call is finished. Since no events come back it get stuck.

_loader.addEventListener(Event.COMPLETE, completeHandler);
_loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);

We expect at lest one of these to be called in ANY case. If not, than maybe it should. I think this is at the core of what everyone is doing in terms of loading. We will be adding a timeout to our loader class to solve/detect this problem.

[ajwfrost]

Thanks @Adrian-S - just on that last point, are you also listening for a SecurityErrorEvent? Maybe that's only sent in certain known/configuration conditions but I'd normally have that on there.. But what I'm actually wondering is whether the connection was established but something meant it never got as far as 'complete'.

We can do some long-term testing of this..

[Adrian-S]

@ajwfrost No listener for SecurityErrorEvent. No traces or errors. And progress is zero.

And one other important piece of information, that I forgot to mention, is that any other new call gets stuck too. In our case load gets stuck on itself as intended, but other api calls should go trough. These are new calls with new loaders and no events come back. For now this is an issue only if app is left running for long periods of time.

A similar behavior was notice on SQLStatement where no response comes back after execute. So maybe the problem is somewhere else. I think we will close the app at midnight to prevent this.

This is part of class, here is the constructor:

public function ApiRequest(url:String, method:String = null, payload:String = null, callback:Function = null, auth:String = null, accept:String = "application/json")
{
	_status = 0;
	_loadProgress = 0;
	_callback = callback;
	_loader = new URLLoader();
	_loader.addEventListener(Event.COMPLETE, completeHandler);
	_loader.addEventListener(ProgressEvent.PROGRESS, progressHandler);
	_loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
	_loader.addEventListener(HTTPStatusEvent.HTTP_RESPONSE_STATUS, httpResponseStatusHandler);
	
	_request = new URLRequest();
	_request.url = url;
	_request.contentType = "text/json";
	_request.method = method == null ? URLRequestMethod.POST : method;
	_request.data = payload;
	_request.requestHeaders = [];
	_request.requestHeaders.push(new URLRequestHeader("Appversion", Settings.VERSION));
	if(auth) { _request.requestHeaders.push(new URLRequestHeader("Authorization", auth)); }
	_request.requestHeaders.push(new URLRequestHeader("Accept", accept));

	_loader.load(_request);
	
	_staticList.push(this);
}

[ajwfrost]

Just checking:

For now this is an issue only if app is left running for long periods of time.

How long is "long"? You can't leave it for 24+ days, as internal clock stuff would then overflow... (known limitation of Flash/AIR, which is why in our local science centre, some of their interactive features are incredibly slow/laggy if they'd not been restarted in a while...)

24 hours should be fine though!

[raresn]

@ajwfrost We leave it open in debug at lets say 5 pm, and next day at 10 am it's stuck

[itlancer]

@ajwfrost
In my similar cases SecurityErrorEvent didn't fired. Looks like it Flash Player related. Maybe I'm wrong.
Related feature request: #1453

[Adrian-S]

Security alert on windows happened again over the weekend. I've downloaded the certificate revocation on Friday and today (screenshot below). I expected it to update again on the 26. It may be possible that certificate server did not respond during the update, but I didn't trace the time so I can't confirm something happened at the exact time the certificate was updated.

URLLoader stopped again, but this time I've notice one more thing. After main function got stopped, Out of +300 calls, about 20 went trough. We extended the trace log but it still got deleted, we only tracked 4880 calls. No SecurityErrorEvent was detected.

[Adrian-S]

@ajwfrost We've ran the tests overnight again and it got stuck at 5:18 AM local time.
Before it got stuck we traced 4096 calls in about 11hours (lost the first 1h36m). Out of these: 3755 loads, 127 version checks and 212 md5Checks.

After it got stuck only calls version api and md5Checks remained to be called (screenshot below). Most requests were dropped, no events no nothing, except occasional calls to version, that gave a response about once or twice an hour. I've manually added spaces between same hour traces for visibility on the right text preview, and md5Checks are highlighted but never seen in a response. These responses now have a load time of 40-60 seconds. But they load in less than 30ms when testing in Postman or new instances of the app.

Certificate error did not show up during this time. The certificate revocation list was updated again at: ‎24 ‎May ‎2023 05:48:21 (unknown time zone).

PS. Load is never called again because we wait for it to finish. Once this happens, all new URLLoader are stuck.

Cleaned up logs, after it got stuck:

[ajwfrost]

We've not been able to reproduce this kind of error, at least on Windows. Had left a test running for 24 hours that was posting data via HTTPS to an echo server every 30s, it kept on going fine..

Is it possible to get a bundle created that would be able to reproduce the problem here? i.e. if you package this up so that we can run it with your exact SWF, XML and AIR dll, we can (hopefully!) then see the same thing happening, and start to replace the AIR DLL with a debug version....

On iOS, we are wondering whether the "unrelated domain" messages were coming due to some update of shared memory caused by asynchronous code accesses, so we've got a change going in that captures the correct domain within the initial context (when we get the system notification, in a background thread) and uses that for the error message rather than using whatever domain may be behind that shared memory when the UI thread kicks in with the pop-up...

thanks