New OpenSSL Man-in-the-Middle Flaw Affects All Clients 217
Trailrunner7 (1100399) writes 'There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software. The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That's not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle. Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.'
Key phrase of vulnerability : (Score:2, Informative)
"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"
Re:Key phrase of vulnerability : (Score:5, Insightful)
"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"
As will always be. Any attempt at security by involving the end user is a recipe for failure.
We're doomed.
Re: Key phrase of vulnerability : (Score:2, Interesting)
No, we just need software that isn't a pile of accreted crap.
Cue LibreSSL. Not a moment too soon. Those guys should be paid to do ALL critical security software, because when they do something, they do it RIGHT.
Re: Key phrase of vulnerability : (Score:4, Insightful)
How does LibreSSL fix users who do stupid things? This I'd like to know...
Re: Key phrase of vulnerability : (Score:5, Funny)
LibreSSL does not yet have any users.
Re: Key phrase of vulnerability : (Score:5, Funny)
So it is 100% save!! Yay!! ;-)
Neat (Score:5, Insightful)
But if you have a man in the middle position, most of those same users would have just clicked "ignore" or typed yes to the "connect anyway" prompt.
Re:Neat (Score:4, Informative)
The summary is actually ridiculous.
The summary suggests SSL is useful without a man-in-the-middle. SSL protects against eaves droppers on your network; but any eaves dropper can become a MITM. ARP cache poisoning is a common technique; on switched networks, you cannot eaves drop without ARP cache poisoning or ARP flooding. Hubbed networks are similarly easy: packet the target with IP=DEFAUTGATEWAY MAC=YOU and it will start addressing default gateway packets to you (routing works by putting the destination IP on a packet, but the default gateway's MAC on the frame; you enter the IP address of the router, and the OS runs an ARP request to find its MAC).
It's entirely unlikely that SSL does anything if there isn't a man in the middle.
Re: (Score:3)
And yet everyone threw a hissy fit when Firefox first made it a massive PITA to use self-signed / untrusted certs.
Honestly their implementation is pretty good; you can get through it, but blindly clicking will result in the cert being rejected.
Re: (Score:3, Insightful)
Speed limits are overly conservative, and it is entirely possible to drive fast and drive safely. Risk increases, but driver ability modifies the risk. Good brakes are even more important in such situations.
I don't pay much attention to speed limits. The signs are posted miles apart and easy to miss; I drive with the flow of traffic, slowing down when there is additional risk. Additional risk includes traffic calming zones (whether zoned properly or not), e.g., residential areas with street parking and
Re: (Score:2)
Speed limits are overly conservative, and it is entirely possible to drive fast and drive safely. [...]
I don't pay much attention to speed limits. [...] slowing down when there is additional risk. Additional risk includes [...]
You are a dangerous idiot. Quite ofthen the speed limit is not to protect you, but others. Quite often the (low) speed limit is due to "addition risk", a risk that might be difficult or impossible for the driver to see. Which you have decided to neglect, because you think you are a "better driver". Hint: your reaction time is most likely not significantly smaller than others.
Re:Neat (Score:4, Insightful)
Society is asking you to follow the law, not to interpret or judge its validity.
Sorry, wrong. Society is asking you drive safely and responsibly. Following the law helps, but not every time, not every circumstance.
Versions (Score:3, Insightful)
Just to be clear, versions 1.01 and 1.02(beta) is the same as saying "Any OpenSSL version released since early 2012", right? It sounds like the summary is trying to downplay the threat a little bit.
Re:Versions (Score:5, Informative)
That's right, it affects all versions that are anywhere close to current.
Re: (Score:2, Interesting)
especially after everyone panic-upgraded after heartbleed.
Re:Versions (Score:4, Insightful)
You can leave out the "panic". Everyone upgraded. Appropriately. No need for the over-sensationalism.
Re: (Score:2)
That's not necessarily true. People may have "panic upgraded" who were using a supported and up-to-date (and not vulnerable) 0.9.8. People may have "panic upgraded" by building and installing the latest OpenSSL, not knowing that their distribution had pushed out a patched version of the version they had been running. Now, their OpenSSL might be totally outside of package management, and they could really be in trouble for this one, unless they're paying a lot of attention (which they aren't, or they woul
Re: (Score:3)
Re: Versions (Score:3, Informative)
There are also stable releases of 0.9.8 and 1.0.0 which are still maintained for security updates. Many long-term-stable distros and even some recent network appliances don't use 1.0.1 because of the possibility that code churn and feature dev has made it less secure than 1.0.0. In this case they would be right.
Re: (Score:2)
Yup, our Linux based application firewall uses a security maintained 0.9.8 based build so we weren't affected by heartbleed. It looks like we'll need to make sure it's patched to 0.9.8za level to avoid the possibility of this being an issue.
This is awesome (Score:5, Insightful)
Re: (Score:3)
Re:This is awesome (Score:5, Informative)
OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases.
Well, the LibreSSL project is ripping out much of the code and rebuilding it: http://www.libressl.org/
I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?
Ummm, your private key should be randomly generated, otherwise public key encryption doesn't work too well.
But your private key doesn't change, so that isn't a good thing to do. Fixing the entropy is one of the many things LibreSSL is doing: http://www.openbsd.org/papers/bsdcan14-libressl/mgp00016.html
Re: (Score:2)
Re: (Score:2)
I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?
Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.
Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?
When functioning properly you shouldn't be able to extract anything except entropy from pool. It is surely possible to weaken a pool by providing known data. Likewise a pool initialized in a
Re: (Score:2)
How is it adding entropy to the pool if you keep using the same private key as one of the inputs?
Re: (Score:3)
Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.
Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?
When functioning properly you shouldn't be able to extract anything except entropy from pool.
Emphasis mine. Putting it in the pool is yet another attack vector, and a great way to increase the chance of something going wrong down the line. Either by mistake or by a planned malicious code change in parts of the code that doesn't seem to have anything to do with the private key.
Re: (Score:2)
Seeding the random source using a private key looks like the same concept as using your encrypted root passwords to seed the TCP sequence numbers. This is not a new concept.
Re: (Score:3)
it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.
Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.
Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.
Re: (Score:2)
it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.
Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.
Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.
Wasn't the TrueCrypt announcement a form of warrant canary?
Re: (Score:2)
Noone knows. Its best to form your own opinion, and if you feel like sharing it with others, to be explicit that it is just an opinion.
The official word is that they "got bored" according to someone who "emailed the devs".
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Another case in point: OpenSSL, which had, until recently, only enough resources for 1 or 2 developers.
Re:This is awesome (Score:5, Insightful)
open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly
Did you even read the summary? They believe that this flaw has existed since 1998. You have a very strange definition of "quickly" if 16 years falls into that category.
I'm all for OSS, but people like you that continue to trot out this tripe aren't helping it. The benefit isn't that there all these mythical "skilled eyes" looking at the code, it's that you can look at the code.
Re:This is awesome (Score:5, Insightful)
Re: (Score:2)
Gp's point is once it has been found things move quickly. Tested and fixed is in the part you bolded, not found.
You objected to a point gp did not raise.
Re: (Score:2)
And the developer that created this bug in 1998 is the same one who created heartbleed. Some people get a lifetime ban for hacking. Do we need a lifetime ban for coding?
Re: (Score:2)
You have a very strange definition of "quickly" if 16 years falls into that category.
That is still a much better definition than yours appears to be!
16 years is at least a number and a unit of time. Your argument that "Closed source bugs are found in never years" is the definition of "quickly" most everyone would call strange.
Re:This is awesome (Score:4, Insightful)
The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.
10 years ago someone said...
"Opensource will eliminate all bugs, because the world can see the source". Doesn't matter if no one reads the source.
Re:This is awesome (Score:5, Funny)
Re: (Score:2)
I think that if that person knew what he was talking about, he would have said, "Open source has the potential to greatly increase the quality of code because the world can see the source and make fixes."
Just because there's the potential for FOSS to be more reliable and more secure doesn't mean that every project will be. And even so, nothing will eliminate all bugs.
Re: (Score:2)
Re: (Score:2)
I knew this excuse would used again and again, long before Heartbleed. I complained loudly (see my history) for your though to be fatally flawed.
The problem is, that this kind of thinking generates more holes than fixes.
But then, I think you were sarcastic and the moderators missed it.
Re:This is awesome (Score:4, Interesting)
Re:This is awesome (Score:5, Insightful)
I agree that 16 years for a fundamental flaw like this is bad, but how can you possibly know that closed source is no worse (or no better) than this? Closed-source software vendors are usually not very open about these problems.
I agree 100%. The only reason this flaw is known is because the source code was available to review. Obviously, it would have been better if this were reviewed and caught sooner, but that ignores the fact that it was only caught because the source code was available. That seems to be a big plus.
Also what is interesting is that even though the flaw has been there for 16 years, there are no known exploits of it. That would seem to dismiss the notion that open source security software is problematic because bad people can find exploits.
Of course another explanation is that the flaw isn't any such thing and was intentional and because it was open source, certain government agencies will now lose the ability to exploit it.
Regardless of how you look at it, it seems to be an advantage to open source.
Re: (Score:3)
This required knowing how SSL is supposed to work, not just being able to read code.
It was found when someone decided to check whether implementations correctly checked the order of messages. This could have been found by testing against a binary, regardless of the code being available.
Open source is a win here because I can fix it without waiting for a vendor patch. Not that I would, but I can. Code availability for finding the bug is nearly irrelevant.
No known exploits means nothing. Exclusive zero days a
Re: (Score:3)
Open source is a win here because I can fix it without waiting for a vendor patch. Not that I would, but I can.
And why wouldn't you?
Probably because you're waiting for some other guy (the vendor) to do compatibility and regression testing.
Re: (Score:3, Insightful)
Neither this bug or heartbleed were found by looking at the source code. They were found through binary analysis.
Re: (Score:2)
Neither this bug or heartbleed were found by looking at the source code. They were found through binary analysis.
Analyzing the binary indicated their was a bug. Analyzing the source code identified exactly what that bug was. I may know something isn't working, but until I know why it isn't working, I can't fix it.
Re: (Score:2)
Re: (Score:2)
Most people are not researchers and furthermore don't have the expertise to even FIND this issue, much less fix it properly.
But for those who do have the skill and expertise, they can't do it without the source code. Think of it like this. You can tune all the settings on a network by the book, but if there is a problem, having a packet sniffer sure makes it easier to correct. Source code is like a packet sniffer. There is a lot of corrective steps you can take without it, but to ultimately fix the problem, whether closed or open source, one needs access to the source code. That doesn't mean each individual is going to fix th
Re: (Score:2)
I think "closed" source is a misnomer in regards to the issue of code review. The source is always open to *someone*; it's just a question of who, and whether those people are competent. Effectively, it doesn't matter how many people look at it, as long as the people looking at it know what they're looking at/for. Certainly it can be argued that the set of "all people" includes more experts than the set of "some people," but in practice the subset of "all people" who actually do code reviews appears to b
Re: (Score:2)
So what you are effectively saying is "we (foss) did a great job, let's pat each other on the back! Then let's continue our marvellous path of joy and glory".
(translation: we, the cowboy coders, are totally ignoring fatal problems in processes and attitude and won't fix them 'cause we "are better". if the sarcasm was lost in translation, your bad).
Re: (Score:2)
So what you are effectively saying is "we (foss) did a great job, let's pat each other on the back! Then let's continue our marvellous path of joy and glory".
(translation: we, the cowboy coders, are totally ignoring fatal problems in processes and attitude and won't fix them 'cause we "are better". if the sarcasm was lost in translation, your bad).
Not at all. What I am saying is the OSS provides some advantages over closed software. Both are fraught with bugs. Free as in beer, doesn't mean free from bugs.
Re: (Score:2)
Wrong. Open source can provide advantages, but only if all processes etc. are followed. Most often they are not.
Re: (Score:2, Insightful)
There are STILL open issues in Windows 8.1 that have existed since Win2000, that are actively being exploited today with no fix in sight. Major flaws that have survived supposed "complete rewrites" even though the steps to exploit are the exact same. There is only a large amount of shrill denial and burying heads in the sand. At least that aspect doesn't exist in open source.
Re: (Score:2)
There are STILL open issues in Windows 8.1 that have existed since Win2000,
You care to give examples? Preferably CVE links to Mitre or similarly respected databases.
Re: (Score:3)
Feel free to look up a CVE for it yourself. This is just one example. Other long-standing MS security holes include the infamous WMF bug. [wikipedia.org] Plenty of such things exist in the wild.
Re: (Score:2)
Er, there is a patch for those IE flaws, and it was released prior to full disclosure: https://technet.microsoft.com/... [microsoft.com]
Theyre also only vaguely sort of issues "in Windows 8.1", in the same way that a safari bug is a flaw in OSX.
The WMF bug was patched 8 years ago.
Re: (Score:2)
On the other hand it is possible to find situations where things are changed between different versions of Windows for no obvious reason. (Except possibly to deliberatly break old or third party software.)
Sometimes even when the new behaviour is noticably infe
Re: (Score:2)
Your post sort of reinforces the point that a blanket statement about one or the other is pretty dumb.
Closed source can have a number of benefits if done right. It has a number of issues, too (like trust).
Open source can have a number of benefits if done right. It has a number of issues, too (like getting volunteers who are experts in crypto, or preventing obfuscated malicious code).
Re: (Score:2)
Of course "He did it too" is a valid argument when comparing two methods of software development.
You are comparing the relative advantages of both, against each other, that what comparing means, no on said open source was perfect.
And as a person who has worked on close source, I can assure you people do go around shouting how great closed source is, and I can assure you closed source and as easily be written by people who have no idea what they are doing.
Re: (Score:2)
"He did it too, mommy!" is a valid position to take in a debate only if you're 8 years old.
I totally agree, now please explain how am I using this argument, because I don't see it.
Re:This is awesome (Score:5, Insightful)
Closed source software is far worse, you just don't hear about it.
Re: (Score:2)
First, I detest the excuse "some one is worse - or at least you cannot prove it is not, therefore we are actually quite good!"
Then, I call bullshit. Closed source do get "CVE'd" and the companies can be held liable. Foss developers cannot be sued (and get as much money as from G/M/A/...).
But do continue with the same attitude. After next exploit, and 10 more later, just say "yes, someone out there is worse, especially now as we have fixed ALL known vulnerabilities". Although the new version out next month w
Re:This is awesome (Score:4, Insightful)
It's actually a false dichotomy...
The vast majority of software is poorly written, hacked-together junk written by dicks and idiots.
Open Source *can* be slightly less terrible, but it's all still terrible.
Re: (Score:2)
(a) if this were closed we still wouldn't know.
(b) OpenSSL is actually really well known to be so ugly that nobody wants to have to look at it. Mountains of cruft piled on mountains.
Open source code quality on average is a bit better than closed, but it's certainly no panacea.
Re: (Score:2)
Open source code quality on average is a bit better than closed, but it's certainly no panacea.
This has got to be the mother of all speculation. Closed source software by definition does not have a source that you can compare to OSS; how on earth can you make a statement like that.
Re: (Score:2)
Open source is no better or worse than closed source
since it is opensource you can know now with absolute certainty where the bug was and for how long it has been there, and you can check exactly how it is fixed. with closed source you would know next to nothing. definitely worse.
Re: (Score:2)
The latter tends to explicitally prevent "outsiders" looking at the code. It's very possible for authors to be "too close" that they will see what should be there rather than what actually is there. Hence in other industries there are the likes of "proof readers".
The other difference is with OSS anyone who spots a bug is able to publish a fix.
Re: (Score:2)
The point is that if a flaw exists, when found, it can be quickly fixed in open source.
In theory it can be fixed quickly, but even in the recent OpenSSL quality assurance effort, there was fixed a 4 year old publicly reported bug [eweek.com]. So it's not guaranteed that anyone fixes the bugs quickly, even if they are already found and described accurately.
It's just like the "given enough eyeballs, all bugs are shallow" law: the bugs can be found if enough professional people are rigorously going through the code. But there is no guarantee that every open source project (even mission critical projects) ha
Re: (Score:2)
There are no guaratee that every closed source project (even mission critical projects) have enough of eyeballs in practice - or that they are any good at their job. Why you think closed source teams are better than open source teams, simply due to the development model choice. thats just weird.
I didn't say that!
Re: (Score:3)
. You can also do your own security audit on open source software if you are really security conscious.
No, you cant, and if you think you can you have a serious ego problem.
A security audit of something like OpenSSL is not something that should be attempted by someone who does not earn a living doing code and crypto audits.
Bet the NSA knew about this... (Score:2, Interesting)
...and it was like ten Christmases to them. They're probably really down that they just lost one of their best toys.
How are people affected in their day to day lives? (Score:4, Insightful)
This is a flaw, but it requires both ends use vulnerable OpenSSL versions. Which means your day-to-day life may or may not be affected that much.
I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows) - since Apple and Microsoft have their own SSL implementations. If you have an Android phone or tablet, then yes, it's quite likely an issue, and while both are popular, people generally don't use them that much for data (iOS traffic, after 7 years, has finally dropped to below 50% of all mobile traffic out there, despite Android outselling iOS by a huge margin). And nevermind the oddball Linux user.
So the real question is, how many people really ARE affected?
Heartbleed affects everyone because it exposes server secrets irrespective of the client side. But this vulnerability is only really present if both ends use OpenSSL.
Re: (Score:2, Informative)
I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)
Ummm, firefox uses NSS, not OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
Re: (Score:2)
The real limiter for your average user is the requirement for man in the middle position.
Even without this flaw, most users will just click through any warning that comes up during a man in the middle attack.
It's still a bad thing that the mechanism designed to protect us from man in the middle is broken, but for the average user, the mechanism is already broken via apathy.
Re: (Score:2)
Oh I totally agree with this. Relying on the user to "make the decision" is (or should be) the last resort when a programmer can't figure out how to deal with a situation.
In the specific area of certificate verification on web browsers, the problem has been too many false positives. Lots of people are sloppy with their certificates, and users have gotten used to the idea that any error mentioning a certificate is probably no big deal (because the other 100 times they clicked the ok button the world didn't e
Re: (Score:2)
Re: (Score:2)
So the real question is, how many people really ARE affected?
That would depend on how much, if any, of OpenSSL code was incorporated into Microsoft and Apple products regardless of the GPL. After all, 1998, was a long time ago.
Re: (Score:3)
That's quite the parabolic sentence there. I hope you didn't give yourself whiplash.
Closed source software (Score:3)
Given all the open-source SSL/TLS security flaws (OpenSSL, gnutls, Apple SSL) that have come out these past few months - mostly thanks to renewed interest in hunting flaws, thanks to the Snowden revelations, I suspect - I hope that companies like Microsoft are also seeing this as a wake-up call driving them to do code reviews on their closed-source SSL/TLS code.
Re: (Score:3)
Not quite sure what you mean there. Closed source gets more code review than opensource apparently.
Speaking as someone who, in a past job, reported a number of brain-dead flaws in their products to Microsoft - I'm curious what experience has led you to draw that conclusion.
Re: (Score:3)
Samba reverse engineered smb with a clean room effort, but I'm sure they didn't get it right the first time. The effect was fuzzing the windows service as they developed.
Similar efforts have been done on lots of proprietary binaries, and plain old assembly level disassembly has also been done.
I'm not saying everything has been tested. But "you can't know" is clearly wrong. If you want to know, you can. Just like if you wanted to know openssl is secure, you can. You had 16 years to read source code and you d
Re: (Score:3)
Closed source gets more code review than opensource apparently.
Clearly you've never worked in the software industry.
Re: (Score:3)
Most of the bugs I reported to Microsoft were flaws in their Fortran and MASM (assembly language) offerings, back in olden days of yore (otherwise known as the 1990s).
With the added complexity of modern Microsoft dev tools, though, I'm sure bugs never make it into production nowadays.
Re: (Score:2)
Closed source gets more code review than opensource apparently.
Clearly you've never worked in the software industry.
Clearly neither did any of the code inspectors that reviewed the code for 16 years...
Non sequiteur.
Stupid summary (Score:2)
That's not an insignificant set of conditions that must be present for a successful attack
But it is exactly the point of TLS, to protect against such an attacker. If you know you don't have a man-in-the-middle then you don't even need it in the first place.
True that the server might not be running that version, but a non-trivial number of them are.
Advisory is a bit unclear (Score:2)
Would it be a sin? (Score:2)
Re: (Score:2)
The accusation implied in that response is that "open source must be weak because vulnerabilities are found".
Whether or not closed source is better is largely irrelevant. Whichever fulfills your needs the best (be they verifiable security, price, etc) is what is "better" for you.
FreeBSD (Score:2)
at least my install still uses 0.9.8n though who knows what other nasties lurk in that one
Re: (Score:2)
'new, exploitable vulnerability' ... 'since 1998' (Score:2)
Something does not add up. How is there a new vulnerability that's been in the source for sixteen years? How are older versions of the server code not vulnerable if it's sixteen years old?
OpenVPN (Score:2)
Re: (Score:3)
"Ultimately you still need to get the encryption information across securely"
This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.
Re: (Score:3, Informative)
"Ultimately you still need to get the encryption information across securely"
This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.
Correct. A MITM beats everything done over the wire. You need to secure your shit before you use the wire. You need a pre-shared key to encrypt the initial communication. A certificate sort of does this, but not really because we still trust them blindly and we initially accept them over the same wire. The proper way to do shit would be for you to go to your bank in person, for example, and generate 2 keys - one for you to use to talk to your bank and one for the bank to use to talk to you. You then u
Re: (Score:3)
Diffie-Hellman Key Exchange [wikipedia.org] allows you to securely share a secret key over an insecure medium. Combining this with asymmetric cryptography to identify parties is how modern handshake protocols work.
The problem here how to trust Bob's asymmetric key really came from Bob and not Eve.
You are correct in that the ideal solution would be to talk to Bob over a different medium (like phone) and ask him if that is his key but there are ways to do this over the wire. As an example, several Linux distros sign their Li
Re: (Score:3)