Is there nowhere else this interminable thread can be taken? Some of us actually subscribe to this list to actually follow *openssl* use & issues. Take it up with the list admins directly? On 04/04/2016 05:39 PM, Jakob Bohm wrote: > On 05/04/2016 01:47, Johann v. Preu?en wrote: >> '/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. >> > > Not in this thread on openssl-users as far as I can tell. > > >> '/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? >> > > I have no way of knowing since I am not one of the list admins. > >> '/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. > > Which other thread was that? > >> >> 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: > > I am not a list admin or other official team member, I am just an > active list member who wants to avoid the list admins following bad > advice from people like you and Ben Humpert. > >> >> 1. make certain ' owenevans98' and any other illegitimate posters are >> not receiving listserv mailings; > > Question is if owenevans97 is an illegitimate poster or a legitimate > poster whose e-mail address was spoofed. > > Anyway, the OpenSSL mailings are all being indexed on the world wide > web by multiple organizations, where anyone can read them. > >> 2. stop publishing the subscriber's protected PII in the clear; and > > Again, I see no sign this is happening other than the age-old inclusion > of original from and reply addresses in postings (which is limited to > those who post, and doesn't affect those who only subscribe). > >> 3. control postings of anchors. >> > > I disagree. A number of e-mail clients (MUAs) automatically turn > textual URLs into anchors and make it very difficult (if not > impossible) for the posting user to avoid this. And people > professional enough to understand most of the stuff on OpenSSL mailing > list also know not to click on links in strange e-mails and forum posts. > > >> according to your comment quoted, supra, it seems that the step >> indicated in Item 1 has yet to be taken. > > I wouldn't know. > >> >> 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. > > Did you read and understand any of that which I wrote, or > are you just trolling? > >> >> 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 am an MTA operator, I am not a listserv op. I was posting concerns I > have as an MTA operator and list member with stupid changes suggested > by you and Ben Humpert. > >> >> 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. >> > > Did you read the brief but very clear message posted on 2016-04-02 > 15:24 UTC by Rich Salz (who is an OpenSSL team member and may have > access to the listserv configuration details not published to avoid > helping spammers)? > > > P.S. > > Please don't CC list members on replies to the list, it causes > duplicate copies to reach them (since list membership is required to > post to the list anyway). > >> >> 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: >>> >>> - URLs of published security research (such as the home >>> pages of new vulnerability descriptions). >>> >>> - URLs of sites that publish OpenSSL related software, such >>> as OpenSSH, stunnel, the Shining Light Windows binaries of >>> OpenSSL etc. >>> >>> - URLs that are showing interoperability problems with >>> OpenSSL. >>> >>> - URLs of independently published OpenSSL patches (that >>> have not yet been accepted into the OpenSSL repositories). >>> >>> - URLs necessitated by the byzantine legal rules regarding >>> which web servers are allowed to publish cryptographic >>> software written by which people for use by which other >>> people. >>> >>> These categories of non-openssl.org URLs occur frequently >>> in legitimate posts to this list and cannot be replaced by >>> some private openssl.org hosted equivalent of pastebin.com >>> etc. >>> >>> >>>> 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. >>> You are now going way outside anything discussed previously, >>> please enlighten the list as to what you are possibly >>> talking about here. >>> >>> So far the only known breach is an apparent breach of >>> *Google owned* e-mail servers, allowing perfect spoofing >>> of gmail.com addresses by causing the fake mail to be >>> sent by *exactly* the same servers with *exactly* the >>> same headers as legitimate mails by the legitimate user of >>> the spoofed e-mail address. >>> >>> This does not expose any of the names of any e-mail >>> addresses stored by the OpenSSL organization, unless >>> that data can be extracted by e-mailing a command to >>> listserv from a spoofed administrator e-mail address and >>> any of those administrator e-mail addresses are actually >>> hosted by Google. >>> >>>> >>>> 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. >>>> >>> Posts by others indicate that the *spoofing* activity >>> seemed to have stopped for multiple gmail addresses, >>> including the e-mail address of one person posting such >>> an observation, indicating a likelihood that Google fixed >>> the underlying security issue. >>> >>> >>> >>>> 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. >>> The issue that the FROM addresses of OpenSSL e-mail list posters >>> (not other subscribers) can be seen by anyone receiving or >>> otherwise finding their postings is age-old and completely >>> unrelated to any issue related to this discussion (the spammer >>> in this case obviously did not know that this was a mailing >>> list, given the incorrect textual name used with the list >>> SMTP address). >>> >>> Even if OpenSSL were to switch to a surveillance vulnerable >>> design where PMs between users would have to go through the >>> OpenSSL servers, the list administrators will probably remain >>> reachable using well known mandatory e-mail addresses such as >>> "Postmaster". A similar issue would apply to most of the other >>> high value subscribers. >>> >>> Any such people would already be required (in order to perform >>> their function safely at all) to employ security measures to >>> isolate their publicly known e-mail addresses from any e-mail >>> addresses that are not intended to be publicly known. As an >>> example, all my (non-blocked) postings on this list use a >>> dedicated mail address and mail box which allows me to dismiss >>> e-mails on other subjects to this address as Spam while not >>> exposing other e-mail addresses used for more trusted uses, and >>> I obviously employ similar measures for any well known role >>> accounts I handle myself. >>> >>> >>> >>>> *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. >>> > > > > Enjoy > > Jakob
