Re: mod_ssl: TLS/HTTPS multiplexing with other protocols

[Graham Leggett]

On 23 Apr 2014, at 8:39 PM, Daniel Pocock  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:dan...@pocock.pro SIP/1.0
> 
> XMPP:
>
> 
> 
> 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
--

mod_ssl: TLS/HTTPS multiplexing with other protocols

[Daniel Pocock]

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
u...@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:dan...@pocock.pro SIP/1.0

XMPP: