RE: [dkim] Re: Can't connect to MSN account

[David Balažic]

Hi!

FYI:
While I (and others) reported in august that the MSN service is closed (at 
least in Europe), these days I noticed I can connect again to my MSN account 
(using Pidgin, the same settings as before).

So either they were reopened or never really closed.

Regards,
David Balažic
Software Engineer
www.comtrade.com

From: David Balažic
Sent: 22. July 2013 20:20
To: 'Michael Secord'; Makoto
Cc: support@pidgin.im
Subject: RE: [dkim] Re: Can't connect to MSN account

I just connected to my MSN account with Pidgin. So the service still works.

My account settings are (on the "Advanced" tab):
Server: messenger.hotmail.com
Port: 1863
"Use HTTP Method" is enabled
HTTP Method Server: gateway.messenger.hotmail.com
The last three optios are enabled.

David Balažic
Software Engineer
www.comtrade.com



From: Support [mailto:support-boun...@pidgin.im] On Behalf Of Michael Secord
Sent: Sunday, July 21, 2013 11:55 PM
To: Makoto
Cc: support@pidgin.im
Subject: [dkim] Re: Can't connect to MSN account

On Jul 21, 2013 5:53 PM, "Makoto" 
mailto:makoto...@gmail.com>> wrote:
>
> I don't know... I had this problem, with the same error, last Monday... but 
> by Wednesday, Pidgin was connecting to MSN, again, and I haven't had any 
> issues since.
>
> To be honest, I'm surprised we've been able to connect to MSN for this long.  
> Didn't Microsoft give a definitive shutdown date?
>
> (Well, that and I'm not sure I want to use Skype.)
>

I had issues early in the week and worked for a bit on Wednesday and then my 
accounts stopped working by Thursday morning and haven't worked since.
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

STOP EMAILS

[lfayman]

Please stop these emails from coming to the email 
lfay...@fxdd.com please. I do not want to be receiving 
emails any longer from ppl I do not know.

[cid:image001.jpg@01CEC8B4.06906D40]
Lawrence Fayman
Dealer
Markets and Liquidity

7 World Trade Center
32nd Floor at
250 Greenwich Street
New York, NY 10007

T: 212.791.3939
F: 212.937.3845
lfay...@fxdd.com
www.fxdd.com



Trading in the Foreign Exchange market involves a significant and substantial 
risk of loss and may not be suitable for everyone. You should carefully 
consider whether trading is suitable for you in light of your age, income, 
personal circumstances, trading knowledge, and financial resources. Only true 
discretionary income should be used for trading in the Foreign Exchange market. 
Any opinion, market analysis or other information of any kind contained in this 
email is subject to change at any time. Nothing in this email should be 
construed as a solicitation to trade in the Foreign Exchange market. If you are 
considering trading in the Foreign Exchange market before you trade make sure 
you understand how the spot market operates, how FXDD is compensated, 
understand FXDD's trading policy and rules and be thoroughly familiar with the 
operation of and the limitations of the platform on which you are going to 
trade. This message and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom it is
addressed. It may contain sensitive and private proprietary or legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistransmission. If you are not the intended recipient, please immediately 
delete it and all copies of it from your system, destroy any hard copies of it 
and notify the sender. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. FXDirectDealer, LLC reserves the right to monitor all e-mail 
communications through its networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorized to state them. Unless otherwise stated, any pricing 
information given in this message is indicative only, is subject to change and 
does not constitute an offer to deal at any price quoted.
<>___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: STOP EMAILS

[Ethan Blanton]

lfay...@fxdd.com spake unto us the following wisdom:
> Please stop these emails from coming to the email
> lfay...@fxdd.com please. I do not want to be
> receiving emails any longer from ppl I do not know.

I have removed you from the list.

This is a public mailing list, and you had to confirm subscription to
it when you joined.  In every email header and in every email footer
there are instructions for unsubscribing.  An all-caps demand to "STOP
EMAILS" was probably not warranted.

Ethan

___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ralf Skyper Kaiser]

David,

can you clarify this quote from you please:

"That goes against the general philosophy of open source clients. The user
should be assumed to be responsible."

Are you saying that users who use open source clients are assumed to be
responsible? (and because of that pidgin should have a lousy SSL security
implementation - because the user knows what he is doing)?

regards,

skyper



