Nick Kew wrote:
True. But in the case of a HTTPS link being used, it would be pretty easy to repeat on all pages a message to the user to the effect that if his browser does not show that this is a secure connection, he should not continue. It would have to be a pretty sophisticated MITM application, to filter these out.On 27 Jan 2009, at 21:00, André Warnier wrote:The only real weak spot is the "man in the middle".Heh. You mean it doesn't use client certificates. The server knows it's talking to just one client, but can't be certain who that client is. You can use the same attack with HTTPS, too. The difference there is that browser will show the user that the connection is not secure, which is useful only if the user knows the connection needs to be secure: Server <-- Digest --> Proxy <-- Basic --> Client Server <-- HTTPS --> Proxy <-- HTTP --> Client In both cases, the connection from server to proxy is secure, but the client end isn't.
But any MITM attack would first have to start by corrupting the DNS system anyway, which should not be that easy, or is it ?
(excepting phishing of course)Anyway, the OP did not sound like he was talking about an access to Fort Knox, although you never know..
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|