False Positive SSL/TLS and Crypto Security Flags in .NET 8 Android App (AppSweep Reports)

[Suryakomma]

Android framework version

net8.0-android

Affected platform version

.Net 8.0.100, .Net 8.0.303 SDK

Description

We have a .NET 8 Android application using the default HttpClient without any custom HttpMessageHandler, trust manager, or certificate validation overrides.

However, in every run of AppSweep by Guardsquare, the following security issues are flagged:

net.dot.android.crypto.DotnetProxyTrustManager missing checkValidity() / verify()

Xamarin.android.net.ServerCertificateCustomValidator_TrustManager does not correctly validate TLS certificate chain

Asymmetric cipher used with insecure padding (likely RSA/PKCS#1 v1.5)

These issues appear even though:

We are targeting .NET 8 (e.g., net8.0-android in our project file)

We use default HttpClient with no override logic

Our app does not implement any custom crypto or certificate logic

After reviewing GitHub issues like #95506, #84202, and MSAL Android #2235, we believe these might be either:

False positives in AppSweep due to static analysis misinterpreting default behavior

Or residual references from internal Xamarin/MAUI code paths still present in the Android build

We would like to confirm:

Are these known false positives?

Can Microsoft provide guidance or updates to resolve these reports?

Is there a way to suppress or eliminate these at the source (framework level), rather than manually in every AppSweep scan?

We appreciate your help in clarifying this and ensuring these legitimate .NET 8 apps aren’t incorrectly flagged for security violations.

Steps to Reproduce

have a AppSweep run on the bundle with minimum sdk support of 29 and targetSdkVersion is 34

Did you find any workaround?

No response

Relevant log output

[jonpryor]

@Suryakomma asked:

Are these known false positives?

They're not known to me…. They also don't entirely make sense, either.

Can Microsoft provide guidance or updates to resolve these reports?

(This question deliberately left unanswered.)

Is there a way to suppress or eliminate these at the source (framework level), rather than manually in every AppSweep scan?

I have no idea.

---

Consider:

net.dot.android.crypto.DotnetProxyTrustManager missing checkValidity() / verify()

DotnetProxyTrustManager in fact does not have a checkValidity() or verify() method.

However, it implements X509TrustManager, which also doesn't have a checkValidity() or verify() method.

Thus, this flagged issue does not make any sense to me. Why would there be a checkValidity() or verify() method when the X509TrustManager interface does not declare any such methods?

Then there's:

Xamarin.android.net.ServerCertificateCustomValidator_TrustManager does not correctly validate TLS certificate chain

ServerCertificateCustomValidator_TrustManager is the Java Callable Wrapper for this nested ServerCertificateCustomValidator.TrustManager type:

android/src/Mono.Android/Xamarin.Android.Net/ServerCertificateCustomValidator.cs

Line 36 in 0f8d36a

private sealed class TrustManager : Java.Lang.Object, IX509TrustManager

The Java Callable Wrapper will likewise not contain a checkValidity() or verify() method, because -- again -- the X509TrustManager interface doesn't require any such method.

I have no idea what is causing this message:

Asymmetric cipher used with insecure padding (likely RSA/PKCS#1 v1.5

I am thus inclined to agree with your guess:

False positives in AppSweep due to static analysis misinterpreting default behavior

[dotnet-policy-service]

Hi @@Suryakomma. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[simonrozsival]

@Suryakomma as @jonpryor said, it's unclear why the checkValidity or verify methods should be implemented on a Trust Manager. This seems like a first sign of false positive. I also wouldn't expect static analysis to be able to correctly validate that the trust manager's methods (checkServerTrusted, checkClientTrusted) are implemented correctly, since these Java methods call into native code and subsequently to the managed .NET code to decide if the peer should be trusted or not. This method is used when you provide custom validation logic via HttpClientHandler.ServerCertificateValidationCallback. When you don't specify ServerCertificateValidationCallback, the custom trust manager will not be used.

Is there a way to suppress or eliminate these at the source (framework level), rather than manually in every AppSweep scan?

I think this could be a bug or limitation of AppSweep rather than an issue in our code. Consider reaching out to Guardsquare for further guidance.

[dotnet-policy-service]

Hi @@Suryakomma. Due to inactivity, we will be closing this issue. Please feel free to re-open this issue if the issue persists. For enhanced visibility, if over 7 days have passed, please open a new issue and link this issue there. Thank you.