On Sun, Sep 22, 2013 at 11:39 PM, David Woolley
wrote:

> On 22/09/13 21:26, skyper wrote:
>
>>
>> 1. Which ROOT CA storage does pidgin use to authenticate a server side
>> SSL certificate?
>>
>
> See ./configure --help.  At a quick scan, it looks like it uses its own
> set of root certificates by default.  The default will depend on the OS, at
> least to some extent.  On Debian, it looks like the default is
> /usr/share/purple/ca-certs.
>
> If you didn't compile it yourself, the choices made by the packager may
> differ from the build system defaults.
>
>
>
>> 2. How can I configure pidgin to use one (and just one; exclusive) ROOT
>> CA storage (or single certificate) and ignore all other system-wide root
>> certs without having to recompile the source?
>>
>
> On that reading.  If it has been compiled to use its own certificates,
> delete the other certificates.  Again, on the above reading, this will be a
> global change for all libpurple clients. If it has been compiled to use a
> system directory, your caveat cannot be met.
>
>
>
>> 3. How can I harden pidgin to fail connecting to the jabber server if
>> SSL trust can not be established? I do not want to see any warning that
>> the SSL cert can not be authenticated or the user being asked if he
>> trusts the certificate manually.
>>
>
> That goes against the general philosophy of open source clients, that the
> user should be assumed to be responsible.  My guess is that this not only
> requires recompiling, but also requires source code changes.
>
> Please note I'm not an expert on this.  I'm just going on a very quick
> scan of the configure script, and the general design philosophy of open
> source client software.
>
>
> __**_
> Support@pidgin.im mailing list
> Want to unsubscribe?  Use this link:
> http://pidgin.im/cgi-bin/**mailman/listinfo/support
>
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ethan Blanton]

Ralf Skyper Kaiser spake unto us the following wisdom:
> can you clarify this quote from you please:
> 
> "That goes against the general philosophy of open source clients. The user
> should be assumed to be responsible."
> 
> Are you saying that users who use open source clients are assumed to be
> responsible? (and because of that pidgin should have a lousy SSL security
> implementation - because the user knows what he is doing)?

Note that David is not a Pidgin developer, and this opinion is his
own.  It is either a common attitude for Open Source software or a
common misconception regarding open source software, depending on your
perspective.  I view it as the latter.  There's no "philosophy" of
open source that says it has to suck in case the user wants it to.

That said, in this particular instance, we do not have a
straightforward option for accomplishing what you're asking for, and I
doubt we will soon provide one.  It is unfortunately quite common for
users to *need* to accept certificates with untrusted chains,
mismatched domains, expired signatures, etc.  We do not currently
provide an option for default disposition (either to confirm or
reject) of such a situation, we require the user to handle it
manually.

Ethan

___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ralf Skyper Kaiser]

HI Ethan,

thanks for your comments. I've summarized some SSL/TLS Security concerns:

https://thc.org/ssl

and also created a video for those who are non-technical:

http://youtu.be/F3BMA3IuvYs

I made a list of features under section 6.4 that would make pidgin secure.
In summary:

For Jitsi/Pidgin/Jabber this would mean:

   1. Do not allow non-private chats
   2. Do not allow clear-text (non-SSL) connections
   3. Accept self-signed certificates but once accepted/stored do not allow
   certificate to change (even if new certificate is a Verisign signed
   certificate).
   4. Feature to select CAfile storage location
   5. Force client to disable logging
   6. Inform server that user is using lockdown (so that server can reject
   all clients which do not).
   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.


The BIGGEST BANG FOR THE BUCK would be 4.: Allow the user to specific a
different (and exclusive) CA location.

It is not a big change and would open up Pigdin to a much larger user base.

regards,

Ralf






On Mon, Oct 14, 2013 at 3:47 PM, Ethan Blanton  wrote:

