Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Mozilla Thunderbird SMTP down-negotiation weakness
From: Tim <tim-security () sentinelchicken org>
Date: Sun, 16 Oct 2005 09:25:18 -0400

I agree that this is less than optimal.  Could you point me to the bug
report you filed in bugzilla that requests these changes?

Here is one, you can follow the links to other ones :)
https://bugzilla.mozilla.org/show_bug.cgi?id=154641

Good, at least you reported it.  


It probably isn't that hard.  Why don't you write a patch? 

I dont have any knowledge of programming.

Ah.....  That explains a lot.


Honestly though, this stuff is such a miniscule portion of overall
security...  How many users actually care when websites don't even have
valid certificates?  Heck, most browsers don't even check for CRLs by
default, including IE.

True, but the ones who would like to check, they find that it is 
impossible. And the ones who are not used to check it, take an example 
from Opera how to make them check it: It clearly displays the symmetric 
and asymmetric key sizes in the addresslike/statusline when you are in 
https connection. Also, it warns if the symmetric keysize is secure, but 
asymmetric is insecure.

And how would you define what is "secure" and what is "insecure"?
Obviously some key sizes shouldn't be used nowadays, but which can be
trusted?  While you are at it, why don't you start a crusade against RC4
in SSL, since it leaks key information at the beginning of conversations
for certain IVs.

Does this help users against SQL injection, XSS, overflows and string
format holes?  Nope.

Yes, it should be addressed.  I totally agree.  Geeks like us tend to
care about key sizes from time to time, and it would be nice if our
paranoia was aleviated.  Your sharp criticism of the Mozilla developers
seems a bit misguided though.  They really should work on fixing their
overflows and other nastier bugs before worrying too much about GUI
components give the same information that openssl at the command line
can provide you with.  For instance, run this:
  openssl s_client -connect HOSTNAME:443
and you can get all the info you need.


There are many many more, much easier ways to steal someone's sensitive
info without attacking the crypto.

Sometimes. But that doesnt mean that obious weakness should not be 
fixed. Heck, why even bother patching at all, since the "weakest" link 
is "always" the dumb user who will execute any file you email to 
them...lets just forget Windowsupdate then, and new versions to Firefox, 
right? ;)

Your slippery slope relies on the same argument I am making.  I said
there's a lot easier ways to attack a user.  One example is to exploit
their own stupidity, but I did not limit my scope to that.  Software
vulnerabilities are numerous on both ends of the HTTP conversations,
many of which can compromise all the information that is going over SSL.
Why bother with taking a host in the middle of the conversation AND
cracking the crypto when you can just hit one of the end points and call
it a day?

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault