SSL security concern

[Ethan Blanton]

Ralf Skyper Kaiser spake unto us the following wisdom:
> > >    1. Do not allow non-private chats
> >
> > I don't know what this means.
>
> ...if OTR plugin is available then do not allow non-encrypted private
> messages.

Oh, OTR.  This is a problem for the OTR plugin.  We started
discussions wit the OTR people to bring it into Pidgin proper, but
they disappeared and it has never happened.  Until it does, it's not
something we can do anything about.

> >    4. Feature to select CAfile storage location
> >
> > This is already provided, as a compile-time option.
> 
> This is not feasible to the average user. (point taken, developers know how
> to use pidgin securely. everyone else should go to hell?)

That's not what I said.

So ... you started with a list of demands with no justification, you
apparently ignored or disregarded existing functionality, and as we
attempt to refine the situation you resort to ego-bribery and reductio
ad absurdum.  It makes it hard to take you seriously.  You may have
some good points, but they're hard to find past the noise.

So, if we assume charitably that your cat sat on the keyboard and made
you look like a jerk, your response before that point probably said "I
would like a runtime option, because while I want the store to be
exclusive and immutable, I want the store to be non-exclusive and
mutable."  At which point I say ... what are you trying to solve?
Give me a use case and we can talk about options.  I don't see any
reason why putting certificates in the predefined store is inferior to
changing the location of the store at runtime, and since you seem to
be concerned about users accidentally changing options, I'd say the
former is preferable to the latter.  Justify.

> > >    5. Force client to disable logging
> >
> > This is not an "option", but can easily be achieved by marking
> > ~/.purple/logs unwriteable by the user.
> >
> Option should be available cross-platform and without OS specific hacks.

That's cross-platform and not OS-specific, you can even do the same
thing on Windows ... assuming you're using Windows and still
pretending to be concerned about security (?).  I agree that it's
inelegant.  However, I don't really get what you're trying to
accomplish, if a simple option to turn off logging is not sufficient,
and you want an option to turn off the option that turns off logging.
Justify.


> > >    6. Inform server that user is using lockdown (so that server can
> > reject
> > >    all clients which do not).
> >
> > This is not useful, as a client can readily lie.
> 
> This is not the point. The client can also circumvent your no-logging idea
> by putting up a camera and filming his screen.
> 
> The point is that it takes reasonable effort and prevents _accidental_
> client misconfiguration.

I ... still don't get this.

> > >    7. Once lockdown option is enabled the user should not be able to
> > >       change any of the above options until lockdown is disabled again
> > >       (e.g. gray out the option). Disconnect when lockdown option
> > >       changes and reconnect to all servers.
> >
> > I don't see what this buys.  We're unlikely to implement it.
> 
> Prevents accidental misconfiguration by the user. A server rule could
> create a rule to only let clients connect that are in lockdown. This would
> ensure against these accidental misconfigurations:
> 
> 1. User has logging disabled
> 2. User is authenticating against server supplied/server-trusted cert (and
> not one of the 600+ CA's out there)
> 3. User can not send unencrypted private messages
> etcetcetc.

So maybe you're just saying something very confusing here.  You don't
want an option that locks down the preferences, you want an option
that automatically sets a variety of security preferences to "known
good" settings?  Your initial description sounded like you wanted an
option to disable further configuration tweaks, regardless of what the
current configuration is.

If your assertion is, instead, that there should be a "secure
everything" global option, then I'd say this is a reasonable idea, but
your specific implementation is not great.  I'd be more inclined to
have a dropdown box in a security tab with a couple of options.
Maybe:

    * Secure all communications, untrusted local storage
    * Secure all communications, trusted local storage
    * Require encrypted server connections
    * Allow insecure connections
    * Custom settings

The first locks down everything you've asked for, the second does the
same but allows logging, the third enforces "Use SSL/TLS Encryption"
for every connection but makes no other security-related demands, the
fourth enforces "Use SSL/TLS if available", and the final setting lets
each preference do its own thing.

My pushback on this is that the complexity of implementation is pretty
high, and I don't really think the benefit is that large.  I wouldn't
implement it, but if somebody handed it to me and it was good, I would
probably take it.

> > This is a disingenuous and misplaced statement.  I assume you're
> > trying to bribe egos.  However, a) Pidgin is already used by many
> > millions of users, b) the "much larger user base" is a small fraction
> > of those millions consisting of (for example) certain financial
> > companies, a small number of privacy-concerned tech-savvy individuals,
> > etc.
> 
> I think there is a use case for such a feature. There is currently no easy
> to use and secure IM client on the market.

That is a very different statement from "ZOMG U WILL BE SO POPULAR!!".

> History (last 2-3 years, and recent PRISM leaks) have shown that
> governments (and I'm not just talking about the US here) are intercepting
> SSL traffic on a massive scale (see the DigiNotar-Iran incident, The
> Blackberry-Etisalar incident, the PRISM case, ...etc etc etc).
> 
> This has been made possible because of lax security implementation - not
> just in pidgin but across the board.

You don't have to convince me that governments suck and cannot be
trusted.

Ethan