Development of libreswan vs openswan

Posted on by
6

animated

UPDATE: Statistics updated to include 2017

Yesterday, openswan released version 2.6.40 to address CVE-2013-6466. You might be confused by its changelog (not the non-updated CHANGES) crediting me for the vast majority of code changes. . Basically all changes are pulled from the libreswan repository and are backports to openswan. The exception is their version of a patch for CVE-2013-6466. Libreswan’s fix is not a band-aid but an updated state machine. The backported libreswan fix is what is going into the updated openswan packages for RHEL5 and RHEL6 and are available at libreswan.org/security/openswan/CVE-2013-6466. RHEL7 will contain libreswan.

Basically, yesterday’s openswan 2.6.40 release brings it up to the initial libreswan-3.0 release of two years ago, plus the two CVE issues. Except that it crashes KLIPS and backported a libreswan commit that broke all non-XAUTH IPsec connections.

History and implementation status of Opportunistic Encryption for IPsec

Posted on by
4

(as sent to the cryptography mailing list)

FreeS/WAN

In light of the NSA achievements, a few people asked about the FreeS/WAN IPsec OE efforts and whatever happened to it.

The short answer is, we failed and got distracted. The long answer follows below. At the end I will talk about the current plans that have lingered in the last two years to revive this initiative. Below I will use the word “we” a lot. Its meaning changes based on the context as various communities touched, merged, intersected and drifted apart.

NOTE: On September 28, 2013 there is be a memorial service in Ann Arbour for Hugh Daniel, manager of the old IPsec FreeS/WAN Project. Various crypto people will attend, including a bunch of us from freeswan. Hugh would have loved nothing better than his memorial service being used as a focal point to talk about “new OE”, so that’s what we will do on Saturday and Sunday. If you are interested in attending, feel free to contact me.

OE in a nutshell

For those not familiar with IPsec OE as per FreeS/WAN implementation. When activated, a host would install a blocking policy for 0.0.0.0/0. Every packet to an IP address would trigger the kernel to hold the packet and signal the IKE daemon to go find an IPsec policy for that destination. If found, the tunnel would be build, and an IPsec tunnel to the remote IP would be established, and packets would flow. If no policy was found, a “pass” hole was poked so packets would go out unencrypted. Public keys for IP addresses were looked up in the reverse DNS by the IKE daemon based on the destination address. To help with roaming clients (roadwarriors), initiators could store their public key in their FQDN, and convey their FQDN as ID when performing IKE so the remote peer could look up their public key in the forward DNS. This came at the price of two dynamic clients not being able to do OE to each other. (turns out they couldn’t anyway, because of NAT)

What were the reasons for failing to encrypt the internet with OE IPsec (in no particular order):

1) Fragmentation of IPsec kernel stacks

In part due to the early history of FreeS/WAN combined with the export restrictions at the time. Instead of spending more time on IKE and key management for large scale enduser IPsec, we ended up wasting a lot of time fixing the FreeS/WAN KLIPS IPsec stack module for each Linux release. Another IPsec stack, which we dubbed XFRM/NETKEY appeared around 2.6.9 and was backported to 2.4.x. It was terribly incomplete and severely broken. With KLIPS not being within the kernel tree, it was never taken into account. XFRM/NETKEY remained totally unsuitable for OE for a decade. XFRM/NETKEY now has almost all functionality needed – I found out today it shoudl finally have first+last packet caching for dynamic tunnels, which are essential for OE. Since the application’s first packet triggered the IKE mechanism, the application would start retransmitting before IKE was completed. Even when the tunnel finally came up, the application was usually still waiting on that TCP retransmit. David McCullough and I still spend a lot of time fixing up KLIPS to work with the current Linux kernel. Look at ipsec_kversion.h just to see what a nightmare it has been to support Linux 2.0 to 2.6 (libreswan removed support for anything lower then recent 2.4.x kernels)

Linux IPsec Crypto hardware acceleration in practise is only possible with KLIPS + OCF, as the mainstraim async crypto is lacking in hardware driver support. If you want to build OE into people’s router/modem/setup box, this is important, though admittingly less so as time has moved on and even embedded hardware and phones are multicore or have special crypto CPU instructions.

An effort to make the kernel the sole provider of crypto algorithms that everyone could use also failed, and the idea was abandoned when CPU crypto instructions appeared directly accessable from userland.

2) US citizens could not contribute code or patches to FreeS/WAN

This was John Gilmore’s policy to ensure the software remained free for US citizens. If no US citizen touched the code, it would be immune to any presidential National Security Letter. I believe this was actually the main reason for KLIPS not going in mainstream kernel, although personal egos of kernel people seemed to have played a role here as well. Freeswan people really tried had in 2000/2001 to hook KLIPS into the kernel just the way the kernel people wanted. (Ironically, the XFRM/NETKEY hook so bad, it even confuses tcpdump and with it every sysadmin trying to see whether or not their traffic is encrypted) I still don’t fully understand why it was never merged, as the code was GPL, and it should have just been merged in, even against John’s wishes. Someone would have stepped in as maintainer – after all the initial brunt of the work had been done and we had a functional IPsec stack.

In the summer of 2003, I talked to John and together we agreed it was time to fork. Openswan was born to clearly indicate US coders could contribute. However, at that point the (then crappy) FRM/NETKEY IPsec stack was there to prevent OE from working due to the missing first+last packet caching. The FreeS/WAN Project ended and Openswan continued. At first in good pace, but that later slowed down and OE was no longer its focal point. (Due to legal reasons, I cannot go into details regarding the openswan history)

3) Not using DNS without DNSSEC

There were various issues that caused DNSSEC to get massively delayed. We needed DNSSEC to secure our DNS based distributed public key platform. Although it would have worked fine to use DNS against passive attackers (NSA trawling), we believed it was principly wrong to trust cryptographic material that was untrusted and vulnerable against active attacks. So while the developers encouraged people to put keys in DNS even without security, no one else picked it up. It sucks to need to say ‘we told you so’. But we should have really not waited on DNSSEC.

4) Dealing with the DNS working groups at IETF

The DNS community is one of the most pedantic group of people I know. They are very smart, often right, and had been known to be extremely defense of their DNS turf. (Note that things have improved considerably and if you think this is still an issue, I’m happy to try and help)

IETF was divided about the convergence of the “security of the DNS” and the “DNS as PKI” despite that this had always been a goal of DNSSEC for a large group of people within the IETF. The FreeS/WAN people were driving DNSSEC not so much for DNS as for the key distribution. After all, you can detect DNS forging if you know your public keys.

When we had the KEY/SIG records ready to go, it was decreed that it could only be used for the DNS itself. Applications could not use this KEY record. To make that distinction more clear, on the next change in the draft protocol, KEY was obsoleted and DNSKEY introduced. So IPsec keys were relegated back to TXT, since at the time we had no Generic Record format (RFC 3597) support, so waiting for any new RRtype to get any deployment to become usuable would take years. Almost everyone was on bind4 and never upgraded left us with no other choice but the TXT. Even though we wrote the OE and IPSECKEY RFCs, OE’s only deployments were done using TXT records.

5) DNSSEC was delayed by a decade

DNSSEC deployment was slowly gaining traction, but I think we really needed the Kaminsky bug to get that extra push for DNSSEC outside the geeks of the IETF. The US government mandate for DNSSEC in .GOV helped as well. But by this time, OE was mostly forgotten.

djb repeatedly tried to peddle his own warez. While not at all realistic, it always gained a lot of hype and media attention and probably did cause delays of DNSSEC deployment.

Kaminsky himself was shooting down DNSSEC too. I personally heckled him at various Black Hat’s and ICANN conferences until we finally sat down for a couple of hours to talk about DNSSEC’s history and design goals. I’ll claim my 15 minutes of fame for having converted him. It helped having Kaminsky say that although he didn’t like the complexity, he couldn’t see anything better. DNSSEC was needed for everyone.

DNSSEC was gaining traction. Then we ran into a bunch of DNSSEC deployment issues. We had the delays due to NSEC vs NSEC3 with OPTIN, and then on top of that in 2008 when the first big ISP in Sweden turned on DNSSEC in their resolvers all that traction was blown away.

Most consumer routers ran DNS proxies that implemented DNS as “known bitstreams” instead of implemeting the actual DNS protocol. The DNSSEC OK bit caused thousands of routers to drop DNSSEC packets as “invalid DNS”. The only realistic solution: Turn it off and wait two years for those routers to get obsoleted by faster wifi standards and talk to those vendors so they would not repeat their mistake with their next generation of routers.

We now have the IPSECKEY record format (though RFC 4025 is not useful, see below) and RFC 3597 for the generic DNS record deployed on all DNS servers. And we’re on our way to have DNSSEC on every end node (see also draft-wouters-edns-tcp-chain-query-00 I just submitted to the IETF)

We have a mostly clean working UDP/TCP port 53 transport for DNSSEC on most networks (in part thanks to Google DNS). Although our hotspot handling is still a little rough, with dnssec-trigger the only tool to hack configurable DNSSEC support into the OS for our coffee shop visits when we need to rely on forged DNS.

6) When you’re NAT on the net, you’re NOT on the net.

Opportunistic Encryption relied on a clear peer to peer connection. But we managed to degrade the internet into servers and clients. NAT was the biggest problem, and with CGN around the corner, it’s not something that is going away despite IPv6 offering enough IPs for everyone. In fact, for our “new OE”, this is the biggest hurdle to overcome. When Alice cannot talk to Bob because she cannot reach him due to a (carrier grade) NAT, we are stuck wildly poking holes and hoping packets flow.

7) The reverse DNS tree is dead Jim

OE depended on the reverse tree as a security mechanism that someone who was claiming a public key for a specific IP range was actually the legitimate owner of that IP space. It was the security method for RFC-4025.

But unless you are running in a datacenter, you do not have access to the reverse DNS. It is useless as key distribtion method. On top of that, large IPv6 deployments don’t even care any more to run any authoritative DNS for their reverse.

8) BTNS

The IETF tried to revive this OE with the Better Then Nothing Security (“BTNS”) working group. Contrary to the name, they also fell into the “perfect is the enemy of good” trap and most discussion seemed to go into “channel binding” to upgrade anonymous IPsec to some kind of authenticated IPsec – at least by the time I became aware of them. In other words, the most important problem of key distribution was left outside the scope and no one actually seemed to have implemented anything. Though I have to admit, I’m behind on reading the VPN auto-discovery drafts. It is just
very discouraging to still be reading problem statement drafts. More over, I don’t think we should setup IPsec tunnels based on packets hitting the kernel. We have better ways now that we can leverage DNSSEC.

9) We were all complacent

