Forum Discussion

Hello_world1's avatar
May 20, 2011

Using SSL::sessionid in SSLv2

Hi, everyone.

 

 

If someone has clarification, please tell me.

 

 

 

We will use SSL::sessionid in communication or SSLv2.

 

As sample, we test following irule.

 

But result have noparameter.

 

 

 

I have a quesion.

 

Isn't available SSL::sessionid in SSLv2.

 

 

 

I seached for wiki, but it is not describled.

 

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/SSL__sessionid.htm

 

 

 

 

irule.

 

----------------------------------------------------------

 

when CLIENTSSL_HANDSHAKE {

 

log local0. "SessionID -> [SSL::sessionid]"

 

}

 

 

----------------------------------------------------------

 

 

 

Result log as follows

 

----------------------------------------------------------

 

May 20 09:55:22 local/tmm info tmm[4609]: Rule yotsu_ssl_rule : SessionID ->

 

May 20 09:55:22 local/tmm info tmm[4609]: Rule yotsu_ssl_rule : SessionID ->

 

May 20 09:55:23 local/tmm info tmm[4609]: Rule yotsu_ssl_rule : SessionID ->

 

May 20 09:55:23 local/tmm info tmm[4609]: Rule yotsu_ssl_rule : SessionID ->

 

 

----------------------------------------------------------

 

8 Replies

  • Are you testing on a physical unit or a VM? In a quick test on v10.2.1 VE, I see the same issue:

    when CLIENT_ACCEPTED {
    log local0. "[IP::client_addr]:[TCP::client_port]: Connected"
    }
    when CLIENTSSL_HANDSHAKE {
    log local0. "[IP::client_addr]:[TCP::client_port]: \[SSL::cipher version\]: [SSL::cipher version], \[SSL::sessionid\]: [SSL::sessionid]"
    }
    when HTTP_REQUEST {
    log local0. "[IP::client_addr]:[TCP::client_port]: [HTTP::request]"
    HTTP::respond 200 content "hi"
    }
    

    And the log output:

    : 10.1.0.1:58485: Connected
    : 10.1.0.1:58485: [SSL::cipher version]: SSLv2, [SSL::sessionid]:
    : 10.1.0.1:58485: GET /
    
    : 10.1.0.1:58493: Connected
    : 10.1.0.1:58493: [SSL::cipher version]: SSLv3, [SSL::sessionid]: 0abe7fe49350fc49cbfd6456a4632d083740b9e8d2d7914c8db4cf87c7350c3c
    : 10.1.0.1:58493: GET /
    
    : 10.1.0.1:58510: Connected
    : 10.1.0.1:58510: [SSL::cipher version]: TLSv1, [SSL::sessionid]: 0abe7fe49350fc4acbfd6456a4632d083740b9e8d2d7914d8db4cf87c7350c0f
    : 10.1.0.1:58510: GET /
    

    There was an old (9.1.x) bug (BZ 244363) with SSLv2 and some SSL:: iRule commands but that should have been fixed a long time ago. I suggest opening a case with F5 Support to have them investigate this.

    Aaron
  • Dear Aaron.

     

     

    Thank you for your response quickly.

     

    I'm grad you to answer for my question.

     

     

    > Are you testing on a physical unit or a VM? In a quick test on v10.2.1 VE, I see the same issue:

     

     

    I use to test physical unit which is LTM1500 with ver.10.2.1.

     

     

    > There was an old (9.1.x) bug (BZ 244363) with SSLv2 and some SSL:: iRule commands but that should have been fixed a long time ago. I suggest opening a case with F5 Support to > have them investigate this.

     

     

    I got it.

     

    I will open F5 support case.

     

  • If you find out more on this issue, can you post the case number and/or BD ID?

     

     

    Thanks, Aaron
  • This is feedback.

     

     

    BIG-IP isn't supported by sessionid in SSLv2.

     

    This is by design, not issue.

     

     

    There is no public letter that sessionID must be supported in SSLv2.

     

    If someone knows about this comment.

     

     

    Please let me know.

     

     

    Many Thanks.
  • Thanks for replying. That's not what I expected. Can you reply with your case number so I can look at the details?

     

     

    Thanks, Aaron
  • Thanks for sending the case number. PD explained that we have never cached the session ID for SSLv2 for internal performance reasons. As a result, SSLv2 clients must establish a session each time they connect. Our official recommendation is to not use SSLv2 on the client SSL profile anyhow, so this is more of an academic exercise.

     

     

    Aaron
  • old thread, but perhaps interesting, while investigating a session ID issue i saw this: SSL stickiness is supported only on SSLv3 and TLSv1 sessions. The reason for this is that SSLv2 places the session ID within the encrypted data,

     

    source: http://docwiki.cisco.com/wiki/Secure_Sockets_Layer_Persistence_Configuration_Example

     

    not sure if it is true, but it might give some extra background to this.