Accept self-signed certificates

  • developer

    @ducktayp: No, I’d have filed these issues anyway. I’m often thinking about this problem, and I’m not yet sure, so I’m investigating. Personally, I use the email app very much and I guess people who use DAVdroid will often sync their mail, too. However, if DAVdroid (and other apps) would use MemorizingTrustManager on app-level, people may be tempted to choose “allow all certs” in the email app (i.e. in all apps which don’t have a local certification management), because “the other apps work and I want the email app to work, too (with a minimum of efforts)”. And I just can’t imagine that people use K9 Mail.

    So I try to investigate how people use their self-signed certs to read email at the moment (see above, see on Twitter, but I don’t get very much response… 😞


  • @rfc2822 : I see. I actually used to use K9 mail myself (I liked it a lot better than the stock non-gmail app), but resistance was, eventually, futile, and I use gmail now.

    Regarding your “slippery slope” argument – I think the effect might be in the opposite direction. If a lot of apps start using local certificate management, Google might take notice (since it means it’s a feature many people want) and increase the priority of an OS-level solution.

    As it currently stands though, for many people (who do not generate their own CA, or cannot import it), the choice is either to use http or to use https that is vulnerable to MITM attacks. I think using the second is still preferable, since it still gives fairly strong security.

    There’s also another, more subtle advantage in having more apps do certificate checking, even when some do not. In the crypto literature, attackers are categorized by their capabilities. An “active” or “malicious” attacker is the strongest, and indeed checking the “allow all certs” option does not protect against such an attacker. However, a very reasonable attack model is a “covert” attacker — one that is capable of performing active attacks, but will not risk getting caught doing it (large ISPs and mobile internet providers might fall in this category). If you’re accessing the same web-server with multiple clients, some of which do host verification, a MitM attack with a fake certificate becomes a lot more risky (since the attacker would have to know in advance which clients check certificates, and which are currently attempting to connect). The more clients do host verification, the riskier it is for the adversary to attack — so by adding host verification to one client, you’re helping protect the “naive” users who do click" allow all certs"…


  • Please note that HTTPS is vulnerable to MITM atack even with proper certificate check. It is broken by design. You only need to pay enough to some less trustful authority and you can have any certificate you want.

    You need to remember entire certificate chain and yell on changes, like SSH does (but SSH has only simple keys). Davdroid works with very sensitive data and it should act accordingly.


  • @jkufner It is hardly reasonable to expect Android app developers to fix HTTPS as a whole. (And if I were particularly worried about HTTPS generally being insecure, I’d worry far more about online banking than I would DAVdroid.)


  • @jkufner I think the GP project I linked to earlier is aiming at solving that exact problem, and it needs people to contribute.

    My (biased) opinion is to add MTM to DAVdroid until the GP project is usable, and to switch from MTM to that then. I hope to be able to provide an easy upgrade path.


  • Sensitivity of data in davdroid and in internet banking is about the same. Especially if your calendar contains when is your house empty (holidays) or when your company have critical meeting with important customer and who this customer is.

    Internet banking uses secondary communication channel to make critical operations safer. Davdroid does not this option, so it should at least try do do its best with certificates.


  • what is wrong with merging #194? this is about a davdroid issue and not about any mail app preference. furthermore fixing the HTTPS trust chain is likely behind the scope of this project. The proposed solution of pinning is what Firefox has had implemented for ages and what have been working fine since then…

  • developer

    @jkufner:

    Please note that HTTPS is vulnerable to MITM atack even with proper certificate check. It is broken by design. You only need to pay enough to some less trustful authority and you can have any certificate you want.

    HTTPS is not vulnerable to MITM attacks – a client which uses a trust store with default certificates that are not trustworthy is.

    • If your goal is very high security (I’ll call it military-grade), there will be no other option than to empty your system’s trust store and add only trusted certificates. In this case, you won’t be able to use online banking or a Web shop or PayPal unless you meet your communication partner and exchange the certificate from face to face (or on another, already trusted, channel). Certificate pinning may provide extra security (but is not required when you really trust all your trusted CAs), and you will have to know everything about your certificates, your keys, your key exchange algorithms, your encryption algorithms etc. You will also have to audit every piece of software and hardware you use directly or indirectly.

    • If your goal is an acceptable level of security while still being able to do things link Internet banking or shopping, you may accept the existence of a trust store that is shipped with your system. This automatically means that you will be “vulnerable” to MITM attacks if the entities you trust are malicious.

    You need to remember entire certificate chain and yell on changes, like SSH does (but SSH has only simple keys). Davdroid works with very sensitive data and it should act accordingly.

    DAVdroid doesn’t operate with more sensitive data than your browser or email client.

    I agree with you that the default trust store may not be trustworthy, but

    I disagree that this is DAVdroid’s concern. If you don’t trust the default system certificates, remove them. If you don’t, other apps (including system apps which won’t ever have MTM) may still trust them.

  • developer

    what is wrong with merging #194? this is about a davdroid issue and not about any mail app preference.

    It’s not a DAVdroid issue. DAVdroid is in no way related to certificate management and should not be. My personal problem with MTM is that

    1. it’s a workaround, while a “real solution” (= adding the certificate system-wide) is available (even if this solution is bugged by Android, see KitKit notification message, see having to change to PIN code etc.)
    2. I disagree that DAVdroid shouldn’t work together with mail client apps. I consider the whole Android device as an ecosystem, and users will not only use DAVdroid.
    3. I will have to read and audit the MTM code (if I don’t and there is an error, all people will blame DAVdroid and how terrible insecure it is), maintain updates, do GUI modifications etc.

    Furthermore fixing the HTTPS trust chain is likely behind the scope of this project.

    My word. DAVdroid shouldn’t have to bother with HTTPS trust chains or certificate management in any way.

    The proposed solution of pinning is what Firefox has had implemented for ages and what have been working fine since then…

    OK, let’s all apps which access Internet have a local certificate management… maybe with an own GUI to manage (add, view, revoke) certs… really?!

  • developer

    By the way, I’m happy about this discussion and I appreciate the work @ge0rg and @ducktayp. However, I’m not ready to decide yet (not enough information, and in the meanwhile it works), so please have patience.


  • @rfc2822 : I completely agree with you at the conceptual level, that davdroid really shouldn’t have to do certificate management on its own. However,

    1. The “real solution” doesn’t work at all for self-signed certificates. At least I couldn’t get it to work, hence the reason for my patch (I’m running cyanogenmod 11, which I assume means the problem exists for the latest android versions in other flavors as well). I suspect the problem is that a self-signed certificate that does not have the CA extension set (this is the case for most of them) is not recognized as a CA certificate, so adding it to the certificate store doesn’t help. This means that if you don’t control the certificate of your web server, or can’t set up your own CA, davdroid will not work at all.
    2. I don’t think there’s too much of a security risk in the way the MTM code is integrated; unless it’s actively malicious, the worst that could happen (if it really does things badly) is that you have some additional vulnerability to MitM attacks. Note that a malicious library is a security risk regardless of whether it’s being used for security purposes, so unless you audit every third-party library I don’t think the situation is that dire. I agree that maintaining updates can be a chore, but as long as they’re not security-related you don’t have to update MTM if the upstream changes…

    Having said this, if I added an option to toggle between MTM and the standard trust manager (e.g., an “accept self-signed certificates” checkbox in the options menu, set to off by default), would this be satisfactory? (it would solve the possible security problems, at least for users who aren’t aware of the risks, but would have a higher GUI maintenance cost)


  • @rfc2822 I finally understand why you are so hesitant to integrating this. You think that certificate management should be done on system level and not on application level. Basically you are right - this should be fixed at system level.

    The open question is now what to do meanwhile. We do not know when this will be fixed in android - on the other hand MTM is available right now.

    Probably what most of the people writing here (at least me) want is to use davdroid with a self-signed owncloud server. So the options for now are either be molested by the android certificate system (warning, requires a screen lock) or access the data without SSL. Neither of which is as convenient as pinning the certificate with MTM. This is by the way is what all of the owncloud android apps do - so owncloud users already have to trust the MTM code…

  • admin

    Please see this new video: DAVdroid: Using a self-signed certificate with Samsung Galaxy Note 10.1 (Android 4.1.2)

    We have tried it on CyanogenMod Android 4.4 as well.


  • @devvv4ever does your self-signed certificate has the CA extension set? Which versions of cyanogenmod did you test against? When I import my own self-signed certificate (in Cyanogenmod 11 M3) it does not appear in the trusted store, and does not allow davdroid to connect.

  • developer

    @ducktayp

    1. Yes, it does:
    $ openssl x509 -text -in debian-test.crt -inform der | grep -A2 Constraints
                X509v3 Basic Constraints: 
                    CA:TRUE
        Signature Algorithm: sha1WithRSAEncryption
    

    You can see the command used to create this certificate in the video or on https://wiki.debian.org/Self-Signed_Certificate

    1. The last version we have tried is CyanogenMod 11-2014-0311-NIGHTLY-i9110 (Android 4.4.2). I have tried it with earlier versions, too.

    2. How did you create your certificate? Can you try exactly the command from the Debian wiki?

    I suspect the problem is that a self-signed certificate that does not have the CA extension set (this is the case for most of them) is not recognized as a CA certificate, so adding it to the certificate store doesn’t help. This means that if you don’t control the certificate of your web server, or can’t set up your own CA, davdroid will not work at all.

    If your domain certificate is not a CA, then it relies on another CA and you can import this one. If you can use a self-signed certificate, you can also change it (to a correct one, with CA set), so I see no reason why this shouldn’t work except when there’s a wrongly configured certificate for this domain and you can’t change it. In this case, the certificate has to be fixed and not DAVdroid.


  • @rfc2822 : It turns out that whether or not the CA extension bit is set depends on the openssl configuration file, not on the command line. Generating a new self-signed certificate on my machine does set the CA extension. However, my certificate was generated a while ago and on a different machine. It’s possible that the default has configuration file was changed since then. Also, it’s arguable whether setting the CA bit is the right thing to do for a self-signed web-server certificate (the example given in the debian help is for signing a root CA).

    Regardless of why it happened, this is still a problem. And while I can – in theory – change the certificate to one that has the CA bit set (or is signed by my own CA), this is very problematic, since it will change the certificate’s fingerprint. I use my server to collaborate with others, some of whom are not technically proficient. Getting them to import one fingerprint for a self-signed certificate was hard enough; I would not like to make any changes that break their access to the server for other programs.

    Finally, I’d like to point out another problem with the system-level solution: it’s actually a lot less secure than “pinning” a specific certificate (especially if the KitKat “bug” that tells the user their connection may be monitored is “fixed”). The reason is that once you’ve imported a certificate as a CA, it can be used to sign any site. Typically, the keys for self-signed certificates have much weaker protection than CA keys (e.g., the keys are stored unencrypted on the web server so that it can start up unattended). If you imported someone’s certificate as a CA, you have to trust that no attacker gained access to their keys, otherwise they could implement a MitM attack against you for any website of their choosing (not just the davdroid website).
    (The vulnerability is slightly mitigated by creating a separate CA key, but, unfortunately, most users’ key management practices are not very sophisticated.)


  • I’m trying to get this to work, but:

    • Importing my certificate doesn’t work (it’s not a CA cert, it’s just a simple self-signed cert)

    • The other alternative of HTTP also doesn’t work (no idea why there’s a drop-down box offering HTTP or HTTPS if HTTP just pops up a ‘I/O error, HTTP protocol not supported’ error message)

    • I’m not overly concerned by MITM attacks, because I’m only connecting to the server over the local network - it’s not exposed to the Internet.

    So the current status, as I understand it, is that the only way for me to make this work is to create a signing certificate, sign my certificate with that, and import that into Android? If so, please update the documentation to include the steps for doing this - not simply for dumping the self-signed cert and importing it, because that does not work.

  • developer

    I’m trying to get this to work, but:

    Importing my certificate doesn't work (it's not a CA cert, it's just a simple self-signed cert)
    

    The difference between a CA cert and a “simple” self-signed cert is the “is a CA” flag. Just create a “simple” self-signed cert with this flag (for instance, default on Debian, but it can be enabled in OpenSSL config) and you will be able to import it.

    The other alternative of HTTP also doesn't work (no idea why there's a drop-down box offering HTTP or HTTPS if HTTP just pops up a 'I/O error, HTTP protocol not supported' error message)
    

    It’s an error in 0.5.10.1, and it’s fixed in 0.5.10.2

    So the current status, as I understand it, is that the only way for me to make this work is to create a signing certificate, sign my certificate with that, and import that into Android? If so, please update the documentation to include the steps for doing this - not simply for dumping the self-signed cert and importing it, because that does not work.

    Just use HTTP if your network is trusted. Otherwise, see this video: http://vimeo.com/89205175


  • Just joining the conversation to get notified. I will be in favor of adding the MTM support in order to simplify the suport for self signed certificate, but I understand @rfc2822 point.


  • @rfc2822 : In case you change your mind about pulling, or if someone else wants to compile their own version, I’ve ported my MTM patch to the the latest davdroid version.

Similar topics