[pfSense] naive suggestion: conform to US laws
Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. Regards, Adrian. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Can pfSense be considered trusted? What implementations of VPNs can now be trusted?
- Forwarded message from James A. Donald jam...@echeque.com - Date: Fri, 11 Oct 2013 07:41:56 +1000 From: James A. Donald jam...@echeque.com To: cypherpu...@cpunks.org, Giles Coochey gi...@coochey.net Subject: Re: [pfSense] Can pfSense be considered trusted? What implementations of VPNs can now be trusted? Message-ID: 52571f24.4030...@echeque.com User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 On 2013-10-11 00:39, Eugen Leitl wrote: - Forwarded message from Giles Coochey gi...@coochey.net - 2. Cipher Selection - we're not all cryptoanalysts, so statements like 'trust the math' don't always mean much to us, given the reports in the media, what is considered a safe cypher? I recently switched from AES-256 to Blowfish-256, hashing from SHA-1 to SHA-512 and pfs group 2 to pfs group 5, and I reduced my SA lifetimes from 28800 to 1800. Could that be considered overkill? What Cipher's are others using? Have any of you, who have been made recently aware of the media coverage recently, also changed your cipher selection? What kind of changes did you make? Overkill is a rational and appropriate response to recent revelations. NIST is actually out to get you, so you might as well put on a tinfoil hat to be on the safe side. Yes, there really is a gigantic government conspiracy, no kidding. While I am pretty sure AES and SHA 256 is perfectly safe, in view of recent events, I would follow the lead of the highly competent cryptographer Jon Callas, http://www.mail-archive.com/infowarrior@attrition.org/msg10926.html and use non NIST algorithms: Use Twofish in place of AES if convenient to do so, and Skein hash in place of SHA hash. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Crypto/RNG Suggestions
- Forwarded message from James A. Donald jam...@echeque.com - Date: Fri, 11 Oct 2013 07:53:02 +1000 From: James A. Donald jam...@echeque.com To: cypherpu...@cpunks.org, li...@pingle.org Subject: Re: [pfSense] Crypto/RNG Suggestions Message-ID: 525721be.3050...@echeque.com User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 On 2013-10-10 22:21, Eugen Leitl wrote: - Forwarded message from Jim Pingle li...@pingle.org - I haven't yet seen anything conclusive. People have called into question some or all of ECC, NSA's suggested Suite B, and so on. I put some links in a previous message[1]. If anyone knows of some solid research showing specific ciphers have been compromised, I'd love to see it so we can inform users. There is a smoking gun on one of random number generators. There is strong circumstantial evidence, reason for suspicion, on suggested Suite B. AES and SHA look to be fine, but using them gives the appearance to end users that you might be playing footsie with NIST. Jon Callas has therefore made Twofish and Skein the default for silent circle. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] cipher suites and NIST
There is a smoking gun on one of random number generators. There is strong circumstantial evidence, reason for suspicion, on suggested Suite B. AES and SHA look to be fine, but using them gives the appearance to end users that you might be playing footsie with NIST. Cryptographer Jon Callas has therefore made Twofish and Skein the default for silent circle. I recommend that everyone follow Jon Callas on symmetric cryptography, and DJ Bernstein on asymmetric cryptography. The best people are putting as much distance as possible between themselves and NIST. Oh, and about tinfoil hats: There really is a great big government conspiracy, and they really are out to get you. Tinfoil hats may not be effectual, but Bernstein's curve25519 will help. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Excellent idea. Really. But that would kill the project probably. Regards, On Fri, 11 Oct 2013 11:57:52 +0200 Adrian Zaugg a...@ente.limmat.ch wrote: (...) mind that pfsense web GUI could declare itself conform to US laws (...) It would be the sign for the users Regards, Adrian. -- Przemysław Pawełczyk (P2O2) - p...@blast.pl The Snapshots My Way - http://pp.blast.pl pgpOHBlwduczr.pgp Description: PGP signature ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Probably would not work (or would get whoever did that thrown in jail). This is similar to a Warrant Canary, but the USDoJ has indicated that Warrant Canaries would probably be grounds for prosecution of violation of the non-disclosure order. - Y On Friday, October 11, 2013, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. Regards, Adrian. ___ List mailing list List@lists.pfsense.org javascript:; http://lists.pfsense.org/mailman/listinfo/list -- Sent from a gizmo with a very small keyboard and hyper-active auto-correct. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 11-10-2013 11:57, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. ? And which country would that be? I mean the Brittish MI4? tapped the Belgian telecom network for over a year to listen into the EU politicians... I don't see the point in this. I've been a developer since november 2005 and since that time I have never seen any evidence that this is the case. Not to downplay the trust issue, it is always good to do a background check on what we put into pfSense (which we do). Pretty much everything we have in pfSense is checked in the version control system. Even in the beginnings (0.83) with CVS. Even our builder scripts are in a RCS system, and it verifies all checksums on external (mostly FreeBSD ports) software we download for the build. The most realistic way to get a backdoor in pfSense would have to come from a upstream source. And FreeBSD generally has this properly in order and a security team that acts properly. The way the most intelligence agencies these days perform the wire tapping is by getting a switch mirror port at a internet exchange. Even fiber optics can be tapped without too much problems. In .NL all large ISPs have a mandatory wiretap in place that stores datetime stamped headers of the internet traffic for discovery purposes from the authorities. The best part of this, it is paid for by the customers, since the ISP needs to pay for the system and storage. Regards, Seth ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 11-10-2013 11:57, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. ? And which country would that be? I mean the Brittish MI4? tapped the Belgian telecom network for over a year to listen into the EU politicians... I don't see the point in this. I've been a developer since november 2005 and since that time I have never seen any evidence that this is the case. Not to downplay the trust issue, it is always good to do a background check on what we put into pfSense (which we do). Pretty much everything we have in pfSense is checked in the version control system. Even in the beginnings (0.83) with CVS. Even our builder scripts are in a RCS system, and it verifies all checksums on external (mostly FreeBSD ports) software we download for the build. The most realistic way to get a backdoor in pfSense would have to come from a upstream source. And FreeBSD generally has this properly in order and a security team that acts properly. The way the most intelligence agencies these days perform the wire tapping is by getting a switch mirror port at a internet exchange. Even fiber optics can be tapped without too much problems. In .NL all large ISPs have a mandatory wiretap in place that stores datetime stamped headers of the internet traffic for discovery purposes from the authorities. The best part of this, it is paid for by the customers, since the ISP needs to pay for the system and storage. Regards, Seth ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] cipher suites and NIST
On 10/11/2013 06:23 AM, James A. Donald wrote: There is a smoking gun on one of random number generators. There is strong circumstantial evidence, reason for suspicion, on suggested Suite B. AES and SHA look to be fine, but using them gives the appearance to end users that you might be playing footsie with NIST. Cryptographer Jon Callas has therefore made Twofish and Skein the default for silent circle. I recommend that everyone follow Jon Callas on symmetric cryptography, and DJ Bernstein on asymmetric cryptography. The best people are putting as much distance as possible between themselves and NIST. Oh, and about tinfoil hats: There really is a great big government conspiracy, and they really are out to get you. Tinfoil hats may not be effectual, but Bernstein's curve25519 will help. hi james, indeed -- i read the post -- seems rather intersesting. question is -- how do you actually implement it in pfsense? i am assuming a custom openvpn build, custom android build, linux build, etc? thanks m ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 11/10/13 2:37 pm, Seth Mos wrote: And which country would that be? I mean the Brittish MI4? tapped the Belgian telecom network for over a year to listen into the EU politicians... Who is this MI4 of whom you speak? :-) In very broad terms, UK to USA equivalents would be as follows: GCHQ = NSA MI5 = FBI (though the FBI has a much wider remit) SIS (sometimes erroneously referred to as MI6) = CIA On 11/10/13 2:37 pm, Seth Mos wrote: In .NL all large ISPs have a mandatory wiretap in place that stores datetime stamped headers of the internet traffic for discovery purposes from the authorities. The best part of this, it is paid for by the customers, since the ISP needs to pay for the system and storage. There have been attempts to do similar in the UK, but ISPA (our industry body) has fought pretty hard against it. It seems to have died for now, but I've no doubt that future governments (or home secretaries) will try and resurrect it at every possible opportunity. Kind regards, Chris -- This email is made from 100% recycled electrons ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] cipher suites and NIST
On Fri, Oct 11, 2013 at 12:23 AM, James A. Donald jam...@echeque.comwrote: There is a smoking gun on one of random number generators. There is strong circumstantial evidence, reason for suspicion, on suggested Suite B. AES and SHA look to be fine, but using them gives the appearance to end users that you might be playing footsie with NIST. Cryptographer Jon Callas has therefore made Twofish and Skein the default for silent circle. I recommend that everyone follow Jon Callas on symmetric cryptography, and DJ Bernstein on asymmetric cryptography. The best people are putting as much distance as possible between themselves and NIST. Oh, and about tinfoil hats: There really is a great big government conspiracy, and they really are out to get you. Tinfoil hats may not be effectual, but Bernstein's curve25519 will help. __**_ List mailing list List@lists.pfsense.org http://lists.pfsense.org/**mailman/listinfo/listhttp://lists.pfsense.org/mailman/listinfo/list To play devil's advocate, I'd say using AES and SHA gives the appearance to end users that it's business as usual in enterprise-town. Right now most people are still going to be using some flavor of AES and some flavor of SHA. And it has nothing to do with some intentional close relationship with NIST. It's just that big gears turn slowly. On the practical side of things, interoperability is a big deal for a lot of people. And a wider array of ciphers will certainly be coming down the pipeline soon, but for now if I want to connect to John Q. Client, I'm at the mercy of what their systems support in terms of transform sets. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 2013-10-11 16:37, Seth Mos wrote: On 11-10-2013 11:57, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. ? And which country would that be? There are many countries which would be a possibility . If wiretapping is done there or not is not so relevant. Relevant is, if the authorities can and do inject backdoors into the project by legal force. Pretty much everything we have in pfSense is checked in the version control system. Even in the beginnings (0.83) with CVS. Even our builder scripts are in a RCS system, and it verifies all checksums on external (mostly FreeBSD ports) software we download for the build. I am not an expert, but in the NSA-thread above there have been examples given, how CVS can be circumvented. Also, the gap between the sources and the binaries could possibly be an port of entry for nasty stuff I guess. Again: The real threat by my comprehension is not some guy in the internet trying to place malicious code into the code base, but simply and plainly some NSA officers knock the door an force the project leaders to do it. The way the most intelligence agencies these days perform the wire tapping is by getting a switch mirror port at a internet exchange. Even fiber optics can be tapped without too much problems. Yes, they do that. And much more, because they do not restrict themselves to a single source. They e.g. get the data from the data providers (google, facebook, amazon, etc.) AND wiretap the internet backbones AND program trojan horses to send them to their peoples (see e.g. https://en.wikipedia.org/wiki/Bundestrojaner#Staatstrojaner) AND collect geolocation data from your mobile phone provider AND force your encrypted-email provider to hand out their SSL keys to them AND ... etc. etc. etc. But: With all those methods they can only collect EXTERNAL data. With exception the mentioned trojan horse, they do not as easily get your INTERNAL data, e.g. the data that circulates between the computers of your intranet. By infiltrating a firewall software such as pfSense, they could get a grip onto the most important neuralgic point of the intranet, since much of the internal traffic flows over this box. Think e.g. about all that VPN traffic that flows over the firewall, e.g. because a company connects many branches via VPN... So: Getting a grip onto the firewall would surely be highly interesting for them... In .NL all large ISPs have a mandatory wiretap in place that stores datetime stamped headers of the internet traffic for discovery purposes from the authorities. The best part of this, it is paid for by the customers, since the ISP needs to pay for the system and storage. Yes, but see above. Regards, Seth Regards Thinker Rix ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 2013-10-11 13:54, Przemysław Pawełczyk wrote: On Fri, 11 Oct 2013 11:57:52 +0200 Adrian Zaugg a...@ente.limmat.ch wrote: (...) mind that pfsense web GUI could declare itself conform to US laws (...) It would be the sign for the users Regards, Adrian. Excellent idea. Really. But that would kill the project probably. I am not sure that I understand what you mean. Is it what you want to say: In the case that the security software that you use gets infiltrated, you would prefer not learning about this fact, but just continue using it? Greetings Thinker Rix ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 2013-10-11 12:57, Adrian Zaugg wrote: After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. I think that your idea is worth further consideration. As I just answered to other postings of this thread, by my comprehension infiltrating firewall software such as pfSense should be highly interesting for NSA, etc. because they would get a grip onto your internal and VPN traffic. So it should be only a matter of time, that they knock the door at ESF and force them to do things they don't like. We all - as a community - should think and act pro-actively to that and take appropriate measures to protect pfSense, ESF and the key people such as Chris Buechler and his partners from this realistic thread in time. Best regards Thinker Rix ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 2013-10-11 16:20, Yehuda Katz wrote: Probably would not work (or would get whoever did that thrown in jail). This is similar to a Warrant Canary, but the USDoJ has indicated that Warrant Canaries would probably be grounds for prosecution of violation of the non-disclosure order. - Y On Friday, October 11, 2013, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. Regards, Adrian. Hi Yehuda, inspired by the keyword you dropped, I researched a little bit and found: https://en.wikipedia.org/wiki/Warrant_canary It seems that you are correct: What Adrian suggests, is called a Warrant canary. In the wikipedia article it says that: The intention is to allow the provider to inform customers of the existence of a subpoena passively, without violating any laws. The legality of this method has not been tested in any court. Is that wrong or in conflict with what you wrote? In the case that it would indeed be prosecuted in the USA, we could consider to host the project in another country. In this case it would be interesting to investigate what needs to be hosted elsewhere: The source code versioning control system? The company behind pfSense (ESF)? I guess that the best solution would be to incorporate pfSense itself and untie it from ESF. Many other free software projects have done so recently. The most prominent example is Libre Office which is now owned by the Document Foundation (https://en.wikipedia.org/wiki/Document_Foundation). The owned refers to e.g. the brand name, since the software itself is free software, it is not owned by anybody. So summarizing: If pfSense would be incorporated as a foundation at some place (many countries would be possible) outside the USA, it could be a solution to this I guess. Regards Thinker Rix ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
As I see it, there are are two things that can happen here 1) NSA breaks into pfSense without knowledge of the staff = The only solution is source code and binary review. This is not an option for people like Thinker Rix or other non coders. The mostly spot for this to happen is upstream from the project (in FreeBSD itself, in the libraries that FreeBSD uses). This will require resources outside of the pfSense project to validate. 2) NSA forces pfSense to put a backdoor in the software. Tells pfSense to be quite about it. The results of 2) are that either pfSense stays quite or they tell. i) If they stay quite, then the only solution is the same answer as for 1), independent evaluation. ii) If they tell, then the project is over as they will be busy fighting the government. They can be arrested for telling. Depending on the Judge, any said or done that tips off someone that the project has a NSL, can be taken as a violation. What do you expect from the project? That they promise that they have not been subverted and further promise to tell you when/if there are subverted, regardless of the personal and financial costs to them? This is a free project... What is reasonable to expect from any project like this? Once we question trust in the project, the only reasonable course of action is independent evaluation. Guess what, that is what the Government does when it evaluates software. In fact, that is one of the NSA's other jobs. This does, however, make software much more expensive. How to we get a trusted evaluation of the software? On Fri, Oct 11, 2013 at 10:46 AM, Thinker Rix thinke...@rocketmail.comwrote: On 2013-10-11 12:57, Adrian Zaugg wrote: After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. I think that your idea is worth further consideration. As I just answered to other postings of this thread, by my comprehension infiltrating firewall software such as pfSense should be highly interesting for NSA, etc. because they would get a grip onto your internal and VPN traffic. So it should be only a matter of time, that they knock the door at ESF and force them to do things they don't like. We all - as a community - should think and act pro-actively to that and take appropriate measures to protect pfSense, ESF and the key people such as Chris Buechler and his partners from this realistic thread in time. Best regards Thinker Rix __**_ List mailing list List@lists.pfsense.org http://lists.pfsense.org/**mailman/listinfo/listhttp://lists.pfsense.org/mailman/listinfo/list -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Who would you trust more that ESF? Why,specifically, would you trust another group of people to be more trustworthy? I admit to have a USA bias, but for the issue in question, I don't there being a much better choice. The UK has less freedoms in this matter. But then this is turning into a case of I'm worried about things, here lets have you [The project] spend time and money to fix the problem? Unless, of course, you are willing to contribute time and money to fixing this issue. Otherwise this just an armchair general telling other people how to run the project. On Fri, Oct 11, 2013 at 10:41 AM, Thinker Rix thinke...@rocketmail.comwrote: On 2013-10-11 16:20, Yehuda Katz wrote: Probably would not work (or would get whoever did that thrown in jail). This is similar to a Warrant Canary, but the USDoJ has indicated that Warrant Canaries would probably be grounds for prosecution of violation of the non-disclosure order. - Y On Friday, October 11, 2013, Adrian Zaugg wrote: Dear all After having read the whole NSA thread on this list, it came up to my mind that pfsense web GUI could declare itself conform to US laws upon the point when there are known backdoors included or otherwise the code was compromised on pressure of govermental authorities. It would be the sign for the users to review the code and maybe to fork an earlier version and host it in a free country, where the protection of personal data is a common sense and national security is not so much an issue. Regards, Adrian. Hi Yehuda, inspired by the keyword you dropped, I researched a little bit and found: https://en.wikipedia.org/wiki/Warrant_canary It seems that you are correct: What Adrian suggests, is called a Warrant canary. In the wikipedia article it says that: The intention is to allow the provider to inform customers of the existence of a subpoena passively, without violating any laws. The legality of this method has not been tested in any court. Is that wrong or in conflict with what you wrote? In the case that it would indeed be prosecuted in the USA, we could consider to host the project in another country. In this case it would be interesting to investigate what needs to be hosted elsewhere: The source code versioning control system? The company behind pfSense (ESF)? I guess that the best solution would be to incorporate pfSense itself and untie it from ESF. Many other free software projects have done so recently. The most prominent example is Libre Office which is now owned by the Document Foundation (https://en.wikipedia.org/wiki/Document_Foundation). The owned refers to e.g. the brand name, since the software itself is free software, it is not owned by anybody. So summarizing: If pfSense would be incorporated as a foundation at some place (many countries would be possible) outside the USA, it could be a solution to this I guess. Regards Thinker Rix ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On Fri, Oct 11, 2013 at 1:41 PM, Thinker Rix thinke...@rocketmail.comwrote: Probably would not work (or would get whoever did that thrown in jail). This is similar to a Warrant Canary, but the USDoJ has indicated that Warrant Canaries would probably be grounds for prosecution of violation of the non-disclosure order. inspired by the keyword you dropped, I researched a little bit and found: https://en.wikipedia.org/wiki/Warrant_canary It seems that you are correct: What Adrian suggests, is called a Warrant canary. In the wikipedia article it says that: The intention is to allow the provider to inform customers of the existence of a subpoena passively, without violating any laws. The legality of this method has not been tested in any court. Is that wrong or in conflict with what you wrote? I do not know of any prosecution for using a Warrant Canary, but that does not change whether the government would intend to prosecute it (and I have discussed it with lawyers in the DoJ and other areas). It just means that the situation has not come up: either because no place that uses a Warrant Canary has received a secret order or because no place that has received one has been willing to really use it as designed. This is what it boils down to: Do you want to go in front of a federal judge and say I did not say we received a subpoena, I just stopped saying we did not receive one.? I know I would not want to. If anyone wants to talk more about Warrant Canaries, email me off the list. - Y ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 2013-10-11 21:20, Walter Parker wrote: Who would you trust more that ESF? Why,specifically, would you trust another group of people to be more trustworthy? The point is not untrusting ESF or anybody else. The point is that ESF is based in the USA, a country where the current government can force you to do things against your community without having any chance to escape from it; they just force you to do so. So the point of the whole idea that we evaluate here is: How can we secure pfSense from this nasty government so that they can not just force ESF or anybody else to comply with them. I admit to have a USA bias, but for the issue in question, I don't there being a much better choice. The UK has less freedoms in this matter. As far as I am informed there are some more countries on the globe than the USA and the UK... But then this is turning into a case of I'm worried about things, here lets have you [The project] spend time and money to fix the problem? Unless, of course, you are willing to contribute time and money to fixing this issue. Otherwise this just an armchair general telling other people how to run the project. Seems like a killer argument to me, which is kind of couterproductive in such an early stage of an idea/proposition, as this is. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Yes, you have been informed correctly. There are more than 2. According the World Atlas (http://www.worldatlas.com/nations.htm#.UlhOHVFDsnY) the number is someone between 189 and 196. But you did not answer the question asked: Name the country that you would move the project to and why you believe that country would do a better job? Then because the USA can't be trusted, who is going to replace the Americans on the project? The name and logo are owned by an American company. I doubt they want to give them up to a foreign company owned by non-Americans just to make it harder for the American government to pressure the project. If the rest of world wants to fork the project because of concerns about the US government, fine, but I don't think you will get buy in from ESF [the American company that owns the rights to the name pfSense]. Once again, name some names. Who do you consider more trustworthy? Follow the link, which of the 188-195 countries on that list do you propose to trust more and why? I'd suggest you pick once that is not already in bed with the NSA (which includes most of major western governments, plus some of the Middle East and Far East governments). But that is me, maybe you prefer to decide to move first and then figure out where you are going after you have left (rather than planning where you are going before you leave). Walter On Fri, Oct 11, 2013 at 12:11 PM, Thinker Rix thinke...@rocketmail.comwrote: On 2013-10-11 21:20, Walter Parker wrote: Who would you trust more that ESF? Why,specifically, would you trust another group of people to be more trustworthy? The point is not untrusting ESF or anybody else. The point is that ESF is based in the USA, a country where the current government can force you to do things against your community without having any chance to escape from it; they just force you to do so. So the point of the whole idea that we evaluate here is: How can we secure pfSense from this nasty government so that they can not just force ESF or anybody else to comply with them. I admit to have a USA bias, but for the issue in question, I don't there being a much better choice. The UK has less freedoms in this matter. As far as I am informed there are some more countries on the globe than the USA and the UK... But then this is turning into a case of I'm worried about things, here lets have you [The project] spend time and money to fix the problem? Unless, of course, you are willing to contribute time and money to fixing this issue. Otherwise this just an armchair general telling other people how to run the project. Seems like a killer argument to me, which is kind of couterproductive in such an early stage of an idea/proposition, as this is. __**_ List mailing list List@lists.pfsense.org http://lists.pfsense.org/**mailman/listinfo/listhttp://lists.pfsense.org/mailman/listinfo/list -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 10/11/13 8:20 PM, Walter Parker wrote: Unless, of course, you are willing to contribute time and money to fixing this issue. Otherwise this just an armchair general telling other people how to run the project. I don't think it is a problem to find a sponsered hosting here in Switzerland for example. Our law protects citizens from govermental despotism quite well. National security is not an issue here. But this is not the question. The question is wether software projects hosted in the US are still trustworthy because of the legal situation there. If the pfsense community has the opinion, that it is too risky, then it is time to start acting. Once this point is reached, me and others would certainly try to contribute. Most of the people here are network specialists and do have their connections to hosting possibilities, I think. Regards, Adrian. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Don't be too sure about Switzerland... https://www.schneier.com/blog/archives/2008/01/nsa_backdoors_i.html Which talks about a story that was in the German papers in the late 90's.. For half a century, Crypto AG, a Swiss company located in Zug, has sold to more than 100 countries the encryption machines their officials rely upon to exchange their most sensitive economic, diplomatic and military messages. Crypto AG was founded in 1952 by the legendary (Russian born) Swedish cryptographer Boris Hagelin. During World War II, Hagelin sold 140,000 of his machine to the US Army. In the meantime, the Crypto AG has built up long standing cooperative relations with customers in 130 countries, states a prospectus of the company. The home page of the company Web site says, Crypto AG is the preferred top-security partner for civilian and military authorities worldwide. Security is our business and will always remain our business. And for all those years, US eavesdroppers could read these messages without the least difficulty. A decade after the end of WWII, the NSA, also known as No Such Agency, had rigged the Crypto AG machines in various ways according to the targeted countries. It is probably no exaggeration to state that this 20th century version of the Trojan horse is quite likely the greatest sting in modern history. On Fri, Oct 11, 2013 at 12:49 PM, Adrian Zaugg a...@ente.limmat.ch wrote: On 10/11/13 8:20 PM, Walter Parker wrote: Unless, of course, you are willing to contribute time and money to fixing this issue. Otherwise this just an armchair general telling other people how to run the project. I don't think it is a problem to find a sponsered hosting here in Switzerland for example. Our law protects citizens from govermental despotism quite well. National security is not an issue here. But this is not the question. The question is wether software projects hosted in the US are still trustworthy because of the legal situation there. If the pfsense community has the opinion, that it is too risky, then it is time to start acting. Once this point is reached, me and others would certainly try to contribute. Most of the people here are network specialists and do have their connections to hosting possibilities, I think. Regards, Adrian. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
This story is about a private company and about technology. We talk about the legal situation. And btw. it is a criminal act to eavesdrop and to hack into other's systems under Swiss law. Regards, Adrian. On 10/11/13 9:54 PM, Walter Parker wrote: Don't be too sure about Switzerland... https://www.schneier.com/blog/archives/2008/01/nsa_backdoors_i.html ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
Hi, I just tried it on an VMware based NanoBSD Version and it allways happens and it is not Memory based, because the VM has 1GB. I'm not a FreeBSD expert, but /dev/md's are MemDiscs right? Is there a reason why only 60MB (/var) and 40MB(/tmp/) are used? and are where are possibilities to change that? It's not in the fstab! I will next try to install a normal (non-NanoBSD) version and do a update there. I hope that will help. CU Jens ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
On Fri, Oct 11, 2013 at 2:58 PM, Jens Kühnel pfse...@jens.kuehnel.orgwrote: and are where are possibilities to change that? It's not in the fstab! /etc/rc.embedded ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On 10/11/13 2:13 PM, Walter Parker wrote: As I see it, there are are two things that can happen here Not yelling at Walter. The problem with all of this is that as long as our Congress (and the equivalent in other countries) passes laws that allow such backdoors with a threat of jail if you talk about it at any level we will have these issues. If you want this to go away, then we need to elect folks to Congress who will change the laws. But for most of us that's too big a hill to climb in terms of personal effort so we don't do it. David ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
On 10/11/2013 4:58 PM, Jens Kühnel wrote: I'm not a FreeBSD expert, but /dev/md's are MemDiscs right? Is there a reason why only 60MB (/var) and 40MB(/tmp/) are used? and are where are possibilities to change that? It's not in the fstab! They are that small because ALIX is the usual NanoBSD target and it only has 256MB of RAM so it's a safe low default. NanoBSD wasn't originally intended to run on device with gobs of RAM, but times are a-changin' and before long all of the viable new hardware will have 1GB of RAM. On 2.1 you can adjust the /var and /tmp sizes under System Advanced on the Miscellaneous tab. It might be possible to auto-scale the sizes with a bit of extra logic in rc.embedded if someone wants to take a crack at it. Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
On Fri, Oct 11, 2013 at 3:25 PM, Jim Pingle li...@pingle.org wrote: On 2.1 you can adjust the /var and /tmp sizes under System Advanced on the Miscellaneous tab. Right! I had forgot about that. So following the original topic, could one more probably ensure a successful upgrade to 2.1 by increasing the size of /var by some amount? I have a nanoBSD system with 4G of RAM sitting at 10% usage. If I dedicated 3G of that to /var and upgraded, will the RRD bug in question still kill my upgrade? On a related note, does this bug affect upgrades from older 2.1 betas and RCs? This system happens to be running 2.1RC0 and I'd very much like to upgrade it to 2.1 without going on site if I can avoid it. db ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
On 13-10-11 04:25 PM, Jim Pingle wrote:
They are that small because ALIX is the usual NanoBSD target and it only
has 256MB of RAM so it's a safe low default. NanoBSD wasn't originally
intended to run on device with gobs of RAM, but times are a-changin' and
before long all of the viable new hardware will have 1GB of RAM.
On 2.1 you can adjust the /var and /tmp sizes under System Advanced on
the Miscellaneous tab.
It might be possible to auto-scale the sizes with a bit of extra logic
in rc.embedded if someone wants to take a crack at it.
Challenge accepted.
I have no idea how to clone the repo and do a pull request, so I'm just
attaching a simple diff instead.
I believe sysctl is available at this point in the boot process. If
not, then the solution will be quite a bit more difficult...
I'm not sure what the point would be in continuing if sysctl *failed*,
but what the heck, I just assume a 256MB machine.
Obviously a lot more special-casing could be done to ensure lower- and
upper-bound cases function correctly; I only handled one simplistic case.
The invocation to get $physmem ensures we don't needlessly fork()/exec()
on an embedded platform.
--
-Adam Thompson
athom...@athompso.net
--- rc.embedded.orig 2013-10-11 16:35:10.691385354 -0500
+++ rc.embedded 2013-10-11 17:26:55.779500598 -0500
@@ -8,7 +8,12 @@
if [ ! -z ${USE_MFS_TMP_SIZE} ] [ ${USE_MFS_TMP_SIZE} -gt 0 ]; then
tmpsize=${USE_MFS_TMP_SIZE}m
else
- tmpsize=40m
+ physmem=${physmem:-$(/sbin/sysctl -n hw.physmem)}
+ # in case we can't execute /sbin/sysctl, assume 256MB machine
+ physmem=${physmem:-282563637}
+ tmpsize=$((physmem*15/104857600))
+ if [ $tmpsize -le 40 ]; then varsize=40; fi
+ tmpsize=${tmpsize}m
fi
# Size of /var
@@ -16,7 +21,11 @@
if [ ! -z ${USE_MFS_VAR_SIZE} ] [ ${USE_MFS_VAR_SIZE} -gt 0 ]; then
varsize=${USE_MFS_VAR_SIZE}m
else
- varsize=60m
+ physmem=${physmem:-$(/sbin/sysctl -n hw.physmem)}
+ physmem=${physmem:-282563637}
+ varsize=$((physmem*25/104857600))
+ if [ $varsize -lt 60 ]; then varsize=60; fi
+ varsize=${varsize}m
fi
# Run some initialization routines
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
So, if I have an ALIX that I would like to upgrade, how much would I have to increase /tmp and /var by to have the upgrade run to completion without filling the partitions? Walter On Fri, Oct 11, 2013 at 2:25 PM, Jim Pingle li...@pingle.org wrote: On 10/11/2013 4:58 PM, Jens Kühnel wrote: I'm not a FreeBSD expert, but /dev/md's are MemDiscs right? Is there a reason why only 60MB (/var) and 40MB(/tmp/) are used? and are where are possibilities to change that? It's not in the fstab! They are that small because ALIX is the usual NanoBSD target and it only has 256MB of RAM so it's a safe low default. NanoBSD wasn't originally intended to run on device with gobs of RAM, but times are a-changin' and before long all of the viable new hardware will have 1GB of RAM. On 2.1 you can adjust the /var and /tmp sizes under System Advanced on the Miscellaneous tab. It might be possible to auto-scale the sizes with a bit of extra logic in rc.embedded if someone wants to take a crack at it. Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] Assign tun0 (created by vpnc at command line) to OPT interface
Hi, I’ve tried the assign interfaces option at the command line, and the Web Configurator, but neither option in 2.1 recognized the tun0 interface (which is up) as a valid interface for assignment. How can I make this happen? Robert ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
On Fri, Oct 11, 2013 at 11:13 AM, Walter Parker walt...@gmail.com wrote: 2) NSA forces pfSense to put a backdoor in the software. Tells pfSense to be quite about it. The problem with doing that to open source is that it's easy to verify that it happened (especially after someone provides an anonymous hint). It's hard to keep secrets these days. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
Thank you for the final word Jim. I have a real issue brought up by this thread; Gmail now considers a significant amount of the list.pfSense.org mail spam, and this thread (and a few others) was just that. I'd complain more but others told Thinker exactly what I would say and he doesn't care. Mike McLaughlin On Fri, Oct 11, 2013 at 5:16 PM, Gé Weijers g...@weijers.org wrote: On Fri, Oct 11, 2013 at 11:13 AM, Walter Parker walt...@gmail.com wrote: 2) NSA forces pfSense to put a backdoor in the software. Tells pfSense to be quite about it. The problem with doing that to open source is that it's easy to verify that it happened (especially after someone provides an anonymous hint). It's hard to keep secrets these days. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] naive suggestion: conform to US laws
I second nixing the thread. pfSense does not benefit from this. Mehma On Oct 11, 2013, at 3:40 PM, Jim Thompson j...@netgate.com wrote: On Oct 11, 2013, at 12:39, Thinker Rix thinke...@rocketmail.com wrote: Again: The real threat by my comprehension is not some guy in the internet trying to place malicious code into the code base, but simply and plainly some NSA officers knock the door an force the project leaders to do it. Please cite the law they might use to so this. Hint: it doesn't exist. Hint 2: if you think Lavabit applies, you're part of the problem. Otherwise: get off my lawn. I'm willing to listen to: I've dreamed up this possible attack that could inject bad code into pfSense. And especially, I think I've found a problem. I'm not willing to endure this uninformed Alex Jonesian crapfest. Now that I'm back on US soil, I promise that if the later continues, I will kill the thread. People who hijack threads will be dealt with. I simply don't have time for it, and the people who actually work on pfSense don't gave time for it. Nor will I endure the besmirching of pfSense's good name and trademark. If you have real issues, or even theories supported by minimal evidence, bring them forward. Otherwise: STFU. Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
Hi, On 2.1 you can adjust the /var and /tmp sizes under System Advanced on the Miscellaneous tab. Right! I had forgot about that. and would not help because it is needed to be done before (or during) the upgrade. So following the original topic, could one more probably ensure a successful upgrade to 2.1 by increasing the size of /var by some amount? I have a nanoBSD system with 4G of RAM sitting at 10% usage. If I dedicated 3G of that to /var and upgraded, will the RRD bug in question still kill my upgrade? I kust did that. I increated it to 2*100MB and now it is enough for my upgrade on my virtual machine. I will do the real upgrade tomorrow, with deletion of the rrd Data before the update and a restore of the rrd-data after the upgrade with the already converted rrd backup. On a related note, does this bug affect upgrades from older 2.1 betas and RCs? This system happens to be running 2.1RC0 and I'd very much like to upgrade it to 2.1 without going on site if I can avoid it. I have a identically setup with ony 4 networks and that works without problem. Only embedded setups with a large number of interface statistics has this kind of problem. CU Jens ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
