I actually did see the EV chrome indicator, but my network latency was
fairly high. (If you want to simulate this, try torrenting Ubuntu.)
It appeared to be a time-delay thing (based on 'oh hey, we've got an
EV-validated connection') as opposed to a content-delay thing (such as
"oh hey, this is a 302 redirect, I shouldn't express that this is an
EV-validated site until I figure out what's going on").
What we have is a situation where TLS certificates actually -- for the
first time in their life other than the initial, insanely overzealous
and overpriced certificates from Verisign -- profess /authentication
data/. And even more, this is the first time they /put that
authenticated data on the chrome/. Further, it's a signifier that is
a lot harder to spoof than prior TLS cert-handling within the PSM that
handled everything exactly the same way and had no way to
differentiate between built-in tokens and user-added tokens.
(One of my colleagues showed me a situation where EV certification is
absolutely necessary: a wildcard certificate for '*' issued to the
proxy server, issued by a company-internal CA and embedded into the
local browsers, which matched www.wellsfargo.com and
www.bankofamerica.com. The net effect of this was that the company
could see all of his private account information when he needed to
check his balances to make sure he had sufficient cash flow to be able
to front the expense of his next business trip.)
It is true that what I'm asking for is not really a TLS request. It
is true that what I'm asking for is really a security-consciousness
architecture change. We know more about the web and how it's
exploited now, and I believe that it's truly irresponsible that we
continue to allow the same old attack vectors that work simply because
we do not actually use the verified information provided by the
underlying socket layer in concert with higher-level application
protocol knowledge.
My wish-list for EV site handling goes something like this:
1) Do not determine EV site status before the request and all of its
redirections are resolved to a non-redirected page.
2) Do not show the EV site status until it's determined.
3) If an EV-validated site (determined after all symlinks are
resolved) redirects to another EV-validated site, STOP THE PAGE LOAD
UNTIL THE USER KNOWS WHAT'S GOING ON. Just because a site has an EV
certificate does not mean that the user automatically trusts them --
only that the user has a much better idea of who it is.
4) If an EV-validated site redirects to a non-EV-validated site, STOP
THE PAGE LOAD UNTIL THE USER KNOWS WHAT'S GOING ON. If a user's
submitting information to an EV site, it doesn't mean that the user
wants to submit information to a non-EV site.
I really cannot stress wishes 3 and 4 enough. In computer security
circles, we have known for years -- decades -- that authentication and
authorization are two entirely separate processes. Banks have known
this much longer than computers have been in common usage. I can
authenticate as myself, but I do not have authorization to access
Nelson's bank account.
The downside of this approach is that it would break things like
Google Analytics, since that relies on the fact that browsers don't
flag TLS sessions with different CNs to be 'insecure connections'.
Thus, I'm not going to assume that I'm going to get my entire
wish-list. (far from it.) [The flip side: there could be a
white-list of approved sites that EV-validated sites could redirect to
that provide useful services.]
The way that Mozilla handles security right now is rather pathetic,
relying on a low-mediation approach with nowhere near enough user
information/authorization. HTTP itself is stateless -- meaning the
server doesn't need to maintain state just to successfully complete a
request -- but we have seen that web interactions in general are
stateful, with 'state' being layered (via cookies and form parameters
and URL generation/interpretation and other things) on top of it.
Users expect 'state'. The least we can do is apply the principle of
least astonishment to those things that they have a legal right to
demand to be private (such as financial interactions). ("I was at
Bank of America, why am I suddenly giving information to Geico
Insurance???")
-Kyle H
On Sun, Jul 6, 2008 at 9:50 PM, Nelson Bolyard
<[EMAIL PROTECTED]> wrote:
> 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-tech-crypto mailing list
> [EMAIL PROTECTED]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
