SSL Holes Found In Critical Non-Browser Software

← Back to Stories (view on slashdot.org)

SSL Holes Found In Critical Non-Browser Software

Posted by timothy on Thursday October 25, 2012 @08:21AM from the will-be-with-us-for-a-while dept.

Gunkerty Jeb writes "The death knell for SSL is getting louder. Researchers at the University of Texas at Austin and Stanford University have discovered that poorly designed APIs used in SSL implementations are to blame for vulnerabilities in many critical non-browser software packages. Serious security vulnerabilities were found in programs such as Amazon's EC2 Java library, Amazon's and PayPal's merchant SDKs, Trillian and AIM instant messaging software, popular integrated shopping cart software packages, Chase mobile banking software, and several Android applications and libraries. SSL connections from these programs and many others are vulnerable to a man in the middle attack."

84 comments

Min score:

Reason:

Sort:

Proprietary software contains vulnerabilities by Anonymous Coward · 2012-10-25 08:24 · Score: 0

Shocking!
1. Re:Proprietary software contains vulnerabilities by Anonymous Coward · 2012-10-25 08:34 · Score: 2, Informative
  
  Shocking indeed. It's pretty much this story but without the Android reference
  http://yro.slashdot.org/story/12/10/20/0545252/poor-ssl-implementations-leave-many-android-apps-vulnerable
  Who'd have thought that poorly coded code is poorly coded?
This again? by Anonymous Coward · 2012-10-25 08:26 · Score: 5, Insightful

News Flash: People bypass inconvenient security features. Security reduced as a result.
How does this at all lead to a "death knell" for SSL?
Death knell? Really? by JDG1980 · 2012-10-25 08:27 · Score: 4, Insightful

The death knell for SSL is getting louder
What does this mean? Just that vendors should be using the newer versions of SSL that were rebranded TLS? Or is there another, competing technology that is recommended instead?
1. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 08:34 · Score: 5, Informative
  
  It means that both Gunkerty Jeb and Timothy didn't read TFA and are both fucking stupid.
  Summary: libraries allow you to selectively ignore part or all of the certificate chain verification, including OpenSSL, which is exactly what your fucking browser asks you to do when you visit a site with a self-signed or expired cert. TFA argues that this is the wrong behavior. TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
  TFA also doesn't understand what the layers of security are around Amazon's EC2 toolkit, either.
2. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 08:34 · Score: 5, Informative
  
  It means that this "post" is really clickbait. And now we know why no one RTFA.
3. Re:Death knell? Really? by wmbetts · 2012-10-25 08:48 · Score: 4, Informative
  
  Yes, it is and it's bs that libcurl got caught in the middle. By default libcurl is secure.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
4. Re:Death knell? Really? by bill_mcgonigle · 2012-10-25 09:09 · Score: 2
  
  It means that this "post" is really clickbait. And now we know why no one RTFA.
  Yes - please, nobody make any more topical comments about the "death knell" phrase or you're just going to encourage this kind of submission whoring and editors who play along. They'd love to see a long thread debating the merits of whether or not TLS is about to go extinct, and there will be trolls to fuel such an absurd thread if you allow it.
  They'll have to make do with a small number of page views on the meta bitching about the poor editing.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
5. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 09:15 · Score: 0
  
  What does this mean?
  It means Netcraft bought a megaphone.
6. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 09:33 · Score: 3, Insightful
  
  TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
  Your session is not going to be very opaque if there's a man in the middle listening in.
7. Re:Death knell? Really? by dkf · 2012-10-25 09:36 · Score: 3, Insightful
  
  TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
  That allows you to have a wonderfully secure conversation with whoever is snooping. Great step forward there!
  It's important that clients verify the identity of the servers to which they connect, but they can do so in many ways. Public HTTPS does it in a particular pattern, but a self-signed certificate also works (provided you've distributed the server's public key to clients in a trusted way first). The problem with self-signed on the public HTTPS web is that there's too many sites for it to be at all practical for you to acquire all their self-signed public certificates before connecting to any of them; that advantage (of the CA system) ceases to be very relevant on a closed system such as an intranet, though larger intranets can go for things like a private CA.
  Expired certificates or non-matching host certificates are a demonstration of poor deployment.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
8. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 09:45 · Score: 0
  
  Your CPA and doctor are right most of the time so they are not arrogant either..
9. Re:Death knell? Really? by Billly+Gates · 2012-10-25 09:54 · Score: 2
  
  Unfortunately they can't leave TLS because of IE 6 and maybe IE 7(?) support. These apps use HTML from IE for functionality and need to support these older browsers for corps and people who refuse to upgrade to a modern browser.
  Another reason to also get rid of XP as you can't upgrade someone's IE from your own setup.exe program.
  Arstechnica.com had an article (older as I can't find it to link) which showed TLS to be ineffective by 2016 as computers became faster and through collisions will be able to hack the keys.
  
  --
  http://saveie6.com/
10. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 10:08 · Score: 1
  
  Yup. And a lot of times people just don't give a damn.
  There are other reasons to use weak SSL - most of them rather stupid and created by not-so-bright IT policies. For example: tunneling through stupidly configured proxy servers often requires an SSL connection - it does not matter to anyone involved what certificate is used to establish such a connection, the proxy simply often wants the connection to be encrypted using SSL.
11. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 10:48 · Score: 0
  
  If I am MITM, your traffic isn't very opaque, is it? I will be able to see every single F-bomb you drop!
12. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 10:50 · Score: 1
  
  Mine are!
13. Re:Death knell? Really? by DragonWriter · 2012-10-25 10:52 · Score: 2
  
  TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
  
  That's because that's a nonsense idea. If the scheme you use is vulnerable to MITM, the session using that scheme are not opaque to unintended eavesdroppers. That's what "MITM" means.
14. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 11:58 · Score: 0
  
  That's ridiculous. Just use stronger Certs. TLS allows different encryption algorithms to be used so it would be nothing to add stronger ones if they are needed.
15. Re:Death knell? Really? by vux984 · 2012-10-25 12:42 · Score: 1
  
  TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
  Others have already weighed in, but I have to pile on too. You need to realize this is an absurd position.
  What is the point of an 'opaque session' if you are having it with an unknown party?
  If you are willing to talk to anyone who presents themselves as the endpoint and you don't authenticate them, what does it matter if someone else can't listen in... for all you know you are having a nice encrypted session with the very 'someone else' you don't want listening in.
16. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 15:31 · Score: 2, Informative
  
  Your parent stated it badly. It's not that you aren't worried about Monkey in the Middle. It's that you aren't worried about third party identity verification to avoid MITM. If you self-sign your own certificate, then you know that it's valid. You aren't relying on a third party signer (e.g. VeriSign) to validate it. You are validating it.
  The thing is that for this to work, you need to verify the certificate. If you don't verify the certificate, then you can end up with MITM attacks. There is a mechanism to automatically verify the certificate with a third party signer. If you bypass that mechanism, you are responsible for doing the necessary verification. Turning off that verification in libcurl is a bad idea--it allows *everyone* to bypass verification. It should only be used for testing. Turning off that verification on a per site basis in Firefox is dangerous but manageable.
  The correct way to do this with libcurl is to manually add that particular certificate to the approved certificates list. That marks that you verified the certificate without opening additional certificates. It's possible that there should be additional tools to make this process easier in both Firefox and libcurl. That would encourage people to do the right thing rather than the expedient thing.
17. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 16:18 · Score: 0
  
  Don't think about it too much. Normal headline style in Slashdot.
18. Re:Death knell? Really? by Anonymous Coward · 2012-10-25 20:54 · Score: 0
  
  Yes, I read Reddit as well.
19. Re:Death knell? Really? by timster · 2012-10-26 00:15 · Score: 1
  
  MITM in cryptography usually stands for "man in the middle". "Monkey in the middle" is a kid's game where a group stands in a circle and tries to keep the ball away from a single kid designated the "monkey".
  
  --
  I have seen the future, and it is inconvenient.
20. Re:Death knell? Really? by Skapare · 2012-10-26 08:41 · Score: 1
  
  MitM success means opaque fail. If you want opaque, you must prevent MitM. If the transit has no MitM opportunity, then what's the point of opaque in the first place.
  
  --
  now we need to go OSS in diesel cars
21. Re:Death knell? Really? by Anonymous Coward · 2012-10-28 10:49 · Score: 0
  
  But what if its a woman in the middle? Monkey is at least gender neutral, if not species.
Death knell? by viperidaenz · 2012-10-25 08:30 · Score: 1

Wouldn't a Death Krull be cooler?
1. Re:Death knell? by UnknownSoldier · 2012-10-25 08:48 · Score: 1
  
  or Glaive ;-)
  http://en.wikipedia.org/wiki/Krull_(film)
