therube
join:2004-11-11
Randallstown, MD | reply to TKJunkMail
Re: SSL security flaw with MD5 certificates announces today
hackademix.net: Putting SSL in Perspectives |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
 ·AT&T U-Verse
 ·AT&T Midwest
| reply to mysec
Mostly, you depend on the reliability of your DNS servers.
The certificate flaw will not be easy to exploit. I am not panicking over this one. I'm taking the advisory as mainly advice to certificate issuers to change their practices.
--
AT&T dsl; Westell 327w modem/router; openSuSE 11.0; firefox 3.0.5 |
|
TKJunkMail
Enjoy the sun
Premium
join:2002-03-03
Avalon, NJ
 ·Sprint Mobile Broa..
 ·Comcast
| reply to therube
Good link. I have been using Perspectives Add-on in Firefox for a couple months now.
--
My BLOG .. .. Internet News .. .. My Web Page
Ask yourself one question: 'Do I feel lucky?' Well, do ya punk? |
|
FiOS Dan
Premium
join:2001-07-06
Redondo Beach, CA
·Verizon FIOS
| reply to nwrickert
said by nwrickert  :The type of redirection that is a concern is the one done by DNS that the browser does not even know about. If you go to the bank site, and there is a browser redirection, that is specified by the bank site. You really do want to follow that redirect. Is it not true that a site can be hacked and the hackers can insert a redirect at that point rather than through DNS?
--
Courage is being scared to death but saddling up anyway.
|
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| Is it not true that a site can be hacked and the hackers can insert a redirect at that point rather than through DNS? If they hack your bank site, all is lost anyway. Whether the hack uses a redirect or a malicious web page at the site, the risk is the same.
--
AT&T dsl; Westell 327w modem/router; openSuSE 11.0; firefox 3.0.5 |
|
Kiwi
Premium
join:2003-05-26
USA
·Comcast
·Aristotle Internet
| reply to Steve
That's a pretty good explanation for those wishing to learn a thing or two and in spite of the MD5 from hell scare going on; anybody with an interest can easily tell this is getting blown into a mountain. MD5 and hash checks have been around for years and so have the holes, nothing new here.
First line of defence is not an MD5 correlation, particularly in the business world; it's just another layer. |
|
La Luna
Surviving Ashraful
Premium
join:2001-07-12
Warwick, NY
clubs:
·Optimum Online
 ·Vonage
