Re: SSL security concern
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
Re: SSL security concern
On Tue, 15 Oct 2013 10:34:11 +0100 Ralf Skyper Kaiser wrote: 1. OTR: encrypt messages by default (private messaging). - Out of scope. Can only be fixed within the OTR plugin (developers disappeared). I don't think the OTR developers have disappeared, only that they haven't been on this list. They're on the cypherpunks list, or at least they were roughly 10 days ago. -- 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
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
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
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
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
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,