The only interest for IPsec was for corporate VPNs. During the above listed problem periods, OE people gave up. Some walked away from IETF. While everyone gained an always-on portable IP device,
their crypto capabilities were practically non-existent. My current iphone 5 can connect to a corporate VPN, but trying to make it _just_ send out encrypted packets is impossible. Some trickery can be used to cause almost any packet to setup the VPN, but while that’s going on it is still leaking like a sieve. VPN is seen by phone vendors as a method to gain some enterprise users, not as the tool to protect the consumer. The Apple VPN client is a 10+ year old patched version of racoon. The only vendor that took VPNs seriously was RIM and we punished them by not buying their products, because we had other priorities like FourSquare, Facebook and Twitter.

We can only hope that those PRISM players are now put under economic pressure by frightened consumers to fix this. But as long as VPNs and DNSSEC is slow and error-prone, it is better for them not to go there.

The New Opportunistic Encryption

I’ve been brainstorming with various people on how to put IPsec OE back on the table. I’ve discussed this with a bunch of people around me, including the late Hugh Daniel, John Gilmore and Hugh Redelmeier of freeswan.

The packet capturing 0.0.0.0/0 policy is not a good method because we cannot make any decision on where to find a public key for an IP address. The reverse is unusable, and IP addresses change often. We used it because we had nothing better. But now we do. Since every (secure) platform now runs DNSSEC on the end node, we can use this as our decision making point. Imagine my phone running a DNSSEC resolver (say unbound) and an IKE daemon (say libreswan). The DNS server has access to the set of DNS name and matching IP address. It can lookup the key in the forward DNS zone, and hand over the public key, dns name and IP address to the IKE daemon!

1) User tells browser to go to www.cypherpunks.ca

2) browser does a lookup for the A/AAAA record of www.cypherpunks.ca

3) DNSSEC resolver performs the lookup/validation for the A/AAAA record of www.cypherpunks.ca and additionally looks up the IPSECKEY record of www.cypherpunks.ca.

4a) The resolver will wait with returning the A/AAAA record to the browser until it knows if the IPSECKEY record exists or not. If not, it releases the A/AAA answer to the application. Packets flow in the clear.

4b) The resolver finds an IPSECKEY record. It sends the pubic key, the FQDN and the IP address(es) to the IKE daemon and waits for a response. Meanwhile it does _not_ release the A/AAAA record to the application.

5) The IKE daemon sets up the IPsec tunnel. We haven’t reached agreement yet over how this should be done. There are two choices:

a) The client uses an “@anonymous” ID for itself along with sending its public key inline with IKE. The client is responsible for ensuring there is no MITM attack, as it knows the server’s public key (from DNSSEC). The responding server will just use any key it received inline if it was received for the “@anonymous” ID.

b) The initiator (aka client) uses its own FQDN-based ID. It has preconfigured its DNS so that an IPSECKEY record exists for its FQDN (protected by DNSSEC). The key is not send inline with IKE. Instead, when the responder (aka server) sees the non-anonymous ID, it will perform a DNSSEC secured lookup to obtain the IPSECKEY out of band. Both parties confirm there is no MITM.

The advantage of a) is that it leaks less user information and makes tracking users harder. The client can regularly generate another anonymous keypair. The disadvantage of a) is that it turns peers into clients and servers. And two clients cannot initiate OE to each other.

6) The tunnel is established and the IKE daemon notifies the local DNSSEC server that had instructed it to setup the IPsec tunnel.

7) The resolver releases the IP address to the application.

8) The applications starts sending packets and the IPsec policy encrypts them al.

I’m personally in favour of the @anonymous solution. But there is no reason why support for both could not be implemented.

What are some of the obstacles and work to do:

1) writing the unbound plugin

2) writing the support for @anonymous for the server-side. This includes raw keys for IKEv2 (draft-ietf-ipsecme-oob-pubkey)

3) With NAT, the client suggests an inner-IP. This could be abused or clash, We need to ‘contain’ each connection, possibly using generated ipv6 addresses 4) We cannot use the “gateway” field of RFC-4025, or people could trick a server into giving a client all communication to a certain IP address that does not belong to them

5) anonymous connections should generate throw-away keys to remain anonymous

6) implement draft-wouters-edns-tcp-chain or else latency/RTTs will prevent real-life deployment of DNSSEC validated IPSECKEYs on mobile devices.

7) This allows no upgrading from anonymous to mutually authenticated, but IKE policies can be added to the server/client that would match on different IDs (eg X.509) that work independantly of OE without introducing complicated channel binding promotion code. Other IKEv2 extensions could possible be applied to facilitate promotions.

I’m sure more implementation issues will show up once we get this going, but there are no real fundamental issues why we cannot deploy this in a couple of months of time. My plan is to get libreswan to support this version of OE. Additionally, once we use draft-wouters-edns-tcp-chain, it becomes cheap to do these lookups through the tor network. If the tor exit nodes then also feed each other with DNSSEC cache material, it should make tracing individual clients even harder.

(anyone willing to assist, especially with coding, do contact me)

Why I think Heml.is is snákaolía

Posted on by
Reply

Heml.is is a new instant message client promise that is “beautiful & secure” that seems to have cashed in on the current NSA scare, by lifting on the good (bad?) name of one of the Pirate Bay founders. Apparently, people have committed $150 USD for this in two days.

heml.is

Clearly people believe hemlis will offer something that the 62 apps in the Google Play store, and over a 1000 apps in the Apple App Store don’t offer…..

What do they promise? Let’s first go through their claims in their video:

“no one can spy on you, not even us”
“only your friend can read what you write”
“based on end to end encryption”