Man in the middle? by gr8_phk · 2012-10-25 08:32 · Score: 1

I thought SSL in general was susceptible to man in the middle attacks, so ANY app that uses it would be too. That doesn't mean a death knell. It means something like Domain Keys need to be used to make these even more secure.
1. Re:Man in the middle? by Bill,+Shooter+of+Bul · 2012-10-25 08:38 · Score: 3, Insightful
  
  As long as you are using a legit SSL cert ( avalible for less than $10 anually) with decent cipher strength ( again, avalible for less than $10 anually), man in the middle should be impossible with TLS/SSL and the proper use of it by the client ( don't connect and send sensitive data, if the ssl cert isn't valid or the signer isn't trusted).
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
2. Re:Man in the middle? by Anonymous Coward · 2012-10-25 08:46 · Score: 0
  
  Since the CAs do screw up and sign the wrong certs it might be better to use self-signed certs for internal SSL stuff and ignore CAs completely.
3. Re:Man in the middle? by pthisis · 2012-10-25 08:49 · Score: 5, Insightful
  
  You're better off running your own CA and distributing that CA's public key to your internal apps. Then you can ignore outside CAs but still avoid MITM attacks.
  
  --
  rage, rage against the dying of the light
4. Re:Man in the middle? by dgatwood · 2012-10-25 09:05 · Score: 4, Insightful
  
  The current versions of SSL/TLS are never vulnerable to man-in-the-middle attacks unless a trusted certificate authority is compromised (as long as both client and server implement RFC 5746). Whether the certificate authorities are trustworthy is another question, of course.
  This particular problem is caused by folks disabling the SSL stack's built-in chain validation and then not implementing their own. As far as I know, there are exactly two correct ways to support self-signed keys in Android: provide your own trust store that includes trust for that specific self-signed key or subclass the X509 validation class to add that specific self-signed key as an additional trusted anchor into the list of trusted anchors that it returns. Unfortunately, there's a lot of very bad advice out there, particularly on sites like Stack Overflow, telling folks to disable chain validation entirely. The result is that not only does the app trust that self-signed key, it also trusts any self-signed key.
  It doesn't help that there's no canonical source for that information from Google, so there are many, many questions on sites like Stack Overflow that all ask the same basic question in different ways and get different answers....
  Patient: Doctor, when I drill a hole in my hand, I can't scoop up water from the bucket to drink.
  Doctor: Why did you drill a hole in your hand?
  Patient: So that the acid wouldn't stay in my hand.
  Doctor (alarmed): Why did you put acid in your hand?
  Patient: Because the bucket dealer wanted too much money for a bucket.
  Yeah, it's like that.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
5. Re:Man in the middle? by Artraze · 2012-10-25 09:10 · Score: 4, Informative
  
  There's not really any such thing as a "legit" certificate; you're referring to a signed one. This does nothing to protect against a man-in-the-middle attack. What it does do is establish a chain of trust linking your certificate back to an authority. If that authority is trusted then your cert can be too (to the extent you trust the authority). If, and that's a big if, we trust that _all_ trusted authorities will thoroughly vet the certificates they sign then we can _trust_ that a MITM attack cannot occur, but realistically "legit" certificates do nothing more than that. If, say, the US DoD (once/often? a trusted authority) decides to MITM you, they can just sign a cert and MITM you.
  The only way to actually prevent MITM is to exchange the certificate (or some verification mechanism like a hash) in some sort of trusted manner (e.g. distributing it's hash with a client app).
6. Re:Man in the middle? by Anonymous Coward · 2012-10-25 09:23 · Score: 0
  
  Vote parent up
7. Re:Man in the middle? by Anonymous Coward · 2012-10-25 09:27 · Score: 0
  
  Vote parent up, now.
8. Re:Man in the middle? by Anonymous Coward · 2012-10-25 10:57 · Score: 1
  
  Vote parent up, now.
  No he is not, the whole purpose of certificate chains is to prevent MITM attacks without having to exchange all the certificates individually like he is saying.
9. Re:Man in the middle? by hobarrera · 2012-10-25 11:06 · Score: 1
  
  You can get them for free from StartSSL, and most browsers/vendors will trust them.
10. Re:Man in the middle? by Luthair · 2012-10-25 20:21 · Score: 1
  
  StackOverflow is really the scourge of the Internet when you're searching for anything programming related, too many unrelated or unanswered pages appear in query results.
11. Re:Man in the middle? by JigJag · 2012-10-26 00:36 · Score: 1
  
  And for the record, OpenCA is all you need, although it's not super simple to use.
  JigJag
  
  --
  "The hallmark of humanity is the ability to move beyond sensory inputs" - Mary Helen Immordino-Yang
12. Re:Man in the middle? by petermgreen · 2012-10-26 08:21 · Score: 1
  
  the whole purpose of certificate chains is to prevent MITM attacks
  But it can only do that if those who hold root or intermediate certificates that your application trusts can be trusted can be trusted not to issue (whether through their own choice, through trickery by the attacker or through pressure applied by the attacker) a fraudulent certificate to your attacker for the service you are connecting to.
  Take a look at this list.
  http://www.mozilla.org/projects/security/certs/included/
  AIUI everyone on that list (and anyone they delegate to!) can generate certificates that will let them MITM your ssl browsing sessions from firefox. I'm pretty sure that most of them would provide certificates for any domain if ordered to do so by the government of the country they are based in. Some of them may even by infiltrated by criminals. Therefore if your threat model includes governments then you should not rely on SSL with the "standard" CAs. OTOH if your threat model only includes low level criminals you are probably ok.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Protocol by Synerg1y · 2012-10-25 08:32 · Score: 4, Insightful

How is the wrong implementation of a protocol in a framework library a fault of the protocol?
Either devs need to be aware that there's extra steps in validating using an SSL library in their framework of choice, or the framework needs to be patched appropriately, but based on the concepts the article's provided, sounds like bad implementation aka crap code, and not enough QC. Some OOP would help make the implementation easier though...
1. Re:Protocol by Anonymous Coward · 2012-10-25 18:47 · Score: 0
  
  Usability matters. The "right" way should be the easiest to implement. Currently, it seems that the wrong implementation is easier to do. Or maybe it's too hard to verify if an implementation is correct.
  So, no, the protocol isn't at fault here. The library is, though. You should never assume the programmer will 'get' it and figure it out themselves. Especially on something as abstract as encryption.
2. Re:Protocol by Synerg1y · 2012-10-26 03:04 · Score: 1
  
  Hmmm... you've just summed up a lot of what's wrong with modern day developers in your sentence.
This is not an SSL problem by gweihir · 2012-10-25 08:32 · Score: 4, Insightful

This is a problem of bad APIs and people not competent to select libraries with better ones. The same would happen with any other encryption protocol. Implementing and using cryptography is hard, in particular because testing will usually not show anything is wrong and testing is still the only thing most software "developers" have in their bag of tools to ensure correctness. As long as people without a clue decide they can implement cryptographic libraries or use them, these things will continue to happen.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
1. Re:This is not an SSL problem by Dast · 2012-10-25 08:50 · Score: 4, Insightful
  
  This is a problem of bad APIs and people not competent to select libraries with better ones.
  While that might sound true, I think the problem is deeper than that. The issue in a lot of cases is developers having to deal with non-ideal SSL/TLS setups that they have no control over.
  It usually goes like this:
  Dev monkey gets told by PHB, we need to make our communications secure, so implement SSL. Dev monkey adds SSL support to the app. Code seems to work. Testing (or even worse, someone in Production) comes back and says: dev monkey's SSL code doesn't work with our Customer XYZ's server. Dev monkey tests things himself and finds that Customer XYZ is using a self signed cert or an expired cert. Dev monkey tells PHB that Customer XYZ needs to fix their setup. PHB tells dev monkey that the setup cannot be changed because of ABC and that dev monkey needs to "code around the issue". Dev monkey updates app to not choke on bad certs. Code gets released, and Customer XYZ's remote worker gets p0wned by a man in the middle attack. Customer XYZ blames PHB, PHB blames dev monkey. Dev monkey sighs and gets another mountain dew.
  
  --
  This sig is false.
2. Re:This is not an SSL problem by The+Moof · 2012-10-25 09:05 · Score: 2
  
  Dev monkey updates app to not choke on bad certs [...] PHB blames dev monkey
  The PHB got the blame exactly right. The Dev Monkey proved he didn't understand SSL as soon as he did a blanket "trust everything." Dev Monkey screwed the pooch.
3. Re:This is not an SSL problem by Synerg1y · 2012-10-25 09:16 · Score: 1
  
  In the real world, dev monkey doesn't get to do what dev monkey wants, a good step would be to ask management what to do since customer won't change set up that way monkey covers monkey's ass and if the customer gets backed, management can deal with it on a my guy told you so basis.
4. Re:This is not an SSL problem by Anonymous Coward · 2012-10-25 09:17 · Score: 1
  
  Your dev monkey is fucking incompetent and should be slapped with a smoked mackerel in the face.
  A reasonable developer would just add XYZ's cert to the list of trusted certificates manually. If you think about it a little, it doesn't matter who tells you that a purported XYZ's certificate is indeed XYZ's. It could be one of the trusted CAs, selected for by Microsoft, Mozilla or Google. Or it could be the holy trinity of XYZ's CEO, CTO and CFO, materializing in your office in person. It could even be your PHB. Somebody whom you trust, or at least pretend to.
5. Re:This is not an SSL problem by Dast · 2012-10-25 09:21 · Score: 1
  
  Exactly. In the real world, dev monkey doesn't get to make the decisions. If dev monkey doesn't code around the problem, PHB finds a different code monkey to make the change. Not everyone gets to work for themselves or for a small startup where they can make their own decisions.
  
  --
  This sig is false.
6. Re:This is not an SSL problem by The+Moof · 2012-10-25 09:26 · Score: 1
  
  Dev monkey proved they didn't understand how to fix the problem.
  
  The last time I came across this in the real world, I was writing a .NET application. The .NET framework offers a delegate to handle exactly this situation. I assume the Java, and any C API (worth its salt) offers a similar functionality. These functions are intended to extend the trust chain validation. You can analyze the chain and verify that your certificate (and only your certificate) caused the error, and that the error was within parameters (typically, an untrusted CA).
  
  You don't need to allow everything under the sun, nor should you ever do so. You don't need to control the authority on the end system, just understand how certificate validation works.
7. Re:This is not an SSL problem by Synerg1y · 2012-10-25 09:29 · Score: 2
  
  To be honest...
  If I was consulting for a company and I clearly outlined the risk of allowing self-signing certs to them and they said we'll take it, I'd make sure I had something in writing... like an email & I'd do it for them anyways, if they get MITM'd later, I'd refer to them to the email. You can't always stop people from taking short cuts, but making them aware of the risks is more than most people probably do.
8. Re:This is not an SSL problem by Synerg1y · 2012-10-25 09:36 · Score: 1
  
  As a MITM attacker, can't I just spoof the sender's domain here?
  Granted, it does add a fairly decent layer of complexity to the MITM : http://www.windowsecurity.com/articles/understanding-man-in-the-middle-attacks-arp-part2.html
9. Re:This is not an SSL problem by The+Moof · 2012-10-25 09:48 · Score: 1
  
  No, because you can still verify the certificate is the correct certificate. If you're expecting a certificate with a fingerprint of 0xF00B4R12 and your error-causing certificate is 0xDEADBEEF, it's not the right certificate. Ideally, you let the built-in libraries to the analysis for you by loading your CA certificate and letting the framework do the comparison for you.
10. Re:This is not an SSL problem by sapgau · 2012-10-25 10:41 · Score: 1
  
  Sure but good luck updating XYZ cert in the certificate store for hundrends and hundreds of clients.
  If you try to document it so that the user can update it then there is a 50-50 chance they will screw their certificate store and then not even their banking, gmail or shopping would work.
11. Re:This is not an SSL problem by gweihir · 2012-10-25 11:33 · Score: 1
  
  While this does not seem to be the issue in the OP, this is definitely a realistic scenario. Maybe I should have said that the implementation on both sides of the tunnel needs to be competently done.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
12. Re:This is not an SSL problem by Raenex · 2012-10-25 22:39 · Score: 1
  
  0xF00B4R12
  Sorry for the nitpick, but 'R' isn't a valid hex character.
libcurl is not insecure by wmbetts · 2012-10-25 08:40 · Score: 4, Interesting

The compliant about libcurl is baseless. It's said VERY CLEAR in the documentation how to use the feature. If stupid devs can't figure it out that's hardly the fault of a library developer. I've never had an issue with it and I've used it in C, C++, and PHP.
To repeat what I said on the mailing list. If I break my thumb with a hammer do blame the hammer or do I blame myself?
As Yehezkel Horowitz pointed out on the mailing list.
This is the quote from the FAQ
>Q: How do I use cURL securely?
>A: CURLOPT_SSL_VERIFYPEER must be set to TRUE, CURLOPT_SSL_VERIFYHOST must be left to its default value or set to 2. Anything >else, such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.
The real answer should be - cURL defaults are secure - no need for any code to use it securely.
==================
In general I think the very short answer for this publication should be RTFM.
The little bit longer answer would be -
1. cURL is a C code library - you can't set a value to TRUE since this is not in the language syntax.
So you has somewhere in your includes something like "#define TRUE 1" - you must be aware to this issue - this is an important part of the relations between computers/compilers/programmers.
2. Before setting any option to cURL - you should read the very clear documentation about this option.
==================
As to what we can do to make cURL even better (in order to protect unprofessional users that don't know what they are doing), We could make '1' to act as '2' (verify peer identity), and add a special magic value (i.e. 27934) that will act as todays '1' (check for CN existence but don't verify it).
I think they owe everyone at libcurl an apology.

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
1. Re:libcurl is not insecure by wmbetts · 2012-10-25 08:46 · Score: 1
  
  Just to clarify Yehezkal didn't say they owed every at libcurl an apology. I did.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
2. Re:libcurl is not insecure by Anonymous Coward · 2012-10-25 09:43 · Score: 4, Insightful
  
  This is the quote from the FAQ
  >Q: How do I use cURL securely?
  >A: CURLOPT_SSL_VERIFYPEER must be set to TRUE, CURLOPT_SSL_VERIFYHOST must be left to its default value or set to 2. Anything >else, such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.
  1. cURL is a C code library - you can't set a value to TRUE since this is not in the language syntax.
  So you has somewhere in your includes something like "#define TRUE 1" - you must be aware to this issue - this is an important part of the relations between computers/compilers/programmers.
  It is good that the default is secure, but this is bad API design. There are at least two ways it can be improved:
  1) The name "CURLOPT_SSL_VERIFYHOST" implies a boolean value, so "set(CURLOPT_SSL_VERIFYHOST, TRUE)" looks like reasonable code after a quick glance. Since the option is a multiple choice option, not a boolean, it should be named something like "CURLOPT_SSL_VERIFYHOST_MODE".
  2) C has had enums since forever. The values "1" and "2" are opaque magic numbers, and flags that are this important should be set with well-named enums, not with magic numbers. Further, if the API setter function was typed with the appropriate enums, the compiler would have complained when it saw "set(CURLOPT_SSL_VERIFYHOST, TRUE)".
  Yes, the application devs used libcurl incorrectly, and yes, the above criticisms are nitpicks, but a library this important should be designed very defensively to minimize the change that users will make dumb mistakes.
