Skip to content
Snippets Groups Projects
New issue look: Off

MTM/AndroidPinning broken in 0.71

    • Closed Issue created by username-removed-20330 @CiaranG

    Fortunately 0.71 is not an official release, but the MTM/AndroidPinning combo is broken in the version. When presented with a new cert using the same private key (so a certificate that should be accepted according to the pinned list embedded in the code) it presents the "Accept Unknown Certificate" dialog.

    It looks like this must be due to the changes made in that area prior to that release being tagged. It works fine with 0.70-test and earlier.

    Designs

    Child items 0

    • No child items are currently open.

    Activity

    • username-removed-20330
      username-removed-20330 @CiaranG ·
      Author Owner

      I've disabled 0.71 so nobody else can install it.

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      My guess is that this is due to changes in the MemorizingTrustManager library, which is what pops up that dialog. It is the first TrustManager in the chain. I'll look into it.

    • username-removed-42726 mentioned in issue #81 (closed)

      mentioned in issue #81 (closed)

    • username-removed-20330 mentioned in issue #81 (closed)

      mentioned in issue #81 (closed)

    • username-removed-20330
      username-removed-20330 @CiaranG ·
      Author Owner

      Three simple solutions to this:

      a) go back to 0.70-test, b) go back to 0.66, which is the recommended version anyway c) accept the cert by choosing 'Always'

    • username-removed-20330 mentioned in issue #81 (closed)

      mentioned in issue #81 (closed)

    • username-removed-26331
      username-removed-26331 @grote ·
      Developer

      Ciaran, could you please - just to be sure - provide the fingerprint of the cert, so we can be sure to accept the correct one?

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      @grote You can get it by going to https://f-droid.org in your browser, then clicking on the lock icon, and finding "certificate information". I'm seeing this:

      SHA-256 Fingerprint:
2D 78 02 5E BD D4 D8 8D 99 A4 19 AD 69 C7 6D F8
F1 56 82 F8 E4 8F 7D 65 56 31 C5 A5 FF 4A D0 27
SHA-1 Fingerprint:
3C 4B 12 BF 7A DC FA 39 F8 A6 1E C1 3D 08 38 8C 7C 75 F7 4A
    • username-removed-20330
      username-removed-20330 @CiaranG ·
      Author Owner

      Interesting - Firefox (which doesn't do SHA256 fingerprints anyway) tells me the SHA1 fingerprint is 3C:4B:12:BF:7A:DC:FA:39:F8:A6:1E:C1:3D:08:38:8C:7C:75:F7:4A

      In any case, if you're concerned about accepting a wrong certificate, just go back to a non-buggy version of the client.

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      doh, sorry, I did this website gitlab.com (sorry, still sick). I see the same for f-droid.org:

      SHA-256 Fingerprint:
2D 78 02 5E BD D4 D8 8D 99 A4 19 AD 69 C7 6D F8
F1 56 82 F8 E4 8F 7D 65 56 31 C5 A5 FF 4A D0 27
SHA-1 Fingerprint:
3C 4B 12 BF 7A DC FA 39 F8 A6 1E C1 3D 08 38 8C 7C 75 F7 4A

      I changed it above too.

    • username-removed-50920
      username-removed-50920 @Tanis ·

      Could it be related to this? http://www.unrelatedshit.com/2011/10/21/positivessl-not-working-with-android/

    • username-removed-20330
      username-removed-20330 @CiaranG ·
      Author Owner

      @patrick Flecken - I don't think so, because Android (try it in a browser, for example, or any version of the F-Droid client except 0.71) has no problem with this cert.

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      This should be useful for testing: https://pinningtest.appspot.com/

    • username-removed-51553
      username-removed-51553 @manulari ·

      FYI, I am also seeing the "Accept Unknown Certificate?", "Trust anchor for certification path not found." message on version 0.66 of the client.

      screenshot version

      screenshot message

    • username-removed-25042
      username-removed-25042 @pserwylo ·
      Maintainer

      Hey @CiaranG, @eighthave, I've sort of kept out of this discussion, as I'm not particularly familiar with certificate pinning. However it's a pretty serious bug, so would you like me to investigate? If so, is there any leads so far, e.g. from IRC discussions, that would help?

    • username-removed-20330
      username-removed-20330 @CiaranG ·
      Author Owner

      @pete - if you want to look at it, that would be great.

      I have one more bit of information to offer - the bug also seems to exist in 0.66, but ONLY with Android 2.x. I think this is a true statement, based on my own testing, a comment above, and a report on IRC. Could be wrong though.

    • username-removed-22388 Milestone changed to 0.72

      Milestone changed to 0.72

    • username-removed-24982 mentioned in merge request !30 (merged)

      mentioned in merge request !30 (merged)

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      !30 (merged) provides a temporary workaround so we can get a stable 0.72 release out. Leaving this open and reassigning it to "next" so we remember to get this working :)

    • username-removed-24982 Milestone changed to next

      Milestone changed to next

    • username-removed-52312
      username-removed-52312 @ge0rg ·

      @CiaranG Android 2.x and Android 4.x differently handle host certificates (vs. CA certs) stored in the keystore used for validation, that might explain the differences you are seeing.

      The new MTM code falls back to asking the user if the supplied TM failed to validate the certificate. Therefore I would assume something goes wrong in AndroidPinning. From a brief look, the place I stumbled over is the SystemKeyStore.getInstance(getApplicationContext()) parameter to PinningTrustManager - I've always just used null here to obtain the default Root CA set - and I'm not sure which Root CA set is obtained by that call. Maybe you can check if passing null here will work?

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      Here is a stacktrace when trying 0.71 with only MemorizingTrustManager enabled: https://gitlab.com/snippets/1881

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      Filed a bug for MemorizingTrustManager: https://github.com/ge0rg/MemorizingTrustManager/issues/25

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      A stacktrace from the default setup with 0.71 of MemorizingTrustManager, then PinningTrustManager:

      09-05 17:21:20.142 15742 15833 D MemorizingTrustManager: checkCertTrusted: trying defaultTrustManager
