Re: Security of HTTP based authentication
Zbigniew Lukasiak writes: > On Thu, Jan 13, 2011 at 3:17 PM, Abigail wrote: > > > On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: > > > > > I have often wondered about that - what is the risk in mixing HTTP > > > images and HTTPS text? > > > > That would depend on the image, and the request to get that image, > > wouldn't? > > Let's assume for now that it is about pure design images (or css), the > same as used on non-authenticated pages. The correct files may be pure design, but if the HTTP traffic has been intercepted and malicious files substituted they could be more sinister: background images or headers could have messages written on them; CSS could hide relevant page elements, or bring in new content which misleads users. Even if you decide you don't care about this for your particular site, there isn't a way of signalling that to browsers, so they won't show the full 'this is a secure site' symbol in their interface. (And apologies for taking a week to reply to this thread.) Smylers -- http://twitter.com/Smylers2
Re: Security of HTTP based authentication
Ash Berlin writes: > The other reason for using another domain (or multiple domains) for > serving static content is that browsers will only open a fixed (4? 6?) > number of concurrent connections to a single domain - by putting > static content on another domain you get higher parallelism. Looks like it was only 2 concurrent connections per site in Firefox 2 and IE7[*1]. IE8 and Firefox 3 increased this to 6 And in Firefox 4 it appears to be 15 (for a total max connections of 30, so using more than two domains may not help). So hopefully this will become less of an issue over time, as browser developers keep up with increases in resources, so site developers don't need to second-guess them. [*1] http://gemal.dk/blog/2008/03/18/firefox_3_beta_5_will_have_improved_connection_parallelism/ Smylers -- http://twitter.com/Smylers2
Re: Security of HTTP based authentication
On 14 Jan 2011, at 13:13, Ash Berlin wrote: > On 14 Jan 2011, at 13:04, David Precious wrote: >> On Thu, 2011-01-13 at 14:09 +, Andrew Black wrote: >>> I have often wondered about that - what is the risk in mixing HTTP >>> images and HTTPS text? >> >> One reason could be that if the web app didn't include 'secure' in the >> Set-Cookie header, the session cookie could be sent in the clear for the >> image requests too, assuming they're requested from the same domain as >> the rest of the page. >> >> Of course, marking the cookie as secure (to be sent only over HTTPS >> requests) would take care of that, as would requesting images from a >> different domain as often seen (ebaystatic.com etc). > > > The other reason for using another domain (or multiple domains) for serving > static content is that browsers will only open a fixed (4? 6?) number of > concurrent connections to a single domain - by putting static content on > another domain you get higher parallelism. Looking at firebug suggests 2 connections in firefox.
Re: Security of HTTP based authentication
On 14 Jan 2011, at 13:04, David Precious wrote: > On Thu, 2011-01-13 at 14:09 +, Andrew Black wrote: >> I have often wondered about that - what is the risk in mixing HTTP >> images and HTTPS text? > > One reason could be that if the web app didn't include 'secure' in the > Set-Cookie header, the session cookie could be sent in the clear for the > image requests too, assuming they're requested from the same domain as > the rest of the page. > > Of course, marking the cookie as secure (to be sent only over HTTPS > requests) would take care of that, as would requesting images from a > different domain as often seen (ebaystatic.com etc). The other reason for using another domain (or multiple domains) for serving static content is that browsers will only open a fixed (4? 6?) number of concurrent connections to a single domain - by putting static content on another domain you get higher parallelism.
Re: Security of HTTP based authentication
On Thu, 2011-01-13 at 14:09 +, Andrew Black wrote:
> I have often wondered about that - what is the risk in mixing HTTP
> images and HTTPS text?
One reason could be that if the web app didn't include 'secure' in the
Set-Cookie header, the session cookie could be sent in the clear for the
image requests too, assuming they're requested from the same domain as
the rest of the page.
Of course, marking the cookie as secure (to be sent only over HTTPS
requests) would take care of that, as would requesting images from a
different domain as often seen (ebaystatic.com etc).
--
David Precious ("bigpresh")
http://www.preshweb.co.uk/
Re: Security of HTTP based authentication
Tom Hukins wrote:
Hi,
> On Thu, Jan 13, 2011 at 07:29:33PM +, Alexander Clouter wrote:
>
> [Lots of good advice snipped]
>
>> I personally would just HTTPS *everything*, the solution is in making
>> your website cache friendly.
>
> I don't understand this, given that nothing should cache HTTPS
> responses. Using HTTPS and cache friendliness seem like two
> contradictory goals to me.
>
Never said you should cache *everything*, just be cache friendly :)
IIRC, browsers will by default cache HTTP data that does not comes with
any cache hints in the headers but for the HTTPS cache they generally do
not ('Cache-control: public' seems to be the thing to force caching to
local disk).
Indeed, you should not cache anything that could contain confidential
and/or user data (anything session specific), however images (such as
logos and products), Javascript and CSS is the kind of stuff that could
be safely cached.
In the example of a online shopping site (dealextreme-esque or fleabay),
how much of that could be aggressively cached? Pulling two numbers out
of thin air, I would probably say somewhere in the 90%+ region?
There is the question of 'snooping' and raiding the local browser cache
for incriminating evidence. If I am on dealextreme/fleabay, the
girlfriend would kill me if she found out I had order yet more 'junk',
but then that's what the porn^Wprivacy browsing mode on browsers is all
about isn't it ;)
>> http://www.ircache.net/cgi-bin/cacheability.py
>
> For a more modern, improved service by the same author, see
> http://redbot.org/
>
Schweet! Thanks for the tip.
Cheers
--
Alexander Clouter
.sigmonster says: May your camel be as swift as the wind.
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 07:29:33PM +, Alexander Clouter wrote: [Lots of good advice snipped] > I personally would just HTTPS *everything*, the solution is in making > your website cache friendly. I don't understand this, given that nothing should cache HTTPS responses. Using HTTPS and cache friendliness seem like two contradictory goals to me. > http://www.ircache.net/cgi-bin/cacheability.py For a more modern, improved service by the same author, see http://redbot.org/ Tom
Re: Security of HTTP based authentication
Zbigniew Lukasiak wrote: > > To add some more context to my question - I am now analyzing what kind > of authentication models I should support - that is write some > exploratory code to check that they are more or less easily realizable > - in WebNano. So what I am looking for are the more universal ways. > But I am also thinking about what I should use in Nblog - to make it a > finished product. > > After your reply and some more research I think I'll settle with the 3 > levels model: > > 1. HTTP without auth > 2. HTTP with auth > 3. HTTPS with auth > > At level 2 someone could also implement additional checks - like > including from time to time an empty image via HTTPS to auth the > unencrypted session with the secure cookie, tie the session to IP, > etc. - but for now I just want to get the overall model right. > *Never* tie to an IP...there are proxy servers out there: http://www.pacfiles.com/images/SSP.htm Also, what stops me coming to you over IPv4...then IPv6, and then back to IPv4? Worth noting my IPv6 address also varies over time... > You wrote that you don't send images via HTTP on a HTTPS page - what > are the reasons for that? > HTTPS is only slow during the initial handshake, transferring the actual encrypted data is *fast*. If you have some el-fango web 2.0-mcwhatsit website with ajax and god knows what else, that's a lot of new HTTP(S) sessions that need to be fired off. HTTP pipelining should help but you will have to twiddle your fingers until web browsers support SCTP. I personally would just HTTPS *everything*, the solution is in making your website cache friendly. By default, iirc, web browsers will not cache anything SSLed; means everytime you refresh the page, thats a lot of new HTTPS sessions being fired up potentially and lots of redownloading...very slow. If you use HTTP headers to instruct web browsers to cache heavily, you will find initially your website is slow, but then very nippy. http://www.ircache.net/cgi-bin/cacheability.py Cheers [1] although often day one you only care about authentication, then later you decide you want encryption everywhere -- Alexander Clouter .sigmonster says: No Canadian coins.
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 02:13:12PM +, Roger Burton West wrote: > On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: > > >I have often wondered about that - what is the risk in mixing HTTP > >images and HTTPS text? > > Leakage of Referer: header? Theoretically, it could be used to attack the encryption of the HTTPS channel. The url of the image will be present both in the plain text requests to the image server and the encrypted page content that was sent to the user. This provides the basis for a known plaintext attack. -- Bruce It is impolite to tell a man who is carrying you on his shoulders that his head smells.
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: > On Thu, Jan 13, 2011 at 01:32:28PM +, Leo Lapworth wrote: > > You wrote that you don't send images via HTTP on a HTTPS page - what > > > are the reasons for that? > > > > > > > Some browsers pop-up alerts if you have mixed HTTP/HTTPS on a page > > I have often wondered about that - what is the risk in mixing HTTP > images and HTTPS text? It's not a specific warning about images, it's a general warning about mixed content, even though http images are the most common cause. With mixed content on a page, the user could be misled about whether information was being transmitted over a secure connection. That simple. -- Bruce The ice-caps are melting, tra-la-la-la. All the world is drowning, tra-la-la-la-la. -- Tiny Tim.
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 3:17 PM, Abigail wrote: > On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: >> On Thu, Jan 13, 2011 at 01:32:28PM +, Leo Lapworth wrote: >> > You wrote that you don't send images via HTTP on a HTTPS page - what >> > > are the reasons for that? >> > > >> > >> > Some browsers pop-up alerts if you have mixed HTTP/HTTPS on a page >> >> I have often wondered about that - what is the risk in mixing HTTP >> images and HTTPS text? > > > That would depend on the image, and the request to get that image, wouldn't? Let's assume for now that it is about pure design images (or css), the same as used on non-authenticated pages. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: >I have often wondered about that - what is the risk in mixing HTTP >images and HTTPS text? Leakage of Referer: header?
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 02:09:16PM +, Andrew Black wrote: > On Thu, Jan 13, 2011 at 01:32:28PM +, Leo Lapworth wrote: > > You wrote that you don't send images via HTTP on a HTTPS page - what > > > are the reasons for that? > > > > > > > Some browsers pop-up alerts if you have mixed HTTP/HTTPS on a page > > I have often wondered about that - what is the risk in mixing HTTP > images and HTTPS text? That would depend on the image, and the request to get that image, wouldn't? Abigail
Re: Security of HTTP based authentication
On Thu, Jan 13, 2011 at 01:32:28PM +, Leo Lapworth wrote: > You wrote that you don't send images via HTTP on a HTTPS page - what > > are the reasons for that? > > > > Some browsers pop-up alerts if you have mixed HTTP/HTTPS on a page I have often wondered about that - what is the risk in mixing HTTP images and HTTPS text?
Re: Security of HTTP based authentication
On 13 January 2011 13:28, Zbigniew Lukasiak wrote: > On Wed, Jan 12, 2011 at 8:41 AM, Leo Lapworth wrote: > > > We set 2 cookies, https (session only) and http (x days) > > > > /account/secure/... > > - HTTPS > > - allows viewing of sensitive information > > - updating of any account information > > - must login each session > > - ALL page content is https (e.g. images/js/css as well), we do not mix > with > > HTTP > > > > /account/ and actually the rest of / > > - HTTP > > - User object available on every page... but restricted... > > - Only has basic viewing of non-sensitive information > > - Can actually update some VERY mundane information - saved items (we do > not > > have a shopping basket so this couldn't pollute an order) > > - Lets users get on with 80% of stuff without having to login each time > > (works for our specific senario). > > > > Hope that helps > > You wrote that you don't send images via HTTP on a HTTPS page - what > are the reasons for that? > Some browsers pop-up alerts if you have mixed HTTP/HTTPS on a page Leo
Re: Security of HTTP based authentication
On Wed, Jan 12, 2011 at 8:41 AM, Leo Lapworth wrote: > On 12 January 2011 07:26, Zbigniew Lukasiak wrote: > >> >From http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_hijacking : >> >> "a large number of websites, although using encrypted HTTPS >> communication for user authentication (i.e. the login page), >> subsequently send session cookies and other data over ordinary, >> unencrypted HTTP connections for performance reasons. Attackers can >> therefore easily intercept the cookies of other users and impersonate >> them on the relevant websites" >> >> So what is the current 'state of art' solution - all application data >> through HTTPS and only images via HTTP? >> > > We set 2 cookies, https (session only) and http (x days) > > /account/secure/... > - HTTPS > - allows viewing of sensitive information > - updating of any account information > - must login each session > - ALL page content is https (e.g. images/js/css as well), we do not mix with > HTTP > > /account/ and actually the rest of / > - HTTP > - User object available on every page... but restricted... > - Only has basic viewing of non-sensitive information > - Can actually update some VERY mundane information - saved items (we do not > have a shopping basket so this couldn't pollute an order) > - Lets users get on with 80% of stuff without having to login each time > (works for our specific senario). > > Hope that helps Thanks! To add some more context to my question - I am now analyzing what kind of authentication models I should support - that is write some exploratory code to check that they are more or less easily realizable - in WebNano. So what I am looking for are the more universal ways. But I am also thinking about what I should use in Nblog - to make it a finished product. After your reply and some more research I think I'll settle with the 3 levels model: 1. HTTP without auth 2. HTTP with auth 3. HTTPS with auth At level 2 someone could also implement additional checks - like including from time to time an empty image via HTTPS to auth the unencrypted session with the secure cookie, tie the session to IP, etc. - but for now I just want to get the overall model right. You wrote that you don't send images via HTTP on a HTTPS page - what are the reasons for that? Cheers, Zbigniew
Re: Security of HTTP based authentication
On 12 January 2011 07:26, Zbigniew Lukasiak wrote: > >From http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_hijacking : > > "a large number of websites, although using encrypted HTTPS > communication for user authentication (i.e. the login page), > subsequently send session cookies and other data over ordinary, > unencrypted HTTP connections for performance reasons. Attackers can > therefore easily intercept the cookies of other users and impersonate > them on the relevant websites" > > So what is the current 'state of art' solution - all application data > through HTTPS and only images via HTTP? > We set 2 cookies, https (session only) and http (x days) /account/secure/... - HTTPS - allows viewing of sensitive information - updating of any account information - must login each session - ALL page content is https (e.g. images/js/css as well), we do not mix with HTTP /account/ and actually the rest of / - HTTP - User object available on every page... but restricted... - Only has basic viewing of non-sensitive information - Can actually update some VERY mundane information - saved items (we do not have a shopping basket so this couldn't pollute an order) - Lets users get on with 80% of stuff without having to login each time (works for our specific senario). Hope that helps Leo
Security of HTTP based authentication
>From http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_hijacking : "a large number of websites, although using encrypted HTTPS communication for user authentication (i.e. the login page), subsequently send session cookies and other data over ordinary, unencrypted HTTP connections for performance reasons. Attackers can therefore easily intercept the cookies of other users and impersonate them on the relevant websites" So what is the current 'state of art' solution - all application data through HTTPS and only images via HTTP? I imagine that one could also use two cookies - one secure and one ordinary session - and then send a link to an empty image over https to periodically authenticate the ordinary session with the secure cookie. But that seems a bit complicated - and guarantees only partial security - the attacker would be able to successfully send a few requests. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
