dpetrov has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks, I got little problem with Server-side SSL Session cache. I got a IO::Socket::SSL Server, which listen at a $LISTEN_PORT and accepts connection.
$SERVER = IO::Socket::SSL->new( Proto => 'tcp', LocalPort => $LISTEN_PORT, Listen => 5, ReuseAddr => 1, %ssl_opts, );
where %ssl_opts includes SSL_key_file, SSL_cert_file, SSL_ca_file and SSL_verify_mode. Than I accept every connection, like that:
while(4) { last if $break_main_loop; my $CLIENT = $SERVER->accept(); if( ! $CLIENT ) { rcd_log( "fatal: $SERVER_SSL_TRAP_ERROR" ) if $opt_ssl and $SERVER +_SSL_TRAP_ERROR; next; } my $peerhost = $CLIENT->peerhost(); my $peerport = $CLIENT->peerport(); my $sockhost = $CLIENT->sockhost(); my $sockport = $CLIENT->sockport(); rcd_log( "info: connection from $peerhost:$peerport to $sockhost:$so +ckport (me)" ); # do the rest
The IO::Socket::SSL documentation says:
SSL_session_cache_size If you make repeated connections to the same host/port and the SSL + renegotiation time is an issue, you can turn on client-side session +caching with this option by specifying a positive cache size. For suc +cessive connections, pass the SSL_reuse_ctx option to the new() calls + (or use set_default_context()) to make use of the cached sessions. T +he session cache size refers to the number of unique host/port pairs +that can be stored at one time; the oldest sessions in the cache will + be removed if new ones are added. SSL_session_cache Specifies session cache object which should be used instead of cre +ating a new. Overrules SSL_session_cache_size. This option is useful +if you want to reuse the cache, but not the rest of the context. A session cache object can be created using IO::Socket::SSL::Sessi +on_Cache->new( cachesize ). Use set_default_session_cache() to set a global cache object.
So how I am supposed to enable the SSL caching? Adding SSL_session_cache_size to the %ssl_opts hash, doesn't do the right thing. I am trying to make 5 repeatedly connection and every time my session-id is different.
openssl s_client -reconnect -state -prexit -connect localhost:443 -cer +t testpkey.pem
Thanks

Replies are listed 'Best First'.
Re: IO::Socket::SSL Server-side Session caching
by Anonymous Monk on Jun 03, 2009 at 08:37 UTC
    So how I am supposed to enable the SSL caching?

    Exactly as described? Example t/sessions.t

    I am trying to make 5 repeatedly connection and every time my session-id is different.

    From my understanding of SSL, that is what is supposed to happen, but i might be wrong.

      Okey, I am kind of lost right now: Let see the foolow examples. First we'll create SSL server using openssl like that: openssl s_client -reconnect -state -prexit -connect localhost:1234 -cert testpkey.pem then we make 5 repeatedly connections:
      openssl s_client -reconnect -state -prexit -connect localhost:1234 -ce +rt testpkey.pem -no_ticket
      Then on all my 5 requests I've the same session-id and master-key:
      Session-ID: 9C2B75807FE8AEB2E1C05B7B34D3F9F0B9394975D23AEA1BCC41F0 +BE1A1578CF Session-ID-ctx: Master-Key: 56182F7B8149E11642665147042CC499581786CA6565D5F3FB7C59 +E446E520BB50D3857CA3323E665C9F86A87D3CD45C

      If I use no_ticket option on the server, each my request have different Session-ID.

      What I understand, is that session caching could set the old session-id or create new one, each time new connection occurs.

      But... what I misunderstood is:

      • How can I get the session ID from the $CLIENT socket?
      • If I enable the session caching, do I renegotiate each time new connection arrives?
      • If the session id is different every time, how can I understand that the caching is working? Wireshark? or debug?

      Thanks
        How can I get the session ID from the $CLIENT socket?

        I think you would have to patch Net::SSLeay.

        If I enable the session caching, do I renegotiate each time new connection arrives?

        Yes, but its shorter negotiation. See SSL.

        If the session id is different every time, how can I understand that the caching is working? Wireshark? or debug?

        Not sure. A simple way would be to benchmark (with cache should be faster).