even a simple XML (or anything else) export/import would be great.
I have 5 different Owncloud accounts and 3 devices. it’s a little bit long to configure caldav+carddav for each combinaison…
@rfc2822 There are many well documented political, legal, practical, and generally smart reasons to broadly use encryption. Even if you don’t find any of these compelling, countless numbers of us do.
@dper I don’t get the point. I strongly recommed encryption, you strongly recommend encryption - so?
@rfc2822 This is you recommending against it…
- If your data is public and you don’t need security for your data (including name/password), why don’t you use HTTP instead of HTTPS? This will save your client’s and server’s resources.
But perhaps I misread. Sorry.
@dschuermann How does fingerprint checking of MemorizingTrustManager work? I coudn’t find it in the Wiki. I also read that host names and expired certificates are “not supported”, what does that mean? Will it ask for certificates that are valid because they’re in the Android trust store?
At the moment, I think that an independent app that provides a certificate verification service would be the best solution. GUI would go into this app, and it would be separated from DAVdroid.
DAVdroid could check if this app is present and if it is, the service will be used as a TrustManager. If it is not installed, the default TrustManager will be used and DAVdroid will still work (but without “custom certificate verification”).
What do you think about this?
Fingerprint checking works by knowing the fingerprint from the certificate deployed on your server and then manually comparing it to the one displayed by MemorizinTrustManager. If they are the same it is your certificate and not some man in the middle cert.
The wiki is really not that helpful. Someone should provide more information…
“If it encounters an unknown SSL certificate, it asks the user whether to accept the certificate once, permanently or to abort the connection.” (https://github.com/ge0rg/MemorizingTrustManager/wiki)
This means: If the cert is not known to Android (not in Android’s cert store), MemorizingTrustManager will show the dialog requesting user interaction.
If that dialog pops up, the validation of the cert is not checked. If the cert is known to Android, the library does not come into action and everything is done as usual by the Android OS (hostname check, validation check etc…)
Sry to post another message here. I just read your other comment.
It will be difficult to code a secure interaction between davdroid and another application that should only be used for verification.
The library is not big, so why not including it and providing a setting to enable this custom verification code?
FYI, Android 4.4 now displays a very obtrusive warning when a self-signed cert is imported into user storage (to warn the user that it could have been installed by a third party to snoop on all SSL connections).
Implementing an independent cert management app just for DAVDroid is overkill IMHO, when the much simpler solution proposed by dschuermann exists (manual fingerprint verification on first contact). owncloud News Reader, the owncloud app, CalDAV Adapter for Android etc. all use this solution, and it works fine without any security drawbacks.
@dschuermann @brb-at I’m not talking about a cert management app “just for DAVdroid” but for all apps that want to allow self-signed certificates without importing them to the key store.
My opionion is that (custom) certificate management is a very delicate software part because it’s security-related. Any mistake can render the whole encryption useless, and repeated public code review and testing is needed. So, I don’t like the idea that every app contains its own certificate management, all in different versions and flavours, some never updated and with security-relevant issues that have been fixed in the library’s master tree for a long time. People also won’t review the certificate management code of the apps because they’re interested in the core functionality.
Also, I don’t consider MemorizingTrustManager in its current version as a “library” because I only see some files that I can merge into DAVdroid. That’s nice and I appreciate the work, but there’s too little task separation for me. I can’t update the trust manager lib just by replacing a .jar file or something like that – that would be the minimum if it’s not a standalone application whose service I can call.
I’d also like to hear your opinion about these points:
These features could be provided if a cert management app would provide a verification service that can be called not only by DAVdroid but by all apps which need this functionality (Owncloud apps, CalDAV Adapter etc.). This app could have a Settings screen where the user can select whether to trust default CAs.
Just in case that such a service would make sense, I’d contact the author(s) of MemorizingTrustManager and ask them about their opinion. Maybe they can create the app with the service and DAVdroid and the other apps could call it (if available, else use the default Android handling). In this case, updating the TrustManager would also be sourced out.
Of course, I’d like to get this thing done with as little work as required – but I fear that this issue just can’t be done with little work.
@rfc2822 Please don’t get me wrong. I understand your concerns, but what you describe is one of Android’s inherent security problems. Because there is no such thing as a real package manager, every application bundles it’s own version of a particular library. This leads to many different versions of the same library found in the wild. This is indeed a security concern but on a much broader scale.
I can point you to my own findings as an example (http://sufficientlysecure.org/index.php/2013/10/29/google-play-billing-hacked/). Still there are many apps in Google Play which were not updated and still suffer from the security holes I found.
And I am not talking about real problems like the broken RNG which need to be fixed by every application via some code found on their developer blog
Stopping my rage now and coming to the problematic conclusion
Regarding 1 and 2) Yes, in my opinion pinning in combination with MemorizingTrustManager would be perfect. If you don’t trust any certs in Android’s store because of three letter organizations, you could at least do TOFU (trust on first use) via pinning.
I have not evaluated it in detail, but we could also look at StrongTrustManager by Guardianproject (https://guardianproject.info/code/netcipher/)
What you propose goes beyond the scope of what a single app can reasonably provide IMO, especially since other apps need to support it explicitly.
This sounds more like a feature that a custom ROM could include - a small core subset of default CAs is enabled, with strict checking and the option to import your own certificates without getting the 4.4 warning. This could be completely transparent to apps, and pinning certificates could be done from the system settings of the ROM.
That being said, I cannot use DAVDroid on 4.4 currently without either having a constant warning in the notifications, or adding my cert directly to the system cert storage. Both are solutions I’d rather avoid, and just accepting/pinning the self-signed cert on the first connect by davdroid (after fingerprint verification) should at least be an option.
As for package management: It all boils down to the focus on apps, and that those should just work - so every library etc. has to be included in the app itself. Having a package management, while being the way to go from a security perspective, has the side-effect of rarely updated apps possibly breaking on a library update, and that is something the average Android users targeted by Google don’t want to deal with.
I think writing a second app to properly handle certificates would be awesome, but it sounds like a gorilla of a thing. And even if you did, if other apps wanted to rely on it, you’d have introduced potential versioning problems. So if it were me, I’d say you’re stuck with a mediocre solution like accept & pin or import the cert to the phone.
As far as complaints about the constant warning in notifications, that is a bug with Android, not with DAVdroid. It gives you the triangle of doom once every reboot, but otherwise it leaves you alone. So on the one hand it looks scary, but on the other hand you can document that and users will adjust. Far from ideal, but in my view not a disaster, provided certificate installation and subsequent warning are clearly documented with screenshots and such. And hey, who knows if the Android devs will fix their bug? It could happen.
Just my few cents to this topic:
a) I also like to keep stuff in the places where they belong. Simply trusting untrusted connections is a bad thing and should not be made available. You simply compromise the connection because you simply allow man in the middle attacks. So the core feature that is missing is the trusting of a certificate and that is something that simply does not belong in this app. And I am really wondering why this isn ot part of the browser in andorid. And I didn’t find an app for it. (There was an app but that was build to accept man in the middle certificates when using a proxy and it simply required a poxy! WTF???) So it is really a doing of google and not of the maintainer of this application.
b) The solution is quite simple in my eyes - once you found it: Just export the (public key of the) certificate in DER Format as .crt file and put it on your webserver server. (The export can be done with firefox on a pc easily - just open the page, click on the lock and view the certificate!) Then open the certificate in the browser of your device and android directly asks you for the name which should be used to install it.
But when we are talking about android: At the moment I am a little confused. It seems that android is thinking that these certificates are client certificates used to authenticate the system/user? That is the reason that you are forced to protect your device e.g. with a pin! And that is simply nonsense in my eyes. I think that the google developers missed something here and simply produced something crazy (Maybe I am wrong but that is what I understood so far!)
@kneitzel As you say, the way Android handles certificates is decidedly stupid. It should be simple enough to import a certificate and not deal with creating a PIN or getting warning messages. Your explanation is reasonably accurate, I think, though in some sense it doesn’t really matter why Android handles certificates so badly, because regardless of the reason, this is the current state of affairs.
so I finally bought a STARTSSL class 2 certificate for the wildcard *.perso.fr, now it’s “green” when I connect with my browser
but still I have this annoying message when trying to connect DAVDROID: “cannot verify hostname”
Note : I imported the class 2 client certificate of STARTSSL into android cert manager:
Did I miss something?
@kneitzel No one is asking for DAVdroid to “simply trust untrusted connections”. We generated the certificates on our servers, and know their fingerprint. Confirming the hash on the first connect and pinning the certificate is not a security issue - if someone tried a MITM, the fingerprint mismatch will make it obvious.
Yes, I saw that a little later when I checked out the library linked. It shows the certificate in a way people are used to from browsers on computers. But if I understood it correctly, the trust is a per application trust and not a trust of a certificate on the whole device? So yes: I see that it is a workaround and I can understand the request.
But I am not sure that implementing such a workaround is required because it is straight forward to import the certificate on your device. (Doing such workarounds might seem to be a nice thing for a user but the other side is the developer who simply has to maintain the code which simply get more complex with such workarounds. And that includes a lot of things e.g. development time to create, test and maintain it, greater chance for a failure/bug, …) So I would prefer to stick to an installation of the certificate. But of course that is my personal opinion only.
Instead of such an workaround I would like to have an application that gets a certificate and installs it. That way users could easily install required certificates.
@sulliwane: Are you sure that the certificate is installed correctly? You show the certificate on blog… but you connect to cloud… And you talked about a *.perso.fr certificate but it seems that there is no cloud.perso.fr at all (or I misspelled something when checking it.)
@kneitzel Yes, the trust is per-application.
And as mentioned above, importing my certificate to the user storage is a straightforward solution in Android 4.3. With the upgrade to 4.4, Android permanently displays a warning when importing such a self-signed cert, both in the notifications and in the settings until you remove the cert.
Now when I try to connect with DAVDROID, I have the error “Cannot Verify Hostname”.
There already is STARTCOM cert in the system trusted credential (you can check on your droid) but still I added another one.
Could it be related to the wildcard cert, or to the CA cert imported in Android?
@sulliwane: Maybe it is a name resolution error? Just wondering, because I cannot get an ip for cloud.perso.fr (Or is it just an server in your internal network?)
And the wildcard certificates work fine here. I have a certificate (self signed) for *.konrad-neitzel.de and it works fine for www.konrad-neitzel.de.
So I am running out of ideas regarding your problem,.
@brb-at: This warning is such a stupid thing. I just imported the certificate of my server and not my “CA” certificate. So yes: I know this annoying message and I also know all the discussions about it and that google simply wants to keep it this way.