Taking a decision whether to use it or not requires some deep knowledge, because if its pros are clear – you can count on the salesmen to get a great picture of it again and again, its cons are silenced.

Too bad, a major disadvantage is security. But guess what? The other day an “analyst” presenting his study about cloud computing just cleared out the issue in 3 words :

“Concerning the people who doubt of the security in the cloud, it is a typical psychological issue of theses persons fearing change or something new . There is really nothing concrete to worry about cloud security.”

Well, not sure I am going to see a psychologist. Of course the guy did not give any solid argument, so here we go.

In short, cloud computing expose to the Internet services that were, in normal conditions, always kept inside an internal network and behind peripheral protections.

Of course, these services offer authentication, but basically almost every traditional web attacks will work as usual. After all, we are talking about the same web portal, the same users, the same browsers, etc.

Let quickly summarize the potential threats: CSRF, XSS, phishing, SSL attacks (MiTM, certificate spoofing),  browser exploits and many more.

So really, it is not a question of being crazy, paranoid or reluctant to change. There are just many issues that don’t make the cloud useless but should incite to caution.

Cloud computing can be used for what it is good at (flexibility, convenience) but not to replace a datacenter. It should not be used if security is a concern.

Don’t listen to the salesman only, read what some specialists are saying. Here is a compilation of some interesting articles I found :

• Black Hat 2009 presentation : pdf and summary
• Owasp presentation (pdf)
• Dangers in the cloud
• So you think *your* capability model is bad? (browser’s weak design)

And last but not least, in case our favorite salesman keeps pushy:

• Amazon EC2 vulnerabilities
• Salesforce phishing incident

But that’s not all. The same goes with “virtualization everywhere”, but that will be another topic…

But whereas some of these attacks concerns CA with insufficient security policies (md5 collisions) or some level of social engineering against the user (sslsniff), this paper alerts us on a more serious and stealth threat.

It explains brilliantly, providing us with real case scenarios, how a CA (probably under the authority of a government agency or a similar powerful organisation) can create a rogue certificate that will be silently trusted by our browsers.

The problem relies in the chain of trust : a root CA delegates trust to intermediate CA, which can at this point generate any “valid” certificate they want, even for a domain they shouldn’t sign.

Excerpt :

<< As an example, the Israeli government could compel StartCom, an Israeli CA to issue an intermediate CA certificate that falsely listed the country of the intermediate CA as the United States. This rogue intermediate CA would then be used to issue site certificates for subsequent surveillance activities. In this hypothetical scenario, let us imagine that the rogue CA issued a certificate for Bank Of America, whose actual certificate was issued by VeriSign in the United States. Were CertLock to simply evaluate the issuing CA’s country of the previously seen Bank of America certificate, and compare it to the issuing country of the rogue intermediate CA (falsely listed as the United States), CertLock would not detect the hijacking attempt. In order to detect such rogue intermediate CAs, a more thorough comparison must be conducted. >>

In such a case, no browser will ever send an alert, so even the most experienced and most paranoid users would be easily cheated. It makes it very easy for an agency to conduct a man-in-the-middle attack, sniffing all of the user activity.
So here is a need for an add-on.

As a Firefox user, I am using Certificate Patrol. It basically alerts the user whenever the certificate of a site changes. The inconvenience is that it requires a long learning period and it also generates quite a lot of false positive (when a certificate is renewed, for instance).

Adi Shamir and Phil Zimmerman, the author of the paper above, plan to publish a new add-on, Certlock. It will check carefully all the chain of trust for a certicate and send out an alert whenever a detail is incoherent, for instance when the country of the parent’s certificate is different from the country the rogue certificate is pretending to be.

I really hope Certlock is coming soon.

At least, the IETF agreed on a fix as Marsh Ray informs us, though it will still take some weeks for the whole validation process to complete.

Moreover, as it requires both the servers and the clients to be patched, it will take months before the patches can be applied and one can have a working client authentification architecture. The longest will be the client side, of course, so I feel sorry for those who have a large park to manage.

As far as I am concerned, fortunately, I will just have a few browsers that I manage directly to update. Anyway, still more patience is needed !

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

• low security by deactivating client authentication on your server
• low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general

PS 2 : bug reported on openSUSE bugzilla

MD5 or SHA-1 is the algorithm used to authenticate the peer in SSL messages. If it gets compromised, and using various combined technics, it becomes possible to do a MiM attack.

But too much noise has been made about it. There is a nice reaction.

Indeed, it still requires a lot of efforts and conditions for the attack to be possible. And the CPU power is still huge : the researchers used not less than a cluster of 200 PS3 to drive the attack. Even with that hardware and engineering, it took until 3 days of intensive computation.

Not everyone can afford it, nor would have much motivation to attack a single user like this.

Security has always been a compromise between usuability and risk. Today, the risk concerning MD5 is still low enough to stop this wind of panic.

Let’s begin the migration to SHA-1 quietly.

By default, Firefox 3 has a very annoying setting : it will prompt you with a box to select your certificate, every time the browser access to a file.

I quickly realized that there is not setting in the preference tab to change this behavior. That sucks, really !

Fortunately, it is possible to tweak it within the about:config page. Set the security.default_personal_cert entry with Select Automatically instead of Ask Every Time.

But what a dumb behavior !

It is like the alert page that Firefox displays every time a self-signed certificate is used. I am now wondering if the developers really understood well what a certificate is !

Setting Firefox properly for Client certificate

These commands should provide quite a good security level for a while (at least again non super-power governmental organizations) :

$ ssh-keygen -t rsa -b 4096
# openssl genrsa -aes256 -out secret.key 4096

I am the only person to use the server, so I don’t have any scallability issue.

Just to enforce the ssh configuration, I added these two line in sshd_config :

Protocol 2
HostKeyAlgorithms ssh-rsa

I have had no time so far to check all the keys on my server. I prefer to stay on the safe side, though I have some reason to believe that my keys might not be so vulnerable : I generated them a long time ago, maybe before the Debian maintainer sad mistake.

It is going to be pretty easy now, for those who are motivated, to get access to the ssh server running keys generated during the 2 last years…

I recommend this article which summarize pretty well the situation. You may also use this tool, which checks if your keys are vulnerable :

$  perl dowkd.pl file ~/.ssh/*.pub

It find it funny to think that I chose to use certificates for security (avoiding brute force attacks).
What’s less funny is the pure disaster for the reputation of Debian.

I already noticed in the past that some companies switched their servers from Debian to Red Hat because of such security problems. They claimed about some security holes being patch much too slowly and about the lack of official support to rely on in such a crisis.
This kind of news is not going to enforce trust from companies.

I myself will think twice in the future about what system to use when I design my networks.