AndroidCaldavSyncAdapater
AndroidCaldavSyncAdapater copied to clipboard
gggard
Enable SSL
When using https connections the app used the "trust all" method for host certificate verification. While this is good for testing environments this should be optional.
I've created a new flag in the account's user data which specifies whether the "trust all" method should be used or the installed device root certificates are used. The option can be set during account creation and only shows up when the URL starts with https.
"TrustAll" is dangerous option. It reduces HTTPS to nothing.
Option to remember certificate is much better. Also, it is dangerous to blindly trust certificates stored in device. So there should be warning when server certificate is changed. But this warning may scare too much users, so I guess it is better to check parent certificate (the one who signed current certificate) and yell when this authority changes.
Long story short: Ask first time, remember certificate and yell when it is changed.
we have a free, open source library currently called OnionKit that makes it easy to implement strong HTTPS. You can find the relevant classes here: https://github.com/guardianproject/OnionKit/tree/master/libonionkit/src/info/guardianproject/onionkit/trust
We're also happy to help you get OnionKit integrated into this app. We're regularly in our IRC room irc://irc.freenode.net/guardianproject, or also #guardianproject on oftc.net. I'm _hc in IRC and [email protected] for email and xmpp.
Is it possible that this tool does not support SNI ? I've got a little VPS with some tools installed and owncloud. The owncloud client itself has an issue with SNI and I'm not able to use the android app until this is fixed. Carddav sync is functional but the last bit I need to quit the great google sync is the goddamn calendar. So, I have no problems accessing my owncloud calendar from lightning within thunderbird, but with the AndroidCaldavSyncAdapater I only get the message "Invalid server answer, check URL."
Nothing else.
When you need a test accound just give me your email address and I'll send you one.
@qwc which version are you using? ssl will be supported fully (some day). but for the moment, there has to be done basic work to get the sync adapter working.
what about setting certificate checking 'on' by default, without a check-box, at least for now? that seems like the safest option.
if there are a few people who use self-signed certificates, then they can install the ca cert on their phone. if they rely on self-signed certs and have a version prior to 4.0, which doesn't allow installing ca certs, then why not leave a special branch for them to compile for the time being, if they need that option.
it seems insecure to wait until interface designs and code structure have been considered then implemented before enabling this feature by default.
@qwc your server doesn't respond as expected. The client receives the response code 403 "forbidden" and i can't figure out why. i do not see the differences.
I don't know exactly what's the problem here. What I know is that some ssl java libs do not support SNI, which one are you using? The owncloud app itself has problems with my server too, and I can't use that app currently until the SNI problem is fixed.
On the other hand, today I checked my apache config and found out that I had SNI configured even for the main domain. So I edited that, restarted that sucker and I've still got a problem trying domain.tld/owncloud/, dammit! Maybe that whole bunch of ssl libs that is used in all this apps just doesn't support the current standards - and I won't lower the security configuration of my server - so I'm stuck here...
Interesting that the CardDav app from https://play.google.com/store/apps/details?id=org.dmfs.carddav.sync has NO problem synching my contacts with the same owncloud. So what's wrong here? Maybe ask that fellow which libs he is using... But as long as he doesn't answer my question if his caldav app supports SNI and the latest SSL implementations I'm stuck again, because I won't buy an app that does not work.
a proper ssl implementation is intended some day. i see that your server responses with Strict-Transport-Security:max-age=31536000 Expires: 19.11.1981 08:52:00 GMT this looks unusual to me
I'm using both CardDAV-Sync and CalDAV-Sync apps and they do work fine with SNI. I have Davical on main domain on Lighttpd 1.4.31-4 (Debian). Lighttpd's SSL config looks like this:
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/ssl/startssl.com/main-domain.cert+priv.key"
ssl.ca-file = "/etc/ssl/startssl.com/sub.class1.server.ca.pem"
}
$HTTP["host"] =~ "^other\.domain$" {
ssl.engine = "enable"
ssl.pemfile = "/etc/ssl/startssl.com/other-domain.cert+priv.key"
ssl.ca-file = "/etc/ssl/startssl.com/sub.class1.server.ca.pem"
}
@qwc your server is configured to keep-alive the connection for 5 seconds and a maximum of 99 reuses. can you remove this restriction?
@timoberger Strict-Transport-Security:max-age=31536000 That would be one year. Maybe a little bit high, but not a problem atm. Expires: 19.11.1981 08:52:00 GMT This just means, that this content is already expired and that the browser or the client has to load the content from the server, that is not an error. I have not configured mod_expire, so the server just sends something in the past... Yes my server was configured for low keep-alive and 99 reuses, the configuration is just some weeks old and mostly default (arch linux) and my main focus was on security. I've just changed that to more open values...
I'll test again today, maybe some configs of that changed something? o.O
it seems that the android-httpClient uses the ip-adress to connect to the server: https://serverip/further_path instead of https://servername/further_path within the http-protocol the correct server name is used Host:servername:port but apache already routed the request to the vhost configured for the ip, so the host-header is being ignored.
@timoberger okay, that means i should create a vhost with the IP of the server to get that working correctly? o.O
@qwc honestly said, i don't know what this means. a) httpClient should not have used the ip. b) there should be no difference whether the request is created with the ip or name, as long as the http-header is set correct. check this: connect with any browser to your ip and you will receive the same status 403 as mentioned here https://github.com/gggard/AndroidCaldavSyncAdapater/pull/83#issuecomment-27171837
wtf is wrong here?! I've got carddav-sync working without a problem...
Okay, after some work I got the owncloud instance on the IP running. Now it syncs! YAY! Okay, I take everything back what I said - It IS possible to use my owncloud instance now. Although with some very strange workaround... I suggest you take a look at the ssl things none the less.
The only little annoying thing I get is a error on every sync saying: "Caldav sync error (caldav) unknown events in ICS"
@qwc there seems to be an event within your calendar that causes this error. i am planning to move to "alert messages" into a statistics section within the account settings. there i can add more debugging information.