Recently I came across a very interesting discussion about SSL. As ecommerce and internet has becoming very integrated to our daily lives, likewise security technology has been very critical as well. SSL has been a very common “tools” that’s available to us when making transaction online.
Sadly as SSL in general has some quite a lot significance weakness (Be it directly or indirectly), both auditors and hackers would love to use that as a gateway to gain insider access to your info. And these were brought out recently and it took me back to books, scan thru multiple website, forums etc to recap my understanding again… Below are the screenshot captured from openssl command “openssl s_client –connect targetedwebsite.com:443”:
issuer=/C=ZA/O=XXXX Consulting (Pty) Ltd./CN= XXXX CA --- No client certificate CA names sent --- SSL handshake has read 1948 bytes and written 431 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD Session-ID: 123J12312K3HFWOIUYQWEWQEWQEWQEWQEWEQWEQW98321412ELKQJDWQL Session-ID-ctx: Master-Key: 1DSADARQREWQD23J12312K3HFWASFDASADSAOIUY98321412ELKQJDWQL Key-Arg : None Start Time: 1286461898 Timeout : 300 (sec) |
Above was partial paste result and it was highlighted with 2 issues:
Website’s SSL Cert was signed with weaker cipher key strength. (Claimed to be signed using RC4-MD5)
Weaker cipher was allowed. MD5 was known to be prompt to collision attack.
I will discuss this further from different point of views:
· Views and assessment from IT Security angle
· Views and assessment from Risk Assessment angle
Website’s SSL Cert was signed with weaker cipher key strength. (Claimed to be signed using RC4-MD5)
From technie’s view: Now above statement is incorrect. Since this weakness has been made known, Major, if not all CA has stopped using such cipher to to be used its client certification. Go to one of the following site to verify and double verify again. Therefore this notion is incorrect.
From Risk Assessment’s view: As above stated, all certification has been using SHA1/2 to sign it. So there should not be a concern here.
Weaker cipher was allowed. MD5 was known to be prompt to collision attack.
From technie’s view: This should be consider as a major weakness as any transaction made to the website may or may not be secure enough. As a user to this website, you may be wondering if my information has been leaked. Think about any secret I shared with you are also been sniffed by a 3rd party. If that’s the case, how can I trust you again??
From Risk Assessment’s view: Now if you view from risk assessment, there’s various angle to see this issue.
· Risk pertaining to affecting users
· Risk pertaining to the business of the provider.
· Risk pertaining to the weakness itself
From user point of view, yes it’s a risk which has been explained previously. If my connection is not secured, how can I be sure my information is not leaked? However there’s no need to be alarmed as most browser will alert you when a low grade ssl cert is been used. But MD5 is a weakness by itself – What can I do? I will discuss this later but basically there’s nothing much a user can do (Not that I know of from browser) as this is most likely defined by the provider.
Now on risk to the business - Frankly speaking, there’s very minimum risk as this is very closely to user. This is a one to one issue where only 1 particular sessions is compromised when session is highjack. So unless there’s some mandatory requirement from the authority – Don’t bet on the provider to do something for you. (I remember PCI has certain requirement but I need to read up on this) The only hope you have or driving force would be: Provider are very particular on its reputation.
Now on the weakness itself – RC4-MD5 are a weakness which no one will deny it. However lets look from a deeper angle:
· Chances of sessions been compromised. We are talking about the possibility here.
o 1st – The session has be active before it got compromised. If the average session of each user is say 30min but successful attack takes about 1 hr – Then risk is still acceptable.
o 2nd - The cipher itself is a weakness but by increasing the bit length, it actually slow down/reduce the possibility of session been cracked.
o 3rd - Understanding on the possibility to make such attacks possible – Now this is a key here.. As a attacker, you need to 1st able to gain access to the sessions either by Man in the Middle or took over the user’s pc directly. So chances are still low. Of course this still depends on the user. Again how easy is this to happen? It's a Yes or No answer. But again attacker must have at very least decent knowledge on how to achieve this
On risk pertaining to the business of the provider - The only risk that the business management will see is still to its reputation. So it vary on the risk taker of the management
Lastly on risk pertaining to the weakness itself – As mentioned above, yes there’s risk but not high. As for now, this cipher is not considered low. Therefore base on the current industry practice’s view, the push factor to stop supporting this is not high.
Personally, I would say it boil down to 1 statement – Due diligence and social responsibilities of the company. If one is only keen to “compliance” to regulation, then there’s no wrong at all for not enforcing a higher standard. However if one feel best practice is way on how business run, they should restrict it.