3. Re:libcurl is not insecure by fnj · 2012-10-25 10:11 · Score: 1
  
  If I break my thumb with a hammer do blame the hammer or do I blame myself?
  Sometimes, and sometimes, respectively. If the head rotates 90 degrees on the handle, or flies off the handle, on a low-mileage hammer without having undergone any abuse, and the thumb was hit a result of that fault, then you blame the manufacturer of the hammer and perhaps sue them. They almost certainly have insurance for this kind of thing.
  Otherwise you're well advised to blame yourself.
4. Re:libcurl is not insecure by fatphil · 2012-10-25 10:28 · Score: 0
  
  > It's said VERY CLEAR in the documentation how to use the feature.
  
  And, following the rules of English grammar, it's VERY CLEAR that one modifies a verb with an adverb, not an adjective.
  
  But such a mistake isn't important, surely? I mean, we understood what you meant, so the communication worked, didn't it?
  
  --
  Also FatPhil on SoylentNews, id 863
5. Re:libcurl is not insecure by sapgau · 2012-10-25 10:44 · Score: 1
  
  Oh please please mod parent up!!!
  +1
  That api design is retarded.
6. Re:libcurl is not insecure by wmbetts · 2012-10-25 10:46 · Score: 1
  
  While those are valid points and should be corrected I still say it's the fault of the developers and not libcurl. Every option is documented well and the documentation is easy to find.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
