Re: [stunnel-users] Relaying OOB data [Was: A series of minor

This is a discussion on Re: [stunnel-users] Relaying OOB data [Was: A series of minor within the Stunnel Users forums, part of the Networking and Network Related category; This is a multi-part message in MIME format. --===============0234457119== Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01C7FE72.30A205C0" This ...

		Usenet Forums > Networking and Network Related > Stunnel Users
Re: [stunnel-users] Relaying OOB data [Was: A series of minor

LinkBack

Thread Tools

Search this Thread

Display Modes

#1 (permalink)

09-23-2007

Richard's Hotmail

Posts: n/a

Re: [stunnel-users] Relaying OOB data [Was: A series of minor

This is a multi-part message in MIME format.

--===============0234457119==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_023F_01C7FE72.30A205C0"

This is a multi-part message in MIME format.

------=_NextPart_000_023F_01C7FE72.30A205C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Luis,

Thanks for the detailed reply!

> Ok, been reading. The short answer is no.

Oh well :-( I guess that's what IPsec's for.

> 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/we.../msg01041.html

Doesn't that thread suggest that OOB functionality is part of the SSLv3
standard? Is version three one of those "yet to be" standards that is =
still
a long way off? Renamed TLS? (I found several RFCs dealing with this, =
anyone
know which is the relevant one? I couldn't find "Urgent", "OOB" or =
"band" in
4346)

My understanding (imagination maybe) is that the OOB character is to be
packaged up as a single byte record surrounded with the SSL wrapper with =
a
bit set that says it's the OOB character. I would now like stunnel just =
to
dequeue it from SSL and then set the MSG_OOB flag and replay it to the
application port. So it's sort of quasi-OOB to Stunnel and then true-OOB =
to
the receiving port.

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

I must be confused about what's available (the only SSL code I've cut =
is
simple Java client stuff) 'cos I'm sure I've seen patch-comments that =
say
something like "make sure stunnel handles OOB data correctly" and isn't
there some sort of OOB INLINE configuration parameter. Is there really
northing available after the SSL_Read that identifies the data as an OOB
character?

Anyway, thanks again for the reply.

Cheers Richard Maher

PS. Does anyone out there know of a lower-level version of Stunnel (or
something else) that spoofs the originating host-address when replaying =
the
connection on the local server? It sure would be useful for client
identification, and for reducing DoS attacks!

----- Original Message -----=20
From: "Luis Rodrigo Gallardo Cruz" <rodrigo@nul-unu.com>
To: <stunnel-users@mirt.net>
Sent: Tuesday, September 18, 2007 9:14 AM
Subject: [stunnel-users] Relaying OOB data [Was: A series of minor
patchesfrom Debian]

> _______________________________________________
> stunnel-users mailing list
> stunnel-users@mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users

------=_NextPart_000_023F_01C7FE72.30A205C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi=20
Luis, Thanks for the detailed reply! > Ok, been =
reading. The=20
short answer is no. Oh well :-( I guess that's what IPsec's=20
for. > The longer answer is SSL doesn't support OOB data, so =
that's=20
why > not. I did read your post saying you've read specs where it =
says=20
it > does, but I could find no such. Take a look at RFC4346, =
section=20
6.2 >  <A=20
href=3D"http://tools.ietf.org/html/rfc4346#page-14">http://tools.ietf.org/html/rfc4346#page-14</A> <FO=
NT=20
face=3D"Times New Roman" size=3D3>> Take a look also at this=20
thread: >  <A=20
href=3D"http://www1.ietf.org/mail-archive/web/tls/current/msg01041.html">=
<FONT=20
face=3D"Times New Roman"=20
size=3D3>http://www1.ietf.org/mail-archive/web/tls/current/msg01041.html<=
/FONT></A> <FONT=20
face=3D"Times New Roman" size=3D3>Doesn't that thread suggest that OOB =
functionality=20
is part of the SSLv3 standard? Is version three one of those "yet to =
be"=20
standards that is still a long way off? Renamed TLS? (I found several =
RFCs=20
dealing with this, anyone know which is the relevant one? I couldn't =
find=20
"Urgent", "OOB" or "band" in 4346) My understanding =
(imagination=20
maybe) is that the OOB character is to be packaged up as a single =
byte record=20
surrounded with the SSL wrapper with a bit set that says it's the OOB =

character. I would now like stunnel just to dequeue it from SSL and =
then set=20
the MSG_OOB flag and replay it to the application port. So it's sort =
of=20
quasi-OOB to Stunnel and then true-OOB to the receiving =
port. > The=20
argument (almost) in full: > - SSL doesn't define anything like =
OOB data=20
in its streams, so > anything we did in stunnel would be an =
extension, and=20
not > interoperable. And, anyways, would have to be done in =
openssl and=20
not > in stunnel, I think. I must be confused  about =
what's=20
available (the only SSL code I've cut is simple Java client stuff) =
'cos I'm=20
sure I've seen patch-comments that say something like "make sure =
stunnel=20
handles OOB data correctly" and isn't there some sort of OOB INLINE=20
configuration parameter. Is there really northing available after the =

SSL_Read that identifies the data as an OOB character? Anyway, =
thanks=20
again for the reply. Cheers Richard Maher PS. Does anyone =
out=20
there know of a lower-level version of Stunnel (or something else) =
that=20
spoofs the originating host-address when replaying the connection on =
the=20
local server? It sure would be useful for client identification, and =
for=20
reducing DoS attacks! ----- Original Message ----- From: =
"Luis=20
Rodrigo Gallardo Cruz" <<A =
href=3D"mailto:rodrigo@nul-unu.com"><FONT=20
face=3D"Times New Roman" size=3D3>rodrigo@nul-unu.com</A><FONT=20
face=3D"Times New Roman" size=3D3>> To: <<A=20
href=3D"mailto:stunnel-users@mirt.net">stunnel-users@mirt.net</A>> Sent: Tuesday, September 18, 2007 9:14 AM Subject:=20
[stunnel-users] Relaying OOB data [Was: A series of minor patchesfrom =

Debian] > =
_______________________________________________ >=20
stunnel-users mailing list > <A=20
href=3D"mailto:stunnel-users@mirt.net">stunnel-users@mirt.net</A> > <A=20
href=3D"http://stunnel.mirt.net/mailman/listinfo/stunnel-users"><FONT=20
face=3D"Times New Roman"=20
size=3D3>http://stunnel.mirt.net/mailman/listinfo/stunnel-users</A=
> </DIV></BODY></HTML>

------=_NextPart_000_023F_01C7FE72.30A205C0--

--===============0234457119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
stunnel-users mailing list
stunnel-users@mirt.net
http://stunnel.mirt.net/mailman/listinfo/stunnel-users

--===============0234457119==--

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Posting Rules
You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are Off [IMG] code is Off HTML code is Off Trackbacks are On Pingbacks are On Refbacks are On

All times are GMT +1. The time now is 11:34 PM.