Thanks for the suggestion!
Would you mind sending a merge request? https://gitlab.com/bitfireAT/icsx5-website/
The actual procedure to add a certificat is too much complicated.
I tried to access to my owncloud server on a mutualised server for using with mirakel (tasks manager) without success.
All of us are not developper!
Please add the option to make it simple and accept the help of dschuermann.
Do you know if MemorizingTrustManager works with sync adapters / whether sync adapters can create a GUI?
@rfc2822 Yes, I think it should work. It will show a notification when the certificate can not be validated including a pending intent which results in the dialog provided by memorizingtrustmanager.
Hi, the same for me, self-signed certificate .crt, cannot get DAVDROID to work with this certificate “Cannot verify hostname”. The news app for owncloud let me bypass this hostname verification, and i’m very happy with that.
+1 to warn the user, but let him the freedom to accept or not this unsecure way (in my case, the contacts and calendar are public anyway, so I don’t need a secure solution, I need a Working solution.)
I just paid for Davdroid, and can’t use it
@rfc2822, as an aside, https does not cause any noticable performance loss over http. That’s an old issue that is non-existent now
@ainola I strongly advise to use HTTPS wherever possible for privacy reasons, but how shall it work that SSL doesn’t use resources? For every connection, there has to be a key exchange (preferably with PFS) which uses CPU and network resources, while the symmetric block encryption is quite cheap (but not non-existent).
@rfc2822 I did not say no resources, I said negligible. http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose will detail the issue.
This is pretty off-topic though, I apologize for de-railing. Look forward to being able to use this software when I can pin my self-signed certificate.
@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.