7. Re:libcurl is not insecure by sapgau · 2012-10-25 10:47 · Score: 1
  
  Oh my god, a parameter that takes either '2' or TRUE???
  What the hell is that?
  I will stick with my strong typed languages thank you very much.
8. Re:libcurl is not insecure by wmbetts · 2012-10-25 10:51 · Score: 1
  
  Forgive me for not proof reading a post on the Internet. Hopefully, the world won't come to an end, but if it does I hope grammer nazis die first.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
9. Re:libcurl is not insecure by wmbetts · 2012-10-25 10:53 · Score: 1
  
  Touche, I was using that phrase in the context of libcurl though. In this case none of those things happen ;).
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
10. Re:libcurl is not insecure by fatphil · 2012-10-25 11:32 · Score: 1
  
  As I predicted, my post would be a wooooosh. Now go back and think about what I posted, and how it was relevant.
  
  --
  Also FatPhil on SoylentNews, id 863
11. Re:libcurl is not insecure by Your.Master · 2012-10-25 16:40 · Score: 1
  
  I think fault is not 0-sum. It can be totally the developer's fault and still a flaw in libcurl.
12. Re:libcurl is not insecure by Anonymous Coward · 2012-10-25 23:29 · Score: 0
  
  ... such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.
  WTF?! Did someone miss the lecture on "Principle Of Least Surprise"?
  Will the connection be secure, if the host isn't verified?
  
  I think they owe everyone at libcurl an apology.
  Not as long as their code has big surprises like that one.
