full-disclosure - Re: Microsoft Outlook Vulnerability: S/MIMELossof Integrity

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]

Date: Mon, 17 Jun 2013 17:19:23 +0200
From: "ACROS Security Lists" <lists@...os.si>
To: <Valdis.Kletnieks@...edu>,
	<security@...ossecurity.com>
Cc: full-disclosure@...ts.grok.org.uk,
 'Defence in Depth' <defenceindepth@...il.com>
Subject: Re: Microsoft Outlook Vulnerability: S/MIMELossof
	Integrity

Valdis,

> No, that's how to do it *hardline*.  There's many in the 
> security industry that will explain to you that it's also 
> doing it *wrong*.  Hint - the first time that HR sends out a 
> posting about a 3-day window next week to change your 
> insurance plan without penalty, signs it with something that 
> doesn't match the From:, and the help desk is deluged by 
> phone calls from employees who can't read the mail, the guy 
> who put "You shall not pass" in place will be starting a job hunt.

If there was an industry standard specifying the you-shall-not-pass for all web
browsers, it wouldn't be the guy (developer) who put this roadblock in place that
would start a job hunt but someone within the company whose job was to avoid the
roadblock by making sure the cert that HR is using was okay. That would happen a
couple of times, and then not any more, as people have great capacity for learning.

But if just one browser vendor replaced warnings with roadblock errors, users would
likely migrate to other vendors to achieve - seemingly - the same.

> For even more fun, think about the failure modes when an 
> insurance company blows it while sending to Joe Sixpack's 
> GMail account.  Who's help desk gets called, and how do they 
> resolve it? Probably the ISP, and the user gets told "You 
> could just turn off that checking...."

That's only because one CAN turn of that checking. But that's silly - if you want to
use encrypted email or HTTPS, do it right or don't do it at all.

> And that's what will happen to your proposal.  Security 
> measures that get in the way of actual work *will* get turned off.

Security is pretty much always in the way of productivity. If I get an encrypted
message that was mistakenly not encrypted with my key, it would be very productive to
have a "Just decrypt anyway" button but we obviously don't have that. I know this is
an extreme example but it illustrates that we only get reliable security where it
happens to be hardline.

It may seem extreme to not show an email with invalid signature - but if attacker can
claim that the signature was invalidated by a mailing list server and that "it's
quite okay, don't worry, just trust me," we haven't achieved ANY security there -
just wasted a lot of time of a lot of people.

But maybe most people don't really want actual security but prefer the theatre. The
meaning of "right" and "wrong" in this discussion would largely depend on that.

Cheers,
Mitja

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