Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
why is junk like this not being caught? -- Thank you, Johann v. Preußen On 2016.Apr.01 12:27, Otis Evans wrote: 923 Dunlap st On Apr 1, 2016 1:02 PM, mailto:otisevan...@gmail.com>> wrote: / Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard. __Wε__Nεεd__Yσμr__Shiρmeηt__Infσrmatiσηs__ Click_Here <http://mail.stunning.email/ct/t6k04w43v2/4CxPt1DbKd> / smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
i guess the reason for my original post was that i was so taken aback by the
fact that the body had so many red flags:
1.) '$1000': this list certainly is about money, but it would seem unlikely that
actual terms not coupled with something like [loss|cost] or the like would seem
improbable;
2.) 'giftcard': seems like a very unlikely discussion element here;
3.) 'shipment': ditto;
4.) 'informations' (sic): i realize this list -- being international in scope --
will not exhibit perfect English usage at all times (even from native English
speakers). however, poor English (even just spell-checked) combined with other
filters could push the score high enough;
5.) links: examples are always very constructive, but it is certainly not much
of an inconvenience to limit active anchors to major sandboxes or even one
operated by openssl; and
6.) obfuscation: the worst and most-telling is the fact the content clearly was
designed to bypass filters by couching the desired message within a highly
unusual number of non-prose, non-technical symbols. in this blatant case there
was a complete lack of prose and that will just never occur in this list.
this list is active, but a very low-volume one and more intensive body checks
that route questionable entries to some monitoring box would seem to be well
worth the small resource utilization required.
moreover, i do not notice anyone from google's security team(s) chiming in here
and it would seem that good old 'otisevans98' will skate without consequence for
the foray against this list which is entirely about security. perhaps added body
filtering and actual human intervention would serve the desired benefit of
having such intrusions actually result in an abuse complaint to the MTA
operator.<mailto:otisevan...@gmail.com>
--
Thank you,
Johann v. Preußen
On 2016.Apr.02 15:30, Ben Humpert wrote:
Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.
Looks like strong encryption is much easier to develop than a decent
spam filter.
The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.
2016-04-02 17:41 GMT+02:00 Jeffrey Walton :
On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich wrote:
why is junk like this not being caught?
Almost all of it is. Nothing is perfect. Thanks for your understanding and
patience.
I was looking at some of it landing in my Inbox. Its all from Gmail
users. The headers are Gmail headers submitted via the web. The DKIM
signatures are OK. There are no headers to indicate its been
forwarded. The {from|return|reply to} address does not appear to
forged. Here's an example header from another Gmail user who contacted
me: http://pastebin.com/hRAtRt7S.
I've also had a couple of people contact me asking me to stop spamming
them. I looked at two of those headers, and it clearly appears to be
coming from me though I did not send it (and no evidence in my
Outbox).
I'm thinking there's a vulnerability in the Gmail or Google servers we
have not heard about.
Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
right now our conversation is bi-directional since the listserv is off-line. i also looked at the headers and they do seem to originate within google itself ( bogon receipts). so, are you telling me that the mere fact that an email is addressed to the list will get it published without verifying that the sender is a subscriber? everything else i mention relate to the needless exposure of the subscriber's real name and email addr and the permitting of private anchors. obviously, i believe that these practices greatly increase security risks for the subscriber and will subject them to a potential flood of noxious junk. -- Thank you, Johann v. Preußen On 2016.Apr.04 13:46, Jeffrey Walton wrote: On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to recognized sandbox sites or -- much better -- to an openssl-operated one. Yeah, this particular message looks like classic spam (headers available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ). When the spam was getting through, I checked some of the headers and most were coming from Gmail users. See, for example, http://pastebin.com/hRAtRt7S. That particular message likely had its spam score lowered because of the DKIM signing. I was also contacted offlist for the spam I was sending. I saw the headers on two of the messages, and they clearly were from me and submitted through Google's web interface. They looked just like the headers in http://pastebin.com/hRAtRt7S. I did not send them, and they did not show up in my Outbox. Its the reason I'm guessing Google services had a vulnerability that was silently patched. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. moreover, as i pointed out in a pm to Steve, this is a real security issue for openssl's list in that such a breach (if it is one) opens the names and email contact info of a broad range of security-responsible people that will invariably include some in the upper regions of the perm chain. these people are the very people that are targeted by malicious attempts (and some startling successes) to breach much more than an organization's email system. yes, this person has seemingly stopped with postings, but i am hearing no assurance that they have even been eliminated from the subscription database. just being able to listen will garner a wealth of sensitive info obtainable re a most desirable crowd of people/victims. even the most simplistic listserv app has the ability to withhold subscriber email addr's and still provide a secure pm capability. now that it is apparent|perceived that the list is vulnerable, i believe the prudent route to go is to keep those addr's and subscriber real-world names out of the "limelight". i see no reason why a sanitized subscriber profile available from a link within the person's public handle would not be adequate for identification purposes and would actually become an enhancement to the listserv app's usefulness to subscribers. this would certainly shield the subscriber in a reliably meaningful way, serve to protect a subscriber's own email system, and enhance the security of openssl's own listserv ops. -- Thank you, Johann v. Preußen *original anchor description (100% of the message content):* Attn:__here__is__your___$lâ â â __FacebÏÏk__giftcard. __Wε__Nεεd__YÏμr__ShiÏmeηt__InfÏrmatiÏηs__ Click_Here On 2016.Apr.04 09:08, Jeffrey Walton wrote: And anyway, this seems to be a case where the genuine operator of an e-mail domain is failing to correctly authenticate submissions by their own users, which no amount of 3rd party automation (other than blacklisting the failing provider, in this case gmail) could stop. Yeah, I'm guessing there was a vulnerability in one of the other Google services, and that Google service was allowed to make web-based email submissions on behalf of the user. Classic injection and failure to validate sessions or parameters... I'm also guessing Google fixed it because it has stopped. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
if this list was for tex-mex cooking recipes or ES vacation rentals, i would agree that expectations for privacy might be very low and individual subscribers are responsible to be as circumspect as they personally feel they must be. however, this is a list of people in the fore-front of addressing global security issues and -- i would think -- subscribers would certainly want their personal info (U.S. Title XIII PII) to be as secure as the issues they are grappling with rather than having it published in the clear. the security issue re the subscriber email addr spreads beyond the actual person as well. suppose we have henrietta schmidt who is the email security officer for xyz corp who is addressed as h.schm...@xyz.com. since most large firms and almost all gov agencies have rigid mailbox addressing schemes, it is quite possible to extrapolate from this one email addr to a much wider range. like xyz's CIO joe blow who is most likely to be found at j.b...@xyz.com or some close variant. the payoffs for the successful breaching of systems of large firms and governments is huge and it does not require much imagination to deduce that the pantheon of perpetrators is large, their diligence is intense, and their numbers are not confined to a bunch of "script kiddies". quite plainly, i do not believe that openssl should be making their job easier. -- Thank you, Johann v. Preußen On 2016.Apr.04 14:49, Jeffrey Walton wrote: On Mon, Apr 4, 2016 at 5:32 PM, Johann v. Preußen wrote: right now our conversation is bi-directional since the listserv is off-line. i also looked at the headers and they do seem to originate within google itself ( bogon receipts). so, are you telling me that the mere fact that an email is addressed to the list will get it published without verifying that the sender is a subscriber? everything else i mention relate to the needless exposure of the subscriber's real name and email addr and the permitting of private anchors. obviously, i believe that these practices greatly increase security risks for the subscriber and will subject them to a potential flood of noxious junk. Yes, I agree Johann. The thing I would point out is there's usually no expectation of privacy with a mailing list, so users should not be surprised if their email address shows up in a traditional email header or an X-header somewhere. What piqued my interest was that sudden spurt of spam. Something was not right, but I could not finger it. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
'/No one (until about 2 hours ago) were discussing how the // //particular "From" address got past the "you must be // //subscribed to post" filter/' actually, i first posted on this issue c. 76 hours ago. '/maybe the spoofed From address happened to be a subscriber/' is it possible that openssl still does not know if the email addr is a real subscriber? '/maybe there is a bug in the list management software or configuration/' yes, i surely hope someone is looking into this possibility. further, not only was owenevans98 able to post an original message (the subject of this thread), but there was a subsequent posting in reply to another thread. thus, the conclusion that owenevans98 was not only able to post but was|is receiving the listserv mailings is self-evident. the fact that this two-way comm path came into existence means that the listserv database was corrupted and that the original posting was not some slip-up in permitting an un-authorized one-time posting. jakob, i appreciate your taking of the time to detail some of openssl's listserv practices and view-points. perhaps it is best to set forth the synopses of my views: 1. make certain ' owenevans98' and any other illegitimate posters are not receiving listserv mailings; 2. stop publishing the subscriber's protected PII in the clear; and 3. control postings of anchors. according to your comment quoted, supra, it seems that the step indicated in Item 1 has yet to be taken. Item 2 can be implemented by inaugurating a subscriber-managed profile and merely publishing a user handle linked thereto. thus, you can shift the onus to the subscriber to reveal whatever info they wish rather than arbitrarily exposing to the world a subscriber's personal name, email addr, and work-force association. in the case of Item 3, i understand all of the reasons for having links (not html anchors) in postings. it is a very minor inconvenience for someone who has a burning interest in viewing a link to copy the clear-text link into a browser versus clicking on an anchor description which could lead the subscriber far astray from what the description says. it also enhances the subscriber experience to visually see where the link is going instead of having the actual target obscured by a description that may be deceptive, merely misleading, or non-apparent (i.e., 'click here'). jakob, you also mention concern re MTA operators having some issues with changes you may make to the listserv ops. please note: none of the three (3) items, supra, i have suggested have any impact on other MTA operators as they are totally internal-control enhancement proc's. i cannot understand why openssl's filtering missed the fact that the posting that is subject of this thread predominated in symbols and control characters, contained no actual message text, and still went through. hopefully, someone is also looking into why this happened. -- Thank you, Johann v. Preußen On 2016.Apr.04 15:36, Jakob Bohm wrote: On 04/04/2016 22:28, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. No one (until about 2 hours ago) were discussing how the particular "From" address got past the "you must be subscribed to post" filter, maybe the spoofed From address happened to be a subscriber, maybe there is a bug in the list management software or configuration. There was discussion of which generic "hard-reject" filters should be applied and someone suggested prematurely applying a number of recently "trendy" such rules promoted by (ironically in this case) Google and others. I was the one who used the word "fad" to refer to such recently promoted "hard-reject" rules and pointed out that many smaller organizations will be unable to cause legitimate mail/postings to comply with such rules anytime soon, simply because it takes time to roll out new protocols to all the worlds legitimate e-mail sending servers. As for the suggestion to forbid links to servers other than OpenSSL.org servers, this will be fatally flawed as it will block discussions of such common OpenSSL related topics as: -
Re: [openssl-users] Spam
i have posted my thoughts on unacceptable list access previously and it sank to the level of a frequent poster denigrating other users since they took exception to his self-professed role of protecting list admins in order "to avoid the list admins following bad advice from people" who might have differing opinions from his own. hopefully, that will not happen here. in re the recent Brazilian Portuguese (note the 'R$' symbol for ISO BRL rather than Euro) spam: what was wrong with that posting that should have been caught: * the IP of origin 52.165.41.104 is an MS delegation without rDNS and -- obviously -- no SPF/TXT RR and * the claimed domain 'cloudapp.net' does not exist in whois (not a 100% indication of non-existence) or DNS (a 100% 'reject' indicator). i have not used mailman for some time, but these two (2) simple errors would have been blocked by normal 'postscreen' checks and should never have gotten as far as mailman in any case. checking the EHLO format is in the µs range and a DNS check should take < 100ms. thus, these types of errors could be quickly and easily eliminated with a '521' without any RBL or list-serve processing at all. the wider problem case is how non-subscribers are given two-way access to the list that exposes so much subscriber info (name, professional affiliation, email addr, ...) to whomever. i cannot fathom why the list does not make use of aliases so that each subscriber can control what they want to make public via their alias profile. Thank you, Johann v. Preußen On 2016.Apr.19 16:40, Oliver Niebuhr wrote: Am 20.04.2016 um 01:05 schrieb Scott Neugroschl: Can the spam filters on the listserv be updated? Got two today in Spanish and Portuguese for monetary scams. Anyone else getting these? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | Morning. Yeah I got those too. I think like everyone else who subscribed to that List and has no specific Filters set up :) I am an Admin for some Mailman Lists myself - there is no way to block everything with 100 Percent efficency - except if you disallow non-members to send Message to $List. It always depends on the local Mailing List Policy. Greetings Oliver smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Spam and posting controls
Mr. Salz:
despite mr dukhovni's assertion that spam is not a problem and that people that
are concerned about it are a problem, i contend that the seeming laxness of list
controls is the core problem and spam is just an indicating vector. to wit:
'/List membership is not public/' which may be true until someone busts into the
list and become privy to all of the personal data of posters. such intrusions
will continue until someone addresses these breeches for what they are: security
lapses.
'/Only members can post to the list/' is obviously not true when the same party
which has prompted this thread posted to the list twice in a short time-frame
(and this has happened before) from IP's without rDNS, from a bogus
email/domain, and via an unknown MTA. these glitches can be easily caught in
postfix when it is set up with a pretty minimalist approach to security.
my comment re aliases goes to the concern that a list that is all about
HTTP/SMTP security and identity surety is freely dispersing so much personally
identifiable subscriber information (PII) that is of such a high order of
sensitivity that it is protected under U.S. Title XIII with parallel Canadian
codes, even more stringent EU reg's such as 'Directive 95/46/EC' and the
newly-enacted 'General Data Protection Regulation' ('GDPR'), and some EU Member
regulations with stronger protections than those embodied in 95/46/EC (such as
Nederland 'Wet bescherming persoonsgegevens' and UK 'Data Protection Act'
amongst others).
in reality, openssl has no choice but to eventually comply with GDPR which would
prohibit what is currently being done. so, it would be best to just get on with
adapting all openssl systems to meet higher ethical and regulatory standards
before they are embarrassingly imposed or, much worse, be shown to have operated
in such a way that system breeches at subscriber firms could be traced back to
openssl.
Thank you,
Johann v. Preußen
On 2016.Apr.19 19:03, Salz, Rich wrote:
the wider problem case is how non-subscribers are given two-way access to the
list that exposes so much subscriber info (name, professional affiliation,
email addr, ...) to whomever. i cannot fathom why the list does not make use of
aliases so that each subscriber can control what they want to make public via
their alias profile.
List membership is not public . Only members can post to the list. Not sure
what else you think we are doing wrong.
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] good riddance to PayPal
Marquess: your treasury re-alignment might be simplified a bit if you look to an on-line-type bank such as Ally Bank. while they are not on the SWIFT network, they use Chase -- like many intermediate-sized banks -- and benefit from having the "wholesale" rate between themselves. this enables Ally to give you free in-coming SWIFT and free in-coming/out-going domestic US wire transfers. out-going SWIFT is only $10. out-going ACH is also free, but they do not provide an API for in-coming ACH so that would require a third-party processor to make that happen on a web-site or automated/directed basis. fortunately, such a processor is dwolla which has several API's in different codings and offers free in-/out-processing with clearance that usually happens no later than the second day after initiation. since ACH has a built-in deferred relay of the next business day after preliminary settlement, this speed is about as good as it gets. since using a dwolla API also lifts the PCI responsibility from openssl, you would receive all your US-based donations at no-cost, quickly, and without much regulatory worry. in fact, dwolla allows you to tie in more than a single bank account so that you can choose where to "sweep" accumulated funds according to momentary needs. dwolla also has a "white-label" API that totally obscures their role in the process. they do charge for this, but the fact that your org is so prominent in the net security field would no doubt favorably prompt them to throw this service in for free just so they could tout openssl as a client. i am also certain they would be more than happy to provide free app customization tailored to openssl's specific needs. if multi-currency is a concern, Citibank offers primary bank account and card services in NYC and London permitting a wide range of denominations (USD, GBP, EURO, et cetera) from which to base such transactions. also, NYC/London do not have to be the same denomination and enjoy free inter-account transfers. from my experience, Citi also runs currency translations with much narrower spreads than other large banks and third-party gateways. as might be expected for this mega bank, their basket of services over-flows and they are lower-cost than other major banks when the services are not free! you have mentioned server-siting and non-US personnel as control agents as somewhat problematic. i might suggest a simple and very low-cost means of obviating these concerns. if openssl were to incorporate as a type IRS Reg 501(c)(3) it would satisfy US Treasury Reg's and make life a lot easier. in California (one of the lowest-cost states) that would cost you $30 to incorporate, $20 to file the SI-100 info form, and $25 to register with the FTB. you would also have to register with the CA Attorney General, but that is free. thus, for a start-up fee of $75 and a bi-annual SI-100 fee of $20 you would be in business and could open any US-based bank account your heart desires and make possible using a bank such as Citibank with accounts both in NYC and London to meet your international banking needs. since the corporation is a domestic one, bank signature cards can be initiated for anyone no matter where they may be citizens/domiciled. server siting is no problem for ACH since the natural limitation of the sending/receiving accounts being US-based means where the servers might be is totally unimportant. at this time, i am not a client or agent of any of the firms herein mentioned and i do not look to receiving any remuneration resulting from any of my suggestions. -- Thank you, Johann v. Preußen On 2016.May.06 08:06, Steve Marquess wrote: On 05/06/2016 10:29 AM, Jakob Bohm wrote: On 06/05/2016 15:26, Steve Marquess wrote: On 05/06/2016 09:14 AM, Jakob Bohm wrote: On 06/05/2016 13:45, Salz, Rich wrote: Consider having the non-U.S. person do the account setup too. Banks are as scared of US jurisdiction as crypto engineers. Yeah, we've done that. Even to the point where one of the team was going to get on a plane to fly to the Isle of Mann. It's amazingly painful and difficult and so far not productive. If folks want to give OpenSSL money, mail a check or cash. I was thinking of the more simple solution of setting up the account in the same non-US bank where the team member does his other business. Lots of this tends to get easier when the person is an existing customer and the bank is nearby. Each non-US team member presumably has at least one existing bank relationship and presumably knowledge and/or easy access to information on how to set up an independent legal entity in his/her own country. Personal bank accounts, yes. But, we don't want to entangle OpenSSL funds with any team members personal finances. Those funds need to be held by an independent OpenSSL legal entity (of which there are already several). Also keep in mind
Re: [openssl-users] good riddance to PayPal
i am somewhat surprised your attorneys have not mentioned the most simplistic solution. if the sole purpose for incorporating is to implement banking, there is actually no need to register for an IRS letter. if you satisfy the state regulations and obtain an EIN you are fine. the IRS letter does give safe harbor to donors that the amounts given are federally deductible. of course, to your major donors who provide moneys under grants and/or contracts there is no practical tax-wise difference between "gift" and "business expense". if you would like the specifics re CA, here are the applicable links granting freedom from CA taxation and franchise fees and establishing subsequent Federal tax-filing status: *the state equivalent of IRC 501(c)(3):* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#d23701 *your qualifications under "Scientific" endeavors:* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#Scientific *your qualifications under "Educational" endeavors:* https://www.ftb.ca.gov/businesses/Exempt_organizations/Types_of_Exemptions.shtml#Educational_org all of that said, there are plenty of examples of open-source org's that are already IRS-recognized under IRC 501(c)(3) such as Software in the Public Interest, Apache, Eclipse Foundation, Open Source Initiative, Linux Foundation, Software Freedom Conservancy, and many more. i have noticed, though, what your attorneys have related to you in that the IRS has recently seemed to turn a blind eye to the "public benefit" clause when it comes to open-source software. this is a trend of just a couple of years and turns from the path they had followed for decades in granting acceptance. if someone took the time to copy/edit one of these org's by-laws and submitted to the IRS they would be hard-pressed to deny based on the facts and would have to reveal a decidedly philosophical reason which would be wide open to appeal. naturally, i have no idea if any of this extra effort would yield anything meaningful to openssl. certainly, qualifying for non-profit status in CA actually grants you what you really need and does not require any extra efforts. -- Thank you, Johann v. Preußen On 2016.May.11 13:00, Steve Marquess wrote: On 05/11/2016 02:46 PM, Johann v. Preußen wrote: Marquess: your treasury re-alignment might be simplified a bit if you look to an on-line-type bank such as Ally Bank. ... It's a U.S. bank. We already have multiple U.S. bank accounts. you have mentioned server-siting and non-US personnel as control agents as somewhat problematic. i might suggest a simple and very low-cost means of obviating these concerns. if openssl were to incorporate as a type IRS Reg 501(c)(3) it would satisfy US Treasury Reg's and make life a lot easier. ... Yes, it would indeed, and if I had a nickel for each time I've heard this suggestion I'd had enough beer I'd need never face sobriety again. We have pursued 501(c) with several attorneys, all of which have advised us that our chances of successfully obtaining 501(c)(3) or 501(c)(6) status are nil. Apparently the IRS does not look kindly on our type of open source project. That is one of the reasons we need to relocate outside of U.S. jurisdiction. -Steve M. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] good riddance to PayPal
i am sorry if i have wasted your time on non-profit formation and taxation issues when i put my CPA hat on. i originally meant to point out some banking alternatives and how to make certain you could qualify and control such with the non-profit formation as a means and California as a low-cost conduit. if you are already set up in DE, you can take advantage of the free in-/out-ACH, web API's, and mass-pay at dwolla (tied to any existing bank account(s) you have now or in the future) and internationally-scoped banking through Citi or some such. i suggested Ally Bank only because they offer free services: in-bound SWIFT, in-/out-bound domestic US wire transfers, and checking. also, their $10 fee for out-bound SWIFT is the lowest i know of for non-analysis (low running-balance) checking acct's. -- Thank you, Johann v. Preußen On 2016.May.11 14:15, Steve Marquess wrote: On 05/11/2016 04:56 PM, Johann v. Preußen wrote: i am somewhat surprised your attorneys have not mentioned the most simplistic solution. if the sole purpose for incorporating is to implement banking, there is actually no need to register for an IRS letter. if you satisfy the state regulations and obtain an EIN you are fine. the IRS letter does give safe harbor to donors that the amounts given are federally deductible. of course, to your major donors who provide moneys under grants and/or contracts there is no practical tax-wise difference between "gift" and "business expense". ... State taxation isn't a problem; OpenSSL Software Foundation is incorporated in Delaware which has no tax. U.S. tax deductibility is largely irrelevant to our donors, most of which are outside the U.S. all of that said, there are plenty of examples of open-source org's that are already IRS-recognized under IRC 501(c)(3) such as Software in the Public Interest, Apache, Eclipse Foundation, Open Source Initiative, Linux Foundation, Software Freedom Conservancy, and many more. i have noticed, though, what your attorneys have related to you in that the IRS has recently seemed to turn a blind eye to the "public benefit" clause when it comes to open-source software. this is a trend of just a couple Bingo. of years and turns from the path they had followed for decades in granting acceptance. if someone took the time to copy/edit one of these org's by-laws and submitted to the IRS they would be hard-pressed to deny based on the facts and would have to reveal a decidedly philosophical reason which would be wide open to appeal. naturally, i have no idea if any of this extra effort would yield anything meaningful to openssl. ... Be my guest and go for it, but I do have a good idea if it would yield anything meaningful because I've been working this issue in detail for a couple of years now. Our attorneys (we've checked with several, and with ones experienced with 501(c)) don't see a viable path worth the substantial investment it would cost us. -Steve M. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] good riddance to PayPal
dwolla: yes, i keyed off your comment re getting your last $'s from paypal and thought they would work for your donations: US, at least. and then somebody like Citi (a globally top-three credit card issuer) could handle accounts in GBP and EURO in London with a relatively small translation cost for Nordics and other Euro-peripherals into either London pool. the rest of the globe would probably be cheaper to come into NYC in USD. if you spend in GBP/EURO you would do so from those accounts with no translation costs. of course, you can concentrate the funds where ever you might need them as the need arises. OK, that type of a system takes a bit of effort to get going; but then it is quite low-cost and easy to actually run. *however, if you are looking for some sort of a paypal "drop-in" one that i am familiar with is propay.* * they have some concessionary pricing for non-profits (you can just provide proof of your "exempt" DE status). * i am not sure what their currency translation hits might be since i only know about a US set-up. * they do non-swipe cards at 2.2%+$0.25 (no surprise: except for Am Ex which you do not have to accept). * they do ACH, but have a percentage applied (less than 1%) instead of a much lower per-transaction fee. * transaction fees might get even lower if your volume is attractive to them. * no other fees at all. * they also have a bunch of API's you can choose from. * one added feature that may interest you is they have a means whereby you can post an anchor in social media sites to capture donations back to their system. * they also do the maximum PCI isolation so that you do not have to worry re that. * they have an "auto-sweep" function every couple of days for depositing into your current bank account which can be altered to your own preferred schedule. * you can establish multiple accounts if you have FX disbursement needs such as GBP and/or Euro and then there would be no attendant translation costs. of course, this is also a place where you can leverage your org's rep to possibly get even better terms. you could start at their non-profit page and look on from there and see if there are more features i do not know about: http://www.propay.com/affiliate/charity/?refid=charity -- Thank you, Johann v. Preußen On 2016.May.12 09:42, Steve Marquess wrote: On 05/12/2016 09:39 AM, Steve Marquess wrote: On 05/11/2016 06:04 PM, Johann v. Preußen wrote: i am sorry if i have wasted your time on non-profit formation and taxation issues when i put my CPA hat on. i originally meant to point out some banking alternatives and how to make certain you could qualify and control such with the non-profit formation as a means and California as a low-cost conduit. Not a waste; despite working these issues for some time I remain ever hopeful that there is indeed a simple solution that has to date escaped us. Or even a complex one for that matter. ... Dwolla I'll call when they open for business. I suspect we'll run into the U.S. web server location issue, but I'll check. -Steve M. That was a short call; Dwolla only handles payments from within the U.S., and the great bulk of our donations come from outside the U.S. -Steve M. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] output from: dh, dhparam, pkeyparam
since 0.9.6 or before, five (5) example PEM files have been included in the 'crypto/dh' directory of the pkg. these represent bit-sizes from 192 to 4096. certainly 192-/512-/1024-bits are hardly applicable today and that leaves the 2048-/4096-bit files subject to current interest. at that, i am not certain what utility these files have since they are not installed. quite a while ago i noticed the 'dh2048.pem' file when deciding to create custom DH param files. this file has two (2) sets of param's. since these files may have originated in some early dev phase, i can see where someone mistakenly appended the second param set instead of supplanting the first. this brings to the fore my actual question. 'pkeyparam' shares the same DH feature of its predecessors in that it ignores all content not included between the /*first*/ PEM header and its accompanying footer. that means virtually anything can surround the first param and will be ignored by whatever call(s) this wrapper is making. i can understand that this may have been coded this way to allow for the history DH param's have with openssl whereby only the PKCS#3 variant has been supported and that format might co-exist in some files. however, it would seem prudent that everything outside the first DH param should not be completely ignored. to wit: consider the very real possibility that a programmatic error is made -- such as the dh2048.pem example, supra -- and an append is performed and the new param is completely ignored and nobody is the wiser. moreover, since it is remarkably unlikely that anyone is hand coding these files or that comments would be inserted; it seems to make a lot of sense for a utilizing module to _*warn*_ of excess content that is not PKCS and _*fail*_ if more than a single PEM-type param is included. -- Thank you, Johann v. Preußen smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DH custom param generation/usage
*use case:* '/openssl genpkey -genparam -algorithm DH/' the '/genpkey/' doc's '*DH PARAMETER GENERATION OPTIONS'* section: * first, before i forget -- again -- openssl's doc's should indicate that the using the '-pkeyopt' option requires that the 'dh_paramgen_generator' setting must precede the 'dh_paramgen_prime_len' if it is present or the setting is ignored and results in a default setting of '2' (which could stand to be mentioned as happening if the "generator" option is missing). Moreover, it also might be useful to mention the default for "len" is '1024' if the setting is missing. * this section could use a note that the '-text' option appends the PKCS#3-formatted data to the PEM-formatted data in the output. i am not knowledgeable enough re PKCS-bound app's to be aware of where this additional data might be required or if it is just a decade-old hold-over of no current value. * it also could be noted that '-outform' is ignored and the output default of 'PEM' rules (while possibly being followed by the PKCS#3 data, as indicated). not everyone is aware that there is no such thing as a DER-formatted file for DH param's. ***DH param file controls:* now, the '-out' option creates a parameter file or the output goes to stdout if missing. it is inconceivable that this option is not used in any automation mode and barely likely that it would be missing in a CLI environment because that would then require copying the stdout for insertion into some file. that leaves the possibility of errors in manual edits and the CLI/script mode wherein the stdout is '>' or '>>' to a file. obviously, '>>' or a language equivalent is an appending blooper worth preventing because the new param set will be ignored if a prior DH param set already exists in the file. using the '-out' option is a not-so-strange 'special case' that openssl itself has created. while not stated in the doc's, using this option will silently over-write any pre-existent file and, thus, create a single-use file that can only be used for the provision of custom DH param's: no other param's, key, certs, or whatever that may have been present in the original file remain after running in this mode. because this openssl-created result is a user/developer expectation (i.e., an openssl-established standard), it is reasonable to expect that openssl's down-stream modules will enforce this standard and that is not happening. later on, when the file is parsed, a search is made for the _*first*_ DH param set and everything else before and after (no matter whether it is other valid PEM data, a subsequent valid DH set, or just junk alpha-num lines) is completely ignored. it is proposed that the openssl file-creation "standard" be enforced in all modules. such enforcement would serve to guard against human error that can creep into the file via manual edits and/or faulty scripting -- such as the ages-old openssl snafu in openssl's own packages in the 'crypto/dh/dh2048.pem' file which contains two (2) valid DH param sets and has been present in every package version since at least 0.9.6. while we are mentioning this example, it would prevent people from getting the wrong idea if the like-situated files representing bit-lengths of 192, 512, and 1024 were removed since virtually all current recommendations suggest starting at 2048 bits or more in 1024-bit steps. the reason i have presented the need for further controls is because a real-world case was brought to me by one of my former students who was testing all the servers on his new job. he found that c. a third of the servers were running under very-old and far-less-secure param's than they thought were in use everywhere. we tracked it down to the same type of error that openssl itself made, supra. if nobody thinks it is a good idea for openssl to prevent mistakes such as this happening and/or make clarifying additions to the doc's, there is no need to make further reply to this thread. -- Johann smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Disable a cipher suite in openssl.cnf?
Mr. Neugroschl's quest for a simple solution does bring up -- in my user-oriented opinion -- a very good follow-on question: "/Why cannot a config file be utilized by openssl to simply give access based on an allow/deny mechanism that would give users system-wide control in a single place?"./ the benefits of such an implementation are clearly manifold from the admin side. as a vulnerability arises, a weakness is revealed, a specific requirement is desired; a user can close out or enable any use of that avenue in a heartbeat ... permanently (/i.e./, persisting through updates), temporarily until a patch can be applied or a new release installed, or when requirements change. this would also greatly ease using openssl (think "views" in bind: although openssl's approach does not have to be as "unified" as bind's single config file) so that openssl could be tailored to different access methods such as intranet, tunnels, VPN's, et cetera. from the dev side i would think this approach would also have benefits worth exploring. FIPS immediately comes to mind. its hard-coded approach and protracted separate compliance certification could be distilled down to checking a hash (or some such security check) on a special over-riding config file when FIPS-enabled is encountered. this would also speed access to standards creators to modify the config file on the fly instead of interludes that can consume years despite industry-wide documentation/recognition that something must be done. then, openssl merely needs to be updated with the new hash or whatever. in fact, openssl could really foster transparency within the whole auth/encrypt process by creating its own allow/deny master listing that a user could modify at will without the need to be conversant at any type of coding. providing a more inclusive and user-friendly process also could, perhaps, forestall app's from "going-it-alone" or using other vendors such as experienced with openssh and lua. i DO realize that such a "modular" approach instead of "all-or-nothing" is not a simple matter from the dev side, but permitting the user an ability to go /a la carte/ according to specific needs seems highly attractive. it could also enable user migration scheduling (think sha1 to sha2, for instance) to keep pace with internal systems integration, configuration, and updating. there are also matters like the 25519 family which "enjoyed" a decade in virtual limbo until recently emerging as the "cats-meow" of speed and security (1. non-NSA/-NIST; 2. https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03; and 3. https://ed25519.cr.yp.to). perhaps if more people saw that it was available via openssl (assuming openssl made it so) and did earlier experimenting with it the hiatus could have been foreshortened and everyone would have benefited. i know openssl cannot include /everything/, but this particular process is Daniel J. Bernstein <https://en.wikipedia.org/wiki/Daniel_J._Bernstein> after all and its "pluses" well-documented and long-known. BUDGETING: i cannot image the large-donor base NOT being enthusiastic re this approach. i also certainly see where openssl could attract new and more one-time/smaller donors to such a "crowd funding" project that exhibits a very real and visible translation of time to money. Thank you, Johann v. Preußen On 2016.Sep.24 08:04, Richard Moore wrote: On 23 September 2016 at 17:13, Scott Neugroschl <mailto:scot...@xypro.com>> wrote: Hi, I’m afraid the man page on the conf file is not particularly clear. I’m looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to disable the DES and 3DES suites in the conf file. Can someone give me a hand? You can't disable them in the openssl config file, you should do it in the cipher suite configuration of the affected application. Cheers Rich. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] free certs: bad idea wosign/startcom/startssl/startencrypt; good alt's
this is a re-worked report i prepared that some might find useful.* CAUTION:* there are several seriously troubling events surrounding WoSign *^1 * (AKA startcom, AKA startssl, and AKA startencrypt) and any of their affiliated/subsidiary businesses: 1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start Commercial LTD' (an Israeli company); hereinafter '*startcom*'] last year. although obfuscation by the parties makes determining the actual control-transfer date impossible, the change-over may have begun in 2014. both companies long completely and publicly denied any change of control even as late as 2016.JUL despite it being a matter of public record that: 1. the entire stock issuance from 15 startcom shareholders including founder Revital (AKA 'Eddy') Nigg's majority ownership was transferred in 2015.NOV; 2. beneficiary of the stock deal was 'StartCom CA Limited' a UK company (09744347); 3. the UK company is wholly-owned by 'StartCom CA Limited' (yes, exactly the same name again) a Hong Kong company (CRN 2271553) with a sole director being Wang *^1 *; and 4. the Hong Kong entity is then owned by wosign. 2. in fact, to-date neither firm has actually admitted what has happened re transfer of control, domiciling of operations, and changes in management personnel. this reticence is despite some aspects of the transactions becoming common knowledge in the security community; 3. wosign attempted (rather poorly it turned out) to make it appear that wosign was actually a subsidiary of startcom and startcom's remnant personnel and former shareholders abetted this *^2 *; 4. startcom is an Israeli company and -- as one would expect -- was subjected to strict auditing and monitoring by the Israeli government to the benefit of all the recipients of their certs ... until the ownership change that is; 5. wosign is a mainland Chinese (PRC) company which completely controls startcom operations in IL, UK, CN, and US; 6. earlier this year and last wosign -- amongst other deceptive actions -- tried to circumvent certain mandated changes to certificate authority (CA) practice by back-/forward-dating certs and issuing certs with duplicate serial numbers while their CA compliance auditors Ernst and Young (Hong Kong) were complicit in covering up these and other forbidden practices *^3 *; 7. in response to all these discoveries, mozilla's firefox version 51 and all look-alikes using their gecko engine have stopped accepting any new (issued on/after 2016.OCT.21) certs that trace back to wosign/startcom/startssl/startencrypt root/intermediate/cross-signed certs and have banned Hong Kong Ernst and Young CPA's from certifying any CA audits; 8. unless wosign and its subsidiaries come up with new root certificates and provide acceptable audit results for their CP/CPS/operations by 2017.MAR, all of wosign-affiliated root/intermediate/cross-signed certs will be removed from mozilla's certificate store; and 9. mozilla has stated that if it detects any further fraud such as exhibited in Item 6, /supra/, all security updates to all its software versions will immediately remove wosign-based "trusted" certs from the mozilla root certificate store on the device being updated which will cause the universe of wosign-issued certs to become un-trusted in the mozilla browser family no matter when they were issued. *OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, qihoo, et alii but *RUN! *i can think of nothing worse than trusting a PRC firm with my sites' security. OK, if that hyperbole is not enough, try my personal idea of what should be network no-go and it pretty much lies in the swath West of Japan and East of Germany. *THE ALTERNATIVE: *the immediate free cert replacement avenue is through letsencrypt.org that uses the cert issuance/renewal protocol ACME. although letsencrypt will not be found in most (if any) browser "trusted" root certificate stores, they use cross-signed intermediate CA certs from a root that is. there are an ever-growing number of open-source scripts (bash, perl, python, go, ...) available to automate the process which one can even customize for your particular needs. there are letsencrypt plug-ins/modules for apache to make your set-up less painful. you can use the nginx process with a lua module to /really /fully automate _/everything!/_ if you want to go /de luxe/ there is the openresty bundle that combines nginx with lua and adds a host of other nginx "add-in" enhancements automatically and some more rarely required that one specifies. if you have looked at openresty or other bundles before and been turned off because there was nothing for your favorite distro/pkg-mgr and the thoughts of maintaining a 2kb configure line immediately switched your focus over to happy hour, look again! with openresty repo's are
