Forum Discussion

Brian_69413's avatar
Brian_69413
Icon for Nimbostratus rankNimbostratus
Sep 22, 2011

SSL vs Non-SSL portions of the a website

How do you folks handle SSL(protected) vs non-SSL(public) content on a website while holding persistence for authed users.

 

 

We have a site where visitors can log in to view customized content or browse as a guest and see default content.

 

 

When they get to protected pages, they need to be logged in and the site needs to switch to SSL, but the rest of the site we would like to be non-SSL.

 

 

If we have two virtuals, one for port 80 and the other for port 443, but a shared pool of servers, how would we handle keeping a user with a particular server(persistence) to keep them logged in?

 

 

Lots of e-commerce sites do this, and I hope it does not have to be by replicating session data between servers...

 

config
design
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Sep 23, 2011
    You can do persistence across virtual servers with a persistence profile... There's 3 options, selectable individually to match across services, virtual servers and pools. You really just want to match across virtual servers (i.e. your port 80 and your port 443 VS). The persistence profile can be of any type (So it'd probably be cookie in your case).

     

     

    That should do what you want...

     

     

    H

     

  • Brian_69413's avatar
    Brian_69413
    Icon for Nimbostratus rankNimbostratus
    Sep 26, 2011
    That is certainly easier than I expected...so a session cookie, for example, will hold true to a pool member even when swapping virtuals with the same pool? What would that session cookie do for you if it was a different pool with different members in the second virtual?
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Sep 26, 2011
    What the session cookie does for you depends on whether it's set for persistence within a VS only, across a service, across VS's, or across pools...

     

     

    A normal session cookie (NO matching) will be ignored by a second VS with a different pool.

     

     

    A persistence across services will ensure that the same pool behind two VS's with the same IP wil hold persistence for a client (i.e. client will hit the same poolmember for :80 and:443 on site.com).

     

     

    A persistence across VS's will ensure that my1.site.com:80 and my2site.com:443 will hold persistence for a client.

     

     

    A persistence across pools will ensure that even if the pools are different...

     

     

    Note that the membership of the default pool in this instance isn't checked... So it could lead to a security hole in your site if you don't encrypt the cookie...

     

     

    H

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Sep 26, 2011
    The (vulnerability?|Opportunity for a more interesting life?) exists in match across pools... I don't believe it exists in match across VS and service (But haven't checked), but it's certainly worthwhile making sure that if you have persistence across anything and are using cookies, then make sure you encrypt the cookie...

     

     

    H
  • Brian_69413's avatar
    Brian_69413
    Icon for Nimbostratus rankNimbostratus
    Sep 27, 2011
    Persistence across service is all I would need. Thanks for this insight!
  • Austin_Geraci's avatar
    Austin_Geraci
    Icon for MVP rankMVP
    Oct 04, 2011
    One thing to note. If you're looking to maintain persistence using the same exact pool across multiple VSs, you can maintain persistence via inserting a custom cookie (specify the name), no need for "match across" option..

     

     

    Since the pool members are the same and if specify the cookie name the cookie will be the set the same when you hit the different VSs with the same exact pool.. This will work even when hitting a completely different LTM, considering the Pool makeup is exactly the same..

     

    That specific scenario isn't documented well anywhere.. but I can confirm it works as I'm using it in multiple high volume production environments..

     

     

    sol6917: Overview of BIG-IP persistence cookie encoding

     

    http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html?sr=13525090

     

     

    sol5837: Match Across options for session persistence

     

    http://support.f5.com/kb/en-us/solutions/public/5000/800/sol5837.html?sr=16887030