Re: [OT] Re: SSL configuration using PFX as keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/22/15 1:18 PM, Mark Thomas wrote: On 08/07/2015 16:22, André Warnier wrote: snip / With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the fact that MS software is by definition bug-free and does not really need support. I've had several extremely frustrating telephone calls this afternoon where various levels of Microsoft staff repeating their position that the WebDAV client is working as designed and that prompting for authentication is a perfectly reasonable response when trying to connect to a server that does not require authentication but does have a cert issued by a CA the client doesn't trust. Yep: working as designed means we designed it to work with our own products under the conditions we ave specified, and nuts to you if you want something different. Otherwise known as the standards be damned design principle. I don't know why anyone is surprised, here. So far the minor security vulnerability (details to follow once Microsoft provide their final response in writing) is working as designed as well. Hmm. Microsoft Windows - insecure by design. There is a nice strap line. I wonder if their marketing folks would like to use it. I'd be happy to offer them a royalty free license. I've asked MS to provide the justification for this position in writing - mainly because I intend writing up a blog post to make clear to those who haven't already figured it out that the Microsoft WebDAV client is, despite the improvements in recent Windows versions, still buggy and - more importantly - Microsoft are point blank refusing to fix obvious bugs and (minor) security vulnerabilities. I recall that someone on this list said that they had switched to a 3rd party WebDAV client and hadn't looked back since. Could that person remind me what that client was. I'd be happy to give it a plug in the blog post. South River Technologies' WebDrive. It's a remote filesystem driver that creates a drive letter which maps to some remote share and supports (proper) WebDAV(S) including proper file-locking (as well as local caching of files with lots of configuration options), (S)FTP/FTP(S), Amazon S3, Google Drive, DropBox, SharePoint, and something called OneDrive, which I've never heard of. I've never used WebDrive for anything other than WebDAV; I'm not sure how great it is for those other protocols, but I suspect it will perform well. Their tech support folks were even kind enough to walk one of my users through the installation and configuration of the software when she called to ask how to download the installer. http://www.southrivertech.com/products/webdrive/ (Note: I have no financial interest in SRT. I'm just a happy user of their product.) I'll also be updating the Tomcat docs to make it clear that the Microsoft WebDAV client is unsupported and I'll be removing the WebDAV fix valve from Tomcat 9 onwards since it fixes bugs in old, unsupported MS WebDAV clients and there is no way to fix issues like the current one on the server side. I'll be asking httpd to add a similar note regarding the supportability of the MS WebDAV client. +1 I just sent an email to the folks running http://webdav.org/ about Tomcat itself as well as WebDrive. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVr+PrAAoJEBzwKT+lPKRYkwUP/RRE/FZ6WYLlsox2TJ5BHKrP Ns/Ke7SiQ7cDfY7Da7lUjRxOYjlVI6LeLDMENsDSkPGWRU76lUDqVFiLGc3VqHpL KQJlERQ7Qu8Byc8UIz3r6gnnZtNpZTmEk4mHhLr8f9LZ9+MABakgmT3nHWt9utdK X9lyBz3FY9y8stnwhDyXau5tUBUhiM4bA0gy38cqynSQEl2UL92NTAz/cwj13NEZ 6lODrV1wR7bONi2FOeCwfEghq13RaGStdRPTtCI/C7UtG+1eCbicCv9Zjx/+0u13 yNJkUJAUNeSyE5ahFLbiz/WtUTUMulWTSU0uLXs3K0B2fpK3FQU26UYFZPVBMhG1 qNXOcHkdjzoYbfxSTwxsrnrk55daf7bdwjPJ5S/Ljz2nythXGzcZJpq9idNS+9VE 5hYsGd5kxyX1FPUn3/nBNcXBsaf2CgEMM1CEJgLIZqXFcRpV5QNZy0OafUUC1FZX qSHJUJDhvYfuUZ6xK89yidSEiKmHgYPG7hNGgQWe4EbQ1SLLdYpQwRQODrJ3selp Rvq2Qy7pZW1qP454gu1xHIuyGNgoCLzrY60knIr68OzQ96vSSGRC29hWPAEOpeh6 qbYG/s86jxq4FRPnxhSVvf8WJme7O4nmafn4c0D1WVGRH16V1bc4PWMTuwf8bV/j 2d85aDMdyUVpUiyMtrgA =hV9K -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
On 08/07/2015 16:22, André Warnier wrote: snip / With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the fact that MS software is by definition bug-free and does not really need support. I've had several extremely frustrating telephone calls this afternoon where various levels of Microsoft staff repeating their position that the WebDAV client is working as designed and that prompting for authentication is a perfectly reasonable response when trying to connect to a server that does not require authentication but does have a cert issued by a CA the client doesn't trust. So far the minor security vulnerability (details to follow once Microsoft provide their final response in writing) is working as designed as well. Hmm. Microsoft Windows - insecure by design. There is a nice strap line. I wonder if their marketing folks would like to use it. I'd be happy to offer them a royalty free license. I've asked MS to provide the justification for this position in writing - mainly because I intend writing up a blog post to make clear to those who haven't already figured it out that the Microsoft WebDAV client is, despite the improvements in recent Windows versions, still buggy and - more importantly - Microsoft are point blank refusing to fix obvious bugs and (minor) security vulnerabilities. I recall that someone on this list said that they had switched to a 3rd party WebDAV client and hadn't looked back since. Could that person remind me what that client was. I'd be happy to give it a plug in the blog post. I'll also be updating the Tomcat docs to make it clear that the Microsoft WebDAV client is unsupported and I'll be removing the WebDAV fix valve from Tomcat 9 onwards since it fixes bugs in old, unsupported MS WebDAV clients and there is no way to fix issues like the current one on the server side. I'll be asking httpd to add a similar note regarding the supportability of the MS WebDAV client. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Mark Thomas wrote: On 08/07/2015 16:22, André Warnier wrote: snip / With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the fact that MS software is by definition bug-free and does not really need support. I've had several extremely frustrating telephone calls this afternoon where various levels of Microsoft staff repeating their position that the WebDAV client is working as designed and that prompting for authentication is a perfectly reasonable response when trying to connect to a server that does not require authentication but does have a cert issued by a CA the client doesn't trust. So far the minor security vulnerability (details to follow once Microsoft provide their final response in writing) is working as designed as well. Hmm. Microsoft Windows - insecure by design. There is a nice strap line. I wonder if their marketing folks would like to use it. I'd be happy to offer them a royalty free license. I've asked MS to provide the justification for this position in writing - mainly because I intend writing up a blog post to make clear to those who haven't already figured it out that the Microsoft WebDAV client is, despite the improvements in recent Windows versions, still buggy and - more importantly - Microsoft are point blank refusing to fix obvious bugs and (minor) security vulnerabilities. I recall that someone on this list said that they had switched to a 3rd party WebDAV client and hadn't looked back since. Could that person remind me what that client was. I'd be happy to give it a plug in the blog post. If that person was me, I was mentioning WebDrive (http://www.southrivertech.com/products/webdrive/) I'll also be updating the Tomcat docs to make it clear that the Microsoft WebDAV client is unsupported and I'll be removing the WebDAV fix valve from Tomcat 9 onwards since it fixes bugs in old, unsupported MS WebDAV clients and there is no way to fix issues like the current one on the server side. I'll be asking httpd to add a similar note regarding the supportability of the MS WebDAV client. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/7/15 9:39 AM, Mark Thomas wrote: On 30/06/2015 21:16, Mark Thomas wrote: 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. snip/ 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. This continues to drag on. The stropy e-mail got the issue re-assigned to someone with marginally more clue. They put together a test environment (with IIS instead of Tomcat) and then attempted to demonstrate that the issue did not occur and hence it must be a Tomcat problem. Our non-standard client works perfectly well with our non-standard server. The fact that our non-standard client doesn't work with your standards-compliant server obviously points to your software as the problem. Nice tautology you got there. It would be a shame if something were to happen to it. *sigh* Well, if you're willing to continue to tilt at this particular windmill, it would be a great service to the world. I'm not hopeful, though, as WebDAV support in Microsoft Windows has degraded consistently over the past 10 years and never improved. I don't know why they even bother to /claim/ support for it anymore. Evidently, nobody in the Microsoft world gives a rats posterior about WebDAV... they all use SMB anyway. However, once they had configured their environment to match my original bug report (server using cert issued by CA client doesn't trust, server configured not to require authentication) imagine my lack of surprise when the problem was repeated with IIS. Needless to say the other end of the conference call went very, very quiet at that point. The issue has now been passed to yet another support employee (I refuse to call these people engineers) who apparently wants to discuss the issue further. What they can possibly need to discuss at this point I have no idea but having told them (again) how to contact me I am waiting to hear from them. I also discovered that - despite the conference call - the latest support ticket update from Microsoft claimed the issue could not be repeated with IIS. It appears that the issue has been passed to the IIS team which makes no sense at all since all the evidence points to this being a WebDAV client bug and I have been making that point since this whole sorry episode started. The good news is that the IIS team is likely to refuse to accept responsibility for the bug (because, by definition, IIS contains zero bugs) and likely to pass the buck back to the WebDAV client team. If you catch them at just the right time, you may be able to show MS how to do their own jobs. While I continue to appreciate the free MSDN license Microsoft kindly provide to Apache committers, I must confess to being completely unimpressed by Microsoft's support structures and count myself fortunate that I don't have to run an IT infrastructure that relies on them. +1 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnSpYAAoJEBzwKT+lPKRYCDkP/2KJK6mjA0rCQ8m/cT+3iPTe bDyXDNTs4g2aycCdKReW9MtcGwy0Qf2M5YEv6+f5EzKjDeMuR5KZU2kieqFf0nh2 DOft4iCLFdbynqyXHPq0fEpbg0dGJjAr9sB+ifA/0t+2v7iXB2bxvfu/2MZrhHYl I9L2zGrrq3JcuXrEMINm5PZJDkHwHf1lWrXTk/P/2hCw7mHFVj9qraPE3bfQULVZ XviuW4l7TfbIfqu5B8w42/VYayOC3l9rh4eW59Eea44bikj44c9q2OuB94JNXYy8 mvSS2oyOX0pe2JtjrAt0XFHL7fuz4C4bbZeEremdYrLclbVlC20PuKvxeuvuEfXn jE71qIuP+4vPD5+VlUuyIkW04r73CqeaEYGQPatrBCA+J702B05IsND3JF7ZHrdq /Ms7PugZurLJD99/UJMCvFCDnPiuL4jWMDo1NLDq5BOCXHtdN2KeDYG0zTJhh2Dk nH1y/sdJ8B3Uaya8heK7b+oxR2LS77vfmTyYRD9KMIgFDeMay1hPOvy9nAot2PEw CJkfd1YVVl+0Ym9mqKq4wybTguSXfA4DrC98H3BskuWhtB3Ev79bUCPsHxa8je1k FcN3+KaslxAk3UcxvgsXTagRIGo3S7Wnk8X2LOqrAmB0m9A8kMZuT3lHiCyhyPxG GhatQDMYanSiOd3NJNTc =+Gqo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/7/15 9:39 AM, Mark Thomas wrote: On 30/06/2015 21:16, Mark Thomas wrote: 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. snip/ 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. This continues to drag on. The stropy e-mail got the issue re-assigned to someone with marginally more clue. They put together a test environment (with IIS instead of Tomcat) and then attempted to demonstrate that the issue did not occur and hence it must be a Tomcat problem. Our non-standard client works perfectly well with our non-standard server. The fact that our non-standard client doesn't work with your standards-compliant server obviously points to your software as the problem. Nice tautology you got there. It would be a shame if something were to happen to it. *sigh* Well, if you're willing to continue to tilt at this particular windmill, it would be a great service to the world. I'm not hopeful, though, as WebDAV support in Microsoft Windows has degraded consistently over the past 10 years and never improved. I don't know why they even bother to /claim/ support for it anymore. Evidently, nobody in the Microsoft world gives a rats posterior about WebDAV... they all use SMB anyway. However, once they had configured their environment to match my original bug report (server using cert issued by CA client doesn't trust, server configured not to require authentication) imagine my lack of surprise when the problem was repeated with IIS. Needless to say the other end of the conference call went very, very quiet at that point. The issue has now been passed to yet another support employee (I refuse to call these people engineers) who apparently wants to discuss the issue further. What they can possibly need to discuss at this point I have no idea but having told them (again) how to contact me I am waiting to hear from them. I also discovered that - despite the conference call - the latest support ticket update from Microsoft claimed the issue could not be repeated with IIS. It appears that the issue has been passed to the IIS team which makes no sense at all since all the evidence points to this being a WebDAV client bug and I have been making that point since this whole sorry episode started. The good news is that the IIS team is likely to refuse to accept responsibility for the bug (because, by definition, IIS contains zero bugs) and likely to pass the buck back to the WebDAV client team. If you catch them at just the right time, you may be able to show MS how to do their own jobs. While I continue to appreciate the free MSDN license Microsoft kindly provide to Apache committers, I must confess to being completely unimpressed by Microsoft's support structures and count myself fortunate that I don't have to run an IT infrastructure that relies on them. +1 With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the fact that MS software is by definition bug-free and does not really need support. And to really bring the point home, MS seems to have plans to not name the next version Windows anymore, but invent some other name. Now /that/ should allow them to definitely start with a clean slate in their support database. There might be an idea for Tomcat there.. Bulldog ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
On 30/06/2015 21:16, Mark Thomas wrote: 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. snip/ 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. This continues to drag on. The stropy e-mail got the issue re-assigned to someone with marginally more clue. They put together a test environment (with IIS instead of Tomcat) and then attempted to demonstrate that the issue did not occur and hence it must be a Tomcat problem. However, once they had configured their environment to match my original bug report (server using cert issued by CA client doesn't trust, server configured not to require authentication) imagine my lack of surprise when the problem was repeated with IIS. Needless to say the other end of the conference call went very, very quiet at that point. The issue has now been passed to yet another support employee (I refuse to call these people engineers) who apparently wants to discuss the issue further. What they can possibly need to discuss at this point I have no idea but having told them (again) how to contact me I am waiting to hear from them. I also discovered that - despite the conference call - the latest support ticket update from Microsoft claimed the issue could not be repeated with IIS. It appears that the issue has been passed to the IIS team which makes no sense at all since all the evidence points to this being a WebDAV client bug and I have been making that point since this whole sorry episode started. While I continue to appreciate the free MSDN license Microsoft kindly provide to Apache committers, I must confess to being completely unimpressed by Microsoft's support structures and count myself fortunate that I don't have to run an IT infrastructure that relies on them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: SSL configuration using PFX as keystore
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
