This is probably off-topic now so marking as such. On 29/06/2015 14:29, André Warnier wrote: > Mark Thomas wrote: >> On 26/06/2015 19:37, Mark Thomas wrote: >>> On 22/06/2015 11:56, Mark Thomas wrote: >>>> On 22/06/2015 09:39, Mark Thomas wrote: >>> <snip/> >>> >>>> Prompting for authentication in response to an untrusted certificate is >>>> bizarre to say the least. >>>> >>>> Microsoft generously provide MSDN subscriptions for Apache committers >>>> which is why I have the various OS's to hand to test this. The >>>> subscription also comes with tech support. I'll open an incident. It >>>> will be interesting to see if things have improved since I last tried >>>> raising bugs with Microsoft (I filed so many bugs with MS Office and it >>>> took so long for MS to fix them that I hit the limit of issues MS would >>>> let me have open in parallel). >>> Support incident raised. I await the response with interest... >> >> Oh dear. Not a good first response from Microsoft. >> >> First they tried to say that the WebDAV server must be triggering the >> prompt for credentials which would be difficult to say the least given >> that the TLS connection is never established AND that the WebDAV >> endpoint was configured for anonymous access. >> >> Then they tried to suggest that I contact Apache for support. Lets just >> say that suggestion got shut down rather quickly. > > Like, "I /am/ Apache support" ? :-)
Pretty much. Once I'd stopped laughing. >> Finally they went back to trying to suggest that the server was asking >> for credentials. A rather circular discussion followed that demonstrated >> that the support person had little to no understanding of the OSI >> network model (they continued to try to claim that establishing a TCP >> connection meant that the WebDAV server could have sent the request for >> authentication credentials despite the fact that the TLS connection >> failed). >> >> The only small ray of hope is that they asked for a network trace of the >> connection process. That should enable someone more clueful at Microsoft >> to confirm it is the client error handling at fault. >> >> I'll keep the list informed of progress. Progress, if you can call it that, has not been good. They have now asked for additional network traces since: <quote> ... to be able to understand what packets are sent by client and what response did Server generate for the specific packet, I would like to check a simultaneous trace on both communication endpoints </quote> I have just sent a very long, fairly stropy reply pointing out the complete pointlessness of this request - not least because the information they claim they don't have is right in front of them in the form of the sequence and acknowledgement numbers in the network trace. I've also formally complained to the support engineer's manager and requested - no, make that demanded - that the issue is passed to the relevant product team. I'd share the full e-mails but during my investigations I have stumbled across a very, very minor security issue in the Microsoft WebDAV client. It barely qualifies as a problem but it is only fair to give Microsoft a chance to fix it before I go public with the details. I'll save the e-mails and make then public once the security issue has gone away. It might make an amusing lightning talk presentation at ApacheCon one year. I will say that if you are using the WebDAV client then it is extremely unlikely that you will be affected by the security issue. My view is that the security issue is not sufficient reason on its own to look for a different client. That said, based on my experience of this WebDAV client in the past (very buggy) and my current experience trying to get what should be a simple bug fixed in the current client I would always recommend that you use a 3rd party WebDAV client (and check out the quality of the support provided before you make your final selection). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
