Several thoughts about the paypal spoof site that uses a redirector from
the real paypal site.
1. I didn't ever see any EV or even non-EV SSL UI chrome indicators at
the same time as the spoof site was displayed, so I don't see this as
a failure of UI for SSL or EV. But I was using FF3 with a very vanilla
configuration (new profile), and if there's some other configuration
that FF3 users use in which there is some confusion about whether the
spoof site is legit paypal or not, please let me know how to configure
my FF3 to see it.
2. I also don't see this as reflecting negatively on EV or SSL at all.
Some of the sentiment that has been expressed in this discussion seems
to be disgust that EV doesn't assure that the site is completely "safe
and secure" for the browser user, against such things as XSS attacks.
But that's not it's job.
Remember that SSL's job is to ensure the user of a secure *channel*
between the user's own computer and the computer with the rightful
identity that the user specified in the URL that he used to open the
channel. EV strengthens the claim of authentication of the identity of
the computer on the other end of the channel.
SSL & EV indicators in the chrome are a statement about the *past*.
They say "The channel(s) through which your request was sent, and through
which the page you now see came to you, were authenticated to be truly
connected to the site specified in the URL, and not some impostor site.
The content was neither modified nor externally visible as it passed
through that channel from the server site to your browser." These are
statements about properties of the *channel* (e.g. opaque, impenetrable,
other end is at a known place). That's all that SSL has ever said.
Neither SSL nor EV mean:
- the server to which you connected is free of viruses and malware
- the server to which you connected is free of XSS vulnerabilities
- the server to which you connected is run by moral and upright people
- the web page you just received won't crash your browser
- your own computer is free of viruses and malware
- the stock market won't crash tomorrow
- you won't become unemployed tomorrow
Any and all of those things might be part of what the user wants to know
in order to feel the he, or his browser, is "safe and secure", but SSL and
EV are about securing *channels*, and none of those statements above is a
statement about a channel.
One more thing that the SSL or EV UI indicators do NOT mean (presently) is:
- When you click a link or push a button on the page that you just got
through a secure channel, you are assured that your next http request
and response will go through a similarly well secured channel.
Such assurance is not a within the scope of responsibilities of a channel,
and those indicators are about the state of the channels used in the past.
But users do seem to *want* and *expect* that assurance, that their browser
will use only secure channels for transactions subsequent to a prior
transaction that used a secure channel. So, it's not an SSL issue, but is
a browser issue, dealing with the browser's willingness to enforce the
user's expectations regarding the level of *channel* security on a series
of transactions that the browser initiates.
The issue Kyle raised, of lack of indicators of transitions from pages
received via EV+SSL to pages received via channels that either are non-EV
SSL or non-SSL, has to do with whether the browser's attempts to ensure
uniform channel security through the steps of a transaction will meet the
user's expectations for "secure" operation, or not. Whether the browser
does that or not is not a measure of SSL or EV's ability to do their jobs.
Johnathan Nightingale wrote, On 2008-07-04 06:53:
> I understand, therefore, why you'd be inclined to ask if we should
> have some kind of alert when you leave an EV page, but I resist doing
> that for a couple reasons, chief among them being questions about
> whether a dialog would actually change anything. There is reasonably
> ample evidence that dialogs that have "ok" as their only really
> "useful" option tend to be quickly ignored by users, at which point
> they stop having any impact on user behaviour.
I completely agree that dialogs with only one button are not very valuable
because they give the user no real control, no real choices over subsequent
events that may impact his security.
And, knowing that FF3's existing https->http transition warning dialog is
indeed such a one-button wonder, I'm OK with it being disabled by default.
Maybe that button should be labeled "Bummer!" or "I forgive you".
But I don't accept that transition interception dialogs must necessarily
be powerless, functionless UI features.
If we ask: "Why does that dialog have only one button?" we find that the
answer is that the code that decides to display that dialog is code that
runs AFTER the new channel has been selected, after the http request has
been sent, and the http reply has been received -- in other words, after
the damage has been done. That carefully worded "You are about to leave
a secure page" really means "we've already sent your info out insecurely
to god-knows where, and now we're just confessing that fact".
As long as the logic for that dialog remains after-the-fact detection logic,
the only purpose that would be served by a Cancel button would be to tell
the browser "Go ahead and conceal from me the damage you've already done
to me.". Not exactly helpful to the user's sense of security.
(This is why I suggested the button label "I forgive you".)
The first browser to use SSL, FF3's predecessor, detected that it was
about to begin (but had not yet begun) to use an insecure connection,
when the previous page was loaded over a secure connection. It displayed
a dialog BEFORE starting the new connection, which gave the user a real
and meaningful choice, to prevent the insecure connection, or to continue
with the insecure connection. I think that's what Kyle and others
(including me) would expect from such an https->http dialog, the ability
to stop the damage BEFORE it's done.
There's a bug/RFE, asking that Mozilla's browser work that way too.
It's bug 62178 (yes, a mere 5 digit number :). It's filed against PSM,
but it's really a browser architecture issue whose scope is much wider
than just PSM. I hope sincerely it will get some traction.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
