Message-ID: <CAH8yC8=d6Ntfoznqsqwbz9yMos4u2zDO1dEc4QBnQwaBETN74A@mail.gmail.com>
Date: Mon, 17 Jun 2013 16:20:12 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Patrick Dunstan <patrick.dunstan@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft Outlook Vulnerability: S/MIME Loss
	of Integrity

On Mon, Jun 17, 2013 at 9:32 AM, Patrick Dunstan
<patrick.dunstan@...il.com> wrote:
> Completely agree with your sentiments here, Valdis.
>
> The error messages given to everyday users are completely ridiculous in most
> cases. I feel though with the padlocks and green bars in browsers nowadays,
> there has at least been some effort made to make security understandable for
> the average user out there. But you're right in saying so much more is
> needed/could be done.
The browsers are just confusing users. Consider:

    No encryption (plain HTTP) - good, no indicators
    Opportunistic encryption (self signed, HTTPS) - bad, red bar
    Encryption (CA, HTTPS) - good, green bar

As Peter Gutmann, puts it, getting a certificate for a website is like
getting one from a vending machine (race to the bottom, FTW), so a CA
certificate has no more value than a self signed certificate used in
opportunistic encryption. Yet users are told opportunistic encryption
is bad, and plain text HTTP is good. And CA's keep making money while
disavowing all warranties and liability for the certificates they
issue.

And don't get me started on the security dialogs written by geeks for
geeks (or more correctly, INTP's and INTJ's from the Myers-Briggs Type
Indicator (MBTI)).

> What bewilders me in 2013 is that email has been completely left behind.
> ...
> Case in point: Google don't even offer support for S/MIME in GMail and it's
> probably the most widely used online email service available today.
+1 (I'd love to give you more).

Jeff

> On Mon, Jun 17, 2013 at 10:23 PM, <Valdis.Kletnieks@...edu> wrote:
>>
>> On Sun, 16 Jun 2013 00:51:10 +0930, Defence in Depth said:
>>
>> > Microsoft Outlook (all versions) suffers from an S/MIME loss of
>> > integrity
>> > issue.
>> > Outlook does not warn against a digitally signed MIME message whose X509
>> > EmailAddress attribute does not match the mail's "From" address.
>>
>> Congrats on the technical side, for spotting this.
>>
>> On the flip side, there are a number of cases where the signer address
>> legitimately does not match the From: address. For instance - if the
>> signer is
>> listed in Sender: instead of From:, if it has passed through a mailing
>> list
>> that rewrites the From: line, or some combinations of resends and
>> forwards. And
>> yes, a lot of this sort of crap is only semi-legit because it's coming
>> from
>> misconfigured servers - but operational reality dictates that you have to
>> deal with the fact that there's a *lot* of  (And we'll overlook the
>> additional
>> fun and games available due to the distinction between an RFC821 MAIL
>> FROM:
>> and and RFC822 From: line).
>>
>> I suppose it could be worse - it's been a few years since I last saw a
>> %-hacked
>> address in an e-mail.
>>
>> A few operational notes regarding alerts in user-facing software:
>>
>> 1) A lot of browsers used to display broken padlocks when SSL failed. They
>> don't do this anymore because users *will not* look at that sort of subtle
>> warning.
>>
>> 2)  They'll look at a big pop-up that obstructs their view - but only if
>> it
>> happens so rarely that they have to call somebody and ask "wtf is this?".
>> If it
>> becomes a "oh it does this once every week or two" click-through, it's now
>> become "worse than useless".
>>
>> As you noted, most browsers will notify the user if the browser detects a
>> CN
>> mismatch.
>>
>> What you gloss over is that browsers *totally suck* at presenting that
>> warning
>> in a way that is both understandable and actionable to a general user.
>> Just
>> yesterday I had Firefox alert on a SLL certificate mismatch, and it gave
>> me the
>> helpful info that the certificate presented was only valid for
>> *.akamai.net.
>> Now, *I* know exactly what happened there, and *you* know, and the guy who
>> pushed some content to Akamai without looking to see if there were https:
>> links
>> pointing at the content will go "D'Oh!" when he finds out - but if you're
>> Joe
>> Sixpack and don't know if Akamai is a box in your ISP's server room or a
>> box in
>> a server roomin the Ukraine, you got nothing.  And if you get enough of
>> these
>> totally annoying pop ups, you'll just learn to click through without
>> thinking.
>>
>> Bottom line:  yes, it would be nice if all this sort of stuff was more
>> widely
>> deployed and enforced.  But given that we've tried this with dismal
>> results
>> with Windows UAC alerts, firewall alerts, browser alerts, and A/V alerts,
>> there's no real reason to expect that *this* time we'll actually get it
>> right
>> for MUA alerts.
>>
>> Bonus points for the most creative suggestion for how to leverage a *fake*
>> From:/signature mismatch alert into a compromise (a la fake AV alerts that
>> get
>> you to download actual malware).
>>
>> Really - Outlook may do this wrong, but I don't think we as an industry
>> have
>> a frikking clue how to actually do this right.

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

Powered by blists - more mailing lists