09-05 17:21:20.272 15742 15833 W System.err: java.security.cert.CertificateException: Didn't find a trust anchor in chain cleanup!
09-05 17:21:20.272 15742 15833 W System.err: 	at org.thoughtcrime.ssl.pinning.CertificateChainCleaner.getCleanChain(CertificateChainCleaner.java:72)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.thoughtcrime.ssl.pinning.PinningTrustManager.checkPinTrust(PinningTrustManager.java:149)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.thoughtcrime.ssl.pinning.PinningTrustManager.checkServerTrusted(PinningTrustManager.java:176)
09-05 17:21:20.272 15742 15833 W System.err: 	at de.duenndns.ssl.MemorizingTrustManager.checkCertTrusted(MemorizingTrustManager.java:400)
09-05 17:21:20.272 15742 15833 W System.err: 	at de.duenndns.ssl.MemorizingTrustManager.checkServerTrusted(MemorizingTrustManager.java:419)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.org.conscrypt.OpenSSLSocketImpl.verifyCertificateChain(OpenSSLSocketImpl.java:613)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:405)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.Connection.upgradeToTls(Connection.java:146)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.Connection.connect(Connection.java:107)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:294)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpEngine.sendSocketRequest(HttpEngine.java:255)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:206)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:345)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:296)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:503)
09-05 17:21:20.272 15742 15833 W System.err: 	at com.android.okhttp.internal.http.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:136)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.net.HttpDownloader.doDownload(HttpDownloader.java:92)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.net.HttpDownloader.download(HttpDownloader.java:64)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.net.Downloader.downloadUninterrupted(Downloader.java:111)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.updater.RepoUpdater.downloadIndex(RepoUpdater.java:101)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.updater.RepoUpdater.update(RepoUpdater.java:147)
09-05 17:21:20.272 15742 15833 W System.err: 	at org.fdroid.fdroid.UpdateService.onHandleIntent(UpdateService.java:344)
09-05 17:21:20.272 15742 15833 W System.err: 	at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
09-05 17:21:20.272 15742 15833 W System.err: 	at android.os.Handler.dispatchMessage(Handler.java:102)
09-05 17:21:20.272 15742 15833 W System.err: 	at android.os.Looper.loop(Looper.java:136)
09-05 17:21:20.272 15742 15833 W System.err: 	at android.os.HandlerThread.run(HandlerThread.java:61)
    • username-removed-52312
      username-removed-52312 @ge0rg ·

      I've had another look into CertificateChainCleaner, it seems to expect the certificate chain to be supplied by the server in a strict order. Running openssl s_client -connect f-droid.org:443 displays the following cert chain:

      Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=f-droid.org
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority

      To my amateurish eyes this looks like certs 1 and 2 are misordered for AndroidPinning, which is why it fails. Feel free to reorder them on the server to see if they will be taken by AP then.

    • username-removed-25042 I strongly believe the ordering of the certificates is causing the problems. Please read this comment on issue #90 (closed) for more details.

      I strongly believe the ordering of the certificates is causing the problems. Please read this comment on issue #90 (closed) for more details.

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      #90 (closed) fixed the 0.71 build for me, I just tried it. You can get it here:

    • username-removed-22388
      username-removed-22388 @mvdan ·
      Owner

      So can this be closed?

    • username-removed-24982
      username-removed-24982 @eighthave ·
      Owner

      we will need to re-introduce code to handle pinning and self-signed certs. I opened new issues: #104 and #105

    • username-removed-24982 Status changed to closed

      Status changed to closed

    Please register or sign in to reply