On 8/13/2020 2:25 PM, Tobias S. Josefowitz via dev-security-policy wrote:
On Thu, Aug 13, 2020 at 10:31 PM Ronald Crane via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
[...] Registrars (and CAs) are
in excellent positions to impede the use of phishing domains, since they
hand them out (registrars) or issue certificates for them (CAs). [...]
Things are rarely this static. The rise of new, efficient strategies
usually change how a game is played.

Suppose [software] and thus CAs/registrars, really any interested
party, could decide the question "Is X a phishing-domain?" with true
or false reasonably well. What would be the consequence? I for one am
reasonably convinced it is not "no phishing", but instead (this may
sound paradoxical at first) ... phishing will be conducted from
non-phishing-domains instead.

One of the more relevant questions in this regard is what influence to
phishing success "more phishy" domain names have over "less phishy"
domain names. We can probably assume that most phishing operations do
not apply bona fide scientific user testing for phishing success, as
well as that deeper psychological studies are not usually a precursor
to phishing campaigns. A "natural" starting point for one's first
phishing campaign might thus rather be to reproduce the experience of
the mimicked site as close as possible, explaining a drive for "more
phishy" domains to be used in phishing campaigns (if even).

It is not actually a given that "more phishy" domains increase a
phishing campaign's success. For example, you may remember hearing
from the general direction of Google/Chrome, "People have a really
hard time understanding URLs. They’re hard to read, it’s hard to know
which part of them is supposed to be trusted, and in general I don’t
think URLs are working as a good way to convey site identity.". It
also is the case that phishing victims often fall victim to selective
attention - i.e. clicking a link in a malicious mail and entering
information/credentials/... mostly on autopilot without ever even
checking the URL!

Detecting phishing domains by "looking at them as strings" may thus be
futile, and "blocking obvious phishing domains" may be a not so
entertaining but ultimately pointless game of whack a mole for CAs;
and that is especially since there is not that much to actually
suggest that CAs are the best place to whack moles *to prevent users
from being phished* **in their webbrowsers**, which I believe is
actually what we are discussing here anyway.

But it could be that examining domains as strings usefully impedes (though of course does not eliminate) phishing. Impeding internet malefactors is _always_ a game of whack-a-mole. If it become harder successfully to phish with official-appearing domains, phishers will try something else, and the guardians of the internet (such as there are) will have to counter that tactic. [1] It is not a question of what's "the best place" to counter phishing, but whether it's useful for registrars, CAs, and hosts to do some of the work.

Along those lines, do you know of any research on whether "phishy" domains are more effective than non-"phishy" ones?

-R

[1] Or we could just retire and let the crooks do their worst.

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
              • Re:... Paul Walsh via dev-security-policy
              • Re:... Burton via dev-security-policy
              • Re:... Paul Walsh via dev-security-policy
              • Re:... Burton via dev-security-policy
            • Re: Con... Tobias S. Josefowitz via dev-security-policy
              • Re:... Paul Walsh via dev-security-policy
              • Re:... Ronald Crane via dev-security-policy
              • Re:... Kurt Roeckx via dev-security-policy
              • Re:... Ronald Crane via dev-security-policy
              • Re:... Tobias S. Josefowitz via dev-security-policy
              • Re:... Ronald Crane via dev-security-policy
              • Re:... Tobias S. Josefowitz via dev-security-policy
              • Re:... Ronald Crane via dev-security-policy
              • Re:... Tobias S. Josefowitz via dev-security-policy
              • Re:... Tobias S. Josefowitz via dev-security-policy
            • Re: Con... Eric Mill via dev-security-policy
              • Re:... Paul Walsh via dev-security-policy
        • Re: Concerns wit... Paul Walsh via dev-security-policy
  • Re: Concerns with Let's Encrp... Ronald Crane via dev-security-policy

Reply via email to