Axley, Jason wrote:
> I think that this trades one security problem for others in the
> application security realm. Sites that allow for equivalent functional
> duality in either HTTPS or HTTP protocols often suffer from problems
> where the HTTPS site inadvertently references an HTTP URL instead
David Wagner writes:
> One thing that web sites could do to help is to always make
> https://www.foo.com work just as well as http://www.foo.com, and
> then browser plug-ins could simply translate http://www.foo.com ->
> https://www.foo.com for all sensitive sites. Of course, web site
> operato
Adam Back wrote:
I would think it would be safer to block the site, or provide a
warning dialog.
Before we do the first redirection, we do ask the user. However, since
TrustBar is really part of our research on secure usability, we are
aware that asking the user is a very problematic mechan
Dare I say that the best must not be the enemy of the good?
--dan
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
I would think it would be safer to block the site, or provide a
warning dialog. (This is what I was expecting when I started reading
the head post; I was bit surprised at the interventionism to actually
go ahead and "fix" the site, maybe that would be a better default
behavior).
btw Regarding un
David Wagner wrote:
Amir Herzberg writes:
However, quite a few of these sites invoke SSL/TLS only _after_ user has
typed in her user name and pw, and clicked `submit`. This allows a MITM
adversary to send a modified login page to the user, which sends the pw
to the attacker (rather than encrypt
John Gilmore wrote:
Perhaps the idea of "automatically" redirecting people to alternative
pages goes a bit too far:
Of course, users can turn this off for one page or for all, but that's
not answering yet John's comments below - I respond following them...
Also: I am not crazy about this solut
Perhaps the idea of "automatically" redirecting people to alternative
pages goes a bit too far:
> 1. TrustBar will automatically download from our own server,
> periodically, a list of all of the unprotected login sites, including
> any alternate protected login pages we are aware of. By default,
Amir Herzberg writes:
>However, quite a few of these sites invoke SSL/TLS only _after_ user has
>typed in her user name and pw, and clicked `submit`. This allows a MITM
>adversary to send a modified login page to the user, which sends the pw
>to the attacker (rather than encrypting it and sending t
On Mon, Sep 19, 2005 at 02:54:14PM +0200, Amir Herzberg wrote:
> We now added a mechanism
> computes a hash of every unprotected site for which the user has
> assigned name/logo. TrustBar compares this hash on subsequent accesses
> to the same site. If the site is not modified in five subsequent
>
Most financial and other sensitive web sites use SSL/TLS to authenticate
the server and protect data from eavesdropping and from modification by
a Man In The Middle (MITM) adversary.
However, quite a few of these sites invoke SSL/TLS only _after_ user has
typed in her user name and pw, and clicke
11 matches
Mail list logo
