"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"."
http://hakipedia.com/index.php/CAM_Table_Overflow#Description --- On Sat, 1/22/11, Camaleón <[email protected]> wrote: > From: Camaleón <[email protected]> > Subject: Re: Let's talk about HTTPS Everywhere > To: [email protected] > Date: Saturday, January 22, 2011, 9:00 PM > On Sat, 22 Jan 2011 13:37:20 -0600, > Boyd Stephen Smith Jr. wrote: > > > In <[email protected]>, > 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 > > > -- > To UNSUBSCRIBE, email to [email protected] > > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: http://lists.debian.org/[email protected] > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