| reply to TKJunkMail
said by TKJunkMail :Good link. I have been using Perspectives Add-on in Firefox for a couple months now. That add on made the news here a few months ago, I'm sure you remember as you posted. 
»New Firefox Extension Thwarts MITM Attacks
--
1/20/09 The Beginning of the End
12,489 DEADLY TERROR ATTACKS SINCE 9/11 |
|
TSI Gabe
Premium,VIP
join:2007-01-03
Chatham, ON
| Either way, it's not just a matter of generating an MD5 hash that matches the SSL cert, it's about generating ANOTHER SSL cert that looks the same that would generate the same MD5 hash. While I agree that MD5 isn't exactly secure anymore the mathematical possibility of generating a valid cert that would generate the same MD5 hash is slim at best. |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| For hashing strings:
Given a string, find another credible string with the same MD5 hash: this is still a difficult problem.
Find two strings with the same MD5 hash. This can be done (has been done).
For certificates:
Given a certificate, find another certificate that will generate the same MD5 hash. This is still a difficult problem.
Find two certificate requests, such that the two certificates will have the same hash. This is presumably an easier problem.
It's the second of these that the exploit security flaw is about. If you can generate two certificate requests that will have the same hash, then you have the CA sign one, and copy that signature into the other.
What I don't quite understand about this, is that while signing the certificate the CA makes some editorial changes to the certificate content. These include inserting a serial number and start and expire dates. If these changes are included in what is hashed for the signature, then that would seem to disrupt the method of attack - unless the attacker can predict this data. Maybe serial and date info are not in the signature hash, but that would be a surprising weakness if true.
--
AT&T dsl; Westell 327w modem/router; openSuSE 11.0; firefox 3.0.5 |
|
Graycode
join:2006-04-17
·net2phone
1 edit | said by nwrickert :What I don't quite understand about this, is that while signing the certificate the CA makes some editorial changes to the certificate content. These include inserting a serial number and start and expire dates. If these changes are included in what is hashed for the signature, then that would seem to disrupt the method of attack - unless the attacker can predict this data. Maybe serial and date info are not in the signature hash, but that would be a surprising weakness if true. You may be exactly right about the serial. The following is by Eric Rescorla, author of recent TLS versions.
»www.educatedguesswork.org/2008/1···t_a.html
quote:
The relevance of the serialNumber is this: unlike the name and the public key, the serialNumber and validity are generated by the CA. So, you need to know in advance what they will be in order to generate the appropriate colliding "bad" certificate. The validity is typically just generated as something like a year or two from the time of issue, so it's relatively predictable. The CA has a lot of freedom in how to generate the serial number. If it's truly a sequence number, it's quite predictable. However, if it's randomly generated, then it can be made arbitrarily unpredictable, which effectively blocks this kind of collision attack. When MD5 collisions were first discovered, the two standard recommendations were (1) stop using MD5 and (2) generate random serial numbers.
...
Bottom Line
As usual, don't panic. In its current state, this is more of a demonstration of a hole than a serious hole. Countermeasures are readily available to the CAs and if the remaining CAs fix their practices fast enough, then it's unlikely that there will be any more bad certificates issued ...
|
|
mysec
Premium
join:2005-11-29
| "This morning's MD5 attack - resolved"
»www.win.tue.nl/hashclash/rogue-ca/
Verisign, the owner of the RapidSSL brand, has immediately responded when our work became public. See the announcement "This morning's MD5 attack - resolved" by Tim Callan. Some interesting quotes from this blog: • "We applaud security research of this sort and are glad that white hats like the "MD5 Collision Inc." group make a point of investigating online security."
• "We have discontinued using MD5 when we issue RapidSSL certificates, and we've confirmed that all other SSL Certificates we sell are not vulnerable to this attack. We'll continue on our path to discontinue MD5 in all end entity certificates by the end of January, 2009."
• "... any customer who would like to do so can replace any MD5-hashed certificate free of charge."
|
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| reply to Graycode
Re: SSL security flaw with MD5 certificates announces today
That's a good reference.
When a CA is doing some investigation to approve a certificate, that will take time. As a result the validity times will be harder to predict. Apparently the demonstration used RapidShare, which generates certificates on the spot. That makes the validity more easily predictable. And presumably the serial can be predictable if done sequentially.
It seems to me that a CA could:
randomize the serial numer;
randomize the validity (adding a few random days, with random hour/minute specified) expiration time.
randomize the validity start time, by backdating the start by a random amount of time from the present.
Such steps would make it far harder to exploit this. However, moving away from MD5 is certainly advisable too.
Even with one of these certificates, you could probably only use that effectively in an MITM attack. And there are many other difficulties involved in launching an MITM attack.
My conclusion: there's no need to panick about this. It isn't practical as a general threat. It is perhaps more of a threat to specialized system known to have valuable data, and worth the expense of attempting to exploit it. But, mostly, it serves as a reminder that it is time to phase out the use of MD5.
--
AT&T dsl; Westell 327w modem/router; openSuSE 11.0; firefox 3.0.5 |
|
TKJunkMail
Enjoy the sun
Premium
join:2002-03-03
Avalon, NJ
·Sprint Mobile Broa..
·Comcast
| reply to TKJunkMail
said by TKJunkMail :Good link. I have been using Perspectives Add-on in Firefox for a couple months now. The Perspectives team has created a web page about this exploit and how their "Perspectives" Firefox add-on can help:
»www.cs.cmu.edu/~perspectives/md5.html
--
My BLOG .. .. Internet News .. .. My Web Page
Ask yourself one question: 'Do I feel lucky?' Well, do ya punk? |
|
Khaine
join:2003-03-03
Australia
| reply to TKJunkMail
Doesn't this just prove that the centralised model of trust is deeply flawed and that end users should not trust CAs? Afterall MD5 has been considered insecure for long enough that it should not be used as a cryptographic hash, and yet some CAs are still using it. |
|
mysec
Premium
join:2005-11-29
| reply to TKJunkMail
said by article :
Let’s look at an example were a rogue CA is used maliciously to generate a certificate for www.google.com . The attacker hijacks your web connection while you are using wireless and impersonates google using the malicious certificate.
To allow Perspectives to detect these attacks, you must instruct it to contact Notaries for all HTTPS sites, even if your browser considers the certificate valid.
Two questions:
1) For those using wireless, please explain how this takes place.
2) Why use as an example, google.com, which is not https?
thanks,
----
rich |
|
NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
Murfreesboro, TN
·AT&T Southeast
·Vonage
·Cingular Wireless
·AT&T CallVantage
| reply to Khaine
said by Khaine :Doesn't this just prove that the centralised model of trust is deeply flawed and that end users should not trust CAs? Afterall MD5 has been considered insecure for long enough that it should not be used as a cryptographic hash, and yet some CAs are still using it. It also shows that some browser suppliers (Mozilla) compound the confusion by showing an MD5 fingerprint for certificates that use SHA-1 With RSA Encryption.
--
A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.
»portscan.dcs-net.net
»nature-pics.com |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| reply to Khaine
Doesn't this just prove that the centralised model of trust is deeply flawed and that end users should not trust CAs? For sure, it provides additional evidence against the trust model used.
--
AT&T dsl; Westell 327w modem/router; openSuSE 11.0; firefox 3.0.5 |
|
TKJunkMail
Enjoy the sun
Premium
join:2002-03-03
Avalon, NJ
·Sprint Mobile Broa..
·Comcast
| reply to mysec
said by mysec :Two questions: 1) For those using wireless, please explain how this takes place. 2) Why use as an example, google.com, which is not https? thanks, ---- rich # 1 can be accomplished with what is known as a "Man In The Middle" attack.
»en.wikipedia.org/wiki/Man_in_the···e_attack
& specifically a wireless attack:
»en.wikipedia.org/wiki/Man_in_the···Examples
# 2 - Google does use https for their gmail product:
»https://mail.google.com/mail/#inbox
--
My BLOG .. .. Internet News .. .. My Web Page
Ask yourself one question: 'Do I feel lucky?' Well, do ya punk? |
|
mysec
Premium
join:2005-11-29
2 edits | OK, thanks.
EDIT: I've removed my response and examples to protect, since they referred to classic pharming and DNS poisoning, and not to MITM, as TheWiseGuy clarified.
----
rich |
|
TheWiseGuy
Dog And Butterfly
Premium,MVM
join:2002-07-04
Yonkers, NY
| To hijack your connection via wireless to me implies you are not at home using a secure encryption protocol such as WPA to connect to the router but using a hotspot.
In your previous post you discussed redirection and DNS but a MITM does not involve either and IMO is the bigger risk.
At a hotspot an Evil twin would allow a MITM and the DNS addresses to the secure sites would not be changed. When using a wireless hotspot SSL would tend to be secure even against a MITM if you can trust the certificates. If certificates were/are compromised then you can not even trust connecting via SSL, from a hotspot.
Another worry not just at a hotspot is the possibility that someone "exploits the internet routing protocol" to create a MITM to some Brokerage or Banking sites.
While preventing redirection or DNS poisoning may mitigate the risk it will not at least IMO reduce the real problems.
--
Warning, If you post nonsense and use misinformation and are here to argue based on those methods, you will be put on ignore. |
|
