Regarding Moxie, I noted in the original post and immediately after his first post that he'd need to provide a valid SSL certificate. He asserted one wasn't necessary and I assumed perhaps he had some other trick to make it appear as though he had one so I invited him to email me details. His attack didn't do that and it turned out he had interpreted the requirement for a valid SSL certificate to mean that he couldn't present one the browser would flag as invalid. I'm sorry if you or he feel that I wasted his time.
The SSL connectivity for the server did work. The only way to defend against the attack Moxie posted would be to modify my browser. The exploit Moxie used depends on the fact that if one doesn't type https:// the browser will request http. You could argue my error was abbreviating in the posting but that wouldn't change how users type it. The best defense against this is HSTS which comes in two flavors: The standard version is applied after first visting the site. Would you have said that invalidated the attack? The attack would work just as well on a browser with cleared cache or running in incognito mode.
The only real defense which, to my knowledge, only exists in Chrome is the HSTS preload. I suppose I could have noted that I'd modify my browser to have it on the HSTS but that doesn't effect real world security either.
That said, I am extremely curious how you would defend against SSL stripping in the wild. This seems like a potentially devastating attack. None of the banks that I checked are on the preload and many don't seem to use HSTS at all. What defenses would you have considered sufficient so as not to consider this trivially exploitable by an SSL redirect vulnerability that effects almost the entire web?
Your argument above effectively reduces to: The web is insecure so you always lose and putting in a disclaimer to ban such attacks is weaselly. The SSL vulnerability is a huge problem but that doesn't mean understanding the security of the rest of the system is worthless.
I never said I'd check the fingerprint of the certificate against my memory. Moxie used that retort against me after his attack produced a session that was obviously not over https. I explicitly denied that that was one of my criteria. That said, at least in chrome, appspot.com is pinned.
The irony is that this does show that SJCL provides a modest security increase over plaintext in the case of broken SSL. It requires a per-site attack to be constructed ahead of time vs. simply reviewing the plaintext for all sites after the fact and picking what's valuable.
Your key argument seems to be that naive developers might use JS crypto because of this. If they use it naively, I'm sorry for that. I'm also sorry if they exclude it naively because of other rhetoric. I hoped that this would generate more nuanced discussion that would cause them to be more aware of the risks if they chose to use it. Obviously that wasn't the case and nothing was learned about the various angles from this app could be exploited aside from the trivial one.
I truly appreciate your laying out your reasons above. I understand I struck a negative chord but am glad that we've been able to move into discussing the specific technical issues.