Using SSL::sessionid in SSLv2

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

Nice, very good to know, thanks for the more detailed info Aaron.

 

 

Colin

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.