SSL security concern

Tue Oct 15 05:34:11 EDT 2013

Hi Ethan,

I apologize if my emails came across like a demand. It was not my intention.

I notice that some of the security concerns have already been addressed by
PidGin
and some are out of scope (like the OTR plugin).

1. OTR: encrypt messages by default (private messaging).
- Out of scope. Can only be fixed within the OTR plugin (developers
disappeared).

2. Do not allow clear-text (non-SSL_ connections:
- Already available as per-account runtime option.

3. Accept (self-signed) certificates and pin those to the server.
(https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)
- Patch wanted.

4. Runtime feature to select exclusive CA store location.
- Pidgin uses (by default) the system wide CA store location. This location
  contains 600+ ROOT certificates (OS depended). PigGin's SSL connection is
verified
  against _any_ one of these ROOT CA's. The attack is the typical
Etisalat-Blackberry
  incident: I do not trust Etisalat's ROOT CA to verify Pidgin's SSL
connection. Yet
  it is not feasible to remove the Etisalat ROOT CA from the system wide
storage (or any
  or all of the 600+ ROOT CA's certificates that I do not trust to verify
IM connections).

- Exclusive CA store location is currently only supported as compile-time
option.
  This is not available or feasible to some users.

- Pros for exclusive CA store location: Allows user/server to use one (and
just one)
  ROOT CA that the user & server trust to verify the SSL connection.
Prevents
  Etisalat-Blackbery, DigiNotar-Iran and similar attacks.

5. Runtime feature to force client to disable logging.
- Currently possible via global runtime option (Preferences -> Logging).
- Idea: Per account and either forced by the server or logging
automatically disabled
  when account's Lockdown option is set.
- Pros: Prevents accidental misconfiguration. Server has control to only
let clients
  connect that do not log (or are in lockdown).
- I hear the arguement that the user can not be trusted: A malicious user
user can always
  turn on logging again by changing the source code. This is correct and
understood for
  malicious users.

  Most users are not malicious and would not change the source to enable
logging. Yet
  most users can not be trusted to disable logging manually. Disabling
logging manually
  would rely on a established security policy and process. We know that
these are prone
  to fail.

6. Inform server that user is using lockdown option.
- As a jabber server admin I have no information or control how the user
verified
  SSL connection, if the user is (accidentally) logging the messages or if
the user
  is (accidentally) sending plaintext messages.
- Pros for feature: I can control on the server that all users who connect
to my jabber
  server do not log, have verified the SSL connection securely (against the
server's
  pinned key and are not verified by Etisalat or Iran) and the user is not
  sending plaintext messages (Protecting against malicious users is out of
scope).

7. Like your ideas regarding lockdown option. Hits the nail on the head and
is
   better than my suggestion.
- Patch wanted.

These are suggestions and just suggestions. I can not implement them. If
there is anyone out there who
has the time, motivation and skills please let me know.

Ethan, if you know of somebody please let me know.

regards,

Ralf

On Mon, Oct 14, 2013 at 5:41 PM, Ethan Blanton <elb at pidgin.im> wrote:

> Ralf Skyper Kaiser spake unto us the following wisdom:
> > I made a list of features under section 6.4 that would make pidgin
> secure.
> > In summary:
>
> So ... we already implement a large portion of this list, either
> explicitly or implicitly.  To wit:
>
> > For Jitsi/Pidgin/Jabber this would mean:
> >
> >    1. Do not allow non-private chats
>
> I don't know what this means.
>
> >    2. Do not allow clear-text (non-SSL) connections
>
> This is already available, as a per-account option.  A global option
> could be added, but that is not substantially more user-friendly or
> secure in any practical sense.
>
> >    3. Accept self-signed certificates but once accepted/stored do not
> allow
> >    certificate to change (even if new certificate is a Verisign signed
> >    certificate).
>
> This is not something we currently support, but I generally think it's
> a good idea across the board.  I doubt we will implement it any time
> soon, but I am pretty sure we would accept a well-written patch that
> notified of certificate changes.
>
> >    4. Feature to select CAfile storage location
>
> This is already provided, as a compile-time option.
>
> >    5. Force client to disable logging
>
> This is not an "option", but can easily be achieved by marking
> ~/.purple/logs unwriteable by the user.
>
> >    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.
>
> >    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.
>
> >
> > The BIGGEST BANG FOR THE BUCK would be 4.: Allow the user to specific a
> > different (and exclusive) CA location.
>
> Again, we already support this, so I guess our buck is already bangin'.
>
> > It is not a big change and would open up Pigdin to a much larger user
> base.
>
> 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., and c) we don't care how many people use Pidgin, anyway.  If you
> can convince us something is a good idea, we'll either do it or accept
> a patch for it.  If you can't, we don't care if the Pope, the Dalai
> Lama, and Captain Reynolds got together and asked for it.
>
> Ethan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEVAwUBUlwesv8fixZ3H8crAQjHEgf/dhKUG/KJ/9Sx5eLtHDFx2TwIOLZVp7hC
> ZEpTLxleH5hlDWIW6Ox0qOoM6yotELnUKO/qYi8e3ES66pY5WbXXp4yF161lJaSr
> NNr7lrCpdqmmhvSaqdTYozkFoFb1fucfHt0z+HwMMQSy52b8TYKVhz7lRhR07zII
> fBByCIJT0vifOvPbVEV6ArZfZ258nF+M7Arrl4J8yNtlmayWnuTZ8zk8i1FlGr5p
> Jm68MGCXHP8XMWCfrMWjiI4sWCowYhiLC9R8vvu1g9Vn+kA+0WcTyMu3ySYHUw6L
> SxuDt57iAmKHUJr1IScoh9gEJs5L1nPLHWFNrS2ZyDGM5ysaYNreQQ==
> =Wp2G
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/support/attachments/20131015/e2e50fc6/attachment-0001.html>