Re: Let's talk about HTTPS Everywhere
On Thu, 20 Jan 2011 16:57:52 -0500, Celejar wrote:
> On Thu, 20 Jan 2011 15:26:31 +0000 (UTC) Camaleón wrote:
>
>> In regards to "http cookie hijacking" the first and foremost a
>> programmer would ask himself is "do we really need to *constantly*
>> generate a write/ read operations of the cookies for *all* the tasks?".
>> On these days, no one of us can browse the web and join to online
>> services with a completely cookie disabled browser and that's a bit
>> excessive, IMO.
>>
>> If the data, that now is being exchanged between the server and user's
>> computer by means of cookies, is to be stored in the server itself in a
>> database, most of theses attacks could be prevented.
>
> How? However your browser is identifying itself to the server, if
> encryption isn't in use, that token can be hijacked.
Well, I already said that the login screen is a "key point" (where the
user provides sensible data) and as such has to use a secure channel and
enforce data encryption but not the remainder traffic. So the problem
here is about identifying the unneeded and avoidable information exchange
that flows between the server and the client. Using cookies for tracking/
identifying the user's session can be replaced with another methods or
can require additional security measures for verifying the authenticity
of the client.
Sensible data needs, at least, a secure/encrypted channel... is the
user's session ID considered "sensible", okay, then use it but do not
abuse of it!
>> In addition, enforcing a good policy, like user login session
>> regeneration or logouts, also help but these options are not always
>> neither implemented nor enforced and most of the new "cloud" services
>> rely on full-session encryption to simplify things.
>
> Again, I'd certainly want full-session ideally, to avoid MITM and
> similar threats.
I can see that many of the new "cloud services" need to use encryption to
protect their users but not all the sections of the sites require the
same level of confidentiality, neither all the actions do, i.e., do you
need to use a secure channel when performing a google search, browsing
digg, reading slashdot or even posting to this mailing list?
What I mean is that enforcing a 100% https policy without a notion of
what we want to prevent would be like telling people that whenever they
are going shopping and use their plastic credit card, tell the seller
"please, do not look at it" to avoid him getting the numbers >:-)
Greetings,
--
Camaleón
Reply to: