Full Disclosure mailing list archives
Re: Python ssl handling could be better...
From: Charles Morris <cmorris () cs odu edu>
Date: Wed, 2 Mar 2011 15:36:33 -0500
It's hard to do if you're starting from zero and have to write your own tools. It's not hard to do when you can just download something off the Internet, which is the reality we're dealing with. Jay Beale released a tool to do this years ago at Toorcon. There are many others. Game over on that discussion.
"Oh no toooools exist!?!?!" Wow.
We should be designing systems for a high level of assurance, not "a little bit better than awful." Besides, with the speed at which technology moves and the innovativeness of users, products should be made robust so they can stand up to unanticipated usage. For example, if someone went out and wrote a Twitter client based on python-twitter and it became popular in North Africa, many people would falsely think their revolutionary conversations are "secure" because it "uses SSL", but in fact the oppressive governments can trivially sniff all the traffic (and possibly impersonate trusted users?). An attacker who is motivated to cause harm will find the tools to do what they want, so MITM is not a high bar. There are available tools to do it that don't require expertise. As I said previously, the only attacker defeated by unauthenticated SSL is the one who wasn't going to cause much harm any way.
Ahh yes, the chorus of nerds everywhere. Guess what, most people just do their job, that they're good at, and expect the technology to do the right thing. The assume computer professionals are as thoughtful about making things easy to use and safe as the designers of microwaves, lawn mowers, paper shredders, etc... With those things you have to try really hard to hurt yourself or cause damage. With unsafe SSL you're hurting yourself by default. That would be akin to a microwave melting your eyes if you were "too stupid to wrap the appliance in protective shielding."
The incorrect assumption of the masses isn't our fault and is only marginally our problem :( It's a sad thing, and I'm more than happy to work to educate them. And no, you aren't "hurting yourself by default"; and your microwave-blaming-the-operator example is incorrect, as I also specifically said that it's the application's (client's / microwave's) fault if it does not advise the user of the current security context.
In short- Encryption without authentication is ALWAYS BETTER than no encryptionIt's not. Would you like to jump out of an airplane with a parachute that you THINK will work, but doesn't, or one that actually will work? You'd make a different choice if you knew the chute wouldn't open.
It is. A parachute that works a nonzero % of the time (encryption without authentication) is infinitely better than one that you can BE SURE WILL NEVER WORK (plaintext) The application, or parachute, should warn of the danger involved so the user may make an educated choice.
Authentication without encryption is ALWAYS BETTER than no authenticationNot if it can be captured/replayed to impersonate you in the future. WTF are you smoking?
It is. Authentication that resists a nonzero percentage of attackers (cleartext authentication) is ALWAYS BETTER than no authentication whatsoever. e.g. Turn off authentication on your in.telnetd, post your IP on FD, and tell me how that works out for you.
Encryption with authentication is ALWAYS BETTER than either of the above two scenariosEven a broken clock...
I think that means you agree with me, otherwise I have no idea what you mean.. so.. Burrito! _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 07)
- Re: Python ssl handling could be better... Valdis . Kletnieks (Mar 08)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... bk (Mar 02)
- Re: Python ssl handling could be better... Marsh Ray (Mar 03)
- Re: Python ssl handling could be better... Jeffrey Walton (Mar 03)
- <Possible follow-ups>
- Re: Python ssl handling could be better... Michael Krymson (Mar 04)
- Re: Python ssl handling could be better... bk (Mar 04)
- Re: Python ssl handling could be better... Marsh Ray (Mar 04)
- Re: Python ssl handling could be better... dave b (Mar 04)
- Re: Python ssl handling could be better... Marsh Ray (Mar 07)
- Re: Python ssl handling could be better... bk (Mar 04)
- Re: Python ssl handling could be better... Charles Morris (Mar 07)