Forum Discussion
Eduard_Laera_26
Nimbostratus
Nimbostratusbad ssl sessionid containing null byte
Hello Everybody,
We have a problem replicating the SSL Proxy feature "SLL Client Session
insertion" into http headers of a BIGIP v4 System into v9. The iRule
does work but replaces the last byte of the sessionid with a null byte which confuses the service on the members of that pool so it becomes unusable.
Example (unprintable chars made visible):
v.4 behaviour of the "Insert Client Session ID: initial"
SSLClientSessionID: 243a02c81348c645b1eadb80f3ba5767e581490e27be1eaf4b83c36f69af9c1d[13][10]
v9.1.0 behaviour of iRule:
HTTP::header insert [SSL::modssl_sessionid_headers initial]
SSLClientSessionID: 412410b6c661d935751242fbf9bf57da9ed4718a4eda68d4bfabf7266ecdf1e[0][13][10]
We also tried using the shortened version [SSL::sessionid] but
it didn't help neither.
Is this a know bug or is there another setting we overlooked?
Our version is BIG-IP 9.1.0 Build 6.2.
Thanks for any response.
Kind Regards,
Edi
- You could always work around the problem by using SSL::sessionid and then trimming the end off. EG:
HTTP::header insert SSLClientSessionID [string trimright [SSL::sessionid] "\0"]
The trimright may not work but you could also use:HTTP::header insert SSLClientSessionID [string range [SSL::sessionid] 0 end-1] 
Eduard_Laera_26Hi unRuleY,
I think that would be worse.
If the client creates a 128Bit Session Id and there 16 Bit
missing that could mathematically
generate 65536 diffrent session that look like the same.
And thats bad bad for secure ecommerce (beside propper session handling)!
Regards,
Edi
P.S. Of corse we do _not_ rely on the ssl sessionid as a the only
session handler, but others may! Who knows what other side effects
this may cause!- Why don't you encode the data returned by SSL::sessionid using b64encode and use 'HTTP::header insert' to insert the header manually.
- Hi there,
Has anybody managed to create a work-around for this issue?
Kind regards,
Jos - We've determine why the problem occurs and we now have a hotfix available for this. Reference CR57247.
So, this leave you with two options.
a) truncate the null byte off the end and go with the first 31 bytes. If the bigip is terminating the ssl, then this will actually be alright because of the way the bigip generates the session id. You are guaranteed not to encounter the same first 31 bytes in a session id for about 65 years.
b) get the hotfix from support.
Hope that helps.
