Accept self-signed certificates


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


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

    Emotions aren’t flying high… but the nonsense about “MITM HIJACKS” is really taking a lot of time. THE CODE ABOVE, MODIFIED FOR PURPOSES OF DAVDROID, along with a global search/replace text of the DefaultHttpClient (or whatever) library calls will yield correct results.

    To understand the REAL nature of the problem… read the DOJ Appellate Brief against Lavabit for contempt in the Snowden fiasco. The DOJ Brief is a confession of everything that Snowden said: AND BEYOND ANY DOUBT, shows you that the entire “PUBLIC” (not private) cloud computing crypto is compromised under “general warrants.”

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

    http://stackoverflow.com/questions/1217141/self-signed-ssl-acceptance-android
    AGAIN: REITERATE: ALL MAJOR PUBLIC WEBSERVERS ARE ALREADY COMPROMISED – US vs LAVABIT, Decided April 16, 2014. It is a confession that points out that all major internet providers private keys have been turned over to whomever. Private certificates are the only secure ones, today. End of story.


  • @ddblack, do you really think screaming at the dev is going to get things done? Please try to remain civil. And remember, you can always fork it 😉


  • Not screaming. How else do you EMPHASIZE THE IMPORTANCE of something when everyone wants to pollute the issue with uninformed (or ignorant – definition – “ignore” indisputable facts) rhetoric. I’ve been around the block as a developer for over 30 years.

    I don’t want to fork it. I want to be able to steer anyone who asks for a reliable, easy-to-use caldav/carddav client to DavDroid. Today, I say: Buy an Apple.

    AS YOU CAN SEE… This topic has been bounced around since last year! Apple can optionally ignore cert errors, web browsers can ignore cert errors, ActiveSync can ignore errors… But, DavDroid can’t. ALL competent business servers who have a Microsoft Server have their own PRIVATE CA. I don’t know any public CA that allows you to issue your own certs. Why??? ANSWER: Someone wants a copy of the keys. They don’t want you to create your own keys. (In addition, this compromised oligarchy of CAs is the reason for development of BOTH DNSSEC and DANE TLS.)


  • @ddblack please, focus. You are mixing up many different problems.
    As you probably know, your proposed code disables hostname verification. This is definitly the wrong approach. It is extremly easy to play MitM with your code in place. What we need is certificate pinning per davdroid account!


  • @ddblack I think the use of all-caps and name calling (“uninformed”, “ignorant”), is best avoided. On any issue, even if you feel you’re definitely right and others are wrong, being dismissive is counterproductive. We’re trying to work together on these issues, after all.

Similar topics