@xyzzy said in Support for SSL client certificate and Basic/Digest at same time:
I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.
It doesn't remove anything, but it doesn't use username/password from the URL. At the moment, DAVdroid unfortunately only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.
BTW, I cannot reply using firefox 59.0.2. In the webconsole I get:
I'm typing this reply with Firefox 59.0.2 (MozillaFirefox-59.0.2-lp150.1.6.x86_64 from OpenSUSE Leap 15 Beta). If you can find out what the problem is, it would be kind if you could report it to NodeBB directly. We're currently using NodeBB 1.8.2 (latest release) without modifications.
I assume you mean 1.11?
Are you absolutely sure that this is caused by DAVdroid and not a relation only in time (like a new certificate on the server)?
I'm asking because there have not been any changes in certificate handling and we didn't see this behavior in our tests.
If you're sure that it's caused by DAVdroid: Which cert provider are you using? Is the cert still valid? Can you provide more details and/or steps to reproduce?
@rfc2822 Thanks for the hint! The automatic conflict resolution didn't worked in our project, since there was a dependency in cert4android, that we hadn't in our module. After adding com.android.support:cardview-v7 as dependency to our module, the conflict resolution works, now.
Hence, the problem is solved without updating cert4android. Thank you very much!
The connections never got past TLS negotiation so there is no chance that a well-known URL or a redirect could have been given by the server and there are none defined on that 12345 port URL hierarchy anyway. Also there are no related SRV records in the DNS.
I tried again and looked a bit further into the data streams. It looks like the server configuration had limited cipher suites so that no common suite was found between DAVdroid and the server on port 12345. The client tried twice, both times ending in the server sending a TLS alert due to cipher suite mismatch. After that I see a DNS SRV query for _carddavs._tcp.server.name.here.invalid which is answered with no such name (nxdomain). Immediately after that traffic to port 443 starts and the note about invalid server cert on port 443 is shown. The cipher suite configuration on port 443 has been compatible enough all the time, so a handshake to that port goes far enough to return the certificate.
I loosened up the acceptable cipher suite list on the server on port 12345 enough to include a cipher suite sent by DAVdroid in the client hello and now it works. Pretty weird / misleading user experience.
Anyway thank you for your work on DAVdroid! Not having native DAV synchronization is a significant deficiency in Android, DAVdroid seems to be filling that gap nicely.
I think that you can switch back to your old notation using 26.+ (if you really want), since you've added the new Google maven repository.
However, you have the same "problem" with the build tools. And for both cases, Android Studio should notify you in case of updates. Unfortunately, there was no notification for the new maven repository.
I have now reproduced the problem on Android 7.0 in the SDK emulator image:
a sample ECC certificate (secp384r1) does not work on Android 7.0, but
this ECC certificate (secp384r1) works with Android 8.0
However, I couldn't see any differences between DAVdroid versions. I have tested DAVdroid 188.8.131.52 and DAVdroid 1.2.2 with Android 7.0, and it does't work, too (as I have suspected).
So, in my tests, this is the Android 7.0 bug which has been fixed in Android 7.1 and is not related to DAVdroid.
I don't have an explanation why different DAVdroid versions have behaved differently in your environment / testing setup.
@mrtuple Protecting against MITM with accepted certificates (either manually or by PKI) is not within the scope of DAVdroid. It would also mean that Basic auth would have to be disabled completely.
TLS is already a way to protect the connection – in my opinion, there's no need to implement "TLS in TLS". "Rogue IT staff" could see all private data (= not only passwords, but also events, tasks etc.) even when using Digest auth. It would also mean that Web-based logins over TLS (like every online bank uses it) is insecure.
But now this is a discussion about whether TLS connections are secure and whether Basic auth is evil, and I don't want to make these topics a discussion about DAVdroid.
Update: Maybe we should create an off-topic / general discussion forum for such things? What would you think?
So the issue indeed seems to be with Android 7 in some way, depending on how you configured your server, I'll just copy a github comment i accidentally made to the wrong place.
I can confirm that the f-droid version was affected, the offending nginx config is this:
other relevant ssl config lines:
So with that option commented out it's working fine, I'm on 184.108.40.206-ose from f-droid and android 7.
Apparently Android 7 supports only up to secp256r1, this was supposedly fixed in 7.1.1.
Aside that, a bit of a rant, why are gitlab issues not enabled and instead this forum is used as a bug report tool? I have to create yet another account and wade through 5 google captchas just to write this.
@phy25 said in does not send requests at all to my host:
Maybe you can try entering https://example.com/webdav/user in your browser to see whether it works. Seems like a SSL error, and maybe you can check your network (try different WiFi / mobile data) and the server SSL configuration.
SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
It works fine in the browser, as far as I can tell (see also first paragraph of my post above for a bunch of other urls that work).
Also when I curl:
$ curl -i https://user:email@example.com/webdav/user/caldav
HTTP/1.1 200 OK
Date: Tue, 21 Mar 2017 19:53:43 GMT
Last-Modified: Tue, 21 Mar 2017 11:24:31 +0000
PRODID:-//Radicale//NONSGML Radicale Server//EN
@jeronemo said in Untrusted Certificate at Account Setup:
Yes, but why does it show me then this certificate? Can I trust it?
Because it cannot be trusted automatically. You have to verify it to know whether you can trust it. Please ask your admin (or whoever has used CAcert for your server) for more information.
@Alela It seems that the SSLLabs Android ciphers refer to the default browser (Chrome?) on those platforms, which has a separate TLS stack which is not the system stack.
DAVdroid can only use the system stack. You can find a list of cipher which is supported by the Android default TLS stack in the SDK docs: SSLEngine (Default configuration for different Android versions).