[squid-dev] Piping existing SSL session into squid SSL session cache

[Florian Schüttler]

On 04/27/2016 at 23:06 Alex Rousskov wrote:
> On 04/27/2016 01:01 PM, Florian Schüttler wrote:
> 
>> I have a scenario in which clients (<10) are connected to a server using
>> an application protocol inside a TLS connection. These clients should
>> now be able to reuse the existing TLS session for a TLS connection to
>> Squid running on the same server by passing the session (e.g. using two
>> OpenSSL s_client instances and parameter -sess_out resp. -sess_in). That
>> would save an expensive key exchange operation. So far, my application
>> server writes the session info to a named pipe when the handshake is
>> completed using OpenSSL's PEM_write_SSL_SESSION().
> 
> Just to clarify: Do you want the client-to-Squid TLS connection to reuse
> a TLS session established when the client was talking to an application
> server that has nothing to do with Squid/HTTP except that both Squid and
> the application server run on the same box?
> 
Well, the application protocol advertises the proxy service to the
client, but other than that they are independent. The client is an
embedded system, so key exchanges are very expensive which makes me want
to reuse the master key of the existing connection.
> 
>> I would now like to implement a feature in Squid which periodically
>> reads the pipe and adds this session information to the staticSslContext
>> in Squid using PEM_read_SSL_SESSION(). Ideally, this would integrate
>> into the event scheduling infrastructure (commEngine?) and not just be
>> hacked into the main loop, but I can not find easy documentation about
>> how to achieve this. Can anyone give me some pointers?
> 
> AFAIK, there is no "easy documentation" for what you want to do.
> 
> If possible, I would simplify this a lot by writing session information
> into a well-known file and [re]loading the session information [if it
> has changed] just after accepting a TCP connection on https_port and
> before calling SSL_accept(). This way, there is no need to add any new
> Squid "events" and maintain an asynchronous session-updating job
> reacting to those events.
> 
Yeah, maybe this will be easier, the pipe could then be used as a buffer
and I would not need to read it directly after writing. At the moment it
is just a proof of concept/prototype anyway.
> 
> HTH,
> 
> Alex.
> 
Thanks,
Florian