Why Cloud security is impossible

Yesterday I've come across a rather old, but still actual (and even more and more actual, I'd say) article, that explains, why in-browser cryptography isn't going to work.

The article is "What's wrong with in-browser cryptography". It is written from security researcher's point of view, and as such is focused on flaws of the in-browser cryptography model. However, out-of-browser (but initiated by the server-side code) model is flawed equally (if not more) seriously, as an in-browser one. It doesn't matter, where the cryptography code is located - will it be some JavaScript in the web page, or a browser plugin or WebCrypto API offered by the browser itself. As long as the web page is changed dynamically, the user can not be sure, that the information is really encrypted, and that it is sent to the intended recipient. SSL/TLS does NOT ensure such security, unlike what most users think.

The article makes a good point, that with desktop software you can always capture the code that was executed and analyze it, in order to find what is being done and where the data is sent. And the code is signed, proving (to some extent) that it is authentic and has not been altered. With web pages such analysis and protection are not possible, because they can be easily altered by the server or by third-party actors (like browser plugins etc).

Browser applets like Flash and Java could solve the problem by applying code signing of applets. Unfortunately, in their desire for openness (which in most situations contradicts to security) the industry has rejected "closed" solutions that applets offer in favor to everchanging HTML, which makes security of user's data a distant dream.

One of solutions would be development of signed scripts, which could be signed with certificates as much as applets are. Unfortunately I didn't see any widespread attempts to introduce "secure Javascript" or "secure web pages". If you came across some, please let me know.

PKI reforms starts. Kind of.

Microsoft has lost faith in more than 20 CAs.

Still this is a partial measure. The chain is as strong as its weakest link is. If we have a web server certificate, signed by CA X , whose CA certificate is issued / signed by (trusted) root CA R, the X can be the weakest link, and no Microsoft measures will help prevent this link to be broken. This is exactly what happened in previous cases, when sub-CAs (like those X) issued certificates in violation to PKI rules and practices.

The solution? Web of trust. This would require certain modifications of the PKI, but the requirement for the end-entity certificate to be signed by at least two CAs would eliminate most issues related to wrongdoing by sub-CAs. Look - if you are an attacker and you hijack CA X , there's little use in this - you would need to hijack CA Y and/or CA Z . This is possible, but much more complicated and imposes higher risks to your attack to you.

In general there's much there that can be borrowed from OpenPGP. CA (Issuer) can still be present in the certificate, but there can be other extensions like subsignatures or counter-certificates included, and that would significantly increase the protection level.

A "fatal flaw" which is neither a fatal, nor a flaw.

The article in SC Magazine talks about "security flaws" in Kerberos protocol.  But what are those flaws about?

If we dig deeper, the only phrase in the article suggests that "if the attacker knows user's secret key, he can replay authentication without the need for user's password". Actually this is not a flaw. If the attacker got to user's secret key somehow, the user and the network are already in trouble, because this means that the attacker has already found some flaws elsewhere.

Now, Kerberos' shortcomings and disadvantages were known for years, and the discussed one was known as well. This is why Kerberos is not recommended and is replaced by modern protocols like SAML and OAuth even in intranets.

To sum it up, digging the grave and finding old flaws and bringing them back to the sunlight is an easy way to establish yourself as a security researcher, but you still need to look at the roots. And protection of credentials and use of multifactor authentication are the things that separate good security from the bad one.

HTTPs as it could be

Google has reinvented the wheel HTTP and called it HTTP/2. This comprehensive article about HTTP/2 describes how the web will benefit from this new protocol.

The problem with HTTP/2, as with most of what Google does is that it was designed by coders, not by system architects. The protocol severely lacks internal clarity and integrity. The server should behave in many (at least 4) completely different ways depending on what it supports and what the client requests. It's like trying to combine the truck's wheel with the bike one.

The authors are definitely not readers but writers. There exists SSH family of protocols, which does a thing very similar to what HTTP/2 does. And SSH has quite complicated but logical internal structure. The only thing missing from SSH (not exactly missing but not used) is X.509 certificates and/or OpenPGP keys - while both are in theory supported as authentication methods, almost no real software supports these methods (our SecureBlackbox supports OpenPGP and import of keys from X.509 certificates). Meanwhile HTTP/2 is a combination of old HTTP, new protocol (completely unrelated to HTTP) with fallback to HTTP, and more. Probably the authors of HTTP/2 are adepts of the pastafarian church.

The authors could easily learn how to design the multiplexing scheme right, but, as said, they are likely not readers.

Hitting him with nails

PKI is having hard time, as more and more human mistakes are revealed, which undermine PKI's position.

In fact,  PKI is not about technology, its about people actions. People forget or don't care to guard their property (private keys, in this case). This is common - people are negligent. There was a study several years ago, which revealed that a huge part (40-something %, if memory serves) of office workers shared their passwords for a chocolate bar. Why would they invest time and resources into guarding other one's secrets, if they don't guard their own?