On Thu, May 17, 2012 at 12:07:16PM -0400, Wietse Venema wrote:
> > I think this is the server's cache key, the OP had issues with the
> > SMTP client, so we probably need to "salt" that lookup also. It
>
> Of course. This was just to give the idea how the session key
> structure would change. I have added an equivalent GEN_CACHE_ID
> definition to the TLS client code.
>
> Too bad this can't be fixed in tlsmgr along with time-stamp expiration.
> tlsmgr is a presistent process so it won't be aware that the on-disk
> library image has changed.
FWIW, my implementation would have been the below, which uses the
run-time library version, rather than the compile-time, just in
case the (SSL_SESSION) structure changes (say grows new members)
as the result of a patch.
Index: src/tls/tls_server.c
--- src/tls/tls_server.c 6 Feb 2012 20:10:46 -0000 1.1.1.6
+++ src/tls/tls_server.c 17 May 2012 16:10:48 -0000
@@ -184,6 +184,7 @@
buf = vstring_alloc(2 * (len) + 1 + strlen(service) + 3); \
hex_encode(buf, (char *) (id), (len)); \
vstring_sprintf_append(buf, "&s=%s", (service)); \
+ vstring_sprintf_append(buf, "&l=%ld", (long) SSLeay()); \
} while (0)
Index: src/tls/tls_client.c
--- src/tls/tls_client.c 6 Feb 2012 20:10:46 -0000 1.1.1.7
+++ src/tls/tls_client.c 17 May 2012 16:16:38 -0000
@@ -827,6 +827,12 @@
vstring_sprintf_append(myserverid, "&c=%s", cipher_list);
/*
+ * Finally, salt the session key with the OpenSSL library version,
+ * (run-time, rather than compile-time, just in case that matters).
+ */
+ vstring_sprintf_append(myserverid, "&l=%ld", (long) SSLeay());
+
+ /*
* Allocate a new TLScontext for the new connection and get an SSL
* structure. Add the location of TLScontext to the SSL to later retrieve
* the information inside the tls_verify_certificate_callback().
--
Viktor.