> Ralf Skyper Kaiser spake unto us the following wisdom:
> > can you clarify this quote from you please:
> >
> > "That goes against the general philosophy of open source clients. The
> user
> > should be assumed to be responsible."
> >
> > Are you saying that users who use open source clients are assumed to be
> > responsible? (and because of that pidgin should have a lousy SSL security
> > implementation - because the user knows what he is doing)?
>
> Note that David is not a Pidgin developer, and this opinion is his
> own.  It is either a common attitude for Open Source software or a
> common misconception regarding open source software, depending on your
> perspective.  I view it as the latter.  There's no "philosophy" of
> open source that says it has to suck in case the user wants it to.
>
> That said, in this particular instance, we do not have a
> straightforward option for accomplishing what you're asking for, and I
> doubt we will soon provide one.  It is unfortunately quite common for
> users to *need* to accept certificates with untrusted chains,
> mismatched domains, expired signatures, etc.  We do not currently
> provide an option for default disposition (either to confirm or
> reject) of such a situation, we require the user to handle it
> manually.
>
> Ethan
>
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[David Woolley]

On 14/10/13 15:39, Ralf Skyper Kaiser wrote:


can you clarify this quote from you please:

"That goes against the general philosophy of open source clients. The
user should be assumed to be responsible."

Are you saying that users who use open source clients are assumed to be
responsible? (and because of that pidgin should have a lousy SSL
security implementation - because the user knows what he is doing)?


Enforcing local management policy tends to be a low priority in open 
source software.  In the case of certificates, as long as the user is 
told that there is a problem with the certificate, it is generally 
assumed that any choice to ignore the warning is an informed decision. 
Freedom tends to include the freedom to ignore warnings.


Windows, although far from open source, tends to take a similar position 
by default, but does provide features like group policies to allow a 
management lock down. Windows SSL security implementation is also lousy, 
in your terms, because:


- most people who use it think that an https URL is all that is needed 
for security and have no understanding of the need for authentication;


- it enables all sorts of weird CAs with low authentication thresholds, 
along with the class 3 certificates - any one of which will let you in 
without a warning.


Incidentally, I don't know any easy way of giving standard Windows 
applications selective access to root certificates, without giving all 
applications the same restriction.


As a specific example of an area where Pidgin doesn't comply with 
management lock down wants is that every few months people ask how to 
disable all but one service, to which the standard answer, is you can 
disable protocols by removing the plugins, but the end user can just 
re-install them, so the correct solution is block at the firewall.  Of 
course, many people asking for this would want Facebook and Google 
blocked, but are using private XMPP servers, so share a common protocol.


As Ethan says, I'm not a Pidgin developer (my programming work with open 
source is in a different area), but I don't notice much support for 
management lock downs anywhere in Pidgin.



___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[David Woolley]

The BIGGEST BANG FOR THE BUCK would be 4.: Allow the user to specific a
different (and exclusive) CA location.



As noted in my original reply, that already exists if you build from 
source - the decision is a compile time one.  If you use a package, the 
packager will generally select the option that makes the software 
easiest to use and maintain out of the box, which means that, if the OS 
supports a compatible certificate store mechanism, the packager will 
select that, so that it will work out of the box, and certificates will 
get updated as part of the OS update process.


If there isn't such a mechanism, it will install Pidgin's standard set 
of certificates in a directory private to libpurple, so that the user 
doesn't have to hunt down certificates before they use it.


At least from a quick glance, you can tell it to use a system 
certificate store, when you build it, but point that at a directory that 
you populate with certificates, rather than the standard OS certificate 
store.


___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ralf Skyper Kaiser]

Hi,

I agree, 1 of the 7 Security features is already possible with pidgin but
requires source code recompilation. That's does not fly for most users
(especially the windows users).

Pidgin should be secure by default or - if Pidgin insists that it has to be
insecure by default - at least the possibility for the user to use it
securely. Without having to recompile from source (and cross platform).

regards,

ralf



On Mon, Oct 14, 2013 at 5:27 PM, David Woolley
wrote:

>
>  The BIGGEST BANG FOR THE BUCK would be 4.: Allow the user to specific a
>> different (and exclusive) CA location.
>>
>>
> As noted in my original reply, that already exists if you build from
> source - the decision is a compile time one.  If you use a package, the
> packager will generally select the option that makes the software easiest
> to use and maintain out of the box, which means that, if the OS supports a
> compatible certificate store mechanism, the packager will select that, so
> that it will work out of the box, and certificates will get updated as part
> of the OS update process.
>
> If there isn't such a mechanism, it will install Pidgin's standard set of
> certificates in a directory private to libpurple, so that the user doesn't
> have to hunt down certificates before they use it.
>
> At least from a quick glance, you can tell it to use a system certificate
> store, when you build it, but point that at a directory that you populate
> with certificates, rather than the standard OS certificate store.
>
>
> __**_
> Support@pidgin.im mailing list
> Want to unsubscribe?  Use this link:
> http://pidgin.im/cgi-bin/**mailman/listinfo/support
>
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ethan Blanton]

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


signature.asc
Description: Digital signature
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ethan Blanton]

David Woolley spake unto us the following wisdom:
> Windows, although far from open source, tends to take a similar
> position by default, but does provide features like group policies
> to allow a management lock down. Windows SSL security implementation
> is also lousy, in your terms, because:

Windows is not a good example of ... basically anything.

> As a specific example of an area where Pidgin doesn't comply with
> management lock down wants is that every few months people ask how
> to disable all but one service, to which the standard answer, is you
> can disable protocols by removing the plugins, but the end user can
> just re-install them, so the correct solution is block at the
> firewall.  Of course, many people asking for this would want
> Facebook and Google blocked, but are using private XMPP servers, so
> share a common protocol.

This is not an accurate characterization.  We get people asking how to
disable all but one service *using the project-provided Windows
binaries*, and we state that there is no such way.  A user can readily
compile Pidgin without plugin loading and include a specific subset of
protocol plugins at compile time and achieve just this.  Just ... not
some clueless Windows sysadmin.

The point here, and the point for many such features, is that the
burden of supporting the option is larger than the perceived benefit,
from our point of view.  In the case of locking down protocols, the
primary concern I see is that, if you allow loadable plugins at all,
it seems likely that the user can find some way to defeat whatever
trivial machanism you put in place with a mediocum of effort.  A
nontrivial mechanism is a significant endeavor.

Ethan

___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[David Woolley]

On 14/10/13 17:33, Ralf Skyper Kaiser wrote:


I agree, 1 of the 7 Security features is already possible with pidgin
but requires source code recompilation. That's does not fly for most
users (especially the windows users).


As far as I know, the Windows build is unable to use the system 
certificate store, so already uses one private to libpurple, but 
pre-populates it.  You could simply clear it out.  It is only on modern 
Linux systems where it is likely to share a certificate store, and those 
are the ones where compiling from source is likely to be easiest.  (A 
packager could, fairly easily, point the certificate store at a symlink, 
which defaults to the system store, in those cases.)


It looks like Debian also uses a private directory for the certificates 
(/usr/share/purple/ca-certs/), and doesn't even install all that come 
with Pidgin.




Pidgin should be secure by default or - if Pidgin insists that it has to
be insecure by default - at least the possibility for the user to use it
securely. Without having to recompile from source (and cross platform).


You just have to look at the typical question on this list to realise 
that a secure by default Pidgin would be unusable to a large number of 
Pidgin users - if you cannot make a usable support request, you are 
unlikely to understand how to source and install certificates securely. 
 There tends to be high support costs in making mass market software 
secure by default.  (As I already noted, Windows seems to let almost 
every Tom, Dick or Harry to act as CAs by default, because starting with 
only class 3 certificates would cause too many support problems.)


If anything, making it "secure by default", if it doesn't scare off new 
users completely, is likely to result in lots of cook book solutions on 
how to get it to trust certificates without going through the proper 
processes to verify those certificates, thus teaching people bad 
security practices.


If Windows set all but class 3 CAs to disabled by default, I suspect the 
standard internet cook book solution would be simply to go into the 
certificate manager and enable them, whenever you got blocked.


Whist making the directory a run time parameter would, probably, be a 
small change, you would then have to lock down the configuration file.


Having to explicitly add trusted certificates won't fly with most end users.



___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ralf Skyper Kaiser]

Hi,

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.
>

...if OTR plugin is available then do not allow non-encrypted private
messages.

>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?)



>
> >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.


> >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.


>
> >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.

It prevents accidental client misconfiguration which form the majority of
all security problems.

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.

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.

Firefox and Chrome are now on the forefront for implementing stricter SSL
security (including certificate pinning, HSTS and exclusive CA locations).

David: Saying that this is not required reminds me of a discussion in the
80s when the car manufactures said that Airbags are not required ("That
cars have a break and that people should drive responsibly. Only a small
ruthless-driving group of people would benefit.").

regards,

Ralf
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Brian Morrison]

On Mon, 14 Oct 2013 19:25:21 +0100
Ralf Skyper Kaiser wrote:

