Rick_Nyman
Nimbostratus
NimbostratusXMPP with STARTTLS
I love the simplicity of SSL offload using standard SSL/TLS. Unfortunately, I've recently been given a requirement to do XMPP (an Instant Messaging protocol) using STARTTLS.
I found the excellent examples of IMAP and SMTP using STARTTLS, but it appears that XMPP is a different animal. To start, it's XML based. In addition, it appears to keep track of client requests and will not respond to what it thinks are repeat requests.
Here's what I have so far (Caveat - I do a little bit of PERL coding, but don't know much about TCL, so there may be fundamental issues with this script). At a basic level, this script starts by watching the server output and when it sees a stream:features XML tag, it inserts the STARTTLS capability. At that point, it starts watching client traffic - and expects to see the client requesting encryption. At that point, it starts encryption locally.
Anyone here familiar with XMPP?
Thanks all,
Rick
Last week's code
when CLIENT_ACCEPTED {
SSL::disable
}
when SERVER_CONNECTED {
TCP::collect
}
when CLIENT_DATA {
set lcpayload [string tolower [TCP::payload]]
if { $lcpayload starts_with " TCP::respond "\r\n"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
SSL::enable
} else {
TCP::respond "TLS is required on this stream - you sent $lcpayload\r\n"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
TCP::collect
}
}
when SERVER_DATA {
if {[string first "" [TCP::payload]] == -1 } {
TCP::release
TCP::collect
}
else {
regsub {\} [TCP::payload] {} changed
TCP::payload replace 0 [TCP::payload length] $changed
TCP::release
clientside { TCP::collect }
}
}
I received the following feedback from our XMPP expert
as I described in mail from last week, there are subsequent requests generated by the client as each feature is negotiated. What is happening is the server responds back w/ a list of (which the F5 rewrites as it is being sent to the client); the client negotiates TLS; then the client sends another request. The server receives this, but will *not* respond back... from the server's perspective, the client has simply made two requests and hasn't negotiated a feature yet.
Last night's rule - I'm still waiting for feedback
when CLIENT_ACCEPTED {
SSL::disable
}
when SERVER_CONNECTED {
TCP::collect
}
when CLIENT_DATA {
set clientdata [string tolower [TCP::payload]]
if { $clientdata starts_with " TCP::respond ""
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
SSL::enable
TCP::collect
} elseif { $clientdata contains " TCP::respond $serverdata
} else {
TCP::respond "TLS is required on this stream - you sent $clientdata"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
TCP::collect
}
}
when SERVER_DATA {
if {[string first "" [TCP::payload]] == -1 } {
TCP::release
TCP::collect
}
else {
set serverdata [TCP::payload]
regsub {\} $serverdata {} changed
TCP::payload replace 0 [TCP::payload length] $changed
TCP::release
clientside { TCP::collect }
}
}
