Samba with SSL from MS clients!

[Hank Leininger]

On 2000-09-13, Selma Tekir <selmatekir at yahoo.com> wrote:

> I wonder if it's possible to establish an SSL connection from a Windows 
> NT client to the Samba Server.

Absolutely.  It may not be as elegant as you'd like, but...

> "Windows clients will try to connect to the SSL
> enabled samba daemon and they will fail. This can fill
> your log with failed SSL negotiation messages. To
> avoid this, you can either not run nmbd (if all
> clients use DNS to look up the server), which will
> leave the Windows machine unaware of the server, or
> list all (local) Windows machines in the "ssl hosts
> resign" variable."
>
> I used the second way, and sniffed the packets and the
> data were not encyrpted. For the first option, it was
> not possible to access the shares from the MS client.

NB: I haven't looked closely at Samba's native SSL support lately; the
below is based on experiences I had roughly a year ago (my solutions still
work, though, even if the problems have gone away :)

If I'm reading this right, the above quote says essentially "Samba-based
clients with SSL support will talk to Samba servers with SSL just fine. 
But since Windows clients can't understand SSL, don't let the Windows
clients talk to the SSL'ed Samba server, or, tell the Samba server to
disable SSL for those clients."  This seems pretty suboptimal, huh?

There's definitely a workable solution, though.  You need some kind of
plaintext-to-SSL wrapper on the Windows clients.  Last time I checked,
there was a catch: Samba's SSL support doesn't just say "I got a TCP
connect; start SSL now."  It does some handshaky stuff first; consequently
you can't just use stunnel or sslwrap or such for SMB clients that don't
grok SSL natively (like Windows).  You need one that knows how to negotiate
Samba-SSL sessions.  There is at least one such beast out there, available
for free which would connect to either Samba-SSL or SomeCommercialSMBServer
-SSL, but connecting to Samba-SSL was broken when I tried it.

What I've done several times is to chuck the SSL support built into Samba,
and use Stunnel (http://www.stunnel.org/) instead, on both ends.  Stunnel
is a simple SSL proxy; essentially, you have the server run Stunnel in
server(accept) mode, forwarding connections from its network socket
(speaking SSL) to a localhost TCP socket, or STDIN/STDOUT to run a daemon
inetd-style.  Then on the client (yes, Stunnel supports Win32) run Stunnel
in Client mode -- listen for incoming connections to localhost, and forward
them over the network via SSL.  This works really well, with two caveats:
it requires some client software be installed on the workstations -- pretty
easily automated -- and it's not fast.  The definition of "Not Fast"
depends on available CPU on both ends, but basically it'll make fast
ethernet feel like regular ethernet.  It's definitely functional for
document storage, etc -- I wouldn't run apps installed on the Samba server
this way, or use any client lower-end than a P2-something.

I rambled a bit more specifically about how to do this on the fwtk-users
mailing list some time ago (only the last couple of paragraphs are
relevant):

http://marc.theaimsgroup.com/?l=fwtk-users&m=96403027410568

I'd be happy to discuss details more (probably off-list).  I might even
have a client install floppy dd image floating around somewhere...

--
Hank Leininger <hlein at progressive-comp.com>