[cap-talk] Posters on Polaris and Petnames
iang at systemics.com
Wed Jul 6 17:38:09 EDT 2005
On Wednesday 06 July 2005 21:40, Jed at Webstart wrote:
> At 11:55 PM 7/5/2005, Ka-Ping Yee wrote:
> >I'm attending SOUPS (http://cups.cs.cmu.edu/soups/) this week,
> >and will be presenting two posters. The posters can be seen at
> > http://wolog.net/
> 1. On phishing, identification, and SSL: I believe SSL is a technology
> that addresses itself to more than just identification. SSL also
> serves to encrypt information that is transmitted across the Internet
> to protect it from eves dropping. I believe SSL has been quite
> successful in this encryption and protection of information role.
> To refer to "The Failure of SSL" without qualification seems a bit
> over broad to me. Perhaps something like "SSL does not identify
> destinations"? or "SSL fails to safely identify Internet sites"?
Well, we've wrestled with this, and we can be more
precise, but that just allows people to excuse themselves
left right and other sideways.
The problem is partly one of terminology and partly
one of ostrich-like behaviour. SSL the protocol was
designed to secure transactions on the web. Transactions
are not secure on the web. Now, the difference between
those two statements is messy ... the reason that transactions
are not secure on the web is that the security model in
browsing has been breached, and SSL the protocol is
only one component in that security model. That's
For short, everyone calls the security model SSL. Until
that point where we point out that it isn't secure, in which
case those that defend SSL point out that it isn't SSL's
problem, and those that defend browsing say that it is
secure because they use SSL. And we go round and
round and round.
The SSL community has to stand up and help define the
problem, because they are the security guys. The browsing
community has to stand up and say they have a problem
with the way they implemented SSL, and they need help.
Until these two groups display some scientific integrity
about where the problem lies, I think stating "SSL has
failed" is as approximately as close as we can get to
describing the problem in terms that have some overall
> I was amazed when I saw your chart indicating that US Bank, PayPal,
> and eBay don't use SSL on their default login page. Why in the world
> not I wonder? The only possibility that comes to mind is to save users
> the cost of linking to an SSL protected page for the login. Wow.
> Many of the personal IDs and passwords for US Bank and PayPal
> and AOL customers fly across the Internet in clear text???
No, it's more subtle than that - the link when you click
LOGIN is a https link, so it is sent encrypted, but the
site leaves itself wide open to phishing, as the user is
supposed to check *before* clicking that they are already
at the correctly named site.
Yet another failure in security models, where one failure
leads to laziness in another area which opens up a
> I have to admit that I'm a little confused by some of the "Classification
> of Attacks" data. For example,
> '41% of attacks are unaddressed by solutions that require the
> target site to use SSL'
> I believe the Waterken petname tool requires the target site to
> use SSL - for a certificate to bind the petname to. Does that
> mean that some portion of those 41% are unaddressed by
> the Waterken petname toolbar mechanism? I don't think so,
> but it seems to me the statement could be taken that way.
There is a non-trivial class of problems that exist
purely on the server side - it is possible to trick the
server itself. I didn't think the class was that large,
but oh well.
My attitude to this is that we have to identify what
we can about the core, fundamental parts of the
problem. For the most part, the browser is at fault,
so let's fix that part (petnames, trustbar, etc). Then,
this makes it easier to concentrate on the other attacks.
(Although I also had trouble clarifying what this
section was saying...... But the more we can hammer
home that this is the result of basic flaws in the
security model, the better, so I wasn't looking for
perfection in the comments.)
Advances in Financial Cryptography, Issue 2:
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
More information about the cap-talk