Forum Discussion

merill_60420's avatar
merill_60420
Icon for Nimbostratus rankNimbostratus
Dec 07, 2010

Can't resume SSL sessions

I've configured SSL termination for my application (Oracle AS - SSO) at my BigIP device (v10.1.0). I'm using the default tcp, http, and clientssl profiles. After implementing this, I've noticed that every request is generating a new SSL session, rather than reusing existing sessions.

 

 

 

Sample ssldump - SSL offload:

 

 

 

38 1 0.0036 (0.0036) C>S Handshake

 

ClientHello

 

Version 3.1

 

cipher suites

 

Unknown value 0xc00a

 

Unknown value 0xc009

 

Unknown value 0xc007

 

Unknown value 0xc008

 

Unknown value 0xc013

 

Unknown value 0xc014

 

Unknown value 0xc011

 

Unknown value 0xc012

 

Unknown value 0xc004

 

Unknown value 0xc005

 

Unknown value 0xc002

 

Unknown value 0xc003

 

Unknown value 0xc00e

 

Unknown value 0xc00f

 

Unknown value 0xc00c

 

Unknown value 0xc00d

 

TLS_RSA_WITH_AES_128_CBC_SHA

 

TLS_RSA_WITH_RC4_128_SHA

 

TLS_RSA_WITH_RC4_128_MD5

 

TLS_RSA_WITH_AES_256_CBC_SHA

 

TLS_RSA_WITH_3DES_EDE_CBC_SHA

 

TLS_RSA_WITH_DES_CBC_SHA

 

TLS_RSA_EXPORT_WITH_RC4_40_MD5

 

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

 

TLS_DHE_DSS_WITH_AES_128_CBC_SHA

 

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

 

TLS_DHE_DSS_WITH_AES_256_CBC_SHA

 

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

 

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

 

TLS_DHE_RSA_WITH_DES_CBC_SHA

 

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

 

TLS_DHE_DSS_WITH_DES_CBC_SHA

 

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

 

compression methods

 

NULL

 

38 2 0.0038 (0.0001) S>C Handshake

 

ServerHello

 

Version 3.1

 

session_id[0]=

 

 

 

cipherSuite TLS_RSA_WITH_AES_128_CBC_SHA

 

compressionMethod NULL

 

38 3 0.0038 (0.0000) S>C Handshake

 

Certificate

 

38 4 0.0038 (0.0000) S>C Handshake

 

ServerHelloDone

 

38 5 0.0125 (0.0087) C>S Handshake

 

ClientKeyExchange

 

38 6 0.0141 (0.0015) C>S ChangeCipherSpec

 

38 7 0.0142 (0.0000) C>S Handshake

 

38 8 0.0142 (0.0000) S>C ChangeCipherSpec

 

38 9 0.0142 (0.0000) S>C Handshake

 

38 10 0.0174 (0.0031) C>S application_data

 

38 11 0.0224 (0.0050) S>C application_data

 

38 12 0.0225 (0.0000) S>C application_data

 

38 14 0.0245 (0.0001) S>C application_data

 

38 15 0.0248 (0.0002) S>C application_data

 

38 16 0.0248 (0.0000) S>C application_data

 

38 0.0250 (0.0001) S>C TCP FIN

 

38 17 0.0289 (0.0039) C>S Alert

 

38 0.0289 (0.0000) C>S TCP FIN

 

 

 

When the virtual server was previously set up with SSL passthrough (no http or clientssl profiles), I could see the SSL sessions being reused (no CERTIFICATE or CLIENTKEYEXCHANGE) for the same request.

 

 

 

Sample ssldump - SSL passthrough:

 

 

 

38 1 0.0017 (0.0017) C>S Handshake

 

ClientHello

 

Version 3.0

 

resume [16]=

 

43 04 a9 b8 25 40 96 f8 91 be 1f 4a 86 3c c9 84

 

cipher suites

 

SSL_RSA_WITH_AES_128_CBC_SHA

 

SSL_RSA_WITH_RC4_128_SHA

 

SSL_RSA_WITH_RC4_128_MD5

 

