I’m sorry to bring that up again, but can anybody from Qualys answer why there is a distinction made between Safari and AWS (highly appreciated, btw), and not so between Android 7.0 (Chrome) and Android 7.0, the system library? ivanr, anybody please?
The system library is used for all apps that don’t bring their own TLS stack with them but rely on the system-provided. Be it your favorite cloud client, your email or your calendar app, most of them are affected, and definitely most of them use HTTPS, so this should be checkable by SSL Labs. Interestingly, Google’s own Chrome (the browser app) uses its own TLS stack and is thus not affected, that’s why it looks as if Android 7.0 would support good crypto.
But actually it does not. It only supports curve prime256v1 (for both ECDSA and ECDHE) and no other curves that have been supported before and after, like secp384r1. Still, SSL Labs doesn’t indicate this severe flaw (that was fixed in Android 7.1.1). If your clients cannot connect to your server while having an up-to-date OS with Android 7.0, they will of course put the blame on you and not their phone vendor who hasn’t managed to upgrade to >=7.1.1.
So: Question: Why can’t we have a client check for buggy Android 7.0, the system TLS library/stack, to help people identify compatibility issues with devices beside the browsers? And while we are at it, can we have tests for other versions of the system stack, too?
BTW, I actually tried to put that feature into testssl.sh, but it appears Dirk relies on SSL Labs client testing strategies *sigh*.