Citibank discloses private information to improve security

[Ian G]

On Wednesday 01 June 2005 23:38, Anne & Lynn Wheeler wrote:
> in theory, the KISS part of SSL's countermeasure for MITM-attack ... is
> does the URL you entered match the URL in the provided certificate. An
> attack is inducing a fraudulent URL to be entered for which the
> attackers have a valid certificates.

Firefox have added a cert domain into the status bar
on the bottom of the browser.  This is part way to what
you suggest and a very welcome improvement to
browser security.

It falls short for (IMHO) 3 reasons:  1. the domain that
is shown isn't the certificate domain, but is something
amalgamated from the URL and the cert;  which then
breaks the independent check you are hoping for above.

2., the CA should be listed so as to complete the
security statement.  Something like "ThisCA signed the
This.Domain.Com cert".  This is done in the Mouseover,
but not displayed all the time, and it is possible to get a
Mouseover that shows a statement that is strictly false
because of 1. above.  (Bugs filed and all the rest...)

3. Another issue is that it is not big enough nor loud enough
in the Trustbar sense to break through the current user
teachings that they can ignore everything as its all safe.

> Rather than complex defense in depth ... all with cracks and
> vulnerabilities that attackers can wiggle around ... a better approach
> would be KISS solution that had integrated approach to existing systemic
> vulnerabilities. For instance, some sort of clear, un-obfuscated
> indications integrated with URL selection that can leverage the existing
> SSL MITM-attack countermeasures.

Yes, this would be a much better way forward.  Now,
bear in mind that the people writing the plugins would
give their left legs to get the attention and respect of
the browser manufacturers so as to create this
integrated solution.  See various other rants...

> The downside of a KISS integrated solution that eliminates existing
> systemic problems (and avoids creating complex layers, each with their
> individual cracks that the attackers can wiggle thru) ... is that the
> only current special interest for such a solution seems to be the
> victims. Some sort of fix that allows naive users to relate and enter
> specific trusted URLs associated with specific tasks could fix many of
> the existing infrastructure vulnerabilities. The issue is what
> institutions have financial interest in designing, implementing, and
> marketing such a likely "free" add-on to existing mostly "free" based
> infrastructure. It appears to be much easier justify the design,
> implementation and marketing of a totally new feature that can be
> separately charge for.

This will change,.  I predict that the banks will end up
with the liability for phishing, for good or for bad, and
they will then find it in their hearts to finance the add-ons,
which will battle it out, thus leading to the 'best practices'
which will be incorporated into the browsers.

(Seeing as this is prediction time, I'll stick my neck
out another several kms and say it will be in about 6
months that the banks are asked to take on the liability.)

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com