full-disclosure - Mozilla Thunderbird SMTP down-negotiation weakness

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] [day] [month] [year] [list]

Date: Sun Oct 16 14:25:27 2005
From: tim-security at sentinelchicken.org (Tim)
Subject: Mozilla Thunderbird SMTP down-negotiation
	weakness

> >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