mod_ssl: TLS/HTTPS multiplexing with other protocols

[Daniel Pocock <da...@pocock.pro>]

I've been working on the SIP over TLS and SIP over WebSockets (with TLS)
in reSIProcate and I'm looking at ways to make it easier people to use
both HTTPS and SIP(S) on a single IP/port

There are already methods (e.g. sshttp) that allow SSH and HTTPS on the
same port - this works fairly easily without code changes and it is able
to preserve the source IP, simply because SSH clients do not send any
ClientHello (SSH is not TLS)

Multiplexing two TLS server processes is slightly more trouble though

Server Name Indication (SNI) is useful for those cases where there is a
different domain for both SIP and HTTPS.  Where this is applicable,
sshttpd could be modified to route the request to the correct server.
However, that is not usually optimal: these days, many people want their
site to be https://example.org and their SIP (or XMPP) address to be
user@example.org and in that case, SNI will use the same domain for both
HTTPS and SIP.

This brings me to the observation that something needs to do the TLS
handshake and then look at the request body from the client (e.g. the
HTTP request line or SIP request line) to work out what type of request
it is.  All of the following are obviously very easy to distinguish from
each other:

HTTP:
   GET / HTTP/1.1

SIP:
   INVITE sip:daniel@pocock.pro SIP/1.0

XMPP:
   <?xml version='1.0'?><stream:stream ... xmlns='jabber:client' ...



so there may be two ways to go about this:

a) the user's preferred process (possibly Apache httpd) will do the
handshake, inspect the request line and then tunnel the data stream to
some other server when appropriate

b) some new process would be created (like sshttpd) to do the handshake
and then route the data to whichever server is appropriate (httpd, SIP
proxy, XMPP server, ...)

In either case, it is very desirable for the process that does the
handshake to relay some data about the client (source IP, client
certificate identity parameters) to the process that is responsible for
the protocol.

Is anybody aware of any existing work in any of these areas, even if it
is just discussion about the optimal architecture or the type of
solution that the Apache community would prefer if somebody worked on this?

Re: mod_ssl: TLS/HTTPS multiplexing with other protocols

[Graham Leggett <mi...@sharp.fm>]

On 23 Apr 2014, at 8:39 PM, Daniel Pocock <da...@pocock.pro> wrote:

> This brings me to the observation that something needs to do the TLS
> handshake and then look at the request body from the client (e.g. the
> HTTP request line or SIP request line) to work out what type of request
> it is.  All of the following are obviously very easy to distinguish from
> each other:
> 
> HTTP:
>   GET / HTTP/1.1
> 
> SIP:
>   INVITE sip:daniel@pocock.pro SIP/1.0
> 
> XMPP:
>   <?xml version='1.0'?><stream:stream ... xmlns='jabber:client' ...
> 
> 
> 
> so there may be two ways to go about this:
> 
> a) the user's preferred process (possibly Apache httpd) will do the
> handshake, inspect the request line and then tunnel the data stream to
> some other server when appropriate
> 
> b) some new process would be created (like sshttpd) to do the handshake
> and then route the data to whichever server is appropriate (httpd, SIP
> proxy, XMPP server, ...)
> 
> In either case, it is very desirable for the process that does the
> handshake to relay some data about the client (source IP, client
> certificate identity parameters) to the process that is responsible for
> the protocol.
> 
> Is anybody aware of any existing work in any of these areas, even if it
> is just discussion about the optimal architecture or the type of
> solution that the Apache community would prefer if somebody worked on this?

Not aware specifically about anything like this, but it is certainly possible to do this.

What you want is a connection filter that looks out for "INVITE * SIP/1.0" and then handles the connection if seen in some fashion, even if this is as simply as proxy the connection to a real SIP server. Same is possible with XMPP.

Sounds like a sensible thing to do.

Regards,
Graham
--