Rewrite cookie tags on CSS11506

squigg · ‎12-11-2003

A client is using CSS11500 with SSL modules to do network based HTTPS.

This presents some problems on the Web Servers as the applications have no idea they are running over an HTTPS connection to the user, as the only traffic they see is HTTP.

Unfortunately this means we cannot set Cookies as "secure", which poses a potential man-in-the-middle attack against user browsers, which will happilly the give up Cookies over HTTP which should only ever be delivered back over HTTPS.

Can the 11506 re-write these application Cookies "secure" tag to "Yes"?

The documentation suggests it can't, but I can't believe this is the only client with this problem.

Thanks for your help,

Stephen

np · ‎12-11-2003

whilst you should still look for a solution to this I believe you are ignoring a risk by relying on the secure flag

For one the secure flag is nothing but a flag, it is up to the browser to honour it, have you tested how many properly do?

If you are looking for security then your cookies should contain encrypted data only readable by you

The client has no need to read the data only send it back to you (unless you are manipulating it with javascript)

By encrypting it you are fairly immune to man-in-the-middle attacks as the attacker will have to know how you are encrypting the data, with what keys and what the data means

If you do not have any control over the web application then perhaps proxy service that sits in between server and the switch and encrypts/decrypts the data would serve you better than looking at the secure tag

If the attacker can maniplute the users dns they could appear to be a secure server at your address and get the cookie data even if you get the flag sorted and the browser correctly honours it

squigg · ‎12-12-2003

I'm well aware of the risks around relying on a browser to honour the rules - these cookies contain fully encrypted data, however this has no relation to the problem of a man in the middle attack.

It is much harder to do a man-in-the-middle attack using SSL as the cert used to set up SSL between the attacker and the browser needs to appear genuine for the site name in use.

Setting the cookie "secure" flag is part of a belt-and-braces approach to security and not a solution on it's own.

If the browser is asked to give the cookies up over non-SSL connections, IE (the app platform) has been tested and will not give them up if the secure flag is set, however in the system we are talking about they can be given up.

Encrypting the cookies has no bearing on a man in the middle attack - if an attacker gets the cookies they can use them to login as the user against the website, as the contents of the cookies along with source IP is the only way the website can identify a logged in user.

We tried a reverse proxy to get round this but it did not work - if Apache is not configured for SSL it strips the secure flag, hence our wish to do it on the CSS.

Unfortunately there appear to be many small niggles with implementing SSL on the network which are not apparent, this isn't a criticism of the device, but a view of what happens when you seperate previously bound-together services, in this case SSL and HTTP.

np · ‎12-12-2003

Glad you are well informed already.

do you want pursue the apache proxy route? or are there other problems with it for you?

Are you saying if an application generates a cookie with the secure flag set the flag gets removed by mod_proxy or are using something within apache to generate the cookie?

> Setting the cookie "secure" flag is part of a belt-and-braces approach to security and not a solution on it's own.

So true

whilst encrpyting the data would not stop a attack on that user, it would hinder the attacker trying to get into other accounts or crack passwords

One other thought

It sounds like you are in a fairly well controlled environment with a known user base? Are client certificates a feasible option?

If you rejected this I'd be interested as to why

Sorry to ask questions without giving many answers

Neil

squigg · ‎12-12-2003

Glad to have someone who knows CSS SSL to discuss this one, so thanks for your opinions and thoughts - they are very welcome.

Agree entirely other user accounts are difficult to compromise, but the nature of the system means compromising just one account can lead to problems. It's not publically live yet, hence me recitence to tell you what type of users it has!

I was a bit misleading in my description as there is also a specialised internet population using it in addition to a large group of trusted users, so client certs are sadly out of the equation.

>Are you saying if an application generates a cookie with the secure flag set the flag gets removed by mod_proxy or are using something within apache to generate the cookie?

I've just asked the person who told me Apache was the problem and mod_proxy was not tried, so I was mis-informed when told Proxy didn't work - doh! It appears Apache bakes the cookies, not the application and if it's not configured for SSL it never sets the "secure" tag, so the problem is convincing Apache to set the flag when running in non-SSL config - I'll ask the guys to investigate this, so thanks.

Hence our initial idea of trying to re-write the cookies on the CSS.

I'm having a look at the CSS scripting language now to see if that can help, but I had hoped this was a common problem with the SSL module - I suspect it is, but most don't bother trying to solve it, or don't notice it!