full-disclosure - Re: Python ssl handling could be better...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimpHaXHfY+nMfedZyuX1frwE5WjaiseXskFV_PN@mail.gmail.com>
Date: Wed, 2 Mar 2011 06:23:48 -0800
From: Charles Morris <cmorris@...odu.edu>
To: Brian Keefer <chort@...ps.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Python ssl handling could be better...

> - ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION
> BTW there really isn't a security difference between encrypted-but-unauthenticated traffic and just plain unencrypted traffic.  The only "attacker" you're defeating is a casual observer,

Fail. I hear the blackhats cackle as you switch to telnet. There are a
million and one attack scenarios where what you have is an observer,
please remember that to execute a MITM you actually have to be in the
middle of something. That's A LOT more difficult than configuring a
SPAN port and running snort. Especially so when you have to be
invisible... you can't just waltz around changing routing tables or
physically sticking a server on top of a rack of switches and expect
not to be noticed.

Not to mention the fact that at any one time you may have N active
sessions, an attacker has to begin his attack at a specific point in
time, thereby only glimpsing (or MITM-ing) NEW sessions at that point
in time, instead of probably being able to hijack the N active
sessions as with an unencrypted protocol.

NOT TO MENTION the fact that doing a live hijack of an encrypted
protocol is severely extended in difficulty by the length of the
session and not observing the beginning transaction (in general). One
would have to crack the key, figure out what the protocol was and how
to hijack it, and execute the attack- all before the session ended-
which in itself is a computational feat that only an attacker with
HUGE resources could accomplish (assuming a "good" algorithm choice,
key length, and session length).

Organized MITM by governments and backbone providers? A resounding YES
this is an issue.
MITM by disgruntled employee X or blackhat trudy? Not so much.

>>Maybe it's even worse than pointless.

It's the idiot user's fault if they don't understand the difference
between authentication, encryption, and authentication + encryption.
Even somebody who has near-zero computer experience should know the
definitions of these words. It's the idiot application's fault if it
does not
explain the scenario to the user i.e. "this connection is encrypted
but unauthenticated".

The solution is to EDUCATE users instead of putting silly annoying
warning banners- that people just click through anyway- on my browser
every time I try to use a self signed cert...

There was a study a while back on how extended validation certificates
do effectively nothing against a phishing site / MITM attacks.

In short-
Encryption without authentication is ALWAYS BETTER than no encryption
Authentication without encryption is ALWAYS BETTER than no authentication
Encryption with authentication is ALWAYS BETTER than either of the
above two scenarios

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/