Preemptive authentication security



  • First: thanks for creating DAVdroid, I'm purchasing it for my family's android devices and look forward to using it.

    During my setup, I may have found a small security concern.

    I've been having trouble making DAVdroid work with lighttpd authentication and it turns out that DAVdroid is using a preemptive authorization header on its first connection to the webserver. The only preemptive authorization capable on a first connection (without pre-shared secrets or PKI) is HTTP Basic.

    When lighttpd is configured to use HTTP digest, it replies with a 400 - Bad Request, this kills off of the DAVdroid discovery process. I think lighttpd should be responding with a 401 - Unauthorized status and a WWW-Authenticate header line - this concern I'll take up with the lighttpd author - it isn't a DAVdroid issue. I guess I'm just trying to give some background... debugging the aforementioned issue is how I stumbled upon this concern.

    It is concerning (I think) that DAVdroid is sending the (essentially cleartext) authentication data on its first connection, before determining that the server administrator has chosen such a weak authentication mechanism. DAVdroid seems to do this only over HTTPS so in theory it is not a clear text transmission, but given the use of MiTM SSL proxy configurations in the real world. Preemptive authentication on the first connection seems (IMHO) to be a dubious approach.

    It also turns out that if the first connection over HTTPS results in a 301 redirect, the preemptive basic authentication request line is
    replayed across HTTP. See attached log showing both cases...


  • developer

    Thanks for your suggestion.

    1. DAVdroid only does preemptive authentication on HTTPS requests (maybe except for redirects, but this is not intentionally).
    2. I don't understand the argument of MiTM proxy configurations, because in such a case, it doesn't matter whether the credentials are sent pre-emptively or upon a 401 response. Also, this is not a DAVdroid problem, but a PKI problem, and it can be solved by distrusting all certificates in DAVdroid settings (so that you have to verify and accept every single certificate).
    3. You're right, preemptive auth probably shouldn't be done when redirected to HTTP. I will have to check that. Of course, a patch would be welcome :)

  • developer

    After having thought about it again:

    1. Authentication, and so pre-emptive authentication, is only done for host names with the same domain as the user-given URL.
    2. Pre-emptive auth is only tried when the user-given URL is HTTPS.
    3. So, after receiving a redirect response, there are two possibilities:
      • the new host has the same domain – In this case, the server explicitly requests to try a HTTP host on the same domain. This is considered to be a case of "server administrator has chosen such a weak authentication mechanism", as you have called it.
      • the new host is on another domain – there will be no authentication


  • @rfc2822 said in Preemptive authentication security:

    1. I don't understand the argument of MiTM proxy configurations, because in such a case, it doesn't matter whether the credentials are sent pre-emptively or upon a 401 response. Also, this is not a DAVdroid problem, but a PKI problem, and it can be solved by distrusting all certificates in DAVdroid settings (so that you have to verify and accept every single certificate).

    If the backend server uses digest authentication, then there is at least modest protection against against snooping for passwords by rogue IT staff. This modest protection evaporates when the first connection "rolls the dice" hoping that basic auth is used.

    When the choice of having or not having Internet access comes down to having to use a third party cert through a proxy most people will do this. It still seems strange to hope the server is poorly configured (basic auth vs digest, imho) and transmit auth in the clear.


  • developer

    @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?


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.