Slightly off topic - summary of problems with SSL from dotCrime Manifesto

This might be slightly off our current topic but the summary might be useful. In my book the dotCrime Manifesto I set out the principle problems as I see them in the current SSL user interface. I wondered if folk might like to review them and comment on possible additions.
 
 
The SSL protocol is widely deployed and used. The protocol itself has survived numerous expert reviews and there is a great deal of confidence in its design. The same is not true of the way that applications implement SSL. The user experience is unsatisfactory in many respects:

The padlock icon is practically invisible.
Most users don't know what it means, of those who do few look for it.

The browser does not answer the question the user is asking.
The questions the user cares about are 'can I trust this site' on first contact and 'is this really the party I know' on subsequent visits. What the padlock actually says is 'this connection is encrypted'.

Information is not presented in a form that typical users can understand.
The certificate information dialog in existing browsers is designed as a debugging tool for site administrators rather than a means of communication to the user. Interpreting the dialog correctly requires detailed knowledge of X509 PKI that is beyond the typical Web administrator let alone users.

The user is bombarded with irrelevant queries.
Most browsers warn when a site contains a mixture of secure and insecure content, when the user moves from an insecure page to a secure one and so on. These dialogs are intrusive and most users quickly turn them off, thus losing necessary information. The only purpose the dialogs seem to serve is to allow the browser designer to blame the user for mistakes caused by the poor user experience.

The user is not told the identity of the trust provider.
The failure to effectively identify the certificate issuer means that the certificate issuer is not accountable for errors or negligence. Reliable authentication processes cost time and money. Without accountability new entrants to the certificate business have little incentive to invest in either.

Elements of the browser user interface allow an attacker to emulate a secure site
One of the chief offenders in this regard is the infamous 'favorites icon' which appears in the address bar of some browsers. Many users assume that favorites icons are trustworthy because they appear in the part of the display that they assume to be reserved for verified information. In fact these are displayed without any authentication measures being taken at all.

In many cases remedying the faults revealed by the gap analysis requires little more than recognizing them as such. In particular the design of the security user experience must be designed to center exclusively on the needs of the user and not on the Web site administrator.

In particular the user should not be warned about administrative security defects. This might sound counterintuitive. What is the point of having security if the user is not told when it fails? But in the Web today the majority of Web sites have no security at all. Adding security measures should never reduce the quality of the user experience.

Instead of warning the user that the site certificate is invalid the browser should display the site in the same manner as any other insecure page. That is the browser should not display the padlock icon.

An intrusive warning message is only justified when the warning itself corresponds to a security condition that directly affects the user. It is appropriate to display a warning if the browser has reason to suspect that the user has been directed to a phishing site. 

The need for administrators to check their own sites should be met by browser tools and extensions that are purpose designed for Web administrators and which allow them to specify the specific sites where they want to see detailed reports on all aspects of the site configuration including security.