<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
'<tt><i>No one (until about 2 hours ago) were discussing how the </i><i><br>
</i><i> particular "From" address got past the "you must be </i><i><br>
</i><i> subscribed to post" filter</i>'<br>
</tt>actually, i first posted on this issue c. 76 hours ago.<br>
<br>
'<tt><i>maybe the spoofed From address happened to be a subscriber</i>'<br>
</tt>is it possible that openssl still does not know if the email
addr is a real subscriber?<tt><br>
<br>
'</tt><tt><i>maybe there is a bug in the list management software
or configuration</i>'<br>
</tt>yes, i surely hope someone is looking into this possibility.<br>
<br>
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.<br>
<br>
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:<br>
<ol>
<li>make certain ' owenevans98' and any other illegitimate posters
are not receiving listserv mailings;</li>
<li>stop publishing the subscriber's protected PII in the clear;
and</li>
<li>control postings of anchors.</li>
</ol>
according to your comment quoted, supra, it seems that the step
indicated in Item 1 has yet to be taken.<br>
<br>
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.<br>
<br>
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').<br>
<br>
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.<br>
<br>
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.<br>
<tt><br>
</tt>
<pre class="moz-signature" cols="80">--
Thank you,
Johann v. Preußen
</pre>
<div class="moz-cite-prefix">On 2016.Apr.04 15:36, Jakob Bohm wrote:<br>
</div>
<blockquote cite="mid:5702EC69.3080303@wisemo.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 04/04/2016 22:28, Johann v.
Preußen wrote:<br>
</div>
<blockquote class=" cite"
id="mid_5702CE88_2000407_forthepolls_org"
cite="mid:5702CE88.2000407@forthepolls.org" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
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 <u>recognized</u> sandbox sites or --
much better -- to an openssl-operated one.<br>
<br>
</blockquote>
<tt>No one (until about 2 hours ago) were discussing how the <br>
particular "From" address got past the "you must be <br>
subscribed to post" filter, maybe the spoofed From address <br>
happened to be a subscriber, maybe there is a bug in the <br>
list management software or configuration.</tt><tt><br>
</tt><tt><br>
</tt><tt>There was discussion of which generic "hard-reject"
filters <br>
should be applied and someone suggested prematurely <br>
applying a number of recently "trendy" such rules promoted <br>
by (ironically in this case) Google and others. I was the <br>
one who used the word "fad" to refer to such recently <br>
promoted "hard-reject" rules and pointed out that many <br>
smaller organizations will be unable to cause legitimate <br>
mail/postings to comply with such rules anytime soon, <br>
simply because it takes time to roll out new protocols to <br>
all the worlds legitimate e-mail sending servers.</tt><tt><br>
</tt><tt><br>
</tt><tt>As for the suggestion to forbid links to servers other
than <br>
OpenSSL.org servers, this will be fatally flawed as it will <br>
block discussions of such common OpenSSL related topics as:</tt><tt><br>
</tt><tt><br>
</tt><tt>- URLs of published security research (such as the home <br>
pages of new vulnerability descriptions).</tt><tt><br>
</tt><tt><br>
- URLs of sites that publish OpenSSL related software, such <br>
as OpenSSH, stunnel, the Shining Light Windows binaries of <br>
OpenSSL etc.</tt><tt><br>
</tt><tt><br>
- URLs that are showing interoperability problems with <br>
OpenSSL.<br>
<br>
</tt><tt>- URLs of independently published OpenSSL patches (that <br>
have not yet been accepted into the OpenSSL repositories).</tt><tt><br>
</tt><tt><br>
- URLs necessitated by the byzantine legal rules regarding <br>
which web servers are allowed to publish cryptographic <br>
software written by which people for use by which other <br>
people.</tt><tt><br>
</tt><tt><br>
</tt><tt>These categories of non-openssl.org URLs occur frequently
<br>
in legitimate posts to this list and cannot be replaced by <br>
some private openssl.org hosted equivalent of pastebin.com <br>
etc.</tt><tt><br>
</tt><br>
<br>
<blockquote class=" cite"
id="mid_5702CE88_2000407_forthepolls_org"
cite="mid:5702CE88.2000407@forthepolls.org" type="cite">
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.<br>
</blockquote>
<tt>You are now going way outside anything discussed previously, <br>
please enlighten the list as to what you are possibly <br>
talking about here.<br>
<br>
So far the only known breach is an apparent breach of <br>
*Google owned* e-mail servers, allowing perfect spoofing <br>
of gmail.com addresses by causing the fake mail to be <br>
sent by *exactly* the same servers with *exactly* the <br>
same headers as legitimate mails by the legitimate user of <br>
the spoofed e-mail address.<br>
<br>
This does not expose any of the names of any e-mail <br>
addresses stored by the OpenSSL organization, unless <br>
that data can be extracted by e-mailing a command to <br>
listserv from a spoofed administrator e-mail address and <br>
any of those administrator e-mail addresses are actually <br>
hosted by Google.<br>
</tt><br>
<blockquote class=" cite"
id="mid_5702CE88_2000407_forthepolls_org"
cite="mid:5702CE88.2000407@forthepolls.org" type="cite"> <br>
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.<br>
<br>
</blockquote>
<tt>Posts by others indicate that the *spoofing* activity <br>
seemed to have stopped for multiple gmail addresses, <br>
including the e-mail address of one person posting such <br>
an observation, indicating a likelihood that Google fixed <br>
the underlying security issue.<br>
<br>
</tt><br>
<br>
<blockquote class=" cite"
id="mid_5702CE88_2000407_forthepolls_org"
cite="mid:5702CE88.2000407@forthepolls.org" type="cite"> 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.<br>
</blockquote>
<tt>The issue that the FROM addresses of OpenSSL e-mail list
posters <br>
(not other subscribers) can be seen by anyone receiving or <br>
otherwise finding their postings is age-old and completely <br>
unrelated to any issue related to this discussion (the spammer <br>
in this case obviously did not know that this was a mailing <br>
list, given the incorrect textual name used with the list <br>
SMTP address).</tt><tt><br>
</tt><br>
<tt>Even if OpenSSL were to switch to a surveillance vulnerable <br>
design where PMs between users would have to go through the <br>
OpenSSL servers, the list administrators will probably remain <br>
reachable using well known mandatory e-mail addresses such as <br>
"Postmaster". A similar issue would apply to most of the other
<br>
high value subscribers.<br>
<br>
Any such people would already be required (in order to perform <br>
their function safely at all) to employ security measures to <br>
isolate their publicly known e-mail addresses from any e-mail <br>
addresses that are not intended to be publicly known. As an <br>
example, all my (non-blocked) postings on this list use a <br>
dedicated mail address and mail box which allows me to dismiss <br>
e-mails on other subjects to this address as Spam while not <br>
exposing other e-mail addresses used for more trusted uses, and
<br>
I obviously employ similar measures for any well known role <br>
accounts I handle myself.<br>
<br>
<br>
</tt><br>
<blockquote class=" cite"
id="mid_5702CE88_2000407_forthepolls_org"
cite="mid:5702CE88.2000407@forthepolls.org" type="cite">
<pre class="moz-signature" cols="80"><b>original anchor description (100% of the message content):</b>
Attn:__here__is__your___$lâ
â
â
__FacebÏÏk__giftcard.
__Wε__Nεεd__YÏμr__ShiÏmeηt__InfÏrmatiÏηs__
Click_Here
</pre>
<div class="moz-cite-prefix">On 2016.Apr.04 09:08, Jeffrey
Walton wrote:<br>
</div>
<blockquote class=" cite"
id="mid_CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1_ONePnAAnV_o_6ke__UQ_mail_gmail_com"
cite="mid:CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com"
type="cite">
<blockquote class=" cite" id="Cite_536673" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>