“We are building Heml.is on top of proven technologies, such as XMPP with PGP”

Great. So full trustworthy end to end encryption. Which means you can do this over ANY insecure transport mechanism. I could post those encrypted IMs on my blog – only the intended recipient would be able to decrypt it. Very secure. But it raises another question:

“We are building Heml.is on top of proven technologies, such as XMPP with PGP”

Great. So full trustworthy end to end encryption. Which means you can do this over ANY insecure transport mechanism. I could post those encrypted IMs on my blog – only the intended recipient would be able to decrypt it. Very secure. But it raises another question:

“build as secure and as fast as possible a service”

Why do we need the hemlis XMPP infrastructure? As far as I can determine, the only reason for that infrastructure is to give the hemlis people an excuse for annual revenue. Why not let Facebook and Google pay to maintain that XMPP infrastructure? While I might not trust Google as an entity, I sure as hell trust Adam Langley’s TLS protocol choices that he can steer Google into using. So, what’s the hemlis excuse for running their own service:

“We will however charge a small fee (via an in-app purchase) to unlock certain features. Exactly which features is to be determined at a later time. We do this to fund the continuing development and infrastructure.”

“The way to make the system secure is that we can control the infrastructure. Distributing to other servers makes it impossible to give any guarantees about the security. ”

As the Islandic Penn & Teller would say (after talking to their lawyer) is: kjaftæði!

Didn’t they just say end to end encryption was going to be used? Who cares about the security of the transport if the message is securely end-to-end encrypted! Didn’t the hemlis people just claim the NSA and GHCQ could vacuum up a copy of my PGP encrypted chat message and they wouldn’t be able to decrypt it? If the end-to-end encryption works, there is no need to require a secure (hemlis run) XMPP network service network.

Centralizing is the wrong thing to do. By running their own hemlis XMPP service, they are actually making it easier for the NSA and GCHQ to get access to our (encrypted) IM data. And additionally, they are making it trivial for governments to just mandate a block of the hemlis XMPP network service. I can guarantee you that China will never even be able to see this network provided it actually launches.

Much better would be to allow people to completely decentralize the whole IM business by letting them running their own XMPP servers. XMPP is made to allow full decentralization. You can find my XMPP identity simply by looking for it based on my email address, paul@nohats.ca. Your IM client will be able to find the XMPP servers of the (very very Small) IM network run by “nohats.ca” via the SRV DNS records published in DNS.

“usually, security means complexity”

Finally a quote I can agree with. However, I’m already cringing and waiting for the padlock to appear. Security is not a binary toggle, so yes, representing a security state to an enduser who is not an engineer is a hard problem. There is a reason security is complex and OTR is one of the few protocols and implementations that has a very strong focus on usability. The developers tried to keep it as simple as possible, but everything about security cannot be reduced to a fucking padlock!

Promising a simple beautiful secure GUI is like promising world peace. It’s not the idea that’s impossible – it’s the implementation of that idea that is impossible.

(If you wonder why I hate padlocks so much just search for “otr padlock” to see the number of people suggesting to use padlocks in the OTR gui. Or search how Moxie basically killed the browser padlock by using sslstrip with a fav.icon).

PGP Key exchange

