Re: Let's talk about HTTPS Everywhere
On Thu, 20 Jan 2011 15:26:31 +0000 (UTC)
Camaleón <noelamac@gmail.com> wrote:
> On Wed, 19 Jan 2011 16:09:30 -0500, Celejar wrote:
>
> > On Wed, 19 Jan 2011 17:50:58 +0000 (UTC) Camaleón wrote:
> >
> >> On Wed, 19 Jan 2011 18:07:36 +0100, tv.debian@googlemail.com wrote:
> >
> > ...
> >
> >> > It is not only the data enclosed inside the cookie which are at risk
> >> > here, but the entire session on the website you are logged in. Say
> >> > you log into your "friendface" account, and someone near your catch
> >> > your unencrypted session cookie, then he is YOU on YOUR "friendface"
> >> > account...
> >>
> >> That sounds like bad programming or a buggy site. There are methods to
> >> prevent such attacks on the server side that involves no encrypted
> >> sessions, but sometimes it is easier (and cheaper) for companies to
> >> rely on completely encrypted sessions and not implement another
> >> countermeasures.
> >
> > I'm curious - how can one completely guard against a MITM attack without
> > using encryption?
>
> We were talking about "session hijacking" which is a bit different from
> "man in the middle" attacks. In fact, this kind of threat ("man in the
> middle") cannot even be totally prevented with just "https" (the Sans
> Institute published a good article on the matter¹ -as well as another
> interesting papers that can be found here²) so when it comes to security,
> relying in only "one point" of failure should be avoided at all.
Interesting, thanks. But the service provider should still be doing
SSL to avoid MITM attacks (AFAICT from the SANS paper's abstract, the
problems with SSL have to do with faulty implementations, and can be
avoided / mitigated with proper ones, and user care).
> 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.
> 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.
> ¹http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480
> ²http://www.sans.org/reading_room/whitepapers/threats/
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: