subject:"SSL"

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
for...@david-woolley.me.ukwrote:

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/supporthttp://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

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

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 e...@pidgin.im 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

2013-10-14 Thread 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

2013-10-14 Thread 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 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

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

2013-10-14 Thread 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

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

2013-10-14 Thread 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: SSL security concern

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 b...@fenrir.org.uk 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: SSL security concern

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

Pidgin 2.10.7 Windows: yahoo / ssl error

2013-10-09 Thread Vlad Ion

Dear support team,

Over the last 2 hours, I started having the following error on both
computers in my house. I tried to reboot the computers and reinstall
pidgin, though I have no luck and I get the same error.
Any help would be greatly appreciated.

(03:07:15) *connection:* Connecting. gc = 04CA35D0
(03:07:15) *util:* requesting to fetch a URL
(03:07:15) *dnsquery:* Performing DNS lookup for vcs1.msg.yahoo.com
(03:07:15) *dnsquery:* IP resolved for vcs1.msg.yahoo.com
(03:07:15) *proxy:* Attempting connection to 66.196.120.43
(03:07:15) *proxy:* Connecting to vcs1.msg.yahoo.com:80 with no proxy
(03:07:15) *proxy:* Connection in progress
(03:07:15) *proxy:* Connecting to vcs1.msg.yahoo.com:80.
(03:07:15) *proxy:* Connected to vcs1.msg.yahoo.com:80.
(03:07:15) *util:* request constructed
(03:07:16) *util:* Response headers: 'HTTP/1.1 200 OK
Content-Length: 46
Content-Type: text/plain; charset=utf-8
Cache-Control: max-age=0, must-revalidate
Expires: Sun, 10 Jun 2007 12:01:01 GMT

'
(03:07:16) *util:* parsed 46
(03:07:16) *yahoo:* Got COLO Capacity: 1
(03:07:16) *yahoo:* Got CS IP address: 66.196.121.24
(03:07:16) *dnsquery:* Performing DNS lookup for 66.196.121.24
(03:07:16) *dnsquery:* IP resolved for 66.196.121.24
(03:07:16) *proxy:* Attempting connection to 66.196.121.24
(03:07:16) *proxy:* Connecting to 66.196.121.24:5050 with no proxy
(03:07:16) *proxy:* Connection in progress
(03:07:16) *proxy:* Connecting to 66.196.121.24:5050.
(03:07:16) *proxy:* Connected to 66.196.121.24:5050.
(03:07:16) *yahoo:* 80 bytes to read, rxlen is 100
(03:07:16) *yahoo:* Yahoo Service: 0x57 Status: 1
(03:07:16) *yahoo:* Authentication: In yahoo_auth16_stage1
(03:07:16) *util:* requesting to fetch a URL
(03:07:16) *dnsquery:* Performing DNS lookup for login.yahoo.com
(03:07:16) *dnsquery:* IP resolved for login.yahoo.com
(03:07:16) *proxy:* Attempting connection to 188.125.82.242
(03:07:16) *proxy:* Connecting to login.yahoo.com:443 with no proxy
(03:07:16) *proxy:* Connection in progress
(03:07:16) *proxy:* Connecting to login.yahoo.com:443.
(03:07:16) *proxy:* Connected to login.yahoo.com:443.
(03:07:16) *nss:* subject=CN=login.yahoo.com,O=Yahoo!
Inc.,L=Sunnyvale,ST=CA,C=US issuer=CN=DigiCert High Assurance CA-3,OU=
www.digicert.com,O=DigiCert Inc,C=US
(03:07:16) *nss:* subject=CN=DigiCert High Assurance CA-3,OU=
www.digicert.com,O=DigiCert Inc,C=US issuer=CN=DigiCert High Assurance EV
Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
(03:07:16) *nss:* partial certificate chain
(03:07:16) *certificate/x509/tls_cached:* Starting verify for
login.yahoo.com
(03:07:16) *certificate/x509/tls_cached:* Checking for cached cert...
(03:07:16) *certificate/x509/tls_cached:* ...Found cached cert
(03:07:16) *nss/x509:* Loading certificate from
C:\Users\root\AppData\Roaming\.purple\certificates\x509\tls_peers\
login.yahoo.com
(03:07:16) *certificate/x509/tls_cached:* Peer cert did NOT match cached
(03:07:16) *certificate:* Checking signature chain for uid=CN=
login.yahoo.com,O=Yahoo! Inc.,L=Sunnyvale,ST=CA,C=US
(03:07:16) *certificate:* ...Good signature by CN=DigiCert High Assurance
CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US
(03:07:16) *certificate:* Chain is VALID
(03:07:16) *certificate/x509/tls_cached:* Checking for a CA with
DN=CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert
Inc,C=US
(03:07:16) *certificate/x509/tls_cached:* Also checking for a CA with
DN=CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US
(03:07:16) *certificate:* Failed to verify certificate for login.yahoo.com
(03:07:16) *yahoo:* Authentication: In yahoo_auth16_stage1_cb
(03:07:16) *yahoo:* Login Failed, unable to retrieve login url: Unable to
connect to login.yahoo.com: SSL peer presented an invalid certificate
(03:07:16) *connection:* Connection error on 04CA35D0 (reason: 0
description: Unable to connect to login.yahoo.com: SSL peer presented an
invalid certificate)
(03:07:16) *account:* Disconnecting account vlad_thoth (02581990)
(03:07:16) *connection:* Disconnecting connection 04CA35D0
(03:07:16) *connection:* Destroying connection 04CA35D0

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

