[openssl-users] Fwd: CONGRATULATION____REF#87670

[PGNet Dev]

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