Lousy documentation by ClayDowling · 2012-10-25 08:53 · Score: 2

While libraries like cURL have excellent documentation, other libraries such as OpenSSL have terrible documentation. Assuming that the cURL developers understood how to use OpenSSL correctly, it's quite simple for me to use their library to establish a secure connection.
What's harder is to figure out how to do it with OpenSSL. There is no obvious starting point for opening a secure connection that you can glean from reading the man pages. There are books you can buy on the subject, but that doesn't excuse the library authors from writing easy to understand documentation. The library itself is quite elegant: with just a few steps you have a secure connection that you can read and write just as if it were any other network connection (or, for that matter, a file on disk). But figuring out how to correctly set up and tear down a connection using that library isn't well documented at all.

--
Easy Online Role Playing Campaign Management
1. Re:Lousy documentation by wmbetts · 2012-10-25 09:00 · Score: 1
  
  By default libcurl is secure. It's only insecure if you mess with an option. Personally, I'm glad that option is there.
  This is the quote from the FAQ
  
  >Q: How do I use cURL securely?
  >A: CURLOPT_SSL_VERIFYPEER must be set to TRUE, CURLOPT_SSL_VERIFYHOST must be left to its default value or set to 2. Anything >else, such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.
  
  --
  "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
2. Re:Lousy documentation by Anonymous Coward · 2012-10-25 09:20 · Score: 0
  
  What's harder is to figure out how to do it with OpenSSL.
  You can start by studying libcURL internals.
