[stunnel-users] Relaying OOB data [Was: A series of minor patches from Debian]

[Luis Rodrigo Gallardo Cruz]

On Sat, Sep 15, 2007 at 08:43:31AM -0500, Luis Rodrigo Gallardo Cruz wrote:
> On Sat, Sep 15, 2007 at 07:39:11PM +0800, Richard's Hotmail wrote:
> > I simply wish to specify the MSG_OOB
> > flag in my client's C Socket SEND call, or use the (below) sendUrgentData()
> > Java method, and have STUNNEL just faithfully replay it to the destination
> > TCP/IP port. Am I asking too much?
> 
> I'll look into it. I think you *might* be asking too much, because if
> you're talking to stunnel the other side might be past a socket type
> that doesn't allow for oob data (a pipe, for example). Also, I need to
> find out how this interacts with ssl.

Ok, been reading. The short answer is no.

The longer answer is SSL doesn't support OOB data, so that's why
not. I did read your post saying you've read specs where it says it
does, but I could find no such. Take a look at RFC4346, section 6.2
 http://tools.ietf.org/html/rfc4346#page-14

Take a look also at this thread:
 http://www1.ietf.org/mail-archive/web/tls/current/msg01041.html

The argument (almost) in full:

- SSL doesn't define anything like OOB data in its streams, so
anything we did in stunnel would be an extension, and not
interoperable. And, anyways, would have to be done in openssl and not
in stunnel, I think.

- Even if SSL did handle some sort of OOB data, it would be *inside*
the stream, and not using TCP's mechanism, since SSL is meant to be a
protocol that runs on top of just about any reliable connection
oriented transport. That probably means you couldn't use the regular
socket functions for OOB transfer.

- We might have stunnel use TCP's OOB handling *outside* the SSL
stream, but this would still have the problem of not being
interoperable, and of running into problems when we go across socket
kinds. For example, when stunnel runs an inetd-type app, communicating
with it through a pipe. Also, there's no telling what the other end of
the connection will do when receiving an OOB package.

- And, even if we could implement that (maybe limiting it to the case
where stunnel is just relaying between TCP sockets?), should we? We'd
be sending information in the clear, posibly creating a vulnerability
for the data *inside* the tunnel (because we'd expose parts of the
protocol, timing info, etc).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20070917/8ed56678/attachment.sig>