(You may wish to visit Kai's home page at http://go.to/kai.engert for more up-to-date information, including pre-compiled binaries.) I'm submitting a patch that adds the new protocol "smb" for -n option. It implements "Samba over SSL" support". At least for the client side. The logic was taken from the Program SSLProxy, available at http://www.obdev.at/Products/sslproxy.html which was developed by Christian Starkjohann. Please find attached some explanations and the patch to add this feature to Stunnel. Please feel free to add this code to the main Stunnel distribution. Best regards, Kai === Explanation The motiviation for this patch is: Establish a "network drive connection" from a computer running Windows (trademark of Microsoft Corporation) to a Unix server over a secure SSL connection: - Unix server running Samba, using the integrated Samba over SSL code. - Windows client If you use Windows NT 4, you can directly run the stunnel on your own client machine. You bind to local port 139 and bind to remote port 139 on the Samba server machine. Then you simple tell Windows to map a drive named "\\127.0.0.1\remote-share-name". Unfortunately this doesn't work on Windows 95/98, as this sytem doesn't allow ip-addresses in computer names for network shares. And "localhost" didn't work, too. I tried Windows 2000, and I was able to start stunnel binding to port 139. But regardless of whether I bound to loopback, any or a special address of the machine, the operating system always connected directly to it's internal Samba network code, and never established a connection to stunnel. There is another configuration which runs probably with all windows versions. Suppose you want to make a network drive connection over the public internet, from your local office to a remote office. The remote office runs Samba over SSL. Locate a Linux (or other Unix) computer in your local office. Run the stunnel executable there. Make sure the port 139 is not used on that Unix machine. Suppose your local Unix computer has the hostname "unixgateway" and the sharename on the remote office is called "myfiles": On your Windows client machine, connect to the share name with the name "\\unixgateway\myfiles". The above description works, if you need to connect to exactly one destination share. As the SMB protocol on Windows computer uses alway Port 139 (this is not changeable), you must use multiple local IP adresses when need to connect to multiple destination shares. You could use assign to your / the gateway computer multiple ip addresses from the "intranet range", e.g. 192.168.x.x. Then bind the stunnel executable to that ip address at port 139. Then use that ip address as the address of the network share you want to connect. If you are using an operating system that can't use ip addresses in share names (e.g. Windows 98) you could use a WINS server to create host name mappings to that ip addresses. (However, I'm not a Windows expert, but think it should work that way. In addition it might work to enable "DNS for windows names resoulution" and create DNS entries...) (Please note that WINS might be a trademark, too.) === Notes from Christian Starkjohann, original author of this code As the author of the original SMB hack in SSLProxy, I feel the need to explain it somewhat: Our company sells a CIFS/SMB client. This client is capable of SSL connections to the server. We found that it would be a very nice feature in the client to connect to servers WITH our WITHOUT SSL transparently. The client must therefore be able to determine whether the server runs over SSL or not. I've looked at other implementations (I think it was SSL-ftp or SSL-telnet) and found that this negotiation must be done in the underlying protocol. Since there was no published way to automatically negotiate SSL in SMB at that time, I decided to try to establish a quasi-standard. It works like this: The client tries to connect in an SSL-less fashion. During the netbios session setup, the server returns an error [new error code, not documented], thereby telling the client that it is an SSL server. Client and server both switch to SSL now. If a "normal" client tries to connect, it will abort when it receives the error. That's useful since non-SSL clients can't connect to SSL servers anyway. If you want to transform a CIFS/SMB server into the SSL variant with automatic negotiation as described above, stunnel must do parts of the netbios session setup (up to the error return). That's what the SMB option to SSLProxy (and hopefully Kai's extension to stunnel) is good for. Transforming a client into the SSL variant also requires to try a normal connection and wait for the error during netbios session setup. That's also done by the extension. Since we tried to establish this as a quasi-standard, we tried to get the patches into the samba distribution. And we succeeded. Samba uses this mechanism (if nobody has removed it in the meantime). === Statement of Christian Starkjohann regarding his SMB code: I'm the author and I can place it under any copyright you want. Please tell me if you need something formally signed. === Some Comments from me Kai Engert: There is a book from O'Reilly named "Using Samba". In Appendix A it describes how to set up SSLProxy to establish a secure connection. (see: http://k12linux.mesd.k12.or.us/using_samba/appa_04.html) For a short while I was a maintainer for SSLProxy, providing some binaries. However, OpenSSL introduced new necessarities for library initializiation etc., and to keep SSLProxy compilable with current OpenSSL versions, it would have been required to put some work into SSLProxy. But as there was and still is Stunnel, which seemed to be much more actively being worked on, I therefore decided that it makes more sense to integrate the logic into stunnel and to stop work on SSLProxy. We already have an "Internet Link chain" from the book to the smb version of stunnel, using Christian's code. When I read my webspace logfiles I can see that most of the users are coming from Christian's page, looking for SSLProxy / Stunnel. :-) I'm already recommending people to prefer the modified stunnel version over SSLProxy. So it would be nice to have that code added to the main source code. === Detailed list of configurations 1.) Windows server, Windows client To protect the connection, you don't need the "-n smb" option. Simply run two stunnel executables, one on the server site, and one on the client site using "-c" option. You might want to use two gateway computers, one at each location, running a Unix operating system to run the Stunnel processes on. 2.) Samba server with integrated SSL, Unix or Windows client You configure the server SSL behaviour using the Samba Server's configuration files. On the client site, you need to run Stunnel with option "-c -n smb". 3.) There might be other configurations where stunnel with "-n smb" option makes sense. However, I must confess that I have not tried other configurations. Especially I have not tested the smb option in stunnel server mode. Feedback is required. Maybe Christian has some more comments on this.