It is more expensive than the sniffer in the article ($120) but very robust. I achieve the requisite frequency agility by handling timing in real-time on the microcontroller on the dongle.
TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.
Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.
Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.
BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 and other venues. For the most recent video see my presentation at USENIX WOOT 13.
In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.
Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.
When Time Warner did the same thing on my connection, they actually returned the RCODE as NXDOMAIN (implying a failure) along with the A records for the advert page. Resolvers which properly/strictly adhere to the RFC would treat the lookup as a failure, which means that for spam purposes this probably wouldn't have caused an issue. My guess is that web browsers aren't quite as concerned with a strict interpretation of the standards, since they want the users to get to the web site they're looking for under even the strangest of circumstances.
In either case, it's still a shady move by the ISP. At least they provide opt-out, which I guess is better than nothing.
In case anyone is wondering how this is possible, remember that you can store basically anything you want in DNS. For opportunistic encryption, you could store a cryptographic public key or an SSL certificate (or perhaps just its digest). Your application would query DNS for the data and, due to DNSSEC, be able to cryptographically verify that the proper owners of your nameserver (i.e., you) are the ones who put it there.
Suppose you don't want to pony up the money for a properly signed SSL certificate from one of the current CAs. You could self-sign the certificate and place the digest for it in DNS. When your web browser receives your certificate, it could be configured to try to look up the SSL digest in DNS. If there's a secure delegation from the root and the digest checks out, you can be pretty sure that the certificate is correct. An attacker would have to steal your DNSKEYs or somehow manage to convince your parent to take his/her DS records instead of yours in order to forge it. About the best they could hope to reasonably pull off is a denial of service by dropping the packets.
If so, then when your ISP queries one of the thirteen root servers for the.gov authority, the attacker could still return a fake response and set himself up as the DNS authority for.gov, at least as far as your ISP knew.
Anyone know how plausible that attack remains? Knowledgeable responses welcome:)
First, to answer your question regarding the plausibility: there are a few scenarios in which it is possible. The most likely scenario is that you're on the same local network as an attacker so that he/she can intercept your DNS traffic and forge replies. This might be the case when you're using the wireless provided at a coffee shop, for instance. There exist automated tools to make this simple, and I would consider this the biggest vector of attack. The only other case I can think of is that an attacker has control of a router between you and the root servers. While this is technically possible, I would personally regard it as fairly infeasible for the average attacker. If you're in $THIRD_WORLD_COUNTRY and the mob controls internet access, you might have something to worry about.
I'm involved with a project called SecSpider that monitors the deployment of DNSSEC. We use a distributed network of pollers around the world to collect RRsets from all known DNSSEC-enabled zones. One of the reasons we use pollers from different locations is to detect attacks such as either of the two listed above, more likely the latter. If any attack were to occur, we stand the best chance of detecting it. We have been monitoring since 2005 and have yet to see such an attack.
An additional benefit of collecting all these RRsets is that we have what we call a "world-wide perspective" on DNSKEYs. Whenever we collect a set of DNSKEY RRsets from a zone, if the set is consistent across pollers, we add it to our DLV repository. A DLV (DNSSEC lookaside validation) resource record is very similar to a DS (delegation signer) record. It contains a cryptographic hash of the DNSKEYs served by a zone so that the zone's integrity can be checked. However, instead of being served by the zone's parent, it can be served by anyone.
The typical way in which a resolver detects if a zone is secure is by tracing a secure delegation from the root. Instead of the typical manner of starting at the root and querying recursively for NS records, the resolver queries for both NS and DS records. Then when it queries one of the nameservers listed in the NS records, it asks for the DNSKEYs and verifies them using the DS record. In this way, it is possible to build a chain of trust that leads all the way back to the root nameservers.
Unfortunately, without the root being signed, this process will not work. One alternative is to configure your resolver to query for DLV records to bootstrap the process. When your resolver queries a zone for DNSKEY RRs, it will also query the DLV repository for a DLV recording matching that zone. It will then attempt to cryptographically verify the DNSKEYs using that record. If it verifies, you know that someone you trust thinks your DNSKEYs are right, side-stepping the typical chain of trust (thus the name: "lookaside"). If you were to configure your resolver to use our repository, you would be able to verify if the DNSKEYs you receive are the same as the DNSKEYs being seen by all of our pollers around the world. Not perfect security, but definitely an improvement on the current situation.
If you're interested in the details of our project, you can check out our web site or ask me for more details. We have information on how to use our repository in our FAQ.
You mention the notion of real-world testing of DNSSEC. It's worth noting that there are actually several TLDs that are currently signed (mostly ccTLDs), as well as a large number of second-level domains. gov is hardly the first, but it should definitely be the highest-profile rollout to date. We're currently waiting with bated breath to see the outcome.
This exact sort of system has been in place for years at PerlMonks, to excellent effect. These guys just took it and applied it to programming questions in general.
I don't suspect you'll even be able to find a FULLY compliant SMTP or HTTP client or server. Possibly something on the FTP client list.
HTTP is extensible, once you take that into account its practically impossible to have 100% interoperability. My web browser for instance could give a damn about the fact that IIS says its running ASP.NET crap.
Even my browser doesn't know what to do with the ASP.NET header, it still works. Actually, it does know what to do with it, which is nothing, but thats coincidence in this case. Some other web server could possibly send me a header that DOES require action of some sort, and my browser may not know what to do with it. But I'm not really worried about not viewing pages.
Your browser most likely is fully compatible with the HTTP standard. There is a fixed list of headers which can be sent and received and are required to be interpreted by a compliant client. The extensions of which you speak must use a header whose name begins with "X-", such as Slashdot's "X-Bender" and anything extra sent by IIS (sorry, not familiar with any of them). A browser may ignore all such headers and remain fully compliant with the RFC. Unsurprisingly, they take such things into account when writing standards.
You jumped from standards compliance to interoperability, which are two separate things. However, the latter typically follows the former. If a web server sends an extension header which alters the semantics of HTTP, it clearly won't be interoperable with compliant client. On the other hand, it isn't likely to be compliant itself.
I'd prefer if people used SIP I guess if it wasn't because people have a hard time getting it to work behind firewalls.
SIP itself is typically just as simple to get working from behind a firewall as most any other chat protocol. It normally uses a single TCP stream for text chat and as a control channel, and firewalls have been able to adequately forward TCP streams forever.
The problems start when you want to establish voice or video chat, since those require end-to-end UDP packet delivery. The only (semi-)effective ways to do that when behind a firewall are establishing a rapport with the firewall (e.g., UPnP) or playing games with the NAT box (e.g., STUN). Do note, however, that this is not unique to SIP. Pretty much every chat protocol needs to do the same thing when establishing a real-time stream unless it channels that stream through the central server, which is hardly ever done due to cost.
What you're talking about is called Mobile IP, which is standardized by RFC 3344. Doesn't seem to be used very widely, probably because the density of 802.11 access points isn't high enough for it to be useful in most areas.
Bummer, but at least all's well that ends well (sort of). For what it's worth, we had the same sound sync issues on Linux natively in the good old days of Flash 7.
Can't you use FreeBSD's Linux binary compatibility to run the Linux version of Firefox with its native version of Flash? If it's possible, it seems like less of a hack and more likely to perform better.
Microsoft owns several patents related to Silverlight, covering both implementation and concepts. Microsoft promises that it will not sue the Moonlight team over any of these patents. However, a promise is not a legal agreement.
How much faith do you have in Microsoft keeping its promises?
On Debian or Ubuntu, install the package uml-utilities, which is from an older form of virtualization (popular around 2002) called user-mode Linux. One of the tools included is called tunctl, and it allows you to create what are called persistent TUN/TAP devices. Write a simple script to run as root at boot that creates the TAP device owned by the Qemu user and adds that to the bridge. Then in Qemu (probably Virtualbox too, but I've never used it), you just specify to use that specific numbered TAP device for your networking. The only permissions you then need are that the user have write access to/dev/net/tun or your OS's equivalent.
I've been doing this for years, no sudo funny business necessary.
To save you all the horror and pain of reading TFA (since TFS doesn't state), Schweickart is suggesting we either push or pull them away with unmanned spacecraft.
Perl is to programming languages what English is to natural languages: easy to fool around with, hard to learn well, but when you do, the expressive power is incredible. And when you mess it up, nobody understands what you're trying to say.
Unfortunately that's politically non-expedient. But now that this vulnerability is out there, maybe the political will can at last materialize.
The political will has been shifting a lot lately. I've spoken directly to the gentleman in charge of managing the root zone, and he says that technically speaking it would be an overnight change. All the DNSKEYs and RRSIGs have been generated, he's waiting for the OK from above, which he says appears to be more likely with each passing day.
The second-best solution is to deploy DNSSEC using DNSSEC Lookaside Validation (which means you get trust anchors from some other known site, not from the root zone). And that's available now.
The largest DLV repository that validates that the DNSKEYs belong to who they say they belong to (think Verisign-style verification), is run by isc.org. At this writing, this zone has a grand total of twenty five DLV records. Not exactly what I would call useful from a security standpoint, although it is a start.
I'm a part of a DNSSEC monitoring project (called SecSpider). We have a set of pollers distributed around the world from which we collect data about the current deployment. In conjunction with this, when we are able to collect an identical DNSKEY RRset, we generate DLV records and serve them from one of our delegations. For details on how to use it, check out our blog. This serves the same purpose as ISC's repo, but the data is collected in an orthogonal manner. We currently have DLV records for over 12000 zones, although we haven't directly verified the identity of any of them.
The worst thing about DNSSEC is it's too damn complicated at present; there needs to be the equivalent of "one-click" zone signing. ISC (and others) are working on getting us closer to that.
This I can't disagree with. DNSSEC is over-engineered by academic crypto people. In fact, DNS in general is somewhat over-engineered, but at least it was successfully rolled out. ISC's efforts are valiant, and hopefully with a larger roll-out their tools will become de-facto.
The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration. There's a difference between "harder" and "impossible" though.
Yes, the difference is that impossible isn't possible. You can't stop a determined hacker, not even with the best technology (think of social engineering attacks). Security is like an onion: as soon as you pull away one layer there are a dozen more to get in your way.
Hear hear! I still can't understand why Perl is downplayed as a language. It has a great set of builtin functions, an incredible community (see CPAN and Perl Monks), can be written in a style that looks and functions exactly like C, and above all, its performance is pretty good.
As noted, it can be used as C on steroids: built-in automatically growing/shrinking arrays, hashes (dictionaries to some), and completely automatic garbage collection. The syntax, being eminently flexible, can be made to look damn similar to C's.
Beyond that, it gives you much more expressive power. In my opinion, in some situations it can be much more meaningful to say something like return unless $t > 0 versus the equivalent if (!($t > 0)) { return; }. Subtle things like that allow code to flow much more freely, and that's barely even scratching the surface.
Perl gives you room to grow well beyond C (without requiring it, of course). Functional programming techniques abound since Perl's array data structure works equally well as a Lisp-like list. It has builtins such as map and grep and a standard bundled module that provides reduce, so virtually any functional programming task can be implemented easily.
With everything it's got going for it, sometimes I'm left scratching my head as to why it's not used more widely. A couple of bad programmers write line noise and suddenly the whole reputation of the language is at stake. A sad thing indeed.
It's a chicken and egg problem. Not surprisingly, most academic journals and conferences have a certain amount of respect associated with them. You can't go out and publish to OpenConference and expect anyone to pay it any heed, since literally anyone can host a conference or publish a journal. People will look at your CV and go ``well that's great that you have a hundred pubs to CreativeCommonsJournal, but the only one on here I'm going to take seriously is SIGCOMM.''
About the only hope would be to get some big names to either host or publish to some of these open conferences and journals to lend them some credibility and maybe even talk them up a little. However, even if you convince them to do it, it will be a slow process for a publication to gain any amount of respect in the academic community. I'm not saying it's impossible, it's just a huge undertaking.
I'd love to see a group of people start something like this, but remember: it takes big names, at least IMHO. I'm lucky that the field in which I work (internet-scale research), the conferences and publications are very open about sharing their work freely, and that seems to be the case in most fields of computer science. It's only the hard sciences that I've really noted a tendency to have to purchase articles. Probably something to do with the open-minded nature CS has always had toward intellectual property.
Slashdot Mirror
I built a BLE sniffer on Ubertooth which does capture traffic on BLE data channels. Also I wrote a tool that can crack the pairing protocol and decrypt the data.
It is more expensive than the sniffer in the article ($120) but very robust. I achieve the requisite frequency agility by handling timing in real-time on the microcontroller on the dongle.
Hi, I'm a Bluetooth Security researcher. My primary focus is on BLE for which I built a highly robust sniffer on the Ubertooth platform. I have experience in other aspects of Bluetooth.
TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.
Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.
Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.
BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 and other venues. For the most recent video see my presentation at USENIX WOOT 13.
In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.
Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.
When Time Warner did the same thing on my connection, they actually returned the RCODE as NXDOMAIN (implying a failure) along with the A records for the advert page. Resolvers which properly/strictly adhere to the RFC would treat the lookup as a failure, which means that for spam purposes this probably wouldn't have caused an issue. My guess is that web browsers aren't quite as concerned with a strict interpretation of the standards, since they want the users to get to the web site they're looking for under even the strangest of circumstances.
In either case, it's still a shady move by the ISP. At least they provide opt-out, which I guess is better than nothing.
It's all a huge ploy by the guys at asciipr0n.com!
In case anyone is wondering how this is possible, remember that you can store basically anything you want in DNS. For opportunistic encryption, you could store a cryptographic public key or an SSL certificate (or perhaps just its digest). Your application would query DNS for the data and, due to DNSSEC, be able to cryptographically verify that the proper owners of your nameserver (i.e., you) are the ones who put it there.
Suppose you don't want to pony up the money for a properly signed SSL certificate from one of the current CAs. You could self-sign the certificate and place the digest for it in DNS. When your web browser receives your certificate, it could be configured to try to look up the SSL digest in DNS. If there's a secure delegation from the root and the digest checks out, you can be pretty sure that the certificate is correct. An attacker would have to steal your DNSKEYs or somehow manage to convince your parent to take his/her DS records instead of yours in order to forge it. About the best they could hope to reasonably pull off is a denial of service by dropping the packets.
First, to answer your question regarding the plausibility: there are a few scenarios in which it is possible. The most likely scenario is that you're on the same local network as an attacker so that he/she can intercept your DNS traffic and forge replies. This might be the case when you're using the wireless provided at a coffee shop, for instance. There exist automated tools to make this simple, and I would consider this the biggest vector of attack. The only other case I can think of is that an attacker has control of a router between you and the root servers. While this is technically possible, I would personally regard it as fairly infeasible for the average attacker. If you're in $THIRD_WORLD_COUNTRY and the mob controls internet access, you might have something to worry about.
I'm involved with a project called SecSpider that monitors the deployment of DNSSEC. We use a distributed network of pollers around the world to collect RRsets from all known DNSSEC-enabled zones. One of the reasons we use pollers from different locations is to detect attacks such as either of the two listed above, more likely the latter. If any attack were to occur, we stand the best chance of detecting it. We have been monitoring since 2005 and have yet to see such an attack.
An additional benefit of collecting all these RRsets is that we have what we call a "world-wide perspective" on DNSKEYs. Whenever we collect a set of DNSKEY RRsets from a zone, if the set is consistent across pollers, we add it to our DLV repository. A DLV (DNSSEC lookaside validation) resource record is very similar to a DS (delegation signer) record. It contains a cryptographic hash of the DNSKEYs served by a zone so that the zone's integrity can be checked. However, instead of being served by the zone's parent, it can be served by anyone.
The typical way in which a resolver detects if a zone is secure is by tracing a secure delegation from the root. Instead of the typical manner of starting at the root and querying recursively for NS records, the resolver queries for both NS and DS records. Then when it queries one of the nameservers listed in the NS records, it asks for the DNSKEYs and verifies them using the DS record. In this way, it is possible to build a chain of trust that leads all the way back to the root nameservers.
Unfortunately, without the root being signed, this process will not work. One alternative is to configure your resolver to query for DLV records to bootstrap the process. When your resolver queries a zone for DNSKEY RRs, it will also query the DLV repository for a DLV recording matching that zone. It will then attempt to cryptographically verify the DNSKEYs using that record. If it verifies, you know that someone you trust thinks your DNSKEYs are right, side-stepping the typical chain of trust (thus the name: "lookaside"). If you were to configure your resolver to use our repository, you would be able to verify if the DNSKEYs you receive are the same as the DNSKEYs being seen by all of our pollers around the world. Not perfect security, but definitely an improvement on the current situation.
If you're interested in the details of our project, you can check out our web site or ask me for more details. We have information on how to use our repository in our FAQ.
You mention the notion of real-world testing of DNSSEC. It's worth noting that there are actually several TLDs that are currently signed (mostly ccTLDs), as well as a large number of second-level domains. gov is hardly the first, but it should definitely be the highest-profile rollout to date. We're currently waiting with bated breath to see the outcome.
This exact sort of system has been in place for years at PerlMonks, to excellent effect. These guys just took it and applied it to programming questions in general.
Your browser most likely is fully compatible with the HTTP standard. There is a fixed list of headers which can be sent and received and are required to be interpreted by a compliant client. The extensions of which you speak must use a header whose name begins with "X-", such as Slashdot's "X-Bender" and anything extra sent by IIS (sorry, not familiar with any of them). A browser may ignore all such headers and remain fully compliant with the RFC. Unsurprisingly, they take such things into account when writing standards.
You jumped from standards compliance to interoperability, which are two separate things. However, the latter typically follows the former. If a web server sends an extension header which alters the semantics of HTTP, it clearly won't be interoperable with compliant client. On the other hand, it isn't likely to be compliant itself.
SIP itself is typically just as simple to get working from behind a firewall as most any other chat protocol. It normally uses a single TCP stream for text chat and as a control channel, and firewalls have been able to adequately forward TCP streams forever.
The problems start when you want to establish voice or video chat, since those require end-to-end UDP packet delivery. The only (semi-)effective ways to do that when behind a firewall are establishing a rapport with the firewall (e.g., UPnP) or playing games with the NAT box (e.g., STUN). Do note, however, that this is not unique to SIP. Pretty much every chat protocol needs to do the same thing when establishing a real-time stream unless it channels that stream through the central server, which is hardly ever done due to cost.
What you're talking about is called Mobile IP, which is standardized by RFC 3344. Doesn't seem to be used very widely, probably because the density of 802.11 access points isn't high enough for it to be useful in most areas.
I've finally found it, nearly as rare as the (Score 5, Troll) is the undecorated (Score 5). This illustrious find with go down with the ages!
Bummer, but at least all's well that ends well (sort of). For what it's worth, we had the same sound sync issues on Linux natively in the good old days of Flash 7.
Can't you use FreeBSD's Linux binary compatibility to run the Linux version of Firefox with its native version of Flash? If it's possible, it seems like less of a hack and more likely to perform better.
Microsoft owns several patents related to Silverlight, covering both implementation and concepts. Microsoft promises that it will not sue the Moonlight team over any of these patents. However, a promise is not a legal agreement.
How much faith do you have in Microsoft keeping its promises?
On Debian or Ubuntu, install the package uml-utilities, which is from an older form of virtualization (popular around 2002) called user-mode Linux. One of the tools included is called tunctl, and it allows you to create what are called persistent TUN/TAP devices. Write a simple script to run as root at boot that creates the TAP device owned by the Qemu user and adds that to the bridge. Then in Qemu (probably Virtualbox too, but I've never used it), you just specify to use that specific numbered TAP device for your networking. The only permissions you then need are that the user have write access to /dev/net/tun or your OS's equivalent.
I've been doing this for years, no sudo funny business necessary.
So by that token, is a huge toolbar with buttons for every possible function more useful than a two-level hierarchy of well-organized menus?
To save you all the horror and pain of reading TFA (since TFS doesn't state), Schweickart is suggesting we either push or pull them away with unmanned spacecraft.
The real question on everyone's minds is, of course, was Natalie Portman involved? If so, was she naked and/or petrified?
Guess it really depends on where you are (or probably more poignantly, where you think you are) on the bathtub curve.
You went two plus years without installing a kernel patch? During what period of two years was that even possible?
If anything, I was trying to praise Perl. Guess the mods around here just have a twisted sense of humor.
Perl is to programming languages what English is to natural languages: easy to fool around with, hard to learn well, but when you do, the expressive power is incredible. And when you mess it up, nobody understands what you're trying to say.
The political will has been shifting a lot lately. I've spoken directly to the gentleman in charge of managing the root zone, and he says that technically speaking it would be an overnight change. All the DNSKEYs and RRSIGs have been generated, he's waiting for the OK from above, which he says appears to be more likely with each passing day.
The largest DLV repository that validates that the DNSKEYs belong to who they say they belong to (think Verisign-style verification), is run by isc.org. At this writing, this zone has a grand total of twenty five DLV records. Not exactly what I would call useful from a security standpoint, although it is a start.
I'm a part of a DNSSEC monitoring project (called SecSpider). We have a set of pollers distributed around the world from which we collect data about the current deployment. In conjunction with this, when we are able to collect an identical DNSKEY RRset, we generate DLV records and serve them from one of our delegations. For details on how to use it, check out our blog. This serves the same purpose as ISC's repo, but the data is collected in an orthogonal manner. We currently have DLV records for over 12000 zones, although we haven't directly verified the identity of any of them.
This I can't disagree with. DNSSEC is over-engineered by academic crypto people. In fact, DNS in general is somewhat over-engineered, but at least it was successfully rolled out. ISC's efforts are valiant, and hopefully with a larger roll-out their tools will become de-facto.
Yes, the difference is that impossible isn't possible. You can't stop a determined hacker, not even with the best technology (think of social engineering attacks). Security is like an onion: as soon as you pull away one layer there are a dozen more to get in your way.
Hear hear! I still can't understand why Perl is downplayed as a language. It has a great set of builtin functions, an incredible community (see CPAN and Perl Monks), can be written in a style that looks and functions exactly like C, and above all, its performance is pretty good.
As noted, it can be used as C on steroids: built-in automatically growing/shrinking arrays, hashes (dictionaries to some), and completely automatic garbage collection. The syntax, being eminently flexible, can be made to look damn similar to C's.
Beyond that, it gives you much more expressive power. In my opinion, in some situations it can be much more meaningful to say something like return unless $t > 0 versus the equivalent if (!($t > 0)) { return; }. Subtle things like that allow code to flow much more freely, and that's barely even scratching the surface.
Perl gives you room to grow well beyond C (without requiring it, of course). Functional programming techniques abound since Perl's array data structure works equally well as a Lisp-like list. It has builtins such as map and grep and a standard bundled module that provides reduce, so virtually any functional programming task can be implemented easily.
With everything it's got going for it, sometimes I'm left scratching my head as to why it's not used more widely. A couple of bad programmers write line noise and suddenly the whole reputation of the language is at stake. A sad thing indeed.
It's a chicken and egg problem. Not surprisingly, most academic journals and conferences have a certain amount of respect associated with them. You can't go out and publish to OpenConference and expect anyone to pay it any heed, since literally anyone can host a conference or publish a journal. People will look at your CV and go ``well that's great that you have a hundred pubs to CreativeCommonsJournal, but the only one on here I'm going to take seriously is SIGCOMM.''
About the only hope would be to get some big names to either host or publish to some of these open conferences and journals to lend them some credibility and maybe even talk them up a little. However, even if you convince them to do it, it will be a slow process for a publication to gain any amount of respect in the academic community. I'm not saying it's impossible, it's just a huge undertaking.
I'd love to see a group of people start something like this, but remember: it takes big names, at least IMHO. I'm lucky that the field in which I work (internet-scale research), the conferences and publications are very open about sharing their work freely, and that seems to be the case in most fields of computer science. It's only the hard sciences that I've really noted a tendency to have to purchase articles. Probably something to do with the open-minded nature CS has always had toward intellectual property.