Secure Socket Layer is Compromised
My posting here has been sparse.
Part of the reason for that is I have been working on a submission to the NIST SHA-3 Competition. My algorithm, WaMM, has the ignoble honor of being the first weak sister to go down in the hash algorithm cage match. To monitor the details of the competition I recommend the SHA-3 Zoo.
This theoretical world of cryptographic hashes has real-world applications. One of those real world applications is the transport layer security (TLS) or secure socket layer (SSL) (aka TLS/SSL). The preceding sentence is best described as the little lock icon you see when you are doing your online banking.
Here is a screen shot
from the web site of Guaranty Banking. I am not picking on Guaranty; the SSL is used by Wells Fargo and Bank of America as well. Here is an excerpt from the BoA Security Guaranty
The TLS/SSL is your assurance from your bank, online store, or government that your private information can be safely broadcast across the internet. The value of that guarantee took a serious hit on December 30, 2008.
At the 25th Annual Chaos Communications the team led by Alexander Sotirov has published this paper announcing the creation of a rouge Certification Authority Certificate (CA Certificate).
Anyone with a rogue CA certificate can impersonate any website which uses certification authorities (CA's) for SSL connection; Think eBay, BoA, and www.Widgetsonline.com
The paper has two excellent pictures. The first is how the SSL uses the CA certificate under normal conditions. The second picture is how the rouge CA certificate can be used to attack the SSL connection.
What this means to Wells Fargo and Bank of America is that it is now possible for someone other than them to create a website which can impersonate the Wells Fargo or Bank of America website. With the rogue CA certificate the impersonation goes so far as to present a bogus CA certificate which the TSL/SSL on your web browser cannot distinguish from the legitimate Wells Fargo or BoA certificate.
What this means to you is that if you previous placed blind trust in the little lock icon, then stop that. The lock used in the icon now has a master key which can open the lock in many commercial settings.
The rogue certificate takes advantage of the poisoned message attack by exploiting the know hash collision problem in the MD5 hash algorithm.
For years people have been recommending the MD5 hash be dropped from the CA certificate specification and that all MD5-based certificates be revoked. The response has been the usual two.
These responses were given even after Peter Selinger published in 2006 this demonstration of the danger posed by MD5 hash collisions.
As you can see this was problem two years in the making. Now VeriSign, BoA, and most online retailers will need to get new certificates which use the stronger SHA-1 hash instead of the broken MD5 hash. Here is a survey of the CA certificates used on several popular sites. Any of the sites listed with MD5 should now be considered broken.
But, this raises a larger epistemology question.
People would then know to shun any site where:
My modest proposal would help by providing three simple data upon which a customer can decide a complicated trust issue. The current model is the usual bureaucratic one; trust us because some Authority vouches for us. My small suggestion is more in keeping with the PGP model: What evidence do you need in order to trust us? Here it is...
The difference is transparency and who makes the ultimate decision to extend or withhold trust:
Part of the reason for that is I have been working on a submission to the NIST SHA-3 Competition. My algorithm, WaMM, has the ignoble honor of being the first weak sister to go down in the hash algorithm cage match. To monitor the details of the competition I recommend the SHA-3 Zoo.
This theoretical world of cryptographic hashes has real-world applications. One of those real world applications is the transport layer security (TLS) or secure socket layer (SSL) (aka TLS/SSL). The preceding sentence is best described as the little lock icon you see when you are doing your online banking.
Here is a screen shot
from the web site of Guaranty Banking. I am not picking on Guaranty; the SSL is used by Wells Fargo and Bank of America as well. Here is an excerpt from the BoA Security Guaranty
Whenever personal information is requested or displayed on our Web site we use encryption technology, such as Secure Socket Layer (SSL), to prevent unauthorized access to data
The TLS/SSL is your assurance from your bank, online store, or government that your private information can be safely broadcast across the internet. The value of that guarantee took a serious hit on December 30, 2008.
At the 25th Annual Chaos Communications the team led by Alexander Sotirov has published this paper announcing the creation of a rouge Certification Authority Certificate (CA Certificate).
Anyone with a rogue CA certificate can impersonate any website which uses certification authorities (CA's) for SSL connection; Think eBay, BoA, and www.Widgetsonline.com
The paper has two excellent pictures. The first is how the SSL uses the CA certificate under normal conditions. The second picture is how the rouge CA certificate can be used to attack the SSL connection.
What this means to Wells Fargo and Bank of America is that it is now possible for someone other than them to create a website which can impersonate the Wells Fargo or Bank of America website. With the rogue CA certificate the impersonation goes so far as to present a bogus CA certificate which the TSL/SSL on your web browser cannot distinguish from the legitimate Wells Fargo or BoA certificate.
What this means to you is that if you previous placed blind trust in the little lock icon, then stop that. The lock used in the icon now has a master key which can open the lock in many commercial settings.
The rogue certificate takes advantage of the poisoned message attack by exploiting the know hash collision problem in the MD5 hash algorithm.
For years people have been recommending the MD5 hash be dropped from the CA certificate specification and that all MD5-based certificates be revoked. The response has been the usual two.
That vulnerability is completely theoretical.
It would be too expensive to upgrade a working system because of a theoretical problem.
These responses were given even after Peter Selinger published in 2006 this demonstration of the danger posed by MD5 hash collisions.
As you can see this was problem two years in the making. Now VeriSign, BoA, and most online retailers will need to get new certificates which use the stronger SHA-1 hash instead of the broken MD5 hash. Here is a survey of the CA certificates used on several popular sites. Any of the sites listed with MD5 should now be considered broken.
But, this raises a larger epistemology question.
- How do you know who uses what combination of encryption and hashing?
- How do you know what you know in order to decide if trust is warranted?
People would then know to shun any site where:
- the encryption algorithm is not AES160, AES192, AES224, or AES256.
- The hash algorithm is not SHA or better.
- The public key bit length is less than 2048
My modest proposal would help by providing three simple data upon which a customer can decide a complicated trust issue. The current model is the usual bureaucratic one; trust us because some Authority vouches for us. My small suggestion is more in keeping with the PGP model: What evidence do you need in order to trust us? Here it is...
The difference is transparency and who makes the ultimate decision to extend or withhold trust:
- An opaque system where trust is decided by an unknown Authority, or
- a more transparent system where trust is given or withheld by the individual
posted by John Washburn | 7:41 PM
3 Comments:
The problem of course is that for 95% of users, those three points of information are rather useless.
In fact, for more than 50% of users, they probably don't even bother to look for the lock icon!
Thats why IE7 and Firefox 3 included the Green/Yellow/Red in the taskbar... to make it more visually noticable when something is phishy.
I would suggest that the green/yellow/red algorithm needs to be changed based on this new information.
True, the information would be useless to most.
But, most users could ask their pet geek what the minimum acceptable values are. My suggestion to my mom would be:
Always look for the lock.
You must see the letters: AES
You must see the letters: SHA
You must see a number 2048 or bigger
I like the red/yellow/green approach as well, but I don't get to add to the red/green/yellow determination. The Firefox and MS developers decide what an acceptable risk is for me.
If I could add or download something akin to:
if CA-Hash = MD5 then RED
if CA-Hash = SHA then YELLOW
if CA-Hash = SHA-2 then GREEN
if CA-Encrypt like *DES* then RED
if CA-Encrypt like RC* then RED
if CA-BitLength < 1024 then RED
if CA-BitLength < 2048 then YELLOW
if CA-BitLength >= 2048 then GREEN
The browser bar would show red, yellow, or green based on the LOWEST assignment given. The color designation then is based on a mixture of the considered judgment of the security developers for IE and Firefox as well as the additional security concerns of a user or their tech savvy child.
Also if the bar is red or yellow, how do I drill down to see why the site is flagged as yellow or red?
Again I may be comfortable with a yellow site if know WHY it is flagged as yellow. How do I acquire the info to decide?
Interesting, thanks for the post.
Post a Comment
<< Home