To many Cookies

I've not heard talk of anything like that, combining the cookies. This is something I'd recommend submitting a request for via your support rep so that it can get tracked by the devs as something that's desired in the future.

 

 

Colin

In most cases, ASM actually create one TS cookie for all domain cookies.

 

In some cases it will create a few TS cookies (it depends on the policy configuration), but definitely not one per domain cookie. if you will open a case with support they could easily help you understand the source of these cookies.

According to both SOL6850 and Sol 7354, BIG-IP ASM creates 2 types of cookies , the main ASM Cookie (TSXXXXXX) and the ASM Frame cookie (TSXXXXXX_d)each serving differ functions.

 

 

 

Infact in practical reality I found that that which was described in these SOL texts differs from what I observed, apart from the fact that ASM creates multiple cookies within a session sometimes up to 6 or more cookies, the names of these cookies is also different to the TS names shown above. I never actually seen a Frame cookie with the _d stated, all cookies observed where in the form TSXXXXXX, sometimes the names would be different whilst the value remained the same, can't understant the purpose of that.

 

 

 

I have not being able to get a more comprehensive or white paper type document that explains the internals and setting of ASM cookies, its a black box.

 

 

Furthermore, I run the ASM in a simple rapid negative security mode nothing exotic there, I have spoken to support and they haven’t been able to shed more light on our findings.

 

 

The problem we have with ASM producing multiple cookies is that it limits our desire to cater for all currently used browsers.

 

 

According to rfc2109, all browser *must* support a minimum of 20 cookies per domain name, problem is IE6 which is still widely used, has taken that number to mean minimum & maximum. Firefox allows 50 cookies. Safari 1000. Opera 50.

 

 

Unfortunately IE6 did ignore this clear standard, it would only support a total of 20 cookies and our app already use close to 20, the fact that ASM now produces multiple cookies means we’ll be decreasing IE6 user experience ⇒ older cookies gets discarded to make space for newer ones during the same session.

 

 

I have already suggested to support about creating a single algorithm within ASM that makes sure that only one ASM cookies ever gets created to protect other cookies, see Cookies is are very expensive to us, infact cookies are bread & butter.

 

Hi jquadri,

 

 

I wonder if the requests are passing through multiple ASM-enabled virtual servers? Can you post some examples of the ASM cookie names. They should start with TS. I'd expect the cookie name for one web application should always be the same as it's a hash of the web application name. If the clients are accessing several subdomains on the same domain which all use ASM, maybe a solution would be to use an iRule to set the domain on the cookies to the fully qualified subdomain. This would ensure the client would only include the ASM cookie for the specific web application.

 

 

That said, F5 Support should be able to explain the logic for when ASM cookies are used--if not what the cookies contain (the latter being proprietary). If the high number of cookies is breaking your application and the product manager of ASM says the behavior you're seeing isn't expected, I think you have good grounds to push F5 to explain why you're seeing so many ASM cookies.

 

 

Aaron

Aaron, the requests are not through multiple ASM, one VIP per single ASM policy. see an obfuscated session seen through HTTP watch for a particular URL below. As you can see, there are indeed 3 unique TS Cookies names, these names then in turn generate 5 unique values

 

 

 

Cooke NameDirectionValuePathDomainExpire

 

CookradSentF/www.foobar.comSat, 12-Dec-2015 00:00:00 GMT

 

CookediSentpriv/www.foobar.comSat, 12-Dec-2015 00:00:00 GMT

 

cooklanguageSentfr/www.foobar.comSat, 12-Dec-2015 00:00:00 GMT

 

regionSentUS/www.foobar.comSat, 12-Dec-2015 00:00:00 GMT

 

COOKIE-IDSent18670353/confidential/www.foobar.com(Session)

 

COOKIE-IDReceived15149633/confidentialwww.foobar.com(Session)

 

CookSSent236dea034e8c2723ea/confidential/www.foobar.com(Session)

 

CookSReceived236dea034e8c2723ea/confidentialwww.foobar.com(Session)

 

JSESSIONIDSent0000nh2UAvelywwm0F9q:j/1/confidential/www.foobar.com(Session)

 

JSESSIONIDReceived0000nh2UAvelywwm0F9q:j/1/confidentialwww.foobar.com(Session)

 

pcook01Sent3567549882.45573.0220/www.foobar.com(Session)

 

TSb5519bSentad0a3a8332ce4b70d54a7504cfd7fbf2663a5ac01ed1c0b1494248d0f945da7s14b88852364a514e01649925ef0fe8cac9s2/www.foobar.com(Session)

 

TSb5519bReceivedc47b3230e29e90bcc2f4207a8b391ec5663a5ac01ed1c0b149424a12f945da7s14b88852364a514e01649925ef0fe8cac9s2/www.foobar.com(Session)

 

