Opened 6 years ago

Closed 6 years ago

#6279 closed defect (fixed)

Rules: POF / Plenty Of Fish

Reported by: grarpamp Owned by: MB
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


1) POF is made up of many more hosts than just (www.)?

  • Documented observed hosts, implemented compact form with *'s. (But see Excludes TODO in the case that POF again does not deploy HTTPS everywhere in the future.)

2) Fixed poor forms

  • unnecessary mapping from https to https with 's?'
  • unused non-backref '?:'
  • mapping www to the domain itself

3) POF is now returning 302 (to HTTP) for all HTTPS requests.

  • Therefore the current rules in git are moot and result in POF falling back via redirection loop to insecure HTTP.
  • POF is now completely unencrypted with no HTTPS capability at all (except for maybe their payment server). Users should be wary about their privacy, account, and financial integrity when using POF.

printf 'GET / HTTP/1.0\nHost:\n\n' \

| openssl s_client -connect -quiet 2>/dev/null

HTTP/1.1 302 Found
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET

4) Due to all this, the attached replacement ruleset is disabled
by default. It should be committed as notes for if/when POF moves
to https in the future.

Child Tickets

Attachments (1)

pof.xml.txt (2.4 KB) - added by grarpamp 6 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by grarpamp

Attachment: pof.xml.txt added

comment:1 Changed 6 years ago by MB

Owner: changed from pde to MB
Status: newaccepted

comment:2 Changed 6 years ago by MB

Thanks for the report. The ruleset is now off by default in master. There are some bits of the website that do support https, which I've changed the ruleset to cover.

If you could try it out and report back, that would be great.

comment:3 Changed 6 years ago by grarpamp

I would have to check and rewrite it parts before testing.
Why continue non-backref'ing when there no backrefs.
Why continue redir https to https.
Why continue not include known hosts.
Why continue remap many hosts to one.
Why unprotect aspx (which is put whole site used) and user at risk anyway then.

comment:4 in reply to:  3 Changed 6 years ago by MB

Replying to grarpamp:

Why continue non-backref'ing when there no backrefs.

I saw the initial wave of uncapturing that went through rulesets had uncaptured exclusion patterns, and assumed that https-everywhere holds onto such atoms despite not needing to. From this question, I'm assuming that my assumption was incorrect.

Why continue redir https to https.

Because the certificate doesn't match, and as the rule is, it rewrites from to This is explained (albeit leaving the reasoning implicit) with "Cert doesn't match...".

Why continue not include known hosts.

Because my time is limited, and I haven't gotten around to that yet.

Why continue remap many hosts to one.

Read the comments, specifically: "pics\d?: Akamai"

Why unprotect aspx (which is put whole site used) and user at risk anyway then.

The comments address this: "302s to http".

If the comments could be better, I'm happy to change them.

comment:5 Changed 6 years ago by grarpamp

I don't know the answer on holding memory usage. I meant people are
'?:'ing with no '$n' replacement, so the '()' would seem to become
a simple PCRE matching group. No '$n's, no held atoms and unneeded
'?:'s. Something like that, afaik.

Aside: All the PCRE I tried works, so I'm assuming HTTPS-E/FF uses
formal PCRE engine. I have a query open on that though.

remapping, known hosts...
We can't know how a site expects to work, so blind redirection of
working hosts to a single fqdn just because it also appears to
'works/serves' isn't the best idea and is likely to break as a site
evolves. Likely also are 404's and other processing oddities.

Whether/where one preemptively '\d's or otherwise captures unknown
hosts is uncertain as to best practice. For example, POF wildcards
their dns zones. So someone's saved pages would then act differently
if pic3 drops from dns but is still mapped. Same as for if pic33
goes live under a new usage model.

redir https...
If a site author embeds a https link, it is expected to work. Yet
people are remapping https to https, that's redundant. Their use
of 's?' in from=https? appears misguided.

Much unauthored material in that... pics.*aspx,*thumbs

CAPS, akamai...
The goal here is working encryption... so you don't want to exclude
broken certs, user can always accept/pin them in the browser to
gain warning free TLS, or to retain TLS period. I'm still laughing
at that CAPS CommonName.

Back to the basics, aspx...
Other than pictures, POF is almost entirely made up of aspx pages.
Since POF 302's or hangs on essentially all of them, we have two

1) exclude them and gain no TLS
2) include them and gain an unusable site

Therefore the rules as proposed via commits gain us nothing, further
developing them is moot, and the user might as well leave them off.

As ticketed, I submitted in production rules that fixed the git
rules of that era. Then POF went 302. 'Plenty' miffed after plenty
of writing/testing them. Anyway, they are expected to be more useful
and complete for if POF reverts to the last known former case (where
replacing everything with HTTPS in fact worked).

POF's apparent cobbling together by amateurs shines through in their
site. Not to mention its behavior towards Tor's legitimate users.
Further, I'd wager that POF 302'd/hung HTTPS, not because the few
hundred HTTPS-E users spent a few more of POF's cpu cycles on HTTPS,
but because POF tired of their own error logs, or some such/config,
from it.

I'll happily collaborate on this set again when they pull their
head from their ass regarding, at minimum, HTTPS. Though I'd expect
and hope that their next move, perhaps driven from user outrage and
public shaming, will be to HTTPS the entire site such that no rules
are needed.

Either way and until then, users have no security with POF. Considering
the personal nature of such a site, that's really sad indeed :(

comment:6 Changed 6 years ago by MB

Resolution: fixed
Status: acceptedclosed

I'm closing this because the problem has been "fixed" by turning the ruleset off, and no feedback on whether the new rules break anything has been forthcoming.

Note: See TracTickets for help on using tickets.