Forum Discussion

Mike_Maher's avatar
Mike_Maher
Icon for Nimbostratus rankNimbostratus
Jul 31, 2014

Issues with Proxy SSL

I have an ASM with a VS with client and server ssl profiles configured with proxy ssl so that the clients can do certificate authentication to a MobileIron VSP behind the ASM, so far all of the clients are working fine with this setup. However we have an appliance that needs to connect to the VSP and when try to run it through the same Virtual all we see is a CLIENT HELLO in the ssl handshake and then the VSP sends a RST. Now if we remove the ASM and go directly to the VSP everything works fine. What I find really strange is that the CLIENT HELLO is very different and I would not expect that to be case. I have copied what they look like below, I am getting much better with figuring out ssl problems but this on has me stumped. I have opened a case with support, but wanted to put it out here as well to see if anyone has had any experience with this. Any thoughts would be appreciated. I am running version 11.4.1 HF4

 

Here is a CLIENT from the appliance to the ASM (with proxySSL enabled) 1 1 0.0001 (0.0001) C>SV3.1(127) Handshake ClientHello Version 3.1 random[32]= 53 d9 a6 de ca 38 45 43 4f 26 d5 f6 dc ab cf e6 b2 34 95 76 69 2d d8 db 31 d8 5a e3 60 7a 87 0c cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xc013 Unknown value 0xc014 Unknown value 0xc009 Unknown value 0xc00a TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA compression methods NULL

 

Here is the same appliance going directly to the VSP Server 1 1 0.0034 (0.0034) C>SV3.1(175) Handshake ClientHello Version 3.1 random[32]= 53 d9 aa 1b 6b 74 5e e4 9f d3 4b 00 26 29 f5 87 b3 86 ea e4 49 f8 dd 35 12 d7 94 48 3b 38 34 27 resume [32]= b5 11 e0 c3 41 f3 f0 93 08 1a 19 8e 60 90 aa f1 66 5b f4 e2 60 f1 41 fc b6 b0 36 e1 08 cc 96 d1 cipher suites Unknown value 0xff Unknown value 0xc00a Unknown value 0xc014 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA Unknown value 0xc00f Unknown value 0xc005 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0xc007 Unknown value 0xc009 Unknown value 0xc011 Unknown value 0xc013 Unknown value 0x45 Unknown value 0x44 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA Unknown value 0xc00c Unknown value 0xc00e Unknown value 0xc002 Unknown value 0xc004 Unknown value 0x96 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA Unknown value 0xc008 Unknown value 0xc012 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL

 

application delivery
deployment
design
LTM
management
security

3 Replies

Sort By
  • Arnaud_Lemaire's avatar
    Arnaud_Lemaire
    Icon for Employee rankEmployee
    Jul 31, 2014

    Hi Mike,

     

    Could be a cipher negotiation issue, that is the main limit we have with proxy SSL we need to support negotiated ciphers. Could you try to force the appliance to use a supported cipher just to see if we fall in this use case ?

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Jul 31, 2014

    Mike,

    What TMOS version are you running? Also have you seen this SOL? sol13385

    `Proxy SSL supports only the RSA key exchange. For proper functioning, the client and
server must not negotiate key exchanges or cipher suites that Proxy SSL does not support, such as the Diffie-Hellman (DH) and Ephemeral Diffie-Hellman (DHE) key exchanges, and the Elliptic Curve Cryptography (ECC) cipher suite. To avoid this issue, you can either configure the client so that the ClientHello packet does not include DH, DHE, or ECC; or configure the server to not accept DH, DHE, or ECC. Proxy SSL supports only the NULL compression method.`

    Wonder if this is the issue?

    N

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 31, 2014

    If I may add, it seems extremely unusual that the CLIENTHELLO, the very first message in an SSL handshake, would be different between two end points. Are you absolutely certain that the client contacting the VSP through the F5 is the same client that talking directly to the VSP (perhaps different processes)? If you attempt multiple connections with the F5 in place, do you see the same cipher sets in the CLIENTHELLO for each attempt?

     

    It's important to understand that ProxySSL provides a mechanism for the client and server to perform a direct SSL handshake. The ProxySSL function essentially shunts the SSL filter during this phase of the session, captures the pre-master secret token sent by the client, and then enables the filter for (transparent) bulk de/re-encrpytion. In other words, if ProxySSL is configured correctlt, the handshake you see should be between the client and server. What Nathan states from the SOL is important in that the F5 must be able to support the cipher that the client and server negotiate in the handshake (for bulk encryption). As a first test, I would disable ASM, the HTTP profile (if one is applied) and both client and server SSL profiles. This creates a pure layer 4 "SSL tunnel" through the F5. Test connectivity this way. If it works, then re-add just the client and server SSL profiles. Both profiles should have the ProxySSL option enabled, and (at a minimum) the private key associated with the VSP. If you notice that the client and server routinely negotiate a non-RSA cipher, then look into whether it's possible to configure the VSP to prefer RSA ciphers.