Accept self-signed certificates


  • @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.


  • ducktayp, please point F-Droid at it. Anyone who has paid attention to SSL security over the past decade can tell you that allowing arbitrary CA-signed certificates is the easiest way of permitting MITM attacks and that you’re a lot safer (if you can manage it) to provide a single cert that is known to be the only one to work with the service. Having to jump through hoops to turn a secure service into an insecure one in order to be able to use it is both a security and usability fail.

  • developer

    @davidchisnall

    1. You know that MemorizingTrustManager still accepts certificates from the local trust store (default certificates), i.e. “allows arbitrary CA-signed certificates”, do you?

    2. As far as I have seen, MemorizingTrustManager doesn’t provide pinning, too (it just adds certificate to an app-level cert store). So assuming that your current certificate has been stolen and you use a new one on your server, you will be asked by MTM whether you accept the certificate the next time. However, the stolen certificate will still be accepted. The point is that a way to add certificates is not enough – you will require a full-blown certificate management subsystem (allowing to add, view, revoke, delete certificates) for each app on the device. And even then, if you forget to remove the old certificate from one single app, this app would accept the stolen certificate and be vulnerable to the thief.


  • @rfc2822 while the attack you outline is plausible, it would be quite difficult, and would apply equally to certs that are pinned or TOFUed. With TLS, the cert is mapped to the domain name. So in order for the attacker to use the stolen certificate, they have to either control the server hosting that domain name, or control the network of the users they are targeting in order to redirect the domain name to a different server. So having a way to remove certs from the memorizing store would be useful, but far from essential. Similarly, CA revokation techniques with CAs have been abandoned by many big players (Google, Mozilla, etc) as more trouble than they are worth.

  • developer

    @eighthave That’s why people like self-signed certificates (and might even prefer them over bought ones): if one gets lost or compromised, they can simply remove it from their devices and it won’t be accepted anymore. It’s a simple revocation that anybody who is able to manage the device’s local trust store can do.

    If you have to deal with your own security, there’s no reason to get third parties (like commercial CAs) involved – it just makes trouble (because for instance, revocation is cumbersome to impossible and stolen certificates can be used for a secured domain). Commercial CAs are only useful when used in public: they promise that the endpoint with a certain certificate is exactly who it claims to be, and that’s what they are paid for.

    (The fact that many users who have own servers also want to send secure mail with SMTPS, meaning that the public is involved, is another story.)

    What does this mean for DAVdroid?

    • When there’s a CalDAV/CardDAV provider that offers its services to the public, a self-signed certificate or an own CA is not appropriate, they will just go with a commercial CA (in the default trust store). These providers can’t control the trust stores of their client devices. If a certificate is lost, only revocation that is supported on client-side would be helpful.

    • Smaller organizations, groups etc. might choose to create an own CA and still use the TLS verification system (domain-boud). They can control their users’ devices; if a certificate gets lost, they can instruct them to remove it and thus prevent MITM attacks (even if the attackers control the server and/or the network).

    • If there are only a few users on a service (as I guess that it’s the case for most users of DAVdroid), the users can create self-signed certificates and also control their own devices. Again, if a certificate gets lost, they can instruct them to remove it and thus prevent MITM attacks (even if the attackers control the server and/or the network).

    In the latter two cases the possibility to remove certificates from the trust store is crucial.


  • @ducktayp thanks for updating your branch. As the discussion here does not seem to reach a consensus anytime soon, I think I will start using builds based on your branch meanwhile.
    Maybe F-Droid could also provide builds based on your branch, so people wont need to go through the hassle of manually compiling it.

  • developer

    I have found a very good paper at http://android-ssl.org/: Rethinking SSL Development in an Appified World (DCSEC, Leibniz University Hannover). On the Web site linked above, they also provide a patch set for Android 4.3 which adds

    • CA pinning,
    • certificate pinning,
    • development mode,
    • logging,
    • pluggable validation strategies

    to the existing architecture. About deployability, they say:

    All our modi cations are implemented as part of Android’s Java Framework. A system update would thus be the most convenient way to make the new features of our system available to developers and users. All apps built from then on would use this update by default and would
    bene fit from our framework’s features. Existing apps’ binaries do not need to be modi ed to bene fit. However, it is possible for power users with root access to their device to install our modi fiations on their devices without having to wait for an official update or having to make major changes to their device, such as flashing the device.

    I don’t know about the status of deployment, but I strongly suggest all people concered about Android security to help merging these patches into the Android source code (ASOP, or otherwise at least the custom ROMs like CyanogenMod).

    Take action now to make Android a secure platform!


  • @rfc2822 I don’t think these changes will ever be merged into the AOSP tree, I also encourage anyone to try getting it into the AOSP, but Google has it’s own ideas sometimes 😕
    I actually know someone working in the research group of Matthew Smith, so I will ask him if there is any progress in getting it into AOSP.

    There is now another possible library besides the original MemorizingTrustManager if that is of any interest: https://github.com/commonsguy/cwac-security/blob/master/TrustManagerBuilder.markdown


  • @dschuermann That would be really good to know – if support for self-signed certificates and pinning is not going to be integrated in the near future, I think it makes the case for using the current ad-hoc solution stronger.

    The TrustManagerBuilder looks interesting, and potentially more configurable than MemorizingTrustManager, but more complex to use. From what I saw, it leaves the matter of the user interface for accepting “memorized” certificates up to the application (whereas MemorizingTrustManager has that functionality included).

  • developer

    @rfc2822 I don’t think these changes will ever be merged into the AOSP tree, I also encourage anyone to try getting it into the AOSP, but Google has it’s own ideas sometimes 😕

    Why? I haven’t even seen such a request in the AOSP issues.

    At least we could create an issue in AOSP, and contact AOSP, CyanogenMod and Replicant developers. If everybody who has commented here does a little bit of evangelization for this patch, we’ll already have a chance.

    Volunteers?

    PS: As far as my experience goes, ad-hoc solutions that work are never updated. People will just say “Never touch a running system” and “at least it works”, and any chance for improving the system is gone until the next iteration (i.e. the next mobile operating system after Android, which may learn from Android’s mistakes).


  • @rfc2822 Sry, maybe I was too negative.
    Besides the AOSP issue page, Google maintains an internal issue tracker with the real accepted issues etc. While Android is open source, it is not really developed in the open.

    If you want to get a patch into AOSP, put it on Gerrit and write to android-contrib.

    Regarding the SSL patches: As far as I know, they do not really solve the problem of pinning certificates based on user interaction. The idea is to pin certs on an app level in the AndroidManifest.xml.


  • rfc2822…

    FOOD FOR THOUGHT: Forget about MITM as an excuse for NOT correcting the self-signed certs issue.

    Most of us are after ENCRYPTION and couldn’t care a less if the NSA somehow manages to target you or some random hacker out of 300+ million computer users in America.

    I can use ActiveSync on android with a self-signed… and I can use Apple with a self-signed. We’re not worried about the extremely remote possibility of an MITM “hijacking.” Google has to worry about it. I don’t.

    TO ALLOW SELF-SIGNED on Android… you gotta substitute your own HttpClient interface.

    THIS WORKS on older Androids… I haven’t tested it on the newest.

    (PS>>> I’d set it up to handle any random TCP port that the user specifies during setup – not limit it to 443. <https://[url]:[port]/whatever. Also, place a configuration checkbox on the setup screen to ignore invalid certs so you can turn it on or off. Risk of MITM is assumed by the user.

    LATER, you or Google can integrate DANE TLS and that solves the public cert problem, altogether. FURTHERMORE, an MITM-hijacking with a bogus private-CA cert requires hacking the DNS server, FIRST. I’ve written my own CA that issues all of my certs – CA, subordinates, clients, S/MIME, etc.

    Everyone here has forgotten one MAJOR problem that’s not addressed by certificate issues. What is the issue, you ask? ANSWER: You forgot that the cellphone companies along with Google make backup copies of all your data (including your private keys?) to their own servers with the Android Backup API. So, if you want security… don’t use a cellphone!

    HINT #1: Why does Google Play require a GMail account? HINT #2: Why does Samsung register your Samsung device OTA with Samsung? HINT #3: Real world: Verizon and ATT can restore your phone and data when you sign a new contract with a new phone? ADVICE: TAKE THE HINT.)

    public class MyHttpClient extends DefaultHttpClient {
    final Context context;
    TrustManager easyTrustManager = new X509TrustManager() {
    @Override
    public void checkClientTrusted(
    X509Certificate[] chain,
    String authType) throws CertificateException {
    }

    @Override
    public void checkServerTrusted(
            X509Certificate[] chain,
            String authType) throws CertificateException {
    }
    
    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }    
    

    };
    public MyHttpClient(Context context) {
    this.context = context;
    }

    @Override protected ClientConnectionManager createClientConnectionManager() {
    SchemeRegistry registry = new SchemeRegistry();
    registry.register(
    new Scheme(“http”, PlainSocketFactory.getSocketFactory(), 80));
    registry.register(new Scheme(“https”, newSslSocketFactory(), 443));
    return new SingleClientConnManager(getParams(), registry);
    }

    private MySSLSocketFactory newSslSocketFactory() {
    try {
    KeyStore trusted = KeyStore.getInstance(“BKS”);
    try {
    trusted.load(null, null);

      } finally {
      }
    
      MySSLSocketFactory sslfactory =  new MySSLSocketFactory(trusted);
        sslfactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        return sslfactory;
    } catch (Exception e) {
      throw new AssertionError(e);
    }
    

    }
    public class MySSLSocketFactory extends SSLSocketFactory {
    SSLContext sslContext = SSLContext.getInstance(“TLS”);

        public MySSLSocketFactory(KeyStore truststore) throws NoSuchAlgorithmException, KeyManagementException, KeyStoreException, UnrecoverableKeyException {
            super(truststore);
    
            TrustManager tm = new X509TrustManager() {
                public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
                }
    
                public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
                }
    
                public X509Certificate[] getAcceptedIssuers() {
                    return null;
                }
            };
    
            sslContext.init(null, new TrustManager[] { tm }, null);
        }
    
        @Override
        public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException, UnknownHostException {
            return sslContext.getSocketFactory().createSocket(socket, host, port, autoClose);
        }
    
        @Override
        public Socket createSocket() throws IOException {
            return sslContext.getSocketFactory().createSocket();
        }
    }
    

    }

  • developer

    FOOD FOR THOUGHT: Forget about MITM as an excuse for NOT correcting the self-signed certs issue.

    AFAIK, there is no self-signed certs issue. It works fine with self-signed certs, and I recommend using them when you don’t want to get a cert from a public CA. Where is the issue?

    TO ALLOW SELF-SIGNED on Android… you gotta substitute your own HttpClient interface.

    You mean: to allow self-signed certs in DAVdroid. To allow them on Android, you have to import them like described on the DAVdroid home page.

    Again: Where’s the issue?

    Also, place a configuration checkbox on the setup screen to ignore invalid certs so you can turn it on or off. Risk of MITM is assumed by the user.

    SSL without certficate checks (this is something other than allowing self-signed certs) is not only absolutely useless but actually dangerous because one might think data are transmitted securely. Would you like to have a “Disable brakes” switch in your car? I wouldn’t. If you don’t care about security, use HTTP – it’s exactly as secure as HTTPS without certificate checks.

    You forgot that the cellphone companies along with Google make backup copies of all your data (including your private keys?) to their own servers with the Android Backup API. So, if you want security… don’t use a cellphone!

    For info about the Backup API, please see here: https://developer.android.com/google/backup/index.html

    »In order to use Android Backup Service, you must register your app with the service to receive a key that you must include in your Android manifest.«

    DAVdroid is not registered with the Backup API; it’s data won’t be stored. Calendar and contact data may be, but that’s not our responsibility and I can only advise to not use that service.

    HINT #1: Why does Google Play require a GMail account?

    Question #1: Why do I use CyanogenMod without GApps, thus without Google Play? 🙂

    HINT #3: Real world: Verizon and ATT can restore your phone and data when you sign a new contract with a new phone? ADVICE: TAKE THE HINT.)

    Can you restore a DAVdroid account? If the answer is yes, you would have to erase this spying firmware as soon as you get the phone and replace it by a free Android flavour (CyanogenMod, Replicant). I also strongly recommend to have a look in the source code; for instance, you might audit the Backup API and then tell us if it really does what it should (and not more than that).


  • SSL without certficate checks (this is something other than allowing self-signed certs) is not only absolutely useless but actually dangerous because one might think data are transmitted securely. Would you like to have a “Disable brakes” switch in your car? I wouldn’t. If you don’t care about security, use HTTP – it’s exactly as secure as HTTPS without certificate checks.

    I disagree here. Using plain HTTP leaves you open to interception by any passive attacker, e.g. someone sniffing the local coffee shop’s open wifi network. Using HTTPS without certificate checks at least requires an active attacker MITM’ing your connection before your data is exposed. Just like most physical locks are easily breakable, that doesn’t mean they are completely useless.

    At this point any implementation at all would be a welcome change; for now most friends & colleagues that I managed to convert away from google are stuck syncing davdroid over plain HTTP, because importing a custom certificate in Android is non feasible for the average user (see many of the comments above).


  • AFAIK, there is no self-signed certs issue. It works fine with
    self-signed certs, and I recommend using them when you don’t want to get
    a cert from a public CA. Where is the issue? <<<

    YES, THERE IS A PROBLEM–IT DOESN’T WORK (even after import). A server certificate,
    signed by a PRIVATE RA or CA returns an error on JellyBean AND REFUSES
    TO CONNECT – IMPOSSIBLE. Also, Subject Alt Names aren’t recognized.
    “I/O error… hostname,… blah, blah, blah”. Self-signed includes ANY
    possible cert in a chain of trust. I think Your definition of “self-signed”
    means a simple test certificate which is signed by its own private key. Again,
    PRIVATE RA/CA certificates do not work. Typical error codes from the
    SSL libs might be 18 (classic self-signed test certificate) or 19 or 20
    or 21 (private CA/RA). Use “openssl s_client” testing with various cert
    configurations for examples. (How do I know? I wrote my own CA. Been
    operational for a couple of years. Don’t have a problem with anything
    else. Only DavDroid. (Hence, the code sample – generally, this is how
    ActiveSync and browser libraries handle it.)

    ==========================================

    You mean: to allow self-signed certs in DAVdroid. To allow them on
    Android, you have to import them like described on the DAVdroid home
    page. Again, where is the issue? <<<

    Importing my certs doesn’t work… for the reason described – both in
    the text and in the code – AND, as described in the previous paragraph.
    I’ve spent several FRUSTRATING hours trying everything under the sun to
    make it work.

    ==========================================

    SSL without certficate checks (this is something other than allowing
    self-signed certs) is not only absolutely useless but actually dangerous
    because one might think data are transmitted securely. Would you like to
    have a “Disable brakes” switch in your car? I wouldn’t. If you don’t
    care about security, use HTTP – it’s exactly as secure as HTTPS without
    certificate checks. <<<

    Who cares? I’m an intelligent user. I want crypto… I assume my own
    risk. Do you think you or your program knows better than I if I should
    receive an error or not? Does it read my mind or employ some miraculous
    Artificial Intelligence code? No.

    ===========================================
    »In order to use Android Backup Service, you must register your app with
    the service to receive a key that you must include in your Android
    manifest.«

    DAVdroid is not registered with the Backup API; it’s data won’t be
    stored. Calendar and contact data may be, but that’s not our
    responsibility and I can only advise to not use that service. <<<

    Geez… Do we now need to discuss the cellco company practices? I only
    noted them because they are an established FACT. What’s that got to do
    with crypto? I’m only MINIMIZING THE CRAP regarding this issue: OH
    NO! WE GOTTA WORRY ABOUT THE AUTHENTICITY OF THE REMOTE SERVER!"

    This subject will go on forever and consume more airtime than even Ed
    Snowden is getting.

    ========================================

    Question #1: Why do I use CyanogenMod without GApps, thus without
    Google Play? 🙂 <<<

    How many of your users have the technical ability to root their
    phone??? .000001%??? Ad nauseum.

    HINT #3: Real world: Verizon and ATT can restore your phone and data
    when you sign a new contract with a new phone? ADVICE: TAKE THE HINT.)

    Can you restore a DAVdroid account? <<<

    If the answer is yes, you would have to erase this spying firmware as
    soon as you get the phone and replace it by a free Android flavour
    (CyanogenMod, Replicant). I also strongly recommend to have a look in
    the source code; for instance, you might audit the Backup API and then
    tell us if it really does what it should (and not more than that). <<<

    YES! The mentioned carriers can restore calendar, contacts, email,
    files, misc phone settings, etc. Online backups are now defaults…
    most people are clueless.

    They are using their “branded” implementation(s) of the Backup API to do
    it… back by popular demand of the spy grid.

    I kid you not. Would you like to know why I dumped my cell phones
    almost 3 years ago??? Have you checked your phones for military IPs
    thru VPN tunnels??? (I have. The phone was shut down the very next
    day. The local salesman at the local sales office had EXACTLY the same
    problem – I found that out because I checked.)

    People don’t even realize that the 4G backbone is generally owned and
    operated by the DOD. In reality, the carriers only own the local access
    towers. The carriers can even use the DOD (DISA) to do billing…
    Another tidbit people don’t know. I have the military documents (under
    FOIA… and, now, these docs are available publicly).

    LIKE I SAID,… This subject will go on forever and consume more airtime
    than even Ed Snowden is getting.

    ==================================================================

    *** WE NEED CRYPTO TO OUR PRIVATE SERVERS WITH PRIVATE CA’S *******
    Creating the subclassed HttpClient stuff will allow that to happen as
    described, previously.

    ==================================================================


  • It seems like emotions are flying high. I recommend a practical approach.

    Various ways of managing certificates from within DAVdroid might be feasible in theory, but in practice it’s the kind of thing that takes a bunch of time. If I were developing for this project, which I’m not, I might prefer to focus on other areas of the code base.

    Certainly many of us have self-signed certificates that we make and import into Android and using those we can use DAVdroid with encryption as desired. This is a simple process, which isn’t to say it’s easy, but if you are trying to do the same and failing, please see the documentation and let us know where things are going haywire.

Similar topics