Weekly Edition
Return to the Security page
| |||||||||||||
25C3: MD5 collisions crack CA certificate (heise online)
Researchers presenting at the 25th Chaos Communication Congress (25C3) have
used MD5
collisions to generate bogus, but trusted, SSL certificates as reported by heise online.
This would allow nefarious web sites to generate a certificate purporting
to be from any other site—greatly increasing the reach of phishing
and other scams. "Using a weakness in the MD5 cryptographic hash
function, which allows different messages to generate the same MD5 hash –
known as an MD5 'collision', the international team of Alexander Sotirov,
Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molinar, Dag Arne Osvik
and Benne De Weger, have used one attack scenario to create a certificate
which will be trusted by all browsers because it appears to be signed by
one of the root CAs that browsers trust by default. The certificate can
also be used to sign other certificates, which could allow attackers to
carry out 'practically undetectable phishing attacks'."
(Log in to post comments)
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 17:29 UTC (Wed) by rvfh (subscriber, #31018) [Link]
I did not read the article, but... I thought these certificates were signed using RSA keys? Or am I missing something?
If it is not the case, at least, you´d expect them to be signed with several keys, maybe MD5 + SHA1 + SHA256...
Not being a security expert, I might well be saying BS, so feel free to clarify...
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 17:39 UTC (Wed) by endecotp (guest, #36428) [Link]
There are a few CAs who use MD5 and so can be impersonated; most use something stronger.
We should probably stop trusting those CAs.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 19:28 UTC (Wed) by flewellyn (subscriber, #5047) [Link] According to the article, that might be problematic:The infrastructure of Certification Authorities is meant to prevent this kind of attack, but despite warnings, some root CAs are still using MD5, leaving people potentially exposed to the possibility of forged certificates. The team found the following CAs still using MD5; RapidSSL, FreeSSL, TC TrustCenter AG, RSA Data Security, Thawte and verisign.co.jp. They collected 30,000 certificates and found 9,000 of them were signed with MD5 and of them, 97 per cent were issued by RapidSSL. Because of this and other attributes of RapidSSL's procedures, such as use of sequential serial numbers in issued certificates, the researchers examined RapidSSL's certificates in greater depth.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 23:02 UTC (Wed) by jwb (guest, #15467) [Link]
It doesn't matter if it is "problematic" because the duty of Mozilla.org, Microsoft, Apple, et al, is to protect the users by only shipping the root certificates of compliant authorities. The browser vendors have no duty whatsoever to the holders of subordinate certificates.
It may be inconvenient for a few tens of thousands of certificate holders, but if they are really upset about it they can sue their CA.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 20:08 UTC (Wed) by jd (guest, #26381) [Link]
That might not be so easy. I'm seeing reports that Thawte and a couple of other major CAs use MD5s. At best, phishing scams will worsen, with browsers unable to tell the difference between the real site and a fake one in these cases.
Now, I'm also concerned about SASL. Cyrus SASL uses CRAM-MD5 and DIGEST-MD5, for example, and I don't see any mention of non-MD5 hash-based mechanisms within SASL as a whole. (It seems to be a choice of plaintext or MD5.) If - and it's a big if - the attack could also be used to compromise SASL, it'll be more troublesome. SSL already supports other hashes and so it's just a matter of disabling the broken mechanism. SASL would seem to require a much more extensive update at a much lower level. That means any update will take a lot longer before it becomes effective.
SASL is used virtually everywhere SSL isn't - LDAP and Kerberos, for example. Therefore, by implication, mechanisms that use any of these (such as MS' Active Directory which uses Kerberos), could be much less secure than conventional wisdom has believed.
It is unclear to me just how generalized this attack is, in terms of how many of the uses of MD5 are now vulnerable, but at this point can any MD5-based mechanism have any real credibility, even if this specific attack turns out not to affect it? Will MD5 users wait to be affected or will they be pro-active (for once)? Can major users of MD5 (like much of the financial world) afford to migrate away before things go from proof-of-concept to something worse? Will major users of MD5 even be aware that they are?
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 20:56 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
there is a difference here.
the CA certs use the MD5 to validate the plaintext and then make extensive use of the plaintext. and the plaintext can be an arbatrary length, but only some of it will have attention paied to it.
with authentication like SASL the size of the input is drasticly limited, and everything in it matters. this makes it _very_ hard to play the games that are being used to break MD5.
it's actually easier to just compute every possible legal input value and what the result of the hash is, then store the result on a few TB of disk space than to use the sort of attack making the news. and this sort of 'rainbow table' attack can be used no matter how strong or weak the hash is against being broken. the only defense against a rainbow is to have such a large variety of possible inputs that the table in so large as to be impractical
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 12:14 UTC (Thu) by mb (subscriber, #50428) [Link]
> the only defense against a rainbow is to have such a large variety of possible inputs that the table in so large as to be impractical
I don't think so. Salts are a pretty effective countermeasure against rainbow tables.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:14 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Salt increases the variety of possible inputs. You need to include all possible salt values along with the domain of "possible" passwords, for reasonable salt sizes this swamps any conceivable time-space tradeoff.
Perhaps you (mb) or dlang were misunderstanding, or perhaps your understandings passed without connecting.
A rainbow table is one kind of time/space tradeoff for multiple attacks on the same system. The effort E2 to make a reliable table is always strictly greater than the effort E1 to brute force a single hash of the same sort found by the table. If you use the table to break N passwords and E2 > E1 * N then you wasted resources by using Rainbow tables. This is why "public" projects to create shared tables are popular. And after all this, it can still take noticeable effort to use the Rainbow table to "look up" a password, since the nature of the table requires hash iterations to do the lookups.
dlang does the Rainbow Table's inventor wrong by associating a mere look-up table with the very much cleverer trick used in actual Rainbow Tables (go read up on them, it's a really good trick).
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 3:58 UTC (Thu) by iabervon (subscriber, #722) [Link]
In general, SASL is about providing an authenticating secret to a remote system. Both the server and an authentic client know the same secret. The server issues a challenge which is effectively a random seed. The client is required to append the password, hash the total, and send the result. The point of the hash is to make it infeasible to find the password given just the response. Finding an MD5 collision would enable an attacker to find a different challenge and password which would lead to the same response. That is, if the server has issued a different challenge, and the user had had a different password, the user could respond with the same value the user actually did respond with, and the server would have accepted it.
But, of course, this doesn't help the attacker at all, because the server will issue some third challenge next time, and the attacker's guess at the password won't work for that challenge. If the server issued any particular known challenge, then the attacker could authenticate simply by replaying the authentic client's observed response.
There hasn't been any particular progress at reversing the hash; that is, finding all of the texts that have a given hash. And finding some random single text that has a given hash isn't so interesting when it's just another wrong password which shares an obscure and strongly useless criterion with the real password.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:34 UTC (Thu) by danpb (subscriber, #4831) [Link]
There is no need to be worried about SASL in general. The main idea behind SASL is that it provides a generic authentication API / protocol for applications to use, into which you can plug many different auth mechanisms. As such Digest-MD5 is just one of very many auth mechanisms for SASL, others being plain password auth, Kerberos /GSSAPI, OTP, etc. Most of these mechanisms need to be used over a secure channel - typically provided by SSL/TLS. Kerberos though can provide channel encryption as well as authentication.
The CRAM-MD5 method has been considered obsolete for a long time and no one should be using it. DIGEST-MD5 is also in the process of being deprecated, and not just because of the flaws in MD5 itself - the mechanism itself has a number of problems in its spec. Read more here:
http://tools.ietf.org/html/draft-ietf-sasl-digest-to-hist...
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:48 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
MD5 is known weak for some time and you are advised not to use it for future applications, design it into new standards, or commission new embedded devices that rely on it. But it's not actually completely broken, only the hardest of the guarantees wanted from a cryptographic hash function has failed.
The broken guarantee is: It's too hard for anyone to create two documents A and B such that MD5(A) = MD5(B). This statement is no longer true.
It remains true that: It's too hard for anyone to take an arbitrary document X and create a new document Y such that MD5(X) = MD5(Y).
For now MD5 is only a risk for situations where untrusted people "prove" to you that they're showing you the same thing as they showed someone else earlier by providing the MD5 of a non-trivial document -- not the word "cat" or a telephone number, something long enough you (or the computer) would not really read all of it, like a PDF document, or an SSL certificate. In this case the break in MD5 can be used to insert gibberish that you'll skip over which changes document A into document B. In this case, the bad guys apply for a certificate for foo.example, and then use the CA's MD5 signature to create an undetectable fraudulent certificate for bar.example.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 15:28 UTC (Thu) by burki99 (subscriber, #17149) [Link]
Thank you very much for this illustrative comment!
And a Happy New Year to all lwn.net readers and writers. For me, this is one of the most helpful and well educated tech groups online and I really appreciate all your comments and explanations.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 18:40 UTC (Wed) by lambda (subscriber, #40735) [Link]
When you sign a message, what you do is take a secure digest of the message (such as MD5,
SHA-1, or one of the SHA-2 variants), and then encrypt that with your private key (using an algorithm like RSA), so that someone else can verify that you signed it by decrypting it with your public key, and comparing the resulting value with their own calculation of the digest of the message. So in this case, the certificate in question was signed with MD5 using RSA encryption.
The problem is that MD5 has been known to be broken since 2004. In 2007, someone
It would likely help if certificates could use multiple hash functions, but I don't believe that the
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 19:11 UTC (Wed) by epa (subscriber, #39769) [Link] It would likely help if certificates could use multiple hash functions, but I don't believe that the X.509 standard allows for that.If it allows interchangeable hash functions then simply define the function MD4+MD5+SHA1+SHA2 where the hash value is the concatenation of the different functions.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 19:35 UTC (Wed) by joey (subscriber, #328) [Link]
Concacenating hash functions is not generally belived to be more secure than just using the most secure of the functions by itself.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#...
(Note that Wikipedia is wrong about Debian package files -- the real reason we have multiple hashes in Packages files is that older versions of apt use the old, less secure hashes. Indeed, I just checked apt's code and if it finds a SHA256 in the Packages file, it only checks that one hash, ignoring SHA1 and MD5SUMs.)
Anyway, the actual flaw here is not cryptographic at all. It's that the CA system creates a series of centralized points of failure, who compete to make money by doing their job to the most limited extent possible.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 19:49 UTC (Wed) by martinfick (subscriber, #4455) [Link]
Concatenating multiple hash functions is not more secure than the most secure hash function, but it is likely more secure than the weakest hash function! That would deal with this problem nicely since you may not even know which is your most secure/weakest function. But it there is a weak one, it should not weaken the hole. If there is a very secure one, it should help make things more secure! It seems like putting in all the hash functions you can think of would help. As long as the reader trusts any one of the functions in the concatenation, they can probably trust the concatenation as a whole.
But, IANAC (I Am Not A Cryptographer)
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:16 UTC (Thu) by Los__D (guest, #15263) [Link] (Note that Wikipedia is wrong about Debian package files
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:17 UTC (Thu) by Los__D (guest, #15263) [Link]
Ah, just checked the history, and you (or someone else) already did, sorry 'bout that. :)
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 5:53 UTC (Fri) by ncm (subscriber, #165) [Link]
My experience suggests that there's little point to fixing any Wikipedia mistake that matters. If it matters, somebody else will come along and unfix it.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:26 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Yes, the CA business is a race to the bottom.
"Our certs cost $200 and we offer same day service - fax us an authorised purchase order and we'll call you. We use the strongest available cryptographic systems"
"Our certs cost just $150 and we offer a telephone service - call our hotline with your credit card. We use strong cryptographic systems"
"Our certs cost just $100 and we offer fast on-line service, just fill this web form out and you'll have a certificate in an hour. We use cryptographic systems"
"Our certs cost just $50 and service is instant. We check your credentials online during purchase. Our epayment site is SSL secured."
"Our certs cost just $10 and we only ask for your domain name & credit card details. Our Windows password is sesame"
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 13:44 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Setting up a CA costs next to nothing, creating a certificate a few pennies (OK, make that dollars if you want) apiece. What does cost real money (and a fixed amount at that) is getting it into MSIE, Firefox, et al. If you set up such a business, you'd want to rake in as much as possible, i.e., compete on end-user price (can't compete on quality, they are all the same; can't compete on "extra services"; "doing things right" is expensive and furthermore drives customers away). This sort of PKI is fundamentally flawed.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 16:05 UTC (Fri) by tbleher (guest, #48307) [Link]
> This sort of PKI is fundamentally flawed.
Like Matt Blaze once aptly said:
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 17:40 UTC (Thu) by epa (subscriber, #39769) [Link] Concacenating hash functions is not generally belived to be more secure than just using the most secure of the functions by itself.True. But how do you know which is the 'most secure'? If you concatenate hash functions A, B, and C, then you get a function at least as good as the most secure of those three, whichever it turns out to be. That is better than picking just one, however good it appears now, because some new flaw might be discovered in the future that affects one function but not all of them.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 6:23 UTC (Fri) by bvdm (guest, #42755) [Link]
There are multiple problems with concatenating hash functions.
The most obvious one is performance. Hashing is inherently computationally intensive.
Another problem is that, in signature schemes, a poor hash may leak information about your secret key. So you should avoid weak hashes, which translates into using the strongest one available.
At the moment there are a multitude of strong encryption algorithms available and a pitiful strong cryptographic hash functions. The SHA-3 competition will help address this, but in the mean time everyone should just move up to at least SHA-256.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 9:24 UTC (Fri) by ekj (guest, #1524) [Link]
You're right on performance. Generating 5 hashes and concatenating them takes on the order of 5 times as long as generating a single hash. This may or may not matter in practice. If I'm digitally signing an email-message I'm sending, I *really* don't care if my CPU spends 50ms or 250ms generating the secure hash of the content. Validating a SSL-certificate is done client-side and the typical client has very good cpu-power. (and does more cpu-intensive stuff such as rendering flash-applets anyway)
The problem with using only the strongest available hash is that you don't actually KNOW which hash will stand the test of time, and which hash will get broken tomorrow. You can guesstimate, but you don't actually know.
Composing hashes considered evil Posted Jan 2, 2009 13:18 UTC (Fri) by ketilmalde (guest, #18719) [Link]
I think the current story illustrates one problem with composing hash functions. Let's say you use two hash functions A and B to generate your hash function C defined as C(x) = A(B(x)). Now, every x and y that collide in B also collide in C, right? And similar, every x and y such that B(x) and B(y) collide in A will also collide in C. So in this respect, C is worse than either of A and B separately.
Composing hashes considered evil Posted Jan 2, 2009 14:21 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Your observation is taken as read in most discussion of hash functions. What you missed is that the original poster in this sub-thread was more specific - hash functions can be composed by concatenation, that is C(x) = A(x) . B(x) where . is the concatenation operator. This composition is not subject to the trivial collision problem you noticed but (as other posters mentioned) it has problems of its own, not least performance.
25C3: MD5 collisions crack CA certificate (heise online) Posted Dec 31, 2008 18:41 UTC (Wed) by kent (guest, #3834) [Link]
> I did not read the article, but... I thought these certificates were signed using RSA keys? Or am I missing something?
The RSA key of the CA is used to sign a message digest (MD5 or SHA1) of the certificate contents.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 1:10 UTC (Thu) by sitaram (subscriber, #5959) [Link]
On Firefox, I just went to about:config and typed "md5" in the search bar. I found only "security.ssl3.rsa_rc4_128_md5" was "true", so I changed it to false like the other 3.
I *think* this is a better and simpler solution than removing CA keys -- there are too many CAs involved plus if you remove the CA key you're refusing to trust their SHA1 signed certs also which is throwing the baby out with the bathwater.
However, I haven't seen this mentioned anywhere else, so I'm beginning to wonder if I'm wrong about this being a solution... Would be nice if someone who knew firefox config well could confirm that this would work!
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 1:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are wrong, that option has nothing to do with the certificates, it has to do with the encryption used within a session
public key encryption is extremely expensive to do, so you only use it when first connecting to a website, and using it you and the site create a random key for that session. you then use that key with a cheaper encryption algorithm.
nowdays you can probably get away with just enabling AES and 3DES (with 3DES only for sites that haven't updated in long enough that you need to question their security anyway ;-)
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 19:30 UTC (Thu) by cortana (subscriber, #24596) [Link]
That won't disable the use of MD5 in NSS. There is a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=471539 to disable the use of MD5 in future versions of NSS. Apparantly NSS also currently use MD2!
What's the big deal? Posted Jan 1, 2009 23:16 UTC (Thu) by khim (subscriber, #9252) [Link] Apparantly NSS also currently use MD2! What's the big deal with MD2? Surprisingly enough MD2 is more secure then MD5, not less! MD2 was (and is) quite secure, but sloooow. Thus MD4 was proposed as replacement. If was fast but insecure so MD5 was invented. Currently MD2 stands as more secure out of the three! SHA-2 is better but I'm not sure if even SHA-1 is more secure than MD2!!! The only know attack requires 2104 iterations of the "compression" function and it's pretty darn good if you'll recall that MD2 is 128bit long!
What's the big deal? Posted Jan 4, 2009 8:58 UTC (Sun) by ekj (guest, #1524) [Link]
2^104 to generate a message with a certain hash. But for this attack that isn't required, what is required is generating two different messages that nevertheless has the same hash.
Which is a lot easier due to the birthday-paradox. (for non crypto-nerds; consider that you'd need to on the average meet 185 people before you'd meet someone with YOUR birthday, yet you need only a group of 24 before it's likely (as in above 50% probability) that atleast 2 people share a birthday)
How hard is it to find a collision in md2 ?
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 14:15 UTC (Fri) by job (guest, #670) [Link]
A rogue CA can sign with any algorithm they like. You would have to modify the certificate chaining logic to be safe from this, which would break a large number of legitimate SSL certs.
Please remember that bad advice is worse than no advice.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 10:05 UTC (Thu) by harlekyn (guest, #9207) [Link]
For those of you interested in the original presentation: There're official stream captures available. Have a look here: http://events.ccc.de/congress/2008/wiki/Streaming#Real_Ti..., chose a mirror and then look in folder "saal1" for files with the tag "ID3023". They're available as OGM and WMV.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 14:19 UTC (Thu) by Los__D (guest, #15263) [Link]
What worries me the most, is that Mozilla isn't already scrambling to remove support (or at least making a warning) for all MD5-based CA-certs.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 1, 2009 21:01 UTC (Thu) by kune (guest, #172) [Link]
I were in the audience at the presentation at Tuesday.
They had two interesting statements: The bulk of the MD5 certificates are from RapidSSL, now owned by Verisign, and those certificates can be found on a third of all CA-signed web servers on the Internet.
A warning would not really be very effective if this is given on every third SSL website a user visits. One should also note that Firefox doesn't warn about the weak Debian keys, which are still used by some commercial websites. Though Firefox 3 warns about self-signed certificates. Apparently the Mozilla organisation doesn't want to affect the trust the public has into SSL and Certificate Authorities.
Technological I think that DNS must be extended to become an identity management system, which supports rapid changes of cryptographic primitives and withdrawal of signatures.
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 23:49 UTC (Fri) by Thue (subscriber, #14277) [Link]
There is a bugzilla bug suggesting to stop honoring md5 certificates here: https://bugzilla.mozilla.org/show_bug.cgi?id=471539
Just day "no" to hashing untrusted input! Posted Jan 1, 2009 22:53 UTC (Thu) by proski (subscriber, #104) [Link] We should try to be proactive and change the procedure so that a similar breakage in SHA-1 doesn't result in a similar exploit. In my opinion, hash functions should not be used to sign data provided by another party without adding random data by the signer.
Just day "no" to hashing untrusted input! Posted Jan 2, 2009 10:58 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
I agree (and so do the authors of this paper if you read it) that in theory SSL could be improved by adding an early prefix field with a random nonce chosen by the signer, but...
How do you ensure that these bits are random? Remember one problem is that the CAs - trusted parties essential to the security of the system - are somewhere on the spectrum of lazy/incompetent through negligent and have a commercial incentive to behave in the opposite way from that intended for their role in the security system. If it's easier to fill out the random field with all zeroes, some CA will probably do it.
Most CAs were using random (or apparently random) bits for serial numbers, making the exploit ineffective. RapidSSL certs were using sequential numbers in this field, and if they hadn't been this talk would presumably have included the caveat "this exploit isn't yet practical in the wild" and nothing would have been done about its security implications.
Really a business problem Posted Jan 2, 2009 14:22 UTC (Fri) by job (guest, #670) [Link]
There is also a more fundamental problem with the PKI model used by SSL, that CAs make their money from signing as many keys as possible. That does not reflect trust.
Really a business problem Posted Jan 2, 2009 18:02 UTC (Fri) by iabervon (subscriber, #722) [Link]
More fundamentally, the flaw with the X.509 PKI model is that CAs can't have any information about the entity whose certificate they're signed that's particularly helpful to the user in deciding whether to trust a site, and sites can't provide signatures by multiple authorities. That is, banks ought to have a signature from a suitable government regulatory body, businesses in general should have a signature from the jurisdiction where they're incorporated, and my site should have a signature from my CA cert, whose fingerprint I can put on my business card. Also, my bank's site certificate should have an additional signature by the bank's CA cert, whose fingerprint could be on my bank statements and my ATM card. Verisign's signature doesn't tell me anything very specific or useful, other than that if I happened to look at the URL, read it correctly, and recognize it as what I want, I'd know I was connected to that site.
Really a business problem Posted Jan 2, 2009 21:18 UTC (Fri) by proski (subscriber, #104) [Link] Hear, hear!
Really a business problem Posted Jan 3, 2009 9:03 UTC (Sat) by rks (guest, #55908) [Link]
Another fundamental problem: SSL is only as secure as the private key of the certificate key pair.
So the CA certifies that the private key was known to some entity at some time. If the key gets compromised (without revocation), too bad. The certificate is now worthless. Even worse, now it creates a false sense of security.
How many sysdmins will take the trouble to create a new certificate after a site was broken into, and also revoke the old certificate?
25C3: MD5 collisions crack CA certificate (heise online) Posted Jan 2, 2009 20:13 UTC (Fri) by Trou.fr (subscriber, #26289) [Link]
It looks like LWN certificate is signed using RapidSSL's CA :(
Wireless credit card requests Posted Jan 4, 2009 8:24 UTC (Sun) by hazelsct (guest, #3659) [Link]
Wow. Another argument against trusting wireless hotspots requiring credit card entry into a website. If it's this easy to forge a legit SSL cert, then anyone with a laptop can walk in and fake a legit hotspot, and even grant access through the real one -- after charging the credit card a few (hundred) bucks extra.
I hope the airports and other public spaces will listen up and change their wireless business model to something less prone to fraud...
Then again, what other revenue model is there? Pay at the counter for a scratch-off card with a password? Unwieldy and dependent on physical media - ugh.
Wireless credit card requests Posted Jan 4, 2009 9:11 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
"this easy" ? "anyone with a laptop" ?
The authors describe this is a fairly difficult exploit which (since their paper doesn't reveal the exact methods they used) they believe could be reproduced by experienced cryptanalysts in a few weeks given the same conditions. These conditions include ordering a suspicious number of certificates from a known weak provider, of which there was only one (RapidSSL) which has now closed the window of vulnerability.
This is a very serious problem, but the sky isn't falling.
Your suggested method of exploitation involves an accredited merchant abusing the credit card system, which means all the customers affected would be refunded, and the merchant would be prosecuted for fraud. That also doesn't sound like something "anyone with a laptop" can get away with.
|
|||||||||||||