2

In the past, there has been lots of productive discussion on how to mount drives programmatically.

This link is one productive example: How do I map a network drive that requires a username and password in .NET?

However, what I seem to be missing is a way to perform this mount when TLS is required.

We see things like this: net.exe use x: "\server.com@ssl:443\folder" /User:UserName Password

Where this can be used in code with:

System.Diagnostics.ProcessStartInfo process = new System.Diagnostics.ProcessStartInfo(); process.FileName = "net.exe"; process.Arguments = "use Z: \\\\JoeDoodle.TheDomain5.com@SSL\\MyFolder\\ PassW0rd /user:JoeUser"; process.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden; System.Diagnostics.Process p = System.Diagnostics.Process.Start(process); // Other stuff...

This sort of thing works great with SSL but not TLS. This is a .Net 4.0 application with our test base starting on Windows 7. Since we are running this as process as shown I am not sure not much that matters.

I cannot use WNetAddConnection2 and related imports because this is a remote drive. The other end is Linux exposing Webdav and it works fine for SSL but not TLS specifically. They are phasing out SSL so I must use TLS.

Any way to mount it programmatically will probably be fine with TLS but I just haven't found the successful combination.

Any help is appreciated.

Community
  • 1
  • 1
JoeDoddleBang
  • 21
  • 3
  • Just to check, have you actually checked on the wire (e.g. with Wireshark) that you were indeed using SSLv3 and not TLSv1.0 or above? Many SSL/TLS stacks do this transparently and it's likely that it's using some system setting (or something more global at least), unless you've tweaked the version explicitly in your code. – Bruno Nov 13 '14 at 18:08
  • Bruno, excellent question! The system previously only had SSLv3 allowed and it worked great so clearly in that case it could have only been SSLv3. However, when they disabled SSL and only allowed TLS it failed. When this caused all kinds of problems, they re-enabled SSLv3 and TLS where if TLS negotiation fails it falls back to SSLv3. This works. I have not gone in with something like wireshark to see if, indeed, it is falling to SSLv3. However, since TLS alone fails I find it doubtful that it is going to TLS under that configuration. SSLv3 will be removed shortly so it isn't viable anyway. – JoeDoddleBang Nov 13 '14 at 18:16
  • There could also be an issue with which cipher suites are available (and also which version of TLS are enabled). Wireshark should be able to tell you what the client claims to support in the ClientHello message. Considering that what you're doing programmatically here is basically just calling a command line utility, I'd look at the OS settings to achieve this manually first. – Bruno Nov 13 '14 at 18:27
  • I needed to followup and not leave this open. Ultimately the problem was an issue on the Apache end. It required some adjustments and then a recompile of Apache. We were able to see the HELLO messages which were befuddling but its turns out an Apache change fixed them. This only applies to Windows 7 where it was tested. I am not sure about Windows 8. – JoeDoddleBang Jan 07 '15 at 18:16

1 Answers1

0

The problem was ultimately not a Windows problem but an Apache problem.

Apache required not just turning SSLv3 off but a slight code change and recompile.

This only applied to Windows 7 connecting so I do not know about Windows 8.

JoeDoddleBang
  • 21
  • 3