> > >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.

This can be set on a per-contact basis for those who use OTR.

-- 

Brian Morrison

___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: [dkim] Re: Can't connect to MSN account

[Makoto]

On 10/14/2013 01:20 AM, David Balažic wrote:

Hi!

FYI:

While I (and others) reported in august that the MSN service is closed
(at least in Europe), these days I noticed I can connect again to my MSN
account (using Pidgin, the same settings as before).

So either they were reopened or never really closed.



Hmm... that's weird.  I'd actually tried to re-enable my MSN account in 
Pidgin and connect (to test) about two or so days ago, before I finally 
decided to import it to Skype, and it didn't work.  But, I tried again 
just now, and it did connect.  Unfortunately, none of my contacts appear 
online, so I can't test actual IMs.


I wish MS would just leave the protocol available as a "low-resource" 
alternative to Skype, for those who can't or won't use Skype, for 
whatever reason.  Or hand it to someone who'd be willing to maintain it. 
 I'd still much rather prefer to use Pidgin and its logging features 
over Skype.



___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: SSL security concern

[Ralf Skyper Kaiser]

Brian,

yes, correct. and It's a good feature to have.

Yet we see users sending unencrypted messages even when they think they are
using OTR with private message encryption (yes, users are sometimes stupid).

An option that use encryption by default (which can be disabled by the
user) provides better security at no cost to usability. So why not do it?

regards,

Ralf



On Mon, Oct 14, 2013 at 7:54 PM, Brian Morrison  wrote:

> On Mon, 14 Oct 2013 19:25:21 +0100
> Ralf Skyper Kaiser wrote:
>
> > > >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.
>
> This can be set on a per-contact basis for those who use OTR.
>
> --
>
> Brian Morrison
>
> ___
> Support@pidgin.im mailing list
> Want to unsubscribe?  Use this link:
> http://pidgin.im/cgi-bin/mailman/listinfo/support
>
___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: [dkim] Re: Can't connect to MSN account

[Matthias Apitz]

El día Monday, October 14, 2013 a las 12:10:28PM -0800, Makoto escribió:

> On 10/14/2013 01:20 AM, David Balažic wrote:
> > Hi!
> >
> > FYI:
> >
> > While I (and others) reported in august that the MSN service is closed
> > (at least in Europe), these days I noticed I can connect again to my MSN
> > account (using Pidgin, the same settings as before).
> >
> > So either they were reopened or never really closed.
> 
> 
> Hmm... that's weird.  I'd actually tried to re-enable my MSN account in 
> Pidgin and connect (to test) about two or so days ago, before I finally 
> decided to import it to Skype, and it didn't work.  But, I tried again 
> just now, and it did connect.  Unfortunately, none of my contacts appear 
> online, so I can't test actual IMs.
> 
> ...

Until today I connected always to my MSN account with pidgin without
facing any change.

matthias
-- 
Sent from my FreeBSD netbook

Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)   
  
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5

___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: [dkim] Re: Can't connect to MSN account

[Makoto]

On 10/14/2013 11:42 AM, Matthias Apitz wrote:


Until today I connected always to my MSN account with pidgin without
facing any change.



It wasn't allowing connections for me, between somewhere around August 
28 and... maybe yesterday, I guess.  Though, I wouldn't be surprised if 
there were periods during that time where MSN would have let me connect 
using Pidgin, and then stopped, again.



___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support

Re: 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 

Re: SSL security concern

[David Woolley]

On 14/10/13 22:39, Ethan Blanton wrote:


Oh, OTR.  This is a problem for the OTR plugin.  We started


I'm afraid I failed to spot that this was on OTR one, rather than a 
corporate lock down one.  (They often have rather conflicting aims.**)


 * Secure all communications, untrusted local storage
 * Secure all communications, trusted local storage


I'm afraid you will need better descriptions.  My first thought was that 
the average user wouldn't make the connection between trusted local 
storage and logs.  On further thought, if you don't actually trust local 
storage, you can't trust the certificates, or the program code.




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.


Of course, being open source, the OP can always fork their own version 
of the code, remembering to change the branding and the embedded support 
address.


** E.g. corporate IT departments usually want to ensure that 
conversations are logged but in a way that doesn't allow the employee to 
manipulate them.


___
Support@pidgin.im mailing list
Want to unsubscribe?  Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support