Re: Let's talk about HTTPS Everywhere
On Sat, 22 Jan 2011 13:37:20 -0600, Boyd Stephen Smith Jr. wrote:
> In <[🔎] pan.2011.01.22.18.58.17@gmail.com>, Camaleón wrote:
>>On Sat, 22 Jan 2011 15:31:10 -0200, Eduardo M KALINOWSKI wrote:
>>> 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.
>
> Not entirely true. On a hubbed network, putting your network card into
> promiscuous mode will allow you do see other's HTTP traffic and
> "sidejack" them. Even on a switched network, there may be a way to fool
> the switch into giving you enough data from the HTTP traffic to preform
> a "sidejack".
A wired network can be easily monitored while wireless ones need
additional effort. You control the cables so you can control the traffic
and possible "black" points. A misconfigured wifi access point or a buggy
firmware in the device can lead to open access to anywhere inside the AP
range.
> WPA2 is still relatively secure. WEP and WPA have known attacks that
> allow attackers in radio range to effectively "tap" to connection
> between the client and the AP, in addition to joining the AP as a
> client.
And WPA2 with AES encryption is considerably slow. There are also
drawbacks when you enforce to use of the best encryption method.
>>And I still fail to see why should we encrypt _all_ of our browsing
>>steps regardless its nature.
>
> Not encrypting is fine, if you are willing to expose the entirety of the
> connection to "tapping" at various locations. Most notably all the
> switches between you and the destination. However, session cookies (and
> other authentication tokens) are not generally something you want
> disclosed with is why end-to-end encryption with some sort of server
> authentication is recommended for transferring that data.
I would prefer to see a good cookie policy that should be enforced to
companies. If you want to keep a secret do not write it anywhere.
> At the end of the day, a server must use *something* in the request
> itself to associate it with a user. That something must be protected
> from snooping, so end-to-end encryption is required. Encrypted session
> cookies are more secure that any of the HTTP Auth mechanisms for use
> after the initial log in / on. For the initial log in / on, we are
> already accustomed to using SSL/TLS since it is more widely supported
> that any of the secure HTTP Auth mechanisms.
You need more than encrypted traffic to avoid some of those hijacking
attacks. Https helps, sure, but it's not the "panacea" and the "cure" for
all the treats. It should be used in conjunction with additional measures.
> HTTP Everywhere is meant as a way for users to protect themselves when
> the servers refuse to for whatever reason.
If the server refuses to provide https the plugin can't do much.
> Ideally, servers would take only non- sensitive actions and provide
> only non-sensitive information over HTTP (and of course, automatically
> "downgrade" cookies transferred over HTTP to "only for non-sensitive"
> status), but some server don't actually see that as being in their
> interest. (E.g. Facebook loses relatively few page views if it
> discloses too much information about you.)
And precisely Facebook is a perfect example of "bad policy" (they have a
long record of privacy issues, most of them involving coding bugs and
relaxed privacy rules).
Greetings,
--
Camaleón
Reply to: