Server problems caused by 'transparent' self-signed SSL certificates
One of the issues with allowing self-signed SSL certificates to be
automatically used for transparent encryption over
https URLs is the
problems that they cause for server-side applications.
Right now, a server-side program that care can more or less assume that
a SSL-encrypted connection means either that it is securely talking
to the real end user's machine or that the end user has been actively
compromised (which it can't do anything about). It may thus use things
like 'you can only talk to this service over
https' as a reasonable
security precaution, one that means something.
If you allow self-signed SSL certificates to be used transparently
for encryption in
https URLs, you enable relatively trivial man in
the middle attacks. This negates all of the security properties of
SSL connections. Because the browser knows what level of security the
certificate it accepted had, browsers can recognize this and lie to
than it actually is.
However, the web server does not know and cannot know this information,
since it has no way of finding out if it is talking to the real end
machine or to a man in the middle. As such, server side applications
can no longer assume that a
https URL and a SSL connection means
actual security; it might be secure and it might not be, and they can't
tell the difference. This leaves them with no way to require something
approximating actual security from clients, and it breaks current
applications (to the extent that they assume that SSL means security).
(In theory the one way out of this is to require everything to have client side certificates. However, I do not believe that this is any more practical than trying to make all server side applications instantly give up any 'SSL means security' beliefs that they may have.)