Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros 144
According to an article at Ars Technica, a major security bug faces Linux users, akin to the one recently found in Apple's iOS (and which Apple has since fixed). Says the article:"The bug is the result of commands in a section of the GnuTLS code that verify the authenticity of TLS certificates, which are often known simply as X509 certificates. The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated, drawing ironic parallels to the extremely critical 'goto fail' flaw that for months put users of Apple's iOS and OS X operating systems at risk of surreptitious eavesdropping attacks. Apple developers have since patched the bug." And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Real question (Score:1)
Who uses GnuTLS over OpenSSL anyway?!
Re: (Score:2, Troll)
Re: (Score:1)
Correction, who uses GPL over BSD anyway?!
Re:Real question (Score:5, Informative)
Well, there is this one crazy project [wikipedia.org].
Re: (Score:3)
In my ports tree:
audio/ario
audio/pianobar
deskutils/fusenshi
deskutils/taskd
deskutils/taskwarrior
devel/gwenhywfar
devel/gwenhywfar-fox16
devel/gwenhywfar-gtk2
devel/gwenhywfar-qt4
devel/librelp
devel/
Re: (Score:2)
Re: (Score:1)
It's time (Score:5, Funny)
Re: (Score:2)
Of course you blithering idiot, why do you think we have all this bloat lying around, if not for your protection?
Re:Ha! (Score:4, Funny)
and the blue screening of classic windows provides a hard shield against any rogue processes owning the machine for too long
Re: (Score:1)
Re:And yet... (Score:5, Informative)
Re: (Score:2)
Ok, the major "workstation" & server distro's patched. How about the embedded distro's? OpenWRT? DD-WRT? Do you run OpenVPN on your router? Does it even depend on GNUtls?
How about the hundreds of other embedded distro's? Bank ATMs?
Re:And yet... (Score:4, Interesting)
routers, package management, vpn (Score:2)
Generally you're right to point to router security, but I don't think it's relevant here. Router software package installation -- where you might think you want tls to fetch the package safely -- should be using package signatures rather than relying on tls.
Article writer Dan Goodin missed this point in his first draft. He thought he had a story, and failed at the fact-checking stage.
Would you rely on X.509 for a vpn? The implementation is irrelevant.
ATMs, no. Web banking really does have a problem, and
Re:And yet... (Score:5, Insightful)
For all the speed with which Debian rolled out a patch, it'll still be months or years before this patch makes it into the wild on all the systems it's being used on.
When you show me the OS that has a patch for idiot, lazy or incompetent operators, I will buy you a beer.
Old news (Score:5, Insightful)
The impact of this bug does not compare to the goto fail bug. Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.
Re: (Score:2, Interesting)
It indeed is the same level as the bug Apple fixed. Plentiful access methods are hinged on this lib and code.
It's non-trivial, and affects clients and servers in a wide breadth. Yes, were you watching, you'd have upgraded to fixed versions. Too many, however, don't know the difference between a CVE and a live hand grenade. Or they weren't watching. Same vulnerability result.
Re: (Score:2)
you are silly, it's already been patched and moreover the gnu crap isn't widely used on web connected servers.
it's a non-issue
Re: (Score:3, Funny)
"The GNU crap". :-)
It's amazing how quite the FOSS community will throw Stallman under the bus, if the alternative is accepting parity with Apple's security bug.
Near Zero Impact (Score:5, Informative)
> Most Linux distributions use OpenSSL for TLS.
> Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation,
> and if it doesn't, then it's not affected by this bug (one example is Google Chrome)
Agree. I've ran through everything that linked to gnutls on my distro (Arch) and although there's
quite a lot of binaries that do, most of those do not offer TLS connections (or any network connectivity at all), so my
guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.
Of those that I know actually capable of SSL/TLS connections, all (also) link to OpenSSL.
So without making a definitive statement, AFAICT this should have near zero impact on GNU/Linux.
Re: (Score:1)
so my guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.
Probably because just like OpenSSL it provides implementations of hash functions (MD5 SHA1 etc), private key algorithms etc
http://gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library
Re: (Score:1)
Check the arch reverse dependencies - wget might be impacted. Pretty much nothing else that's popularly used is affected. As others have said, fortunately, this was patch last month.
Re:Old news (Score:5, Funny)
"Linux" refers to a broad range of systems and vendors, rather than a single company,
really? this is /. timmy, get with the program, everyone knows this because THIS YEAR will be the year of linux on the desktop
Re: (Score:2)
I checked. Running linux on the desktop since 16 years.
So yeah, no news for me.
There will be no linux on the desktop, because the desktop dissapears. But there is already linux on the smartphone, if you say it's unix on the smartphone, then there are even more... and add all tablets into the mix.
Re:Old news (Score:5, Informative)
This is quite old news, why is slashdot only picking up on it now?
Slashdot picked it up on March 4th [slashdot.org], actually. This is a dupe.
The impact of this bug does not compare to the goto fail bug.
Agreed.
Re: (Score:3)
Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.
Another (non-issue) example is MTA (email) transfers; typically on Linux systems MTAs such as Exim use GnuTLS for TLS transfers, but purposely don't do certificate verification (but can be specifically configured to do so).
This is still a serious security issue for anything that does use GnuTLS for certificate verification of course, but off the top of my head I don't have a specific example of where this is done on the Linux platform. [There probably is an example to be found somewhere though.]
Re: (Score:2)
Re: (Score:2)
It's not like iOS where everything is required (by App Store rules) to use SecureTransport.
It's worth noting there is 100% no such rule. There is no app store rule enforcing any certificate validation or networking technology. Almost all the app store rules these days are around content, not technical implementations. The only technical rule I can think of off the top of my head is no using private functions in Apple's libraries, which is a no brainer.
OpenSSL is widely used, and in fact has it's own section in Apple's documentation acknowledging so. From TFM:
"Further, although OpenSSL is commonly
Re: (Score:2)
Re: (Score:2)
You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.
Yeah. To Google and Mozilla, this is probably a big deal. To a developer? As long as the content runs, it doesn't really matter. I've never really found an instance where I'm going "Gee, I really wish I was able to embed Chrome here."
It is a little frustrating UIWebView on iOS doesn't have all the DOM editing/inspection functions that WebKit on the desktop has, but it is pretty flexible and customizable. In relation to the original article, you can even override the connection functionality and probably ove
Re: (Score:3)
Actually, no, I'm pretty sure they're just not allowed to use any JavaScript engine other than the built-in JavaScriptCore. And as of iOS 7, it's theoretically possible to actually do so without using WebKit.
Re: (Score:3)
This is quite old news, why is slashdot only picking up on it now?
Slashdot did pick it up [slashdot.org] earlier already when it was first announced. So it's a dupe, really.
Re: (Score:2)
This is a dupe. We saw this on slashdot weeks ago.
I researched into this and OpenSSL' bugs, and.. (Score:1)
The GnuTLS bug is freakishly easy to exploit. The OpenSSL bug at least requires you to modify your code to exploit the bug. This one is almost work-free.
If the same bug appears on OpenSSL, I would immediately disable all SSL related applications.
Thank god nothing uses GnuTLS...except aptitude.
(I am a security researcher who spent a day or 2 researching these 2 bugs)
Slow weekend over at Ars? (Score:5, Informative)
My distro patched this over a month ago.
Re: (Score:2)
Heh, I might have known. Same day that openSUSE issued their patch, even.
Re: (Score:2)
Slow weekend at Ars? Had you actually looked at the Ars article, you may have noticed it was from one month ago, March 4 2014.
The fact it's here now (and is also a dupe of a previous article here) reflects more on Slashdot and its submitters and editors, than Ars.
Re: (Score:2)
Had you actually read this thread, you'd have seen that the article date has already been brought up, and I've already taken note of same. But, hey, thanks for playing.
There are rumours... (Score:4, Interesting)
Re:There are rumours... (Score:4, Informative)
Re: (Score:2)
You misspelled "suppressed truth".
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Who said anything about aliens? The reptilians are actually an earlier sentient species of Earthling, driven underground by the asteroid impact that ushered in the extinction of the dinosaurs. They're only meddling in primitive Human politics to keep us from interfering with their space program.
Re: (Score:2)
When they're not entering into eeeeebil same-sex relationships with their deceptively mousey ninja-housemaid hybrids...
People use GnuTLS? (Score:4, Insightful)
Is anyone other than Debian zealous enough to use GnuTLS?
I rarely agree with Howard Chu of OpenLDAP fame, but... http://www.openldap.org/lists/... [openldap.org]
Re: (Score:2)
Hey! I got the karma for posting that link in the first article, you... you... karma whore! ;)
Stop using GNU TLS (Score:1)
And use OpenSSL. As awkward as it may be, it doesn't have the design flaws that GNU TLS does.
Re: (Score:1)
OpenSSL is far far from great (the API, my eyes, they burn! don't get me started on openssl error codes/messages), but it's not quite the steaming pile of something smelly GnuTLS is.
Although it has improved somewhat over the past few years, at least on the "other SSL clients will actually interoperate" side of things.
Re: (Score:2)
You should poke through the OpenSSL code some day. It's pretty stinky.
What the hell is this, timothy? (Score:5, Insightful)
Are you trolling for an Apple-vs-Linux flame war? do you have a zealous attachment to Apple? or are you just dull?
1) This is old news, and the /. has already reported on it;
2) Hardly anything uses the GNU TLS library, and for the same reason people have been advising against Apple's rewrite of security libraries: because it's better to use something that's had over a decade of development and review and is widely deployed across a series of platforms;
3) You're arguing about the heterogeneity of the Linux platform as if it's a bad thing, while in fact this acts in Linux's favour. Even though the GNU project might like people to use gnutls, distros have chosen not to. Apple either discourages choice or makes it impossible, depending on what exactly you're targeting, which is why everything was affected.
Re: (Score:2)
yep, it is old news - already fixed in most Linux (Score:2)
Fixed at the beginning of March.
Example: http://advisories.mageia.org/MGASA-2014-0117.html
"Nothing to see here. Move on."
If GNUTls is unneeded, then create a NO-OP library (Score:2)
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
Re:If GNUTls is unneeded, then create a NO-OP libr (Score:5, Informative)
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion. There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
As for why GnuTLS exists, AFAIK it's mainly because of licensing issues -- compiling a GPLv2+ program against OpenSSL gets into licensing troubles, so there needed to be a GPL compatible alternative.
Re: (Score:2)
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion.
Unauthenticated public key encryption is useless against an active attacker (one able to modify traffic, rather than just eavesdrop on it).
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
Re: (Score:2)
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
I think you mean ESMTPS. And no, usually TLS certificates are not checked by default (they can be, optionally); many TLS certificates used for ESMTPS are not signed by a CA, so there's nothing to check them against. There's also a new DANE protocol where domains that are using DNSSEC can specify TLS certificate details for mail in the DNS record for the domain, but this is currently not popular (supposedly only about 20 domains are using it). Other issues with this are that a number of DNS servers haven'
Re: (Score:2)
It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Re: (Score:2)
Re: (Score:2)
MITM requires active interception to eavsdrop
It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.
Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal
Re: (Score:2)
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.
Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.
Re: (Score:2)
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Actually it's quite common for email providers to support TLS transfers today. And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
If you look at the mail headers for email you receive, you're likely to find "smtps" or "esmtps" in the Received: lines which indicates that it was sent via a TLS transfer. M
Re: (Score:2)
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
Re: (Score:2)
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing.
No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.
Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
Re: (Score:2)
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
Re: (Score:2)
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.
Oh well. OpenSSL apparently has a vulnerability too. sigh :-/
Re: (Score:2)
Re: (Score:2)
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
You've skipped over the PFS key exchange portion used in TLS.
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
Maybe the MITM exploit you're talking about is possible, I don't know.
Re: (Score:2)
Re: (Score:2)
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
MITM can be an issue. More detailed information about the state of things at the link below.
https://wiki.exim.org/lurker/m... [exim.org]
Wow, that made it seem 10 times worse, thanks! (Score:2)
Yes its used, but only sometimes. Only for that mail stuff, and hey maybe only if someone else is handling authentication because we know thats broken. And we need the stuff there for legal reasons and we need it there as an alternative. Just in case we need to use it, even though we know its broken.
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
xubuntu seems patched (Score:2)
libgnutls26:amd64 2.12.23-1ubuntu4.2
zless /usr/share/doc/libgnutls26/changelog.Debian.gz
gnutls26 (2.12.23-1ubuntu4.2) saucy-security; urgency=medium
* SECURITY UPDATE: certificate validation bypass
- debian/patches/CVE-2014-0092.patch: correct return codes in
lib/x509/verify.c.
- CVE-2014-0092
-- Marc Deslauriers Mon, 03 Mar 2014 14:14:00 -0500
Re: (Score:2)
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
I understand what you're trying to get at; you'd like to have a log of the failure. However unfortunately that wouldn't tell you what you needed to know in this case; if you did have logging on this, the result you'd get would be "client authenticated" even though it was possible that the authentication actually didn't succeed. :-(
The unfortunate truth is that software bugs happen, and bugs that report success are harder to find than bugs that cause a failure.
Nonsense (Score:1)
"Linux" refers to a broad range of systems and vendors
Actually, Linux refers to the operating system kernel which has nothing to do with GnuTLS. (Wow, someone actually uses GnuTLS?)
Re: (Score:2)
Open source can't be patched? (Score:2)
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did
FTFA
GnuTLS developers published this bare-bones advisory that urges all users to upgrade to version 3.2.12. The flaw, formally indexed as CVE-2014-0092, is described by a GnuTLS developer as "an important (and at the same time embarrassing) bug discovered during an audit for Red Hat." Debian's advisory is here.
Re: (Score:2)
Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did
I think the point TFS is trying to make is that GnuTLS maintainers can't just fix the issue and push the fix to end users, it has to go through the vendors first. The same PITA issue that Android users have with OS updates having to go through carriers where sure the tech-savvy minority that happen to know about it can chase down the fix, recompile and re-install their systems but the vast majority of people can't and so are exposed to vulnerabilities for a much longer time.
Editor's "editing" (Score:1)
Now, who was this comment for? Half the stories generate complaints about obcure acronyms and lack of context in the summary, but you manage to throw that in?
Open Source commercial (Score:1)
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
And thanks to the LGPL license of GnuTLS, all the users have the possibility to upgrade their systems, independently of whether Red Hat, Debian, Ubuntu, Apple, Microsoft believe that maintaining those systems is still commercially convenient or not. GPLv3 would be better, as it would give the users the warranty of being able to actually install the updated code into their devices, which is important for non-PCs.
March != April (Score:2)
Looks like someone can't tell the difference between "March" and "April". Hint: "April" is the one that starts with an "A".
The major distros posted patches for this flaw to their repositories within a day or two of it being made public. (Not to say that it isn't embarrassing for stuff like this to make it into the codebase; but at least it was fixed quickly once it was discovered.)
Microsoft PR Fail (Score:4, Interesting)
The irony, of course, is that most people haven't read Microsoft's EULA which effectively says 'Not only are we not responsible if Windows fails, but we'll sue you if you try to fix it yourself.'
This is really gonna bite the hundreds of millions running XP who will be orphaned this year when Microsoft stops supporting it. Not only do they face the prospect, in a matter of weeks, of never again seeing security updates from Microsoft, but it will be illegal to even try to fix future bugs themselves (or hire a third party to do it).
This last bit is something that Linux users have as a right
But but (Score:1)
Oracle installs the Ask toolbar!!!!!!!!!!!!!!
Oh, *those* bugs (Score:2)
The ones that were fixed by the updates for all RHEL-derived distros, like CentOS, a month ago?
mark
Re: (Score:1)
Re: (Score:3, Interesting)
The difference is that with closed source, the only exploits that are discovered by third parties and get fixed are those that have already been exploited, and already resulted in vulnerable systems.
With open source, exploits can potentially be discovered and reported by other parties *before* the exploit has actually ever been used, meaning that a fix is available at the same time that the exploit becomes public knowledge, and anyone who updates as soon as such an exploit becomes known has a higher leve
Re: (Score:1)
This is an unprovable statement. You have no idea how many exploits are discovered by the authors or those in charge of maintaining closed code nor how many of those are fixed.
What your statement really is saying is that the only publicized exploits are those found by third parties. And this is, for the most p
Re: (Score:2)
EIght years is better than never.
This bug was fixed the same day that it became public knowledge. Unless the bug was discovered by the internal team, this will never be case with closed source.
Re: (Score:2)
This bug was fixed the same day that it became public knowledge.
What do you mean "public knowledge"? The code was always there, the bug was always "public knowledge". I think what you really mean is "responsibly disclosed" which also happens regularly in closed-source software.
Re: (Score:2)
The code was always public knowledge.. the bug itself was still unknown until its discovery last month. With closed source, the only way to find a bug is by seeing it happen in a live running instance, while with open source bugs can also be discovered by individuals through inspection of the code itself.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, abso
Re: (Score:2)
The code was always public knowledge.. the bug itself was still unknown until its discovery last month.
Unknown to who? Everybody? You really think responsible disclosure is unique to closed source software? It isn't.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, absolutely everyone must wait for the software's dev team to address the issue.
Yeah nobody disputed that, you're getting confused.
Re:Trust No One (Score:4, Insightful)
Re: (Score:2)
This story should prove once and for all that ... "open source" does not provide any different level of security than closed source.
Um how? It proves that OSS is not perfect. No one ever claimed otherwise. An isolated incident proves nothing about the reltive security of the two.
OpenBSD (OSS) has had a couple of security flaws over the years. Windows 95 also had "some". Doesn't mean they're equally secure.
Re: (Score:2)
GnuPG [gnupg.org] implements RFC4880 [ietf.org]. See also the OpenPGP alliance [openpgp.org]. GnuTLS [gnutls.org] implements SSL, TLS and DTLS. See also OpenSSL [openssl.org] and PolarSSL [polarssl.org].
Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.
It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.