CA configuration library? by Anonymous Coward · 2012-10-25 08:58 · Score: 0

I've been frustrated by the bad API's for simple HTTPS requests in PHP. Any feedback on this approach?
* http://www.reddit.com/r/PHP/comments/xush4/php_applications_and_ssl_certificates/
* https://github.com/totten/ca_config
Not as interesting as.. by number6x · 2012-10-25 09:05 · Score: 1

A death cruller!
Please mod parent up by Anonymous Coward · 2012-10-25 12:42 · Score: 0

Valid criticisms of API with suggestions for improvement. Please mod up.
ssh gets by just fine w/o Uzbekistan's CA by Anonymous Coward · 2012-10-25 18:47 · Score: 1

The public CAs are fundamentally untrustworthy. Your only hope is to do like ssh: keep track of certificates that have been seen, and raise an alert if a site's certificate ever changes. Self-signed isn't worse than China-signed, Belarus-signed, Russia-signed, France-signed, Israel-signed, or any of the other supposedly "trustworthy" public CAs you so love.
1. Re:ssh gets by just fine w/o Uzbekistan's CA by Lennie · 2012-10-25 22:07 · Score: 1
  
  I'm sure that would work really well: NOT
  This policy does not work because one of the first website people visit is Google, they change their certificated on a weekly basis (yes all servers; every week they roll out new certs).
  
  --
  New things are always on the horizon
