PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

Fri Feb 10 21:37:55 UTC 2012

In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:
> The problem space is that most folks won't catch the difference
> between an email and link from ripe.net, ripe.org and ripe.ca. The
> game is lost long before a purely technical version of validating the
> message source becomes an issue.

You're reply is along the lines of what several other folks have
told me privately, and I think they all miss the mark of where I
am going with my suggestion.

Hypothetically, I get an e-mail from ripe.ca, which uses some trick
(perhaps as simple as HTML text and link that go to different places)
to visually show me ripe.net and actually sends me to ripe.org.

Let's also assume I have a ripe.net account and have been to that
web site before.

The software can do a pile of things that make life better for the user:

1) When I reach ripe.org (from the phish above), my browser can say:

   "This is an SSL web site asking for a login and password, and yet,
    you've never been here before.  Maybe you would prefer to register,
    or leave if you came here incorrectly."

   That's all client side UI, and would make even novice users stop
   and think about what happened.

2) Let's say the e-mail was signed, by ripe.ca, the original sender.
   When my e-mail client passes the URL to my browser, it can also pass
   the details of the ripe.ca key.  My browser can then say "You got
   an e-mail from Key ABC, but went to a web site run by XYZ, are you
   sure this is what you want to do?"  Of course if everything matches,
   it can be silent.

Specifically I am NOT suggesting to ever trust a root-CA, or the
details in a certificate.  Indeed, browsers could ship with no
certificates what so ever in my scheme.  The key is comparing
multiple sources of information.  Most folks might not know the
difference between ripe.ca and ripe.net.  The existing CA scheme
may allow both of them to get the common name "Réseaux IP Européens",
confusing even the technical who look close.  But it's trivial for
the software to say Cert in E-mail != Cert in Web, or even that
they don't have a common branch in the tree (in a large org they
may have the same parent, for instance).

As I've also said, a good UI feature would be the ability to add a
description to a cert locally.  Once I'm sure my banks web site is legit
I should be able to add "Leo's Bank" in the cert store locally.  Now
when my web browser or e-mail client use that cert to validate a message
they can display "Leo's Bank" next to it.  I can easily look for that
and know I went back to the same place.  I click on a link in my e-mail
and see no description, I know something went wrong.

Does my scheme stop all phishing.  Heck no.  If we wait for a perfect
solution we'll never have any solution.  Look at NANOG.  Bandy Rush is
here somewhere.  It's why many years ago I set my mailer to PGP all
e-mail to NANOG.  See an e-mail from me not signed, don't trust it.
Does that stop all impersonation on NANOG.  Heck no, but if we all did
it, and subscribed to the web of trust, it would all but stop it.

Users hate encryption and ignore the warnings not because they don't
want to be secure, or are idiots.  They do it because the darn software
is broken, confusing, and has the worst UI's ever invented.  If the
industry fixes it, encryption will be much more widespread.  Small
steps, like banks allowing users to upload an cert to their account
profile, and then communicate via two-way authenticated e-mail would go
a long way to traning the user community how this should work.  End user
ISP's (cable, DSL) issuing e-mail certs automatically and installing
them as part of their install package would be a quantum leap forward.

It's not hard, people just don't do it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/742945ee/attachment.sig>