> Proponents of the requested change believe that it is much > likelier to have > your communications observed by a passive attacker, than to have an active > attacker in the path that masquerades as e.g. "amazon.com". Not that the > later is impossible - just less probable and less frequent.
Except HTTPS is not supposed to be a "not likely somebody's going to bother to break it" type of security. It's supposed to be security that provides fundamental guarantees. Perhaps the reason passive attacks are more common than active ones is because there really aren't deployed solutions that are vulnerable to one and not the other. So it's not logical to make a more difficult attack when a simpler one will do. That said, there are quite a few people who can and would hijack and actively intercept HTTPS sessions if they *could* do so. If that worked and passive interception didn't, then that type of 'attack' would be become more probable and more frequent. (Almost everyone who currently does so with HTTP would do so with HTTPS if they could.) > I'd adopt the change and created a new icon - say a small "fence" > instead of > a small "lock" to denote that the link is encrypted but the peer is not > authenticated. :-) The problem is that people may not look at the icon at all. The current model, requiring the user to acknowledge that he is not getting the level of security he expects, ensures the user actually knows what he is getting. Excepting the user to notice that the icon is not the usual one is not sufficient. However, it is true that the current scheme creates an "all or nothing" choice that might result in sub-optimal behavior in many real-world situations. However, any solution that increased the risk of an active attack on HTTPS would be unacceptable, IMO. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