SSL_RSA_WITH_AES_256_CBC_SHA

 

SSL_RSA_WITH_3DES_EDE_CBC_SHA

 

SSL_RSA_WITH_DES_CBC_SHA

 

SSL_RSA_EXPORT_WITH_RC4_40_MD5

 

SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

 

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5

 

SSL_DHE_DSS_WITH_AES_128_CBC_SHA

 

SSL_DHE_RSA_WITH_AES_128_CBC_SHA

 

SSL_DHE_DSS_WITH_AES_256_CBC_SHA

 

SSL_DHE_RSA_WITH_AES_256_CBC_SHA

 

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

 

SSL_DHE_RSA_WITH_DES_CBC_SHA

 

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

 

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

 

SSL_DHE_DSS_WITH_DES_CBC_SHA

 

SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

 

compression methods

 

NULL

 

38 2 0.0045 (0.0027) S>C Handshake

 

ServerHello

 

Version 3.0

 

session_id[16]=

 

43 04 a9 b8 25 40 96 f8 91 be 1f 4a 86 3c c9 84

 

cipherSuite SSL_RSA_WITH_RC4_128_SHA

 

compressionMethod NULL

 

38 3 0.0058 (0.0013) S>C ChangeCipherSpec

 

38 4 0.0058 (0.0000) S>C Handshake

 

38 5 0.0074 (0.0015) C>S ChangeCipherSpec

 

38 6 0.0074 (0.0000) C>S Handshake

 

38 7 0.0075 (0.0000) C>S application_data

 

38 8 0.0130 (0.0055) S>C application_data

 

38 9 0.0167 (0.0037) S>C application_data

 

38 10 0.0168 (0.0000) S>C Alert

 

38 0.0168 (0.0000) S>C TCP FIN

 

38 11 0.0524 (0.0356) C>S Alert

 

38 0.0525 (0.0000) C>S TCP FIN

 

 

 

Is this the expected behavior? Turning on oneconnect definitely helps by reducing the number of handshakes, but since each handshake is resulting in a key exchange, I wonder if it's just masking a problem. If this is not supposed to happen, am I just missing some extra configuration at my application server or LTM?

 

 

 

Thanks,

 

merill

 

4 Replies

  • You mentioned being on 10.1.0. Is it possible you are hitting this issue?

     

    SOL8933:Server-side SSLv3-only connections are aborted when attempting to resume an SSL session

     

     

  • Checked the article, thanks. I'm not using any ServerSSL profile, though.

     

     

    Another thing I should mention is that the "KeepAlive Off" is set in my http server, per Oracle/F5 configuration: http://www.oracle.com/technetwork/middleware/ias/bigip-1-132437.pdf

     

     

     

    This looks like the obvious reason why SSL sessions are not resumed, but in my SSL passthrough setup (with KeepAlive Off), I do see resumed SSL sessions.

     

     

     

     

  • Hi Merill,

     

     

    SSL session reuse should be independent of the TCP connections as clients can resume a session on a new TCP connection.

     

     

    I'm not sure why you'd see this with a default client SSL profile as LTM should cache sessions. Has the default client SSL profile been modified? What is the Cache Size set to?

     

     

    You can test whether LTM is allowing reuse using opessl:

     

     

    from: http://royontechnology.blogspot.com/2008/01/how-to-find-out-if-server-supports-ssl.html

     

     

    openssl s_client -reconnect -state -prexit -connect ServerURL

     

     

    Assuming the openssl test shows support for session resumption, maybe there's an error happening on the initial session which triggers LTM to remove the session from its cache? It's a stab in the dark.

     

     

    It would probably be fastest to open a support case on this to get help troubleshooting the issue.

     

     

    Aaron
  • Merill,

     

     

    I know it's been a little while since there was any activity on this thread, but if you are still having issues with this check out SOL12248. That is likely the solution for you. There was an issue when a COMPAT cipher was chosen and the client advertised support of the TLS session ticket extension. Corrected in 10.2.0 HF2 and 10.2.1. If not, I'd suggest opening a case with support.