If it is not to facilitate the very securely encrypted PGP messages, then the only other thing left to protect is the exchange and verification of PGP public keys. Of course for that we have PGP key servers – although the PGP key servers suck. Knowing where to get PGP keys is not enough. For example, the key for assange@wikileaks.tld is (most likely) not a real key used by Assange. Someone dropped a key there in the hope that someone would use it to encrypt something for Assange. (Interestingly, since the “tld” domain does not exist, one has to mail it to one of Assange’s real email addresses, and I only know of a few parties outside of Assange that are guaranteed to get a copy of such an email. But what if hemlis solved this already through superb engineering skills? Well, then they have another problem: they won’t accept untraceable anonymous accounts.

Why not use OTR? Well, according to hemlis:

“Even though we love OTR it’s not really feasible to use in a mobile environment. The problem is that OTR needs both parties to be online for a session to start, but a normal phone would not always be online. It would not work at all for offline messages neither.”

Kjaftæði!

Let’s ignore the fact that 99.99% of phones are always on and always connected to the network, making this statement completely bogus to begin with. Let’s say Aðalbjör wants to send Björn an OTR message. If Björn is offline, then Aðalbjör cannot initialise an OTR session to establish a secure channel over which they can talk securely. Aðalbjör will have to queue up her message to Björn until he becomes available. How is this different from Björn’s client receiving the securely transmitted message while Björn is asleep and not reading it? The only difference is where the message was queued up. Aðalbjör and Björn actually never need to both be online at the same time to start or continue to use OTR. As the hemlis people themselves admit on the FAQ, the XMPP protocol allows for storing messages to offline people, and those messages include the OTR handshake messages to establish a secure connection! Remember, OTR is an inline encryption
protocol. It works fine with XMPP offline messages.

Will it be open source?

“We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety. It sure helps with transparency, but technology by itself is not enough. The fundamental benefits of Heml.is will be the app together with our infrastructure, which is what really makes the system interesting and secure.”

Mæli kjaftæði! This is where the snake oil really burns bright! While I have no doubt that
the opportunity for hemlis to make money is “interesting”, when you start saying that your application cannot be fully open source because it would be a security risk, you’ve committed the gravest mistake in cryptography – security by obscurity. Hemlis is going to be blackbox security. They should have called it Clipper Hemlis!

Why is Heml.is different from WhatsApp, MessageMe, iMessage etc?

“Our focus is your privacy so we are building everything from software to company structure to protect that.”

If the security of the hemlis IM network depends on the company structure of three guys standing up to the billion dollar a year military industrial complex combined with the billion dollars a year entertainment industry, you better have a plan B. I’m not comfortable with a distance of three waterboarding sessions, six kneecaps or one extremely expensive lawyer.

Not to mention that IM network that hemlis needs to run. They say it needs an annual revenue to keep running. Just ask wikileaks how easy it is to keep donations or payments going when Mastercard, VISA and PayPal ban you.

Finally, this last FAQ from their site is also very intriguing:

“How will the codes, pre-register usernames and “My name in the app” work? Prior to the release of Heml.is all backers will get an email with their codes and instructions on how to proceed. “

Unfortunately, they are not giving out any details about “hemlis IM network user identities”. Probably because they have no fucking clue how to deal with it. Can I register “NSAgov”? wikileaks@nohats.ca”? “EdSnoden”? helpdesk@heml.is?

They said they were using PGP, so I expect some kind of web of trust leverage with @heml.is identities or something. I have no idea how they would scale that so I can easily and securely find out what hemlis identity Assange has. The PGP keyservers are a disaster. It’s a battle field of spam, malicious fake identities, bogus signatures, keys where the private key was lost forever, and probably a bunch of compromised keys too. And despite all of that, it still failed to scale, provide a unified interface to easily obtain and verify keys. PGP keyservers should be taken down – they are a security risk at best. What is hemlis going to do different? Require a confirmation email? We’ve seen how well that works with the various Certificate Agencies.

Summary

While I’m happy to be proven wrong, the inevitable conclusion for now is that an hysteric mob of people gave three guys $150K for complete vapourware. I’m not sure who is more happy – those guys or the NSA. Next time you find yourself with a strong desire to sponsor the Alliance in the Crypto Wars, consider donating to those people who are actually working on these problems. Give some money to the IETF, or one of the crypto opensource projects. Just don’t buy more snákaolía please.

For those who wish to send me hate mail after reading this, please concentrate all your anger and hate and torpedo my OPENPGPKEY and OTRFP drafts that I submitted to the IETF instead. These two drafts are aimed at using DNSSEC to make Email and Instant Messages scale against passive (and some active) attackers and will assist and making encryption (and authentication) the default mode of the internet for our personal and private content.

What’s left for Hemlis? A imagined beautiful interface based on a few photoshop screenshots and a logo.

Snákaolía

Changing my default OTR setting to “require private messaging”

Posted on by
Reply

A few weeks ago, I met up with a friend I hadn’t seen in a year or so. We both knew cypherpunk (unlisted) co-founder Hugh Daniel who recently passed away, very well. She said that she now really wanted to introduce me to her little kids, because since Hugh passed away, I was now the most principled person she knew. That statement actually hit home pretty hard. If I’m the most principled person left, then we are all pretty much doomed.

Unlike me, Hugh was infuriatingly principled on all subject matters. I often told him (and John Gilmore) that fighting all fights at once, only ends up with you losing all fights. Pick one or two, and focus on those. Not Hugh (or John). Every single fucking bug he had to take the time to report upstream. Usually in email to software authors that was not in the least way filled with kindness about the author’s code quality. Everyone, everywhere were “Linux Children” (the reason why all my VM disk images live in a directory /vol/children). Kids these days did not understand the unix philosophy (or libertarian principles). Every single time I wanted to talk to Hugh, half the time would be lost in setting up, fixing, re-configuring IPsec between our networks, so we could talk IPsec encrypted SIP. But then we would have good conversations. I would poke fun of his absolute gun freedom lunacy, he would poke fun at my european communist subduing health care package.

And he was easily distracted by bugs. In my friends circle, when someone gets distracted from their time critical overdue work, we say such a person is “re-compiling KDE” because that’s what Hugh actually did – repeatedly! He would find some kind of bug in KDE, flame about and in fact recompile the entire KDE suite to see if it was fixed. He in fact did this for years, on laptops that were a couple of generations outdated. Breaking things is what Hugh did best. The problem was there were always bugs worth reporting, delaying the actual work we wanted him to do. Real crypto work! The important stuff!

Every single time Hugh sent me an email, I had to live through the pain of opensource crappy pgp software to read it. Every time I sent someone his way, Hugh would whine about needing to send an “e-postcard” because he did not have the crypto key of that new person. He would complain that finger did not work to obtain a public GPG key. Hugh’s death has single-handed reduced the amount of PGP encrypted email sent over the internet by at least 50%. We all should be pretty ashamed by that and we owe it to him to work on improving that percentage.

But I did end up getting him to compromise on rare occasions. As a KDE user and Gnome-hater, he did run pidgin because it was the only software at the time that could use Off-The-Record – although we both agreed pidgin is a terrible terrible piece of junk.

So getting back to the title of this post,

Hugh was a royal pain the ass to communicate with. Unlike Hugh, I do not believe that insisting on encrypting all communications should come at the expense of actually being able to communicate at all. So while I will continue to work on making OTR and GPG (and IPsec) easier to use, I won’t become another Hugh Daniel. However, I do believe that OTR has gotten to the point where it can be used by anyone without technical skills. Just install the right Linux, Windows or OSX client to use, and it just works. There are even Android and IPhone IM clients with OTR support now. If you are not using them, you are just plain lazy. It has nothing to do with your skill level.

So, in light of our lovely “Five Eyes Axis of Alliance” as well as in remembrance of Hugh Daniel (see below) I will change my IM client’s OTR setting to “require private messaging”. The only exceptions I will make to temporarily disable that encryption in the future, is to teach the other end on how to install and use OTR. If you cannot be bothered to invest 5 minutes of your time to increase our mutual privacy in light of the exposure of the collective world’s governments information tapping hunger, perhaps we should no longer be talking.

So there you go Hugh Daniel, I’ll pick up one of your fights. As of June 23rd, 2013, 4pm PDT (the start of Hugh’s memorial service on the beach at Pacifica), I will no longer accept unencrypted instant message communication.

And our next goal can be to do the same with SMS within the year, and email in two years from now.

Philips Hue alternative for “Lamp Stealer” using telnet

Posted on by
35

When you buy two Philips Hue light start kits, you have the problem that the lights are already paired with the bridge in each starter pack. When you search you will find a lot of people whining about how unfair this is and people talking about the “Lampstealer” OSX app that Philips released to fix it. I tried using the lamp stealer app but it would never find my bridge. I could also not use QuickHue which supposedly supported the lamp stealer function because it was compiled for OSX 10.8 and I still run 10.7.x. And compiling it from source with xcode didn’t work, likely due missing libraries and other mistakes I made since I’m not too familiar with Xcode.

I found out that the solution was really really simple, and requires no OSX, java or advanced rocket science. Place a bulb of the second starter kit into a socket within 30cm of the bridge from the first starterpack. Telnet to port 30000 of the bridge and type:

[Link,Touchlink]

The light should blink a few times to acknowledge the hostile takeover. Now you can use your iphone hue app. Go into the app settings, select the bridge, then run “find new lights”, or us your own python code (I like phue.py). Change bulbs and repeat this process for the other two lights.

Skytech and Dawson College versus Ahmed the kid

Posted on by
1

In case you had not heard it, the information of about a quarter million Canadian students was compromised in a security incident last week. These kind of breaches are so common place now, I hardly take notice of them any more. But an article about this case appeared in the National Post, “Youth expelled from Montreal college after finding ‘sloppy coding’ that compromised security of 250,000 students personal data”

hamed02_small
It turns out 20 year old Ahmed Al-Khabaz found a flaw that was trivial. He reported it to the vendor. The data was not leaked online on pastbin – at least, not by Mr.Al-Khabaz. But others before Al-Khabaz could have come in, copied the data, and left.
According to the article,

After an initial meeting with Director of Information Services and Technology François Paradis on Oct. 24, where Mr. Paradis congratulated Mr. Al-Khabaz and colleague Ovidiu Mija for their work and promised that he and Skytech, the makers of Omnivox, would fix the problem immediately, things started to go downhill.

Two days later, Mr. Al-Khabaz decided to run a software program called Acunetix, designed to test for vulnerabilities in websites, to ensure that the issues he and Mija had identified had been corrected. A few minutes later, the phone rang in the home he shares with his parents.

It was Edouard Taz, the President of Skytech, the company who wrote the Omnivox software. Taz threatened to report Al-Khabaz to the RCMP promising six to twelve months jail time unless Al-Khabaz agreed to immediately meet up and sign an NDA. It goes down hill from here. Dawson College expelled the student for a “serious professional conduct issue”. Fourteen out of fifteen professors in the computer science department voted in favour to expel Al-Khabaz. And the result is that a smart young kid, who did the right thing, and made a little mistake out of curiosity, is facing serious long term effects of not being able to get a college degree. And with him having nothing left to lose, the NDA they forced him to sign became useless, and Skytech lost as well because we all now know how crappy the security of Omnivox is. Edouard Taz shot himself in the foot. It’s just too bad he had to take down Al-Khabaz with him.

And the vulnerability? We don’t know we can assume it was something as trivial as manually editing the URL in the address bar, or some simple SQL injection attack. Something that in any other industry would be called “gross negligence”, but for some reason IT companies get away with delivering cars with faulty breaks and calling the slippery road an “Advanced Persistent Threat”. And companies like Skytech, with the assistance of an ill-informed Computer Science department at Dawson College, take it out on a young kid who honestly tried to do the right thing. Security through bullying. The response of both Skytech and Dawson College was over the top, and counter-productive to everyone’s interest.

Compare this to the response of my old university, the Radboud Universiteit Nijmegen. A 19 year old kid spent all his money on a 1200 baud modem (half duplex) and uses it to login to a university LAT-TCP server to connect to something called “the internet”. He uses “ftp” and “sz” to download files, “nn” and “telnet” to read news and chat with people all over the world. He did much worse then Al-Khabaz, although he too was careful not to do any accidental damage. And like Al-Khabaz performing his scan of Skytech, this person knew he was a trespasser. An assistant professor known as “Sparky”, notices that a student who had not been active at the university, started logging in very regularly. He becomes suspicious that the account might have been compromised. So he sends a Unix Talk request to her (see man talk). The two briefly chat online. Sparky confirms the account is compromised. But instead of screaming and threatening like Mr. Taza, Sparky asks the hacker how he got into the account. The hacker tells him he used ypcat to get /etc/shadow, then ran a cracker. Sparky then tells the hacker he has two days to get his stuff from the account and leave, and not to come back using any other accounts. Three years later, our young hacker has actually enlisted with the university to study CS, and in his second year he becomes friends with Sparky – and even gets an account on the university’s historic PDP-11. He confesses the whole affair and both have a good laugh. The student later on starts an ISP, becomes a security consultant who speaks at Black Hat, and is part of a group that writes VPN software in use all over the world. And the young-hacker-turned-sysadmin also has to deal with hackers himself. One time he logs into an irc channels to tell a group of file sharing hackers that they overstayed their welcome and should not have filled up the disks, and that it was time to go – and probably stop stealing movies and ISP resources. The circle of not threatening kids who make mistakes continued.

I can’t imagine how my life would have turned out if Sparky had hunted me down and had threatened me with jail time or that he would have kicked me out of university when I was 19. I learned a lot from Sparky, and I’ve passed along the same treatment to others. I wish Mr. Al-Khabaz all the best. He deserves much better then the treatment he received from Skytech and Dawson College. Don’t we all make those mistakes when we are that young? The real mistake here, is that Omnivox is a product with severe security flaws, that could have resulted in identity theft of 250,000 Canadian Students. Perhaps Mr. Taz should focus his bullying at his own security department?

Can the NSEC3-OPTOUT record cover no RRTYPE’s?

Posted on by
1

At first glance, the answer seems obvious: No. The point of NSEC3 is to proof the (non)existence of data. With the OPT-OUT flag set, you skip all the non-secure data. So you would expect to have some data to cover for such an NSEC3 record. If you read RFC 5155 Section 3.2.1 it is not entirely clear, though I’m tempted to think these should not happen in the wild. Except we just found one, generated by bind’s dnssec-signzone:

aaa.ottawa.on.ca.  IN NS foo.
problementry.ottawa.on.ca.  IN NS foo.
problementry.ottawa.on.ca.  IN DS blob.
zzz.ottawa.on.ca.  IN NS foo.

The change was that “problementry.ottawa.on.ca” submitted a DS record which was added to the zone. Note also that  neither “on.ca.” or “ottawa.on.ca.” are zone cuts, although there are many delegations underneath XXXX.ottawa.on.ca. (but none with a DS record or orphan glue)

This caused bind to add two NSEC3 entries as part of the NSEC3 chain, an entry for HASH(on.ca) and an entry for HASH(ottawa.on.ca) (forgive the wordpress wrapping of lines)

+qf6k201pudkgikusoidrujdfikql15qc.ca.   3600 IN      NSEC3   1 1 5 – qnkecttopnji0h479fhpjmv18gsl1sdk ;{ flags: optout}

+qnkecttopnji0h479fhpjmv18gsl1sdk.ca.   3600    IN      NSEC3   1 1 5 – r85l4g712aibs65e47aj79e7odi202h9 ;{ flags: optout}

Note how these NSEC3 entries do not cover a single RRTYPE, because there is no zonecut and there are no RRTYPE’s for these entries.

When signing this zone with opendnssec, instead of bind, the entries are not added. Who is right? Before using my brains, I decided to use other people’s brains.

named-checkzone loaded both the bind and ods version with “OK”. So no help there. It’s a bug because it should declare at least one of the copies as containing errors in the NSEC3 hash chain

ldns-verify complained about ALL the non-zone-cuts in the zones but otherwise showed no difference. So that’s also a failure, on top of the failure of assuming dots are zone cuts.

validns found the bind zone OK, but complained about the ods zone with:

ca.signed.ods-signer-01.ldns:2898958: no corresponding NSEC3 found for on.ca.
ca.signed.ods-signer-01.ldns:2907968: no corresponding NSEC3 found for ottawa.on.ca.

So validns seems to agree with bind. Which software is right? The only thing I”m sure of now, is that I need more coffee and time to re-read RFC 5155, and specifically look at how things are supposed to work in this case.

I’m continuously surprised at how many TLD’s have rolled out DNSSEC, yet we’re still seeing differences between signer engines and validators all the time……

 

EarthCalm EMF Protection Technology (USB or Ethernet)

Posted on by
1

There is almost nothing that gets me more mad then pseudo science. There are those who are just completely self-absorbed and believe in their quackery science, such as the “vaccinations causes autism” people, who are now responsible for an increased infant mortality in the western world. That upsets me and frustrated me, but there is another group that actually infuriates me. Those frauds trying to sell people bracelets, stones, crystals, and as it seems like now, usb drives filled with stones or a variation powered by non-PoE ethernet connectors. Note that Earthcalm is aware of lawyers, so their website states:

Disclaimer: The products and/or technologies listed on this website are not FDA-approved and are not intended to diagnose, treat, cure, mitigate, or prevent any disease. Please consult your physician or health care practitioner for any questions about EMFs and your health.

 

Instead of spending $179 on these gutted USB drives, please consider this $49,90 bargain Possible Health Effects of Exposure to Residential Electric and Magnetic Fields instead. Or spend nothing and read its summary:

CHARGE TO THE COMMITTEE

Public concern regarding possible health risks from residential exposures to low-strength, low-frequency electric and magnetic fields produced by power lines and the use of electric appliances has generated considerable debate among scientists and public officials. In 1991, Congress asked that the National Academy of Sciences (NAS) review the research literature on the effects from exposure to these fields and determine whether the scientific basis was sufficient to assess health risks from such exposures. In response to the legislation directing the U.S. Department of Energy to enter into an agreement with the NAS, the National Research Council convened the Committee on the Possible Effects of Electromagnetic Fields on Biologic Systems. The committee was asked “to review and evaluate the existing scientific information on the possible effects of exposure to electric and magnetic fields on the incidence of cancer, on reproduction and developmental abnormalities, and on neurobiologic response as reflected in learning and behavior.” The committee was asked to focus on exposure modalities found in residential settings. In addition, the committee was asked to identify future research needs and to carry out a risk assessment insofar as the research data justified this procedure. Risk assessment is a well-established procedure used to identify health hazards and to recommend limits on exposure to dangerous agents.

CONCLUSIONS OF THE COMMITTEE

Based on a comprehensive evaluation of published studies relating to the effects of power-frequency electric and magnetic fields on cells, tissues, and organisms (including humans), the conclusion of the committee is that the current body of evidence does not show that exposure to these fields presents a human-health hazard. Specifically, no conclusive and consistent evidence shows that exposures to residential electric and magnetic fields produce cancer, adverse neurobehavioral effects, or reproductive and developmental effects.

 

The committee reviewed residential exposure levels to electric and magnetic fields, evaluated the available epidemiologic studies, and examined laboratory investigations that used cells, isolated tissues, and animals. At exposure levels well above those normally encountered in residences, electric and magnetic fields can produce biologic effects (promotion of bone healing is an example), but these effects do not provide a consistent picture of a relationship between the biologic effects of these fields and health hazards. An association between residential wiring configurations (called wire codes, defined below) and childhood leukemia persists in multiple studies, although the causative factor responsible for that statistical association has not been identified. No evidence links contemporary measurements of magnetic-field levels to childhood leukemia.

 

 

nsd packages for Fedora/EPEL build that address CVE-2012-2978

Posted on by
Reply

I had only gotten around to build nsd 3.2.11 a few days ago and run it through testing when I was told about the 3.2.12 security release. So there was only a small (but important) code change to address the vulnerability issue. It ran on my own name server for nohats.ca for 24h without issues, so I could quickly pull the pending 3.2.11 updates and build and release updates today for 3.2.12 when CVE-2012-2978 became public.

You can find the Fedora and EPEL packages here: https://bugzilla.redhat.com/show_bug.cgi?id=841268

(of course, this was kind of a test posting to see if I show up in http://planet.fedoraproject.org)

The Chinese G101 tablet and Fedora 17 (Part 1)

Posted on by
2

So I managed to get a tablet that’s actually a full PC. It has no name, but you can find it  when you google for “tablet g101 atom“.

The tablet installing Fedora 17 from USB DVD. An iphone 3G is placed in front for size (and shape) comparison

It is not an ARM based device like many Android tablets, but an Intel Atom N450, 64bit, 2GB RAM, 160GB HD, WLAN 54 Mbps, 10.1″ capacitive multitouch touchscreen 1024×600, 3 USB ports, 1 (optional, not there?) 3G SIM slot, 1x HDMI, front facing webcam, sound, mic.

The amazing thing, Fedora 17 installed straight onto it from USB-DVD. I did not need to do any command line tinkering to load any kind of kernel module, driver or xorg driver. It installed, booted and all the hardware worked, though I haven’t yet tested the HDMI output. Wireless worked fine, sound and video worked, even the webcam! And of course the touch screen worked, though I haven’t confirmed multitouch, as I don’t know of an app that supports it to test it.

So what didn’t work? The biggest issue is that the machine cold boots from sleep mode, instead of resuming. It seems to enter sleep mode fine, and the LED blinks in that sleepy way, but it will just cold boot after that. The “home” button seems to just map to a return key. And I haven’t found the accelerometers yet, so it won’t rotate the screen automatically like it did with the pre-installed win8 beta. I tried using lm_sensors and i2c_detect but those do not find anything. When you rotate the screen using xrandr, the touchscreen input does not rotate its location to match, and I haven’t found the right xinput command yet. The speaker volume is a little on the low side.

Gnome3 – made for tablets!

There were a few things that made using this device a frustrating job, mostly because of gnome3. Which is odd because gnome3 was meant to be tablet friendly. You can select the Universal Access symbol and get a virtual keyboard to login, kudos there since I have no keyboard unless i bring along a USB keyboard. But when the virtual keyboard vanishes, it goes into that bottom tray bar, which auto-hides. It is next to impossible to get the tray bar to appear again to select the keyboard. If someone knows how to NEVER hide the tray bar, let me know, google only knows about people who want to never see the tray bar at all). Next, selecting the “activities” is way too hard. Pressing it just fails too often. The same for selecting “windows” or “applications”. This is not due to the touch screen being of bad quality, as for instance scrolling using the scroll bar in firefox works fine.  Scrolling through the application list most certainly will start the application you didn’t want, because your finger motion either didn’t scroll up enough (so it bounces back without scrolling) or it scrolled too far (hitting the top and thereby jumping out of the select, and you have to start from scratch). It’s a terrible terrible user experience.

Disk encryption

Since this is a mobile device, I opted to use full disk encryption. But that was a mistake. When you boot the device, you get the nice login prompt for the passphrase for your root filesystem, but there is no virtual keyboard. I had to plugin a USB keyboard to boot the device. We can’t really load X here, as the rootfs is still encrypted. I’m afraid there is no other way then to add a new virtual keyboard option, somehow.

Conclusion

All in all, it’s a nice device. I can’t wait to put it in the hands of gnome3 developers and say “go fix it!”.

I’m not sure if you can actually buy it anywhere. I bought this one on craigslist. It seems most links I found on google lead to Chinese shops who want to sell you at least 10. The price would probably be somewhere between 200-400 dollar each, for a version with a little less disk and ram then I tested with.

So, Linux is almost ready for the tablet!