SSL security concern

2013-09-22 Thread skyper

Hi,

1. Which ROOT CA storage does pidgin use to authenticate a server side SSL
certificate?

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?

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.

thanks  regards,

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

tor/privacy (socks5) option giving ssl error

Hello,

Pidgin 2.10.6 (libpurple 2.10.6)
4cfe697ea3ae39a4fb3dad8e3ed1c70855901095

I am trying to connect to Tor using Pidgin.  I am having a connection
issue.  Of the three proxy options socks4, socks5, and
tor/privacy(socks5), it seems I should be using tor/privacy(socks5). 

This issue has come up on some Tor lists.

Can someone explain exactly what is the difference between Tor/Privacy
Socks5, and just Socks5, and whether you believe Pidgin to preserve the
anonymity?

And also, my question as to why on my system, socks 5 works, but
Tor/Privacy(Socks5) results in SSL connection error almost
immediately (i.e. I don't think it is even making any network activity,
it just immediately displays the SSL connect error.  Setting Socks5
works fine.

Thanks

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

Re: tor/privacy (socks5) option giving ssl error

2013-04-02 Thread Daniel Atallah

On Tue, Apr 2, 2013 at 7:08 PM, Ileana ile...@fairieunderground.info wrote:

 Hello,

 Pidgin 2.10.6 (libpurple 2.10.6)
 4cfe697ea3ae39a4fb3dad8e3ed1c70855901095

 I am trying to connect to Tor using Pidgin.  I am having a connection
 issue.  Of the three proxy options socks4, socks5, and
 tor/privacy(socks5), it seems I should be using tor/privacy(socks5).

 This issue has come up on some Tor lists.

 Can someone explain exactly what is the difference between Tor/Privacy
 Socks5, and just Socks5, and whether you believe Pidgin to preserve the
 anonymity?

The difference is that the Tor/Privacy proxy will disable various
other pieces of functionality (e.g. DNS queries) instead of just
proxying actual connections through a proxy.  If you have pidgin
configured appropriately (e.g. disabling UPnP, etc) we're not aware of
any leakage of information to someone listening between you and the
proxy endpoint.

 And also, my question as to why on my system, socks 5 works, but
 Tor/Privacy(Socks5) results in SSL connection error almost
 immediately (i.e. I don't think it is even making any network activity,
 it just immediately displays the SSL connect error.  Setting Socks5
 works fine.

You didn't provide any context to the specific issue, but the likely
reason for this particular error is that the Tor/Privacy Socks5 mode
will prevent DNS queries from occurring and this probably has the
effect of preventing you from determining the correct server to
connect to (e.g. a DNS SRV lookup is necessary to connect to the
appropriate XMPP server for a number of domains unless you specify a
Connect Server manually).

-D

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

Re: tor/privacy (socks5) option giving ssl error

 
 You didn't provide any context to the specific issue, but the likely
 reason for this particular error is that the Tor/Privacy Socks5 mode
 will prevent DNS queries from occurring and this probably has the
 effect of preventing you from determining the correct server to
 connect to (e.g. a DNS SRV lookup is necessary to connect to the
 appropriate XMPP server for a number of domains unless you specify a
 Connect Server manually).
 

Daniel,

Sorry for the lack of context.  I am using tor and pidgin 
Pidgin 2.10.6 (libpurple 2.10.6), on linux.

I am connecting to a normal irc server.

It works with socks 5, it doesn't work, and immediately fails, with
tor/privacy socks5 with error ssl connection failed.

When I try to connect to an IRC tor hidden service
address (blahblahblah.onion) I get: 
Unable to connect: Aborting DNS lookup in Tor Proxy mode.

When I try to connect to a regular IRC address/hostname, I get SSL
Connection Failed.

Both work when I select socks5.  Neither works with tor/privacy(socks5).

Are you suggesting I should be putting the ip addresses in directly for
these hostnames?  That isn't even possible in the case of the hidden
service addresses.  And the hidden service address seems to resolve and
work fine with the socks5 setting.

I don't see how this can't be some kind of bug?  Aren't the dns requests
supposed to go through the proxy?  Do you need to add a check box (do
dns lookup at proxy end), as appears in the main proxy config screen,
for each individual setting?

I am concerned some users may be using pidgin incorrectly.  But you
might be right that it is a dns problem, and it is attempting the
lookup locally.  In the case of the TAILS OS, all dns is transparently
routed over the tor, so local dns gets resolved, and that would work.
But for most privacy users, local dns queeries are a big no-no, yet
they need to be done, and hence are done via socks 5 at proxy end.

What is the workaround now? Use socks4 and make the changes? Is it
sufficient to turn off unpp and disable uneccessary plugins, or is the
tor/privacy setting doing stuff in the code that an end user can't set
manually?  I.E. If I just use socks5 and disable plugins, is that
enough?  Does it do anything versus cctp/ping/dcc etc?

Thanks


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

Re: tor/privacy (socks5) option giving ssl error

From my basic understanding, a tor/privacy setting should ensure:

*no local dns lookups (perhaps as an options checkbox)
socks4 automatically does lookup at end...there is no option.
socks5 you have option for local or remote dns in the spec.  Most tor
users want remote, except in the case of TAILS a user might handle the
dns queeries locally(and then resolving them through for instance tor's
dns port).  I think the same side is to do them remotely.

*real ip address never gets sent out

*no other system information gets sent out(kernel version, uname,
os, etc)

*nothing that seems to be a unique identifier gets sent out upon
connect/reconnect. (i.e. ssl session ids, user agents/version, etc).

*timestamps all converted to utc

*any functionality such as dcc where there is a direct connection to
the other client should either be disabled or also insure real ip is
not leaked.

I can't think of anything else off the top of my head, but I may have
missed something.

If you are a developer and can point me to a link to the code that
handles the proxy settings, I would take a further look.

Thanks

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

Re: tor/privacy (socks5) option giving ssl error

2013-04-02 Thread Daniel Atallah

On Tue, Apr 2, 2013 at 8:55 PM, Ileana ile...@fairieunderground.info wrote:

 You didn't provide any context to the specific issue, but the likely
 reason for this particular error is that the Tor/Privacy Socks5 mode
 will prevent DNS queries from occurring and this probably has the
 effect of preventing you from determining the correct server to
 connect to (e.g. a DNS SRV lookup is necessary to connect to the
 appropriate XMPP server for a number of domains unless you specify a
 Connect Server manually).


 Daniel,

 Sorry for the lack of context.  I am using tor and pidgin
 Pidgin 2.10.6 (libpurple 2.10.6), on linux.

 I am connecting to a normal irc server.

 It works with socks 5, it doesn't work, and immediately fails, with
 tor/privacy socks5 with error ssl connection failed.

 When I try to connect to an IRC tor hidden service
 address (blahblahblah.onion) I get:
 Unable to connect: Aborting DNS lookup in Tor Proxy mode.

 When I try to connect to a regular IRC address/hostname, I get SSL
 Connection Failed.

You'll need to provide more details - a sanitized debug log
(Help-Debug Window) from when it tries to connect should help.


 Both work when I select socks5.  Neither works with tor/privacy(socks5).

 Are you suggesting I should be putting the ip addresses in directly for
 these hostnames?  That isn't even possible in the case of the hidden
 service addresses.  And the hidden service address seems to resolve and
 work fine with the socks5 setting.

No, that's not necessarily what I'm suggesting.

 I don't see how this can't be some kind of bug?  Aren't the dns requests
 supposed to go through the proxy?  Do you need to add a check box (do
 dns lookup at proxy end), as appears in the main proxy config screen,
 for each individual setting?

Again, it's hard to say without more information.  It's not possible
to do all DNS requests through the proxy - you can pass a hostname to
the proxy and have it resolve it, but e.g. a SRV request can't be done
through a proxy.

No, that checkbox is globally applied, it doesn't need to be more
granularly applied.

 I am concerned some users may be using pidgin incorrectly.  But you
 might be right that it is a dns problem, and it is attempting the
 lookup locally.  In the case of the TAILS OS, all dns is transparently
 routed over the tor, so local dns gets resolved, and that would work.
 But for most privacy users, local dns queeries are a big no-no, yet
 they need to be done, and hence are done via socks 5 at proxy end.

 What is the workaround now? Use socks4 and make the changes? Is it
 sufficient to turn off unpp and disable uneccessary plugins, or is the
 tor/privacy setting doing stuff in the code that an end user can't set
 manually?  I.E. If I just use socks5 and disable plugins, is that
 enough?  Does it do anything versus cctp/ping/dcc etc?

TAILS is pretty much irrelevant from the application perspective.
I'm going to hold off answering the rest because we don't know what
the problem is.

-D

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

Re: tor/privacy (socks5) option giving ssl error

2013-04-02 Thread Daniel Atallah

On Tue, Apr 2, 2013 at 9:11 PM, Ileana ile...@fairieunderground.info wrote:
 From my basic understanding, a tor/privacy setting should ensure:

All of my answers below apply to stock Pidgin when you select
Tor/Privacy in the proxy settings- any third party plugins could
change the behavior.

Some effort has been put into making XMPP safe from a privacy
perspective; other protocols have issues - good patches are always
welcome.

 *no local dns lookups (perhaps as an options checkbox)
 socks4 automatically does lookup at end...there is no option.
 socks5 you have option for local or remote dns in the spec.  Most tor
 users want remote, except in the case of TAILS a user might handle the
 dns queeries locally(and then resolving them through for instance tor's
 dns port).  I think the same side is to do them remotely.

The libpurple DNS functionality will be blocked - anything that can be
done through the proxy will be done, otherwise the functionality will
fail (for things using the libpurple DNS API).

It's possible that protocols like gadu-gadu or sametime, which use
external libraries to implement the protoco,l would make DNS requests
without using the libpurple API.

It looks like Bonjour/Link-Local accounts will send stuff out on your
local network, because that's how the protocol works.

 *real ip address never gets sent out

This should be the case for XMPP.

If libpurple/Pidgin is configured appropriately, it won't know what
your external IP address is.


 *no other system information gets sent out(kernel version, uname,
 os, etc)

Your IRC account default settings contain some information from your
OS user account, but you're free to change them.

See https://developer.pidgin.im/ticket/15295

There may be other issues for other protocols


 *nothing that seems to be a unique identifier gets sent out upon
 connect/reconnect. (i.e. ssl session ids, user agents/version, etc).

Of course unique things will be sent out - you're connecting to a IM
account and your account name will be sent out (and possibly your
password too depending on what you're connecting to).


 *timestamps all converted to utc

I'm not sure if there are places where your timezone or information
that can be used to deduce your timezone are sent out, but I don't
consider this sensitive.

 *any functionality such as dcc where there is a direct connection to
 the other client should either be disabled or also insure real ip is
 not leaked.

This wouldn't be a reasonable assumption to make for protocols other than XMPP.

 I can't think of anything else off the top of my head, but I may have
 missed something.

 If you are a developer and can point me to a link to the code that
 handles the proxy settings, I would take a further look.

libpurple/proxy.c

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

Re: tor/privacy (socks5) option giving ssl error

On Tue, 2 Apr 2013 21:46:20 -0400
Daniel Atallah datal...@pidgin.im wrote:

 
  Daniel,
 
  Sorry for the lack of context.  I am using tor and pidgin
  Pidgin 2.10.6 (libpurple 2.10.6), on linux.
 
  I am connecting to a normal irc server.
 
  It works with socks 5, it doesn't work, and immediately fails, with
  tor/privacy socks5 with error ssl connection failed.
 
  When I try to connect to an IRC tor hidden service
  address (blahblahblah.onion) I get:
  Unable to connect: Aborting DNS lookup in Tor Proxy mode.
 
  When I try to connect to a regular IRC address/hostname, I get SSL
  Connection Failed.
 
 You'll need to provide more details - a sanitized debug log
 (Help-Debug Window) from when it tries to connect should help.
 

(21:49:24) account: Connecting to account foo44...@irc.oftc.net.
(21:49:24) connection: Connecting. gc = 0xb83c3868
(21:49:24) dnsquery: Performing DNS lookup for localhost
(21:49:24) dnsquery: Aborting DNS lookup in Tor Proxy mode.
(21:49:24) proxy: Connection attempt failed: Aborting DNS lookup in Tor Proxy 
mode.
(21:49:24) connection: Connection error on 0xb83c3868 (reason: 0 description: 
SSL Connection Failed)
(21:49:24) account: Disconnecting account foo44...@irc.oftc.net (0xb7c39428)
(21:49:24) connection: Disconnecting connection 0xb83c3868
(21:49:24) connection: Destroying connection 0xb83c3868
(21:49:28) autorecon: do_signon called
(21:49:28) autorecon: calling purple_account_connect

I don't understand this...it says it is doing dns lookup for localhost?

Ahh! I found it...I had localhost in the settings rather then
127.0.0.1.

When I set it to 127.0.0.1 for the proxy host, it works.  I see, it
cuts off all local dns requests, including looking at the host file.

I am not sure if this should be documented...most other applications
(firefox, thunderbird, etc) have the option to do some names locally,
in particular, localhost should usually work.  This may be considered a
minor bug?


 
 Again, it's hard to say without more information.  It's not possible
 to do all DNS requests through the proxy - you can pass a hostname to
 the proxy and have it resolve it, but e.g. a SRV request can't be done
 through a proxy.


 
 No, that checkbox is globally applied, it doesn't need to be more
 granularly applied.

Perhaps you are right.  And I am mixed up in my statements.  socks 4
you have the option local/remote dns.  socks4a seems to automatically
do remote, no option, but pidgin doesn't seem to do socks4a.  And socks5
again the option, but it seems the common setting is to do remote
lookup.  

 
  I am concerned some users may be using pidgin incorrectly.  But you
  might be right that it is a dns problem, and it is attempting the
  lookup locally.  In the case of the TAILS OS, all dns is
  transparently routed over the tor, so local dns gets resolved, and
  that would work. But for most privacy users, local dns queeries are
  a big no-no, yet they need to be done, and hence are done via socks
  5 at proxy end.
 
  What is the workaround now? Use socks4 and make the changes? Is it
  sufficient to turn off unpp and disable uneccessary plugins, or is
  the tor/privacy setting doing stuff in the code that an end user
  can't set manually?  I.E. If I just use socks5 and disable plugins,
  is that enough?  Does it do anything versus cctp/ping/dcc etc?
 
 TAILS is pretty much irrelevant from the application perspective.
 I'm going to hold off answering the rest because we don't know what
 the problem is.
 
OK...I see what you are saying.  I see how TAILS should be irrelevant
from the application end...up into the point the application itself is
sending out information that could deanoymize the client.  TAILS really
can't do anything about that, hence I like that pidgin is
compartmentalizing the problem by having this privacy setting.  I just
think it should be documented exactly what it is doing.

It seems your Tor/Privacy mode should keep the user, by any means
possible, from doing un-intentional loss of private information at the
application level.

Thanks for helping me resolve this, and your obvious work on this app,
which is really nice. I guess I will have to look at the code to see
exactly what is the difference from the socks5/torprivacy setting?  You
mentioned, obviously, it blocking DNS, and we see that here.  I am
wanting a full list of differences.

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

Re: tor/privacy (socks5) option giving ssl error