Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Fri, 24 Oct 2014 23:33:01 +0200 Lars Magne Ingebrigtsen
<address@hidden> wrote:
> "Perry E. Metzger" <address@hidden> writes:
> 
> > Once you've listened to the secret service or DEA chatting on the
> > radio in the clear by accident because they don't realize they
> > inadvertently turned off the encryption on their P25 radios
> > (which is trivial to do by accident and provides no warning
> > feedback) you realize that essentially *no* user can be trusted
> > with such decisions in the average case.
> 
> [...]
> 
> > Really the only safe system follows "there should be only one
> > mode, and it should be secure".
> 
> This is alarmist nonsense.

No, it is the result of working in security for about twenty years.

> It's telling that your example is a case where, perhaps, it might
> have made a difference whether the communication was secure or not.

As I've said earlier: the problem is that ordinary users use the same
applications as extraordinary ones. P25 radios are used both by
shopping mall security guards and by the US Secret Service. If you say
"oh, the security doesn't have to be perfect for a security guard",
you end up endangering the highest risk users.

When the reporters who dealt with Edward Snowden were communicating
with them, they didn't have the special unusual operating system
issued only to special reporters, they had the normal one. People
with secrets to keep use the same mail programs other people do, the
same text editors, the same web browsers.

You can't say "oh, most users don't need protection", or "well, for
most web sites the user doesn't need protection". You have to aim your
protection to the users you have with the highest need for secrecy,
your web browser for the banking application, not the times when the
user is browsing auto reviews.

> However, the common case for a normal user is when you're binging
> around for a solution as to why your Foobarzot device is not

And who cares, because that same user will also look at his bank
statements, and who cares, because the reporter who is talking to
someone risking their life in Iran just by communicating with a
Western journalist is using the same email program or web browser as
everyone else.

And let me be blunt: I'm sick of cleaning up the messes
software developers playing amateur security people have created for
the world over the last few decades. I spend my life cleaning up
messes caused by people who think they're smarter. SSL itself is an
example of this -- designed by people at Netscape who knew better and
didn't consult anyone who actually had any experience.

You read the full disclosure mailing list or the equivalent and you
see exactly what the amateurs have produced with their "oh, who would
think to do that" or "well, we need to be compatible" or their "well,
most users don't need protection" attitude, and worse, you see it day
after day, week after week.

You started this by saying that I was producing "alarmist nonsense".
Sadly, we live in a world where the largest banks in the world, the
largest retailers, etc. get broken in to regularly, where there are
spy agencies trying to record your, yes your, phone calls, never mind
how unimportant you think you are, where there are activists in
countries all of the world whose lives are put at risk by crappy
software, where most system security is a broken mess.

Quit playing amateur security expert. You're part of the problem when
you do.

> In real life, virtually all situations where the security of the
> communication channel can't be verified, you simply don't care at
> all.

Yes, but your software will not be used exclusively by people who
don't care, and you have no control over who uses your software.

> The super-alarmist "don't allow the user to do what she obviously
> wants to do" just makes the user to disable all security.

Not if you remove the ability to disable security. In fact, if you
let the user disable security, they'll be tricked into doing so by
social engineering attacks of various kinds, so you can't actually
leave that knob available anyway. That's not theoretical either. It
was a huge mistake that many of our protocols make security optional
-- a mistake being corrected in the new HTTP, by the way, which will
not even permit unencrypted connections.

Perry
-- 
Perry E. Metzger                address@hidden