TSd4a7b3Sent62018140da31d410d46a211258255069663a5ac01ed1c0b1494248d0f945da7s14b88852364a514e01649925ef099d595fs2d626fe9dd32c60ed/confidential/www.foobar.com(Session)

 

TSfb4472Sent7b94953a2a07baf46135e2e4cf5909b4663a5ac01ed1c0b1494248d0f945da7s14b88852364a514e01649925ef099d595fs260ac0ec50efbd2580aaf8394b766037cagt6/confidential/www.foobar.com(Session)

 

TSfb4472Received57592a963d1114d054522ca088ceceb3663a5ac01ed1c0b1494248d0f945da7s14b88852364a514e01649925ef099d595fs260ac0ec50efbd2580aaf83943e858adeagt6/confidentialwww.foobar.com(Session)

 

 

I was told a while back by ASM development that the ASM cookie name format is TSxxxxxx where the x's are six hex characters generated from the web app (httpclass) name. So if you're seeing multiple ASM cookies being set in the same response, I'd expect it's because there are multiple ASM web applications in the response chain. As you've said that's not the case, I'm not sure what would explain the variety of ASM cookie names.

 

 

Someone from F5 mentioned you have a case open on this. I expect they'll be able to help you investigate this. If you don't mind, can you post the explanation once it's determined?

 

 

Thanks,

 

Aaron

It looks like those are Path Cookies.

 

 

Starting in v9.4.2 we sign Domain Cookies on a per-path basis. Domain Cookies belonging to the root path are signed in the main ASM cookie (TSxxxxxx, where the x's are generated from the HTTPClass name), and those belonging to sub paths are signed in additional ASM cookies with one cookie being added for each distinct paths.

 

 

Having said that, there seem to be three distinct ASM cookies in the above example, and I only see two paths.. there's only three if you count the trailing "/" which is on some cookies and not others, and I'm not sure if that 'should' be considered relevant in terms of distinct paths.

 

 

Aaron

There are 3 ASM cookies because ASM sees 3 different paths in two different requests,

 

- /

 

- /confidential/

 

- /confidential

 

 

In the previous trace, all the cookies have the following path "/confidential", therefore ASM sends only 2 ASM cookies to the client,

 

TSfb4472 Received 57592a963d1114d054522ca088ceceb3663a5ac01ed1c0b1494248d0f945da7s14b88852364a514e01649925ef099d595fs260ac0ec50efbd2580aaf83943e858adeagt6 /confidential www.foobar.com (Session)

 

TSb5519b Received c47b3230e29e90bcc2f4207a8b391ec5663a5ac01ed1c0b149424a12f945da7s14b88852364a514e01649925ef0fe8cac9s2 / www.foobar.com (Session)

 

 

I am trying to delete these TS cookies using an iRule between a created sandwich VIP, the HTTP Response part of my code is off key, can you please check where my logic is going wrong....

 

 

 

when CLIENTSSL_CLIENTCERT {

 

virtual www.mysite1.vip

 

}

 

when HTTP_REQUEST {

 

virtual www.mysite2-vip

 

}

 

 

 

when HTTP_RESPONSE {

 

 

set acookie [HTTP::cookie names]

 

set asmTS "TS\w{6}"

 

 

for {set i 0} {$i < [HTTP::header count $acookie ]} {incr i}{

 

log local0. "the cookes are $i: acookie"

 

if {[info exists $asmTS ] and [HTTP::cookie exists $asmTS] } {

 

 

log local0. "TS matched cookie: $eCookie "

 

HTTP::cookie remove $asmTS

 

log local0. "TS Cookies gone!"

 

}

 

}

 

}

 

 

 

 

Lastly, I also tried deleting using STREAM, no joy with that either, doesn't stream do headers?

 

 

Thanks in advance.

 

 

 

A stream profile operates on the payload only. For a TCP VIP which passes HTTP traffic, the stream profile would affect the HTTP headers and payload. Once you add the HTTP profile, LTM parses the request/response as HTTP and the stream profile only applies to the HTTP payload.

Can you try this example to remove cookies with match the format TSWWWWWW and TSWWWWWW_D:

 
 when HTTP_RESPONSE { 
  
    log local0. "Cookies: [HTTP::cookie count] - [HTTP::cookie names]" 
  
     Save the cookie names in the response to a list 
    set cookies_names [HTTP::cookie names] 
  
     loop through each cookie by name in response 
    foreach a_cookie $cookies { 
  
        log the current cookie name 
       log local0. "a cookie: $a_cookie" 
  
        check the current cookie name to see if it's in the format TS?????? or TS??????_? 
       if { [string match "TS??????" $a_cookie] or [string match "TS??????_?" $a_cookie] } { 
  
          log local0. "matched cookie: $a_cookie" 
  
           Remove the cookie(s) which match the patterns 
          HTTP::cookie remove $a_cookie 
       } 
    } 
 } 
 

Aaron