On 09/22/2010 08:48 PM, Martin Rex wrote:
Henry B. Hotz wrote:
[...] For example the user may trust a dedicated discovery service
or identity service that securely redirects requests from the source
to a target domain.
Thinking about it, I feel slightly uneasy about some redirects, such as
https://gmail.com -> 301 -> https://mail.google.com/mail
I think these should never go without a warning.
That bugs me too. Lots of sites do it though, usually with Javascript.
If my banks online-banking portal (https://www.<mybank>.de)
would suddently redirect me to https://www.<mybank>.com before
asking me for credentials and transaction authorization codes,
that would be a real security problem, because www.<mybank>.com
is not leased by my bank (it is apparently not currently leased to anyone)
Yep. There are often ways to make that happen with just a blind
plaintext injection capability, too.
A hacker that breaks into a web-site in order to do trap
victims
The site is now 100% (to use the technical term) "pwned".
It's not possible for a network security protocol to survive the
compromise of one of the endpoints. We can no longer reason about Alice
and Bob if Bob is allowed to be under the hypnotic control of Eve.
I think it's dangerous to try. We're likely to optimize for cases of
dubious security at the expense of some properly functioning cases.
might be less easily detected if he doesn't subvert
the entire site and tries to send collected data to external
places, but instead puts redirects into place that browsers
will blindly and silently follow, maybe additionally filtering
the clients that will be redirected based on their origin,
so that the helpdesk and security guys can not immediately
repro it with their browsers.
Should a users decision to trust a particular service with
a particular issue always imply that this particular service
is a fully trusted naming service (i.e. one that performs
secure name transformations)?
There are lots of ways a site can delegate its security like that. They
could load Javascript or HTML from external sites, for example. They can
use headers and script to broaden the origin which the browser trusts.
http://code.google.com/p/browsersec/wiki/Part2
Not to mention that they could simply proxy the requests on the server
side, outsource their servers to someone untrustworthy, add insecure 3rd
party tracking cookies, redirect via non-SSL HTTP, and so on.
Once your browser trusts a server to serve some domain/origin, there's
almost nothing that server can't do with its identity, including
delegate it to someone else (intentionally or not).
- Marsh
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf