Sdk: badCertificateCallback is called with issuer certificate instead of leaf certificate for LetsEncrypt published certificate

Created on 18 Nov 2019 · 11Comments · Source: dart-lang/sdk

I want to do SSL pinning of server certificate that is issued by LetsEncrypt in my flutter code. Following is my code:

 static http.Client get _secureClient => IOClient(
      HttpClient(context: SecurityContext(withTrustedRoots: true))
      ..badCertificateCallback = (cert, host, port) {
            if (HOSTNAME != host) return false;

            final parser = ASN1Parser(cert.der);
            final ASN1Sequence signedCert = parser.nextObject();
            final ASN1Sequence _cert = signedCert.elements[0] as ASN1Sequence;
            final ASN1Sequence pubKeyElement = _cert.elements[6];
            final ASN1BitString pubKeyBits = pubKeyElement.elements[1];
            final List<int> encodedPubKey = pubKeyBits.stringValue;
            final ASN1Parser rsaParser = ASN1Parser(encodedPubKey);
            final ASN1Sequence keySeq = rsaParser.nextObject();
            final ASN1Integer modulus = keySeq.elements[0];
            final ASN1Integer exponent = keySeq.elements[1];
            //print("hostname: $host:$port");
            //print("modulus : ${modulus.valueAsBigInteger}");
            //print("exponent: ${exponent.intValue}");

            return PUB_KEY_MODULUS == modulus.valueAsBigInteger.toString() &&
                PUB_KEY_EXPONENT == exponent.intValue.toString();
          },
      );

The issue is that the callback if returning with the issuer certificate instead of the leaf certificate. Following is the PEM formatted cert that is being called with:

Is this how it is supposed to be or is it a bug? If this is the correct behavior how can I validate the leaf certificate that is issued to my server?

$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.9.1+hotfix.6, on Linux, locale en_IN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Android Studio (version 3.5)
[✓] Connected device (1 available)

• No issues found!

area-vm

Source

daadu

👍9

Most helpful comment

I hit this also. I dug into the code that calls badCertificateCallback. The dartlang code calls OpenSSL to perform the TSL connection. When OpenSSL cannot verify a certificate, it returns the certificate to dartlang, which passes it to the badCertificateCallback. This means that dartlang only sees the bad certificate, not the whole chain provided by the server. The fix will be non-trivial.

mleonhard on 4 Jan 2020

👍4

All 11 comments

I also realized that flutter doesn't respect the platform trusted CA store (checked with android, added a Charles proxy cert). It bundles the app with its own trusted root store (at least that is what I assume). If that is the case then do I need to pin the SSL certificate or Public Key of LetsEncrypt (which is already trusted) to prevent Men in the middle attack?

daadu on 18 Nov 2019

@mit-mit Could you answer the query in the comment? If I can go ahead with my hypothesis then I can publish my app.

daadu on 22 Nov 2019

👍1

mleonhard on 4 Jan 2020

👍4

I can confirm that this happens for all kinds of CAs, not just LetsCrypt.

If the default behaviour of OpenSSL is to return the unverified certificate, and not the whole keychain then how does iOS does it in AFNetworking. The flow in iOS is pretty similar to this. We disable trusting of certificates, the system calls badCertificateCallback and we extract the public key.
Haven't tried it though.

sahil-oyo on 23 Apr 2020

Is there any response for this issues. This seems very serious issues. Why would the certificate provided with only root CA instead of whole chain is not provided with parent,leaf or intermediated. Can we suspect that there is some configuration issues with LetsEncrypt ?

basnetjiten on 24 Apr 2020

👍2

@sahilpatel16 has confirmed that it is an issue with all CAs not just LetsEncrypt

daadu on 25 Apr 2020

As Mentioned here: https://developer.android.com/training/articles/security-ssl#MissingCa

The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don't sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate—signed by the intermediate CA—and the certificate verifier, which knows the root CA. To solve this, the server doesn't send the client only it's certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA.

There are two approaches to solve this issue:

Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2.

Or, treat the intermediate CA like any other unknown CA, and create a TrustManager to trust it directly, as done in the previous two sections.

I think adding these three things in the .conf file (Apache 2.4.8) file will solve the issues.
You need to use:
SSLCertificateFile /etc/letsencrypt/live/kultureshock.net/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/kultureshock.net/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/kultureshock.net/privkey.pem

basnetjiten on 27 Apr 2020

@daadu you found any workaround? Having same issue, it is returning the intermediate certificate

TMSantos on 25 Aug 2020

badCertificateCallback should not be used to trust root or intermediate CAs. Use setTrustedCertificates for that (although it is broken #35462).

The point of badCertificateCallback is to facilitate certificate pinning. The purpose of certificate pinning is to avoid trusting the CA ecosystem or the device's list of trusted CAs. Until badCertificateCallback is changed to pass the leaf certificate, it remains useless for certificate pinning.

mleonhard on 26 Aug 2020

@mleonhard setTrustedCertificates cannot be used to do Public Key Pinning.

Anyways, I am pinning public key of Let'sEncrypt CA, as a workaround, as LetsEncrypt in theory would not release sign certificate to someone else, for the hostname that I use. This will prevent any sniffing tool like Charles Proxy to function.

Also this article (I have quoted below) suggests that flutter relies on its own trusted CA bundle (embedded within app) and does not rely on platform's trusted CA (so say in Android, user importing custom CA would not cause MITM on our app)

So I dug further, after some further research I found out that Flutter bundles the BoringSSL libraries into “libflutter.so” and performs its own verification steps rather than trust the OS’s systems. It also forces the use of a known set of Root certificates which goes someway to explain why I couldn’t MITM the connection.

If what the article says is true, that in a way setting SecurityContext(withTrustedRoots: true) (which is BTW default), flutter will do the "SSL CA Bundle Pinning" for you, if the API service that the app consume uses SSL cert signed by some reputed CA.

Please point me if I am wrong, I am assuming for SSL cert signed by reputed CA, flutter does the "pinning" for you to prevent MINTM attack. (Although, as the article suggests it can be bypassed too! By modifying the libflutter.so in APK)

daadu on 26 Aug 2020

@daadu @mleonhard only way I found to retrieve the correct certificate was using HttpClientResponse object

HttpClientRequest request = await _httpClient.getUrl(Uri.parse(url));
HttpClientResponse response = await request.close();

Here you can access:

response.certificate.pem
response.certificate.subject

Etc and it has the correct certificate, instead of CA certificate only.

I somehow made this to be compatible with "http" by returning response like this:

    final streamedResponse = IOStreamedResponse(
        response.handleError((error) {
          final httpException = error as HttpException;
          throw ClientException(httpException.message, httpException.uri);
        }, test: (error) => error is HttpException),
        response.statusCode,
        contentLength:
            response.contentLength == -1 ? null : response.contentLength,
        isRedirect: response.isRedirect,
        persistentConnection: response.persistentConnection,
        reasonPhrase: response.reasonPhrase,
        inner: response);
    return Response.fromStream(streamedResponse);

I would prefer to do the pinning normally at badCertificateCallback, but until it is fixed, this was the only way I found to perform certificate pinning, at response level

TMSantos on 26 Aug 2020

👀1

Was this page helpful?

0 / 5 - 0 ratings