Re: Let's talk about HTTPS Everywhere
On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
> On 01/22/2011 01:39 PM, Camaleón wrote:
>> I wish I had.. sessions carried at server side, hidden fields in forms
>> or variable uri encoding were the common methods used in the past.
>
> I don't think you've fully understood the problem. The problem is not
> that cookies contain sensitive data (well, some do), but rather that
> even just a session ID - which can be just a random number with no
> meaning other than identifying in the server data related to that user,
> even if has nothing sensitive, can be used to hijack the session if
> another uses gets hold of that ID, depending on how the server side is
> implemented. Several sites fall to this attack (as FireSheep shows). I
> confess I don't have a good solution on how to solve that in the server
> side.
Well, I think the problem is that online services rely just on cookies
(whether encrypted or not) and do not apply additional verification steps
to check if the user is the one who claims to be.
And that's a bad proceeding, IMO.
> If traffic is unencrypted (http), then it's easy to capture session IDs.
> SSL prevents that, even if someone can sniff the traffic, all they get
> is random garbage. (At least in theory, but I don't know of any real
> attack on SSL.)
Yes, but there are also cross-site scripting attacks that are not
mitigated by using ssl but implementing another methodologies (wikipedia
talks about "HttpOnly" flag to use within the http response header but
this is still a draft, if I read it correctly.
> That's the same reason I was advocating that people should not leave
> Wi-Fi (even if public) unencrypted. If traffic is unencrypted, it is
> trivial for anyone to capture session IDs flying in plain text through
> the air. If the network is encrypted, then it is much harder to capture
> other people's traffic. (Should be impossible, but there are attacks.
> But things are much more difficult.)
I agree. Wired networks are not that exposed to these attacks.
>> Cookies are insecure by their own nature and fail to provide a proven
>> mechanism for uniquely identifying users. You can "hide" (by encrypting
>> the file) the content of the cookie and you'll avoid remote side
>> hijacking when someone is sniffing the connection, but the root of
>> problem still remains: should the "hijacker" has physical access to the
>> computer I guess he can also impersonate the login session (someone in
>> the know may want to correct this statement).
>>
>> Or just think about removable flash drive devices with portable
>> versions of the browsers; the owner logins into his online account
>> (facebook, gmail, whatever...), check the "remember me" option and
>> keeps the full session encrypted via https (not just the login part).
>> Another user with access to the flash drive could copy the whole
>> content of the data and re- use (hijack) the cookie that holds the
>> session id.
>
> Well, if someone has physical access to the hardware, it's game over.
> They can do everything with it. Encrypting the contents of the HD can
> limit somewhat what someone can do, though.
Having access to removable media is very easy (they're tend to be left
unattended, mostly at the office) and a high percentage of the people do
not encrypt the data on it neither by software nor hardware.
That's why I choose the flash drive to illustrate the above example.
>> What I was trying to expose here is that http is a protocol designed
>> mostly for single-user sessions [...]
>>
>> Maybe is just we are not using the "right" tool for the job...
>
> I'd agree, but I don't see things changing any time soon. Just see the
> status of IPv6 transition: IPv4 addresses are running out, and yet very
> few people are bothering to switch for IPv6. The same will happen: even
> if a new protocol is proposed, browsers won't rush to support it because
> no sites will be using it, and no sites will use it because few browsers
> support the new protocol.
Yes, and switching to ipv6 should be *a must*, not a *recommended* option.
After all, this discussion was generated because people wanted to use ssl
all the time for all the tasks and I did not agree on that :-)
And I still fail to see why should we encrypt _all_ of our browsing
steps regardless its nature. It reminds me the same argument that people
uses to convince others to switch into imap instead pop. I can accept
that imap provides some advantages, but pop still has it uses.
I'm open to changes but with a good and logical reasoning "inside".
Greetings,
--
Camaleón
Reply to: