Re: [Full-disclosure] Python ssl handling could be better...

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.
Hosted and sponsored by Secunia -

Relevant Pages

  • Re: Block cipher and CBC based MAC using the same key / stream cipher based MAC
    ... should use different keys for authentication and encryption. ... find this attack. ... encryption key and E_Kas your authentication key. ... provably secure, assuming that the block cipher is good, and if it isn't ...
  • Re: MAC / MIC / MD for short messages
    ... potential attack vectors. ... If the encryption and authentication both use X, ... and having K primitive leads to a document (and ...
  • Re: Strong vs. Weak Authentication
    ... > What is the difference between Strong and Weak Authentication? ... If a session is protected by encryption that has ... Authentication architectures using plaintext, ... sessions are stronger. ...
  • Re: MAC / MIC / MD for short messages
    ... potential attack vectors. ... If the encryption and authentication both use X, ... Isn't it better to use two different methods, as after breaking of X, ...
  • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
    ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...