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