Hi Nenad,
>> But my tests with Vincents rfc5077-client indicate that we use all
>> available keys in the file for decryption, not only TLS_TICKETS_NO.
>
> This is definitely not expected. Can you please let me know how you
> tested this? I did some quick checks with openssl and it seems to be
> working correctly (TLS_TICKETS_NO=3):
Code works as expected, this was some kind of PEBCAK:
The way I was testing it was that I spawned different haproxy instances
on different IPs and then run Vincents rfc5077-client against it:
~/haproxy$ sudo ./haproxy -D -f ../cert/tlstickets80.cfg
~/haproxy$ openssl rand -base64 48>>/tmp/tls_ticket_keys
~/haproxy$ sudo ./haproxy -D -f ../cert/tlstickets81.cfg
~/haproxy$ openssl rand -base64 48>>/tmp/tls_ticket_keys
~/haproxy$ sudo ./haproxy -D -f ../cert/tlstickets82.cfg
~/haproxy$ openssl rand -base64 48>>/tmp/tls_ticket_keys
~/haproxy$ sudo ./haproxy -D -f ../cert/tlstickets83.cfg
~/haproxy$
So what I was expecting was that the test on the third instance could not
be resumed (because the key of the first instance won't be available for
the third instance), but actually the rfc5077-client was able to resume all
of them (expect the first test on the first ip of course).
The reason is simply that the test on instance 2 will encrypt the session in
a new TLS ticket with the instance 2 encryption key, which IS available for
decryption to instance 3.
So we CAN resume all sessions like this (10.0.0.XX where XX is the cfg name):
./rfc5077-client 10.0.0.80 10.0.0.81 10.0.0.82 [10.0.0.83]
But we CANNOT resume if we skip an instance (confirming that the code really
does only decrypt TLS_TICKETS_NO number of keys):
./rfc5077-client 10.0.0.80 10.0.0.82
So what that means is that even though a session was negotiated in an
instance older than 1 TLS key, we can still resume it if that session
information was (re-)encrypted by the last instance/key.
This is a good thing and totally expected behavior.
Sorry of the noise :)
Lukas
