[openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v. Preußen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/0de1ecea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/0de1ecea/attachment.bin>