Re: Let's talk about HTTPS Everywhere
"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 <noelamac@gmail.com> wrote:
> From: Camaleón <noelamac@gmail.com>
> Subject: Re: Let's talk about HTTPS Everywhere
> To: debian-user@lists.debian.org
> Date: Saturday, January 22, 2011, 9:00 PM
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
>
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] pan.2011.01.22.21.00.12@gmail.com">http://lists.debian.org/[🔎] pan.2011.01.22.21.00.12@gmail.com
>
>
Reply to: