the real problem and real solution for https

(for background see this hackerne.ws post)

Really, the problem here is nobody trusts the CAs. (it is kind of difficult to just assume 650 different CAs will all maintain 100% security over their cert-generation procedures)

What people seem to be looking for here is an early warning system for possible mitm *after* an initial "trusted" connection (which you can never tell for sure because even if you're browsing from a secure LAN the destination site could have been compromised, or the nameserver).

The best solution to this problem is one that will fix the problem of a trusted initial connection without relying on CAs. Of course this is difficult. But let's simplify it a bit first.

Assume for a second the internet is only two nodes: me at a desk in one room and an ethernet cable that goes into an adjoining room. I don't know who's in that other room - but I want to connect to the other end and do my banking. So how do I know if it's my bank in there or a stranger?

What do I have that I can trust right now? I have my computer, which contains (among other things) an operating system and a web browser. We won't discuss how it got there, because to discuss the origin of things ad infinitum will leave us with religion and that never solves anything.

My browser already ships with trusted information: the certificates of trusted authorities. But it's trying too hard to make everybody happy, sucking up as many different sources of trusted information as possible. In ten years we might have 6,500 trusted CAs. This won't end well.

I just want to tell if the person in the room is really my bank. What can I do to be sure?

I can ask the person in the room a secret only my bank knows, for one thing. I could have told my bank in person or over the phone, via a letter, or probably whenever I joined my bank for the first time. This would be something only I would know, not something that came with my computer.

Another way I can be sure is if I verify all the steps in the process to connect to my bank. If someone was trying to fake being the bank, they would probably have a different IP address and a different certificate. If I had a print-out with a hash of those and punched it into my browser before I made the connection, my browser would know for sure this is the bank's information and reject the connection if anything was different.

What we have here essentially is static configuration and CHAP. Combine this with PKI and you have three separate pieces of information which must be spoofed in order to successfully compromise the connection. If the person in the other room knows all of this, the bank is surely compromised anyway.

Note that this is merely a way to establish a "secure first connection". You will still need to at least have specific information about the site you're connecting to (IP and cert hash) and to be more sure of the connection have already registered and set a secret only you and the other person know.

There are technical limitations with some of this design, but if these can be worked around you should have a fairly secure connection. If you want to sleep better about PKI there should be less CAs (more like 10 instead of 650).

universal webapp architecture

I think its funny when people have  to redesign their architecture. It's like, what, you couldn't scale? Just throw some hardware at it.

Your framework had limits? Why'd you reuse it in a way that would eventually run into bottlenecks? Didn't you learn how the whole thing worked before deciding to implement it?

Your code is slowing down and bloating up, so you figure a redesign is easier than optimization? Congratulations, you've fallen victim to the worst thing you can do when faced with performance problems: throwing the baby out with the bath water.

Just optimize your current crappy system and add layers to make it get cheap performance, scale horizontally and get on with business. Redesign is usually a waste of business resources.