It’s fun to stay at the C-M-I-S
Introduction to SAP HANA Cloud Platform, week 3
This week left me a bit confused. The first 2 sessions were about connectivity, while the rest was about CMIS. I had the impression that the JDBC sessions were misplaced and belonged to week 2, but for time reasons were lifted over to week 3. Nevertheless, the actual topic of week 3 was CMIS.
Anyone still remember the 2008 CMIS announcments (like this one)? Well, CMIS survived the last years (no surprise) and Hana Cloud supports CMIS. While the service is normally only accessible from inside HCP, Rui demonstrated a CMIS proxy servlet that lets you access the content repository from outside. He used the Apache Cemistry workbench to show that you can create folders, file and interact with them directly from your computer.
I am now wondering if this means that I can use the SAP HANA Cloud Document Service as a CMIS repository for my Alfresco or Liferay installations. The only application I need to have running is the CMIS proxy on HCP, right? I guess later I will try this out.
Talking about trying it out: the video for week 3 unit 3 comes with an interesting line:
“It is also very secure, so all the data transport is encrypted via HTTPS, and also the data storage is encrypted with the standard AES, so very safe and secure encryption.”
Very secure? Challenge accepted.
[Disclaimer: I am not a security expert. I also have no detailed information about the internals of HCP. I ran my test against hana.ondemand.com as this is an public available server that serves as the entry point to HCP. To me, this server should be 100% secure, as you send and receive sensitive information (like credentials). I executed the test on Wednesday (20/Nov/2013)]
Let’s take a look back at our beloved NSA and the statement that RC4 is hacked.
For now, assume that RC4 is hacked and that SAP wants to be aligned to German and European security guidelines.
How to check if a web server is using a secure certificate? Fortunately, there are free tools available to see if a web server uses RC4 or not, like:
https://www.ssllabs.com/ssltest/analyze.html?d=hana.ondemand.com Running the scan shows a very good result:
Looking at the details reveals:
That’s not so good, as RC4 is allowed and no Forward Secrecy.
RC4 is not anymore recommended (or here) and should therefore not used. Considering its weakness, a web server should not offer RC4. Forward Secrecy is something you want to have. It ensures that when an intruder gets the key to decrypt your current session, he can only read / encrypt the current session, but not any other session. Even when your earlier streams were saved by the intruder, the captured session key won’t help in decrypting the data. To take a closer look at the result I got by SSLlabs I used sslscan. SSL scan can give a list of what the server accepts.
sslscan hana.ondemand.com:443
AES and DES are also supported, not only RC4, that’s good. But the preferred cipher is RC4-SHA.
Connecting to the server shows which cipher is used, and it is RC4-SHA:
openssl s_client –connect hana.ondemand.com:443
To see if Forward Secrecy is supported, as I understand it, Diffie-Hellman needs to be used and not RSA. Let’s check this:
openssl s_client –ciper ‘ECDH:DH’ –connect hana.ondemand.com:443
Looks like Forward Secrecy is not supported.
In case you do not have the tools available, a simple tool to see what the server gives you is Google Chrome:
A site that uses Forward Secrecy is Gmail
For the web server running hana.ondemand.com I think the phrase very secure is a little bit exaggerated. Maybe a real security expert can jump in.
Other example: login.live.com
Hi Tobias,
Thanks for bringing up this interesting topic (cryptography and cryptoanalyses are always interesting 🙂 ).
Very good analyses, btw!
We, the HCP team, are aware of the pointed recommendations from https://www.ssllabs.com/ssltest/analyze.html?d=hana.ondemand.com, as we are doing continuous internal and regular external security testing. However, I see a big difference between a recommendation and an exaggerated statement like "RC4 is hacked". This can be seen in the details
link from the report. Also a quick test with prominent servers like https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com
shows the same recommendation, proving the usage of RC4 does not necessarily
imply security vulnerability on its own.
The situation with “forward secrecy” is similar – again, as described in the blog
linked from the report, not using a key exchange algorithm with perfect forward secrecy does not directly imply vulnerability. On the other hand those algorithms have side effects like missing support in browsers and increased performance overhead.
As there are a lot of crypto-related researches there is dynamics in the recommendations for SSL configuration. We will continue to monitor those
and if we foresee increased risk for HCP or its customers we will update the SSL configuration accordingly.
Regards,
Svetoslav
Hi Svetoslav,
Thanks in your interest in my finding and sharing some insights.
As stated in my blog, this is not an analysis done by someone that is a security expert. I just assumed that RC4 can be hacked in real time and is done by NSA. AFAIK no one actually knows IF this is true. If not, Applebaum throwed away quite some reputation.
In my preparation of the blog, I read some material and at least for the EU and Germany my understanding is that RC4 should be avoided where possible. Not sure if it can be avoided by HCP because of backward compatibility. What I did not understand is why my openssl client connected using RC4 and not something stronger. After all, HCP is offering other ciphers too.
Hi Tobias,
To motivate the low risk of RC4 usage in HCP, I must also say
that I am confident in the security measures we have done on application level, which mitigate. To list some (without revealing too much inside information):
- solid session management
- audit logging and intrusion detection / prevention which can detect and eventually stop probing attempts (the known attacks need a huge number of requests)
What I did not understand is why my openssl client connected using RC4 and not something stronger.
This is a matter of preferred algorithms (their order is part of the TLS configuration).
As seen from the report the most preferred suite from HCP is TLS_RSA_WITH_RC4_128_SHA (0x5). And this is the potential update I mentioned.
Hi,
here is an update on this topic.
As the risks related with RC4 based ciphers concern our customers we updated the TLS configuration.
Now the prefered ciphers by HCP (verified with https://www.ssllabs.com) are
This eliminates the risks and recommendations related to RC4 usage:
Regards,
Svetoslav