2. Re:ssh gets by just fine w/o Uzbekistan's CA by Anonymous Coward · 2012-10-25 22:54 · Score: 1
  
  (yes all servers; every week they roll out new certs).
  Apparently I just hit the one server, they forgot about:
  Common Name (CN) www.google.com Serial Number 4F:9D:96:D9:66:B0:99:2B:54:C2:95:7C:B4:15:7D:4D Issued On 10/26/11 Expires On 10/1/13
  Unless "new certs" means one that was issued a year ago.
3. Re:ssh gets by just fine w/o Uzbekistan's CA by andy.ruddock · 2012-10-25 23:07 · Score: 1
  
  Doesn't matter, unless they roll out a new CA cert every week.
  It's the longevity, and security, of the CA cert that matters.
  
  --
  God: An invisible friend for grown-ups.
4. Re:ssh gets by just fine w/o Uzbekistan's CA by Lennie · 2012-10-26 04:01 · Score: 1
  
  I don't know that is what I heared in a presentation, I think it is somewhere online. I'll see if I can find it somewhere.
  
  --
  New things are always on the horizon
5. Re:ssh gets by just fine w/o Uzbekistan's CA by Zibri · 2012-10-28 10:45 · Score: 1
  
  I don't really like the CA model either, but your suggestion doesn't seem thought through. SSH asks you to actually verify the key fingerprint of the new host key you are trying to connect to; this would be quite hard for non technical users that want to visit their bank website etc.. And like other commented, that would also be a PITA with key rollovers.
  No, the real solution I think is developed in the DANE IETF WG: distributing keys through DNS, secured by DNSSEC.
Lowering the barriers. by Anonymous Coward · 2012-10-25 20:27 · Score: 0

"The death knell for SSL is getting louder."
Oh my... WHY ARE THERE SO MANY BS SUBMITS ACCEPTED?
Seriously /. editors, get your act together and keep the BS out! (Along with "how to build xyz", 'how to reuse first gen photo frames", idiotic posts by some dads asking re: tablet usage for their 3yrs old, etc. etc.)
(But anyway, since i discovered HN this year, my dissatisfaction about how low the standard for news "articles" on /. became is a bit remedied. There IS actually hope for real technical information & stuff discussed on the internet.)