Patch info for smb_kai

Author Comments

(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.

This website makes patches available for use by the Internet community. However it does not endorse any of the patches contained herein. They could be work perfectly, or totally foul up everything. We don't know. Contact the authors if you have any questions. Use at your own risk.

The Stunnel software package does not contain any cryptography itself, however please remember that import and/or export of cryptographic software, code providing hooks to cryptographic algorithms, and discussion about cryptography is illegal in some countries. It is imperative for you to know your local laws governing cryptography. We're not liable for anything you do that violates your local laws.