Jul 172014
 

XViewerThe first release of XViewer is now available, providing TK-IP101 users with a way to still manage their installations using modern Java versions and operating systems without any blocker bugs and crashes. I have created a static page about it [here] including downloads and the statements required by TRENDnet. You can also see it on the top right of this weblog. This is the first fruition of TRENDnet allowing me to release my modified version of their original KViewer under the GPLv3 license.

As requested, all traces of TRENDnet and their TK-IP101 box have been removed from the code (not that there were many anyway, as the code was reverse-engineered from the byte code) on top of the rename to XViewer. In time, I will also provide my own documentation for the tool.

Since I am no Java developer, you shouldn’t expect any miracles though. Also, if anyone would be willing to fork it into yet another, even better version of the program, you’re of course welcome to do so!

Happy remote monitoring & managing to you all! :)

Edit: Proper documentation for SSL certificate creation using a modern version of [XCA] (The X certificate and key management tool) and about setting up and using XViewer & XImpcert has now also been made [available]!

Jul 162014
 

XViewer logoIn my [last post] I have talked about the older TRENDnet TK-IP101 KVM-over-IP box I got to manage my server over the network even in conditions where the server itself is no longer reachable (kernel crash, BIOS, etc.).

I also stated that the client software to access the box is in a rather desolate state, which led me to the extreme step of decompiling the Java-based Viewer developed by TRENDnet called KViewer.jar and its companion tool for SSL certificate imports, Impcert.jar.

Usually, software decompilation is a rather shady business, but I did this as a TRENDnet support representative could not help me out any further. After reverse-engineering the software, making it compatible with modern Java Runtime environments and fixing a blocker bug in the crypto code, I sent my code and the binary back to TRENDnet for evaluation, asking them to publish the fixed versions. They refused, stating that the product was end-of-life.

In a second attempt, I asked the guy for permission to release my version of KViewer including the source code and also asked which license I could use (GPL? BSD? MIT?). To my enormous surprise, the support representative conferred with the persons in charge, and told me that it had been decided to grant me permission to release KViewer under the GNU General Public License (GPL), as long as all mention of TRENDnet and related products are removed from the source code and program.

To further distinct the new program from its original, I renamed it to “XViewer”, and its companion tool to “XImpcert”, as a hommage to my server, XIN.at.

KVM host:port

The former KViewer by TRENDnet, that works up to Java 1.6u27

XViewer

XViewer, usable on JRE 1.7 and 1.8

Now, I am no Java developer, I don’t know ANYthing about Java, but what I did manage to do is to fix all errors and warnings currently reported by the Eclipse Luna development environment and the Java Development Kit 1.7u60 on the source code. While my version no longer supports Java 1.6, it does run fine on Java 1.7u60 and 1.8u5, tested on Windows XP Professional x64 Edition and CentOS 6.5 Linux x86_64. A Window closing bug has been fixed by my friend Cosmonate, and I myself got rid of a few more. In addition to that, new buttons have been added for an embedded “About” window and an embedded GPLv3 license as suggested by TRENDnet.

On top of that, I hereby state that I am not affiliated with TRENDnet and that TRENDnet of course cannot be held liable for any damage or any problems resulting from the use of the modified Java viewer now known as XViewer or its companion tool XImpcert. That shall be said even before the release, as suggested to TRENDnet by myself and subsequently confirmed to be a statement required by the company.

In the very near future, I will create a dedicated site about XViewer on this weblog, maybe tomorrow or the day after tomorrow.

Oh and of course: Thanks fly out to Albert from TRENDnet and the people there who decided to grant me permission to re-release their viewer under the GPL! This is not something that we can usually take for granted, so kudos to TRENDnet for that one!

Jul 112014
 

TK-IP101 logoAttention please: This article contains some pretty negative connotations about the software shipped with the TRENDnet TK-IP101 KVM-over-IP product. While I will not remove what I have written, I have to say that TRENDnet went lengths to support me in getting things done, including allowing be to decompile and re-release their Java software in a fixed form under the free GNU General Public license. Please [read this] to learn more. This is extremely nice, and so it shall be stated before you read anything bad about this product, so you can see things in perspective! And no, TRENDnet has not asked me to post this paragraph, those are my own words entirely.

I thought that being able to manage my server out-of-band would be a good idea. It does sound good, right? Being able to remotely control it even if the kernel has crashed and being able to remotely access everything down to the BIOS level. A job for a KVM-over-IP switch. So I got this slightly old [TK-IP101] from TRENDnet. Turns out that wasn’t the smartest move, and it’s actually a 400€ piece of hardware. The box itself seems pretty ok at first, connecting to your KVM switch fabric or a single server via PS/2, USB and VGA. Plus, you can hook up a local PS/2 keyboard and mouse too. Offering what was supposed to be highly secure SSL PKI autentication via server+client certificates, so that only clients with the proper certificate may connect plus a web interface, this sounded really good!

TRENDnet TK-IP101

TRENDnet TK-IP101

It all breaks down when it comes to the software though. First of all, the guide for certificate creation that is supposed to be found on the CD that comes with the box is just not there. Also, the XCA software TRENDnet suggests one should use was also missing. Not good. Luckily, the software is open source and can be downloaded from the [XCA SourceForge project]. It’s basically a graphical OpenSSL front end. Create a PEM-encoded root certificate, PEM-encoded server certificate and a PKCS#12 client certificate, the latter signed by the root cert. So much for that. Oh, and I uploaded that TRENDnet XCA guide for you in case it’s missing on your CD too, its a bit different for the newer version of XCA, but just keep in mind to create keys beforehand and to use certificate requests instead of certificates. You then need to sign the requests with the root certificate. With that information plus the guide you should be able to manage certificate creation:

But it doesn’t end there. First I tried the Windows based viewer utility that comes with its own certificate import tool. Import works, but the tool will not do client+server authentication. What it WILL do before terminating itself is this:

TK-IP101 IPViewer.exe bug

TK-IP101 IPViewer.exe bug

I really tried to fix this. I even ran it on Linux with Wine just to do an strace on it, looking for failing open() calls. Nothing. So I thought… Why not try the second option, the Java Viewer that goes by the name of KViewer.jar? Usually I don’t install Java, but why not try it out with Oracles Java 1.7u60, eh? Well:

So yeah. What the hell happened there? It took me days to determine the exact cause, but I’ll cut to the chase: With Java 1.6u29, Oracle introduced multiple changes in the way SSL/TLS worked, also due to the disclosure of the BEAST vulnerability. When testing, I found that the software would work fine when run with JRE 1.6u27, but not with later versions. Since Java code is pretty easily decompiled (thanks fly out to Martin A. for pointing that out) and the Viewer just came as a JAR file, I thought I’d embark on the adventure of decompiling Java code using the [Java Decompiler]:

Java Decompiler decompiling KViewer.jar's Classes

Java Decompiler decompiling KViewer.jar’s Classes

This results in surprisingly readable code. That is, if you’re into Java. Which I am not. But yeah. The Java Decompiler is pretty convenient as it allows you to decompile all classes within a JAR and to extract all other resources along with the generated *.java files. And those I imported into a Java development environment I knew, Eclipse Luna.

Eclipse Luna

Eclipse Luna

Eclipse Luna (using a JDK 7u60) immediately complained about 15 or 16 errors and about 60 warnings. Mostly that was missing primitive declarations and other smaller things that even I managed to fix, got rid even of the warnings. But the SSL bug persisted in my Java 7 build just as it did before. See the following two traces, tracing SSL and handshaking errors, one working ok on JRE 1.6u27, and one broken on JRE 1.7u60:

So first I got some ideas from stuff [posted here at Oracle], and added the following two system properties in varying combinations directly in the Main class of KViewer.java:

1
2
3
4
5
6
7
8
9
10
11
12
public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}
public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}

This didn’t really do any good though, especially since “interoperable” mode should work anyway and is being set as the default. But today I found [this information on an IBM site]!

It seems that Oracle fixed the BEAST vulnerability in Java 1.6u29 amongst other things. They seem to have done this by disallowing renegotiations for affected implementations of CBCs (Cipher-Block Chaining). Now, this KVM switch can negotiate only a single cipher: SSL_RSA_WITH_3DES_EDE_CBC_SHA. See that “CBC” in there? Yeah, right. And it got blocked, because the implementation in that aged KVM box is no longer considered safe. Since you can’t just switch to a stream-based RC4 cipher, Java has no other choice but to drop the connection! Unless…  you do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                             */
  /* This disables CBC protection, thus re-opening the connections'     */
  /* BEAST vulnerability. No way around this due to a highly restricted */
  /* KLE ciphersuite. Without this fix, TLS connections with client     */
  /* certificates and PKI authentication will fail!                     */
  java.lang.System.setProperty("jsse.enableCBCProtection", "false");
  /* ------------------------------------------------------------------ */
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}
public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                             */
  /* This disables CBC protection, thus re-opening the connections'     */
  /* BEAST vulnerability. No way around this due to a highly restricted */
  /* KLE ciphersuite. Without this fix, TLS connections with client     */
  /* certificates and PKI authentication will fail!                     */
  java.lang.System.setProperty("jsse.enableCBCProtection", "false");
  /* ------------------------------------------------------------------ */
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}

Setting the jsse.enableCBCProtection property to false before the negotiation / handshake will make your code tolerate CBC ciphers vulnerable to BEAST attacks. Recompiling KViewer with all the code fixes including this one make it work fine with 2-way PKI authentication using a client certificate on both Java 1.7u60 and even Java 1.8u5. I have tested this using the 64-Bit x86 VMs on CentOS 6.5 Linux as well as on Windows XP Professional x64 Edition and Windows 7 Professional SP1 x64.

De-/Recompiled & "fixed" KViewer connecting to a machine much older even than its own crappy code

De-/Recompiled & “fixed” KViewer.jar connecting to a machine much older even than its own crappy code

I fear I cannot give you the modified source code, as TRENDnet would probably hunt me down, but I’ll give you the compiled byte code at least, the JAR file, so you can use it yourself. If you wanna check out the code, you could just decompile it yourself, losing only my added comments: [KViewer.jar]. (ZIPped, fixed / modified to work on Java 1.7+)

Both the modified code and the byte code “binary” JAR have been returned to TRENDnet in the context of my open support ticket there. I hope they’ll welcome it with open arms instead of suing me for decompiling their Java viewer.

In reality, even this solution is nowhere near perfect. While it does at least allow you to run modern Java runtime environments instead of highly insecure older ones plus using pretty secure PKI auth, it still doesn’t fix the man-in-the-middle-attack issues at hand. TRENDnet should fix their KVM firmware, enable it to run the TLSv1.2 protocol with AES256 Galois-Counter-Mode ciphers (GCM) and fix the many, many problems in their viewer clients. The TK-IP101 being an end-of-life product means that this is likely never gonna happen though.

It does say a lot when the consumer has to hack up the software of a supposedly high-security 400€ networking hardware piece by himself just to make it work properly.

I do still hope that TRENDnet will react positively to this, as they do not offer a modern replacement product to supersede the TK-IP101.

Jul 032014
 

ibm-logoI was thinking about getting some spare parts for my server for quite some time now, but now I found a guy in the US who had not just some processor boards compatible with black 1MB Pentium PRO CPUs, but also a complete system board, all in completely new and unused condition. This is pretty rare for parts from 1995 and 1997, so I negotiated a good price with the man, and the boards have already arrived. Of course I had the honors of paying for customs again (20% VAT plus 10€ administrative fee), but oh well. Can’t do anything about that.

Let’s take a look at the system board first, this thing is pretty huge, featuring two north bridges with two separate PCI busses, and also two SCSI controllers onboard:

All new and shiny! And here are the processor riser boards, they hold two processors each for a total of four processors. Note that one of the boards has red capacitors, something I have not seen so far, but they seem to be pretty identical otherwise. The capacitors are 105°C parts:

Now I have one processor, two proper CPU riser boards supporting my 1MB CPUs (the first generation of CPU boards didn’t) and a whole system board as spare parts. Not that I’d really need them, so far there have been no hardware failures other than dead hard drives in my server. But you can never know, and getting parts in such good condition might get harder and harder over time. Now I’m only looking for one last thing, a hot-swappable power supply, IBM FRU #12J3342. While I do have three installed, another spare in case of failure surely wouldn’t hurt:

So that’s the last spare part missing. You can get them in the US, but I’ll keep looking until I can find one for a half-decent price. Shipping is expensive for these parts, because the power supplies are very heavy, and then there is customs too (they include the shipping cost in their fee calculation). But one day, I’ll surely get a fourth power supply too. Then XIN.at will be protected against pretty much all possible hardware failure scenarios. :)

Jun 272014
 

JustitiaThis just in: A very important battle has been won! The [Austrian Constitutional Court] has decided just this morning that the data retention laws are unconstitutional and illegal, following a similar decision made by the [European Court of Justice]. The Austrian government is thus required to repair the laws to re-establish an environment that respects personal privacy and data security. For those of you who can read German, here is the corresponding [news report]German flag!

The Constitutional Court – highest and most significant in the country – has decided that the laws we currently have are disproportional when it comes to what we have to sacrifice for gaining what seems to be very little. They stated, that the possibility of linking meta data together (to create profiles of persons and networks of persons) is especially problematic. Several paragraphs of the laws have been declared outright unconstitutional!

On top of that it was said that baseless surveillance is dangerous and the risk of abuse is high due to many people having access to the data collected (think: Internet Service Providers). Plus, the laws have never actually been used for their prime purpose, fighting terrorism. Not even once. They have been used in cases of theft and stalking though, which does not justify such a deep cut into the privacy of every single citizen of Austria.

The current Austrian government (including the minister of justice!) had still defended data retention and declared to want to keep it as-is. However, now they have to back off from that stance, no matter what.

A very important battle has been won, while the war rages on. So, while this is one of the most significant victories in terms of freedom in a long time, never forget:

“The price of freedom is eternal vigilance”.

Now that we are sensitized for the matter, and mechanisms to defend against further attacks are firmly in place, we are in a good position to defend against the next attempt to undercut our society. Just need to stay vigilant!

One can only hope that this will serve as a guiding light for countries that still have data retention in place… This really needs to go for good, not just in Austria!

Jun 162014
 

Zune LogoAnyone remember Microsoft Zune? No? Maybe because it’s dead. Well, one day Microsoft thought that Apple got a bit too powerful in the multimedia business, and late to the game as the guys from Redmond usually are, they launched their counterpart when the battle was already lost – in 2006. To promote their music service and their dedicated WMA (ew!) players a bit, they also released a free (as in freeware of course) Zune theme for Windows XP. Now while I’m a XP x64 freak, I don’t usually care about Luna UI themes since I’m using plain GDI, but a guy I know said that he used it back then, for the eye candy.

So, since it’s a bit quiet on the Linux and UNIX front lines right now, I felt a little bit more stupid than usual today! I thought I’d go ahead and install myself some Zune Theme, that can strangely still be [downloaded] from Microsoft at the time of writing.

Well, na-ah. It’ll just tell you, that you need “Windows XP SP2″ for that. On XP x64 SP2 that is. Since it’s a MSI installer package, I thought I’d take a look with the [Orca resource editor]. And well, what do we have here…

Orca, inspecting the WinXP Zune theme installer

Orca, inspecting the WinXP Zune theme installer (click to enlarge)

For things that should work but don’t, it’s usually the LaunchCondition resource causing the trouble. Here we can see the rule that checks your system before letting the setup actually install anything:

  • ( ( VersionNT = 501 ) AND ( ServicePackLevel >= 2 ) )

So, what does that mean? I mean, besides “Fuck you, XP x64 users!”. Well, it’s checking the kernel version (5.1) and service pack level (equal to or greater than 2). The service pack level is ok, it’s the kernel check that’s troublesome, since XP x64 has a newer kernel with version number 5.2.3790. We’re interested in the “5.2″ part. Now most users on the web just delete the entire LaunchCondition resource, but that’s not very smart, as it’d make the software installable on Vista, 7, etc. It’s not a clean way to do it! To do it the right way, we need to extend the rule and make this installable on XP only, but still on NT 5.1 (Windows XP 32-Bit) as well as NT 5.2 (Windows XP Professional x64 Edition and Server 2003). Like this:

  • ( ( ( ( VersionNT = 501 ) OR ( VersionNT = 502) ) AND ( ServicePackLevel >= 2) )

This means “we need NT 5.1 or NT 5.2, but in both cases we also need service pack 2″. This works just fine. See here, in Orca:

Orca, after modifying the Zune theme installer

Orca, after modifying the Zune theme installer (click to enlarge)

After saving the modified file, you can just launch the Zune theme installer on XP x64 as usual, and it’ll work. After resetting a few things like the larger scrollbars and title bars back to my pixel saver settings, it’ll look somewhat like this:

Applied and slightly modified Zune theme on XP x64

Applied and slightly modified Zune theme on XP x64 (click to enlarge)

The task bar is still too thick here, but I guess we can’t shrink that. If you have a filled up tray on a two-line task bar it’ll now be three icons high instead of just two. So yes, this does still consume more screen real estate than plain Win2000-style GDI does. But well, just in case you want to get the Zune theme to install on your XP x64 box “the right way”, here it is!

Oh, and if you don’t want to do it by yourself, I’ll provide the modified theme here, just remember: If you don’t trust me or the files I’m hosting here, you can always do the modification yourself!

Jun 072014
 

APC logoJust recently, two power outages within just two weeks have shut down my server, the second one resulting in a little bit more serious file system damage. Nothing I couldn’t repair & restore, but still. Originally, my server was protected by an APC SmartUPS 1000VA unit, delivering 680W of real power, barely enough for my infrastructure. The first set of batteries died after 2 years and so did the second, after which I had given up the unit altogether. So since then, the whole server – which also hosts this weblog – has been running without any backup power.

Due to recent events however, I have decided to finally change that, I’ve been thinking about this for a long time anyway. Some people that I have talked to might be disappointed that I went for APC again, instead of AEG or some other company, but there were three crucial factors leading to that decision:

  • Extended runtime.
  • Price per minute of runtime on battery power.
  • Ease of management and availability of parts.
  • Reluctance to risk using unkown hardware (yeah yeah, I know, that’s a weak one).

So I calculated the sweet spot that would give me the most runtime per €, and chose an APC SmartUPS SMT2200I. And to make it globally manageable without having to install any software, I installed an APC AP9630 network management card 2 instead, that gave me the possibility of out-of-band management, so I can distinguish between G.SHDSL network failure and server failure. Also, I can use it as a killswitch to shut down everything immediately remotely, should that ever be necessary. The corresponding interfaces can be reached from anywhere on the Internet.

But now, time for some pictures:

The thing weighs some nice 50kg batteries included, so I had to transport the unit with its massive transformer coils and the batteries separately. Two of those RBC55 batteries give us some 2200VA apparent as well as 1980W of real power. You might’ve spotted the black little thing up left. That’s the AP9630 network management card 2. Let’s have a closer look:

The card features  a ton of stuff (I’ll show some screenshots farther below), like a SSL capable web interface, FTP server as well as Telnet+SSH. It can continuously monitor the unit, logging to an external Syslog even if you want. eMail notifications are also possible, and SSL/TLS mail servers are supported. But more about that later.

Now, since I had a new WAN interface, as the network management card 2 was supposed to get a static public IP + domain name, I now had two WAN interfaces to serve, a third going to be added when I upgrade my RAID-6 to an Areca ARC-1882ix-12, which has its own out-of-band management too. So I decided to decouple LAN and WAN physically. Could’ve done it with a single switch and VLANs too, but I went the physical route:

Now I know what you’re thinking, and it’s surely something along the lines of “wtf Netgear?!”, but while I had to solder back together broken Netgear hardware before, it’s another story with their business hardware, at least the unmanaged one, their ProSAFE switches. Have several running, never a single problem. Unfortunately, I got the managed switches instead of the unmanaged ones I wanted, seems the managed ones [are a little bit more shaky]German flag, but well. Let’s settle with that.

2½ hours later, after pullling some 10kg of unused cables out of my server closet and re-wiring power and network, it’s up and running:

SMT2200I operational

Operational. This photograph sucks. I got the white balance all wrong, so I had to rape the image afterwards.

I hate it when I get the white balance wrong. Looking at that photo almost hurts physically after my attempts to repair the damage, I should pay more attention when taking photos. Meh. Well, now that everything’s online, let’s have another look at the NMC2 interfaces:

And while you should maybe deactivate Telnet and also FTP (unless you need FTP for certain APC InfraStruXure solutions), you also got SSH2 and SCP for a secure shell, whis is pretty neat, see here:

Proof that APCs notification system is quite extensive are the following emails I have already been getting, proving that security by obscurity is a pretty weak concept, no matter how weird that TCP port may be: ;)

Name : (cut)
Location : Bruck an der Mur
Contact  : (cut)

https://(cut, host version)
https://(cut, IP version)
Serial Number : (cut)
Device Serial Number : (cut)
Date : 06/07/2014
Time : 13:55:41
Code : 0x0005

Warning - Detected an unauthorized user attempting to access the Control Console interface from 211.143.140.202.

Yeah, that’s a Chinese IP address, what else? :roll: Guess I’ll be getting a lot more of those.

Now, all that’s left is to wait for the next power outage and to hope that the batteries can survive the heat in here!

PS: Thanks fly out to the XIN users Giovannie and Bier, who agreed to contribute a little bit of cash to the purchase of this super expensive unit. :)

Jun 052014
 

JustitiaIn battling the previously legalized data retention policy of the European Union, the European Court of Justice ([EuGH]) has now declared data retention as illegitimate, it seemingly being incompatible with the EU charter as it violates fundamental laws regarding privacy. Also, the original purpose of data retention in the fight against terrorism and organized crime in Austria has in practice been extended to much more mundane things like [theft or stalking]German flag as well as hunting down people who produced counterfeit cigarettes and stuff like this.

Our own Federal Chancellery has now stated that it will [not abandon data retention]German flag for reasons hardly understood, as Doris Bures, former minister of innovation and technology had stated that “[we do not need data retention]“German flag before.

AKVorrat logoIt may not be possible for them to keep it though, as on the coming 12th of July June, the issue will be brought before the Constitutional Court of Austria ([VfGH]) by more than 11.000 plaintiffs including myself, suing for data retention being unconstitutional, violating the basic rights of privacy in this country, represented by the organization AKVorrat and their lawyers, an organization which was founded for this very purpose. It still feels strange though, that our beloved rulers should have changed their minds about this so quickly. Or maybe individual opinions do differ greatly amongst members of the government, partly maybe due to lack of information and proper expert guidance.

The now-public statement that has been submitted to the Constitutional Court can be read in PDF form [here]German flag.

If the VfGH decides that data retention is unconstitutional (which it pretty damn well should!), this would mean a major victory for freedom and privacy on both a European as well as national level. Of course, new proposals for data retention – slightly changed and renamed – are already looming on the horizon, ready to be smuggled through European parliament. But this time around, resistance is already forming beforehand, as the proper anti-data-retention organizations like AKVorrat are already in place and actively working against any such rule in multiple European nations.

Still, the price of freedom is eternal vigilance. No war can be one by winning just one major battle. But still, if the VfGH decides in favor of freedom and privacy here, this may turn the tide!

I will continue to report about this as soon as new information or the actual ruling by the VfGH become available!

May 292014
 

Truecrypt LogoJust recently, I was happily hacking away at the Truecrypt 7.1a source code to enhance its abilities under Linux, and everybody was eagerly awaiting the next version of the open source disk encryption software since the developers told me they were working on “UEFI+GPT booting”, and now BOOM. Truecrypt website gone, forum gone, all former versions’ downloads gone. Replaced by a redirection to Truecrypts SourceForge site, showing a very primitive page telling users to migrate to Bitlocker on Windows and Filevault on MacOSX. And told to just “install some crypto stuff on Linux and follow the documentation”.

Seriously, what the fuck?

Just look at this shit (a snippet from the OSX part):

The Truecrypt website now

The Truecrypt website now

Farther up they’re saying the same thing, warning the user that it is not secure with the following addition: “as it may contain unfixed security issues”

There is also a new Truecrypt version 7.2 stripped of most of the functionality. It can only be used to decrypt and mount anymore, so this is their “migration version”. Funny thing is, the GPG signatures and keys seem to check out. It’s truly the Truecrypt developers’ keys that were used for signing the binaries.

Trying to get you a screenshot of the old web site for comparison from the WayBackMachine, you get this:

Can't fetch http://www.truecrypt.org from the WayBackMachine

Can’t fetch http://www.truecrypt.org from the WayBackMachine. Access denied.

Now, before I give you the related links, let me sum up the current theories as to what might have occurred here:

  • http://www.truecrypt.org has been attacked and compromised, along with the SourceForge Account (denied by SourceForge administrators atm) and the signing keys.
  • A 3-letter agency has put pressure on the Truecrypt foundation, forcing them to implement a back door. The devs burn the project instead.
  • The Truecrypt developers had enough of the pretty lacking donation support from the community and just let it die.
  • The crowdfunded Truecrypt Audit project found something very nasty (seems not to be the case according to auditors).
  • Truecrypt was an NSA project all along, and maintenance has become tedious. So they tell people to migrate to NSA-compromised solutions that are less work, as they don’t have to write the code themselves (Bitlocker, Filevault). Or, maybe an unannounced NSA backdoor was discovered after all. Of course, any compromise of commercial products stands unproven.

Here are some links from around the world, including statements by cryptographers who are members of the Truecrypt audit project:

If this is legit, it’s really, really, really bad. One of the worst things that could’ve happened. Ever. I pray that this is just a hack/deface and nothing more, but it sure as hell ain’t looking good!

There is no real cross-platform alternative, Bitlocker is not available to all Windows users, and we may be left with nothing but a big question mark over our heads. I hope that more official statements will come, but given the clandestine nature of the TC developers, this might never happen…

Update: This starts to look more and more legit. So if this is truly the end, I will dearly miss the Truecrypt forum. Such a great community with good, capable people. I learned a lot there. So Dan, nkro, xtxfw, catBot/booBot, BeardedBlunder and all you many others whose nicks my failing brain can not remember: I will likely never find you guys again on the web, but thanks for all your contributions!

Update 2: Recently, a man called Steve Barnhart, who had contact with Truecrypt auditor Matthew Green said, that a Truecrypt developer named “David” had told him via email, that whichever developers were still left had lost interest in the project. The conversation can be read [here]!

I once got a reply from a Truecrypt developer in early 2013, when asking about the state of UEFI+GPT bootloader code too…

I just dug up that email from my archive, and the address contained the full name of the sender. And yes, it was a “David”. This could very well be the nail in the coffin. Sounds as if it was truly not the NSA this time around.

May 282014
 

YaCy logoJust recently I have published my [vision for our networked society], claiming that freedom, self-determination and independence can be reached through decentralization, putting control over our services and data back into the hand of the users. My idea was to use distributed hash tables on a lower level to power search engines or social networks, distributed across a wide field of user-operated home servers. I thought my idea was pure utopia. Something we’d need to work hard for years to accomplish.

After I published it, users approached me via various channels, pointing out already existing software that deals with the centralization problems and dangers of today, like for instance the decentralized social network [Diaspora*] or more significantly even, [YaCy], which is a DHT-based search engine just like I envisioned it.

Let me show you the simple way the YaCy developers chose to show us, what they’re doing exactly. If you’ve read my article about decentralization linked at the beginning, you’ll immediately recognize what’s going on here (Images taken from YaCy):

So you can see, where this is going? In the right direction is where! And how is it implemented? Basically a Java server built on top of the [Apache Solr] / [Lucene] full text search engine well known in certain enterprises with a web interface on top. The web interface can be used for administration and as a simple web search, like we know it already. The Java code works with both Oracle Java 1.7 (Windows, MacOS X) as well as OpenJDK 1.7, which is preferred on Linux. I haven’t tested it, but I presume it might also work on BSD UNIX, as some BSD systems do support OpenJDK 1.7 too. Could also work on OpenSolaris I guess, and it can run with user privileges.

If you want to go the Oracle route on Linux, this also seems to work, at least for me, despite the YaCy developers asking for OpenJDK. But then again, if you wanna stay clear of any even remotely fishy software licenses, just go with OpenJDK!

In case you haven’t noticed yet, I have already joined the YaCy DHT network as a node, and the search using my node as an entry point into the DHT superstructure is embedded in this weblog already, look at the top right and you’ll find it! Mind you, it ain’t the fastest thing on the track, and the quality of its results won’t yet match Google or anything, but we’re getting there! I may also choose to embed it at [http://www.xin.at], not just here. But we’ll see about that.

Also, the web interface has a few nice monitoring gadgets, let’s have a look at those for my own fresh node, too:

Now, YaCy doesn’t provide data all by itself. Like in my original idea, the network needs to pull in data from outside the superstructure, from the regular Internet and make it searchable. For that, YaCys administration web features a simple crawler that you can send off to index everything on a certain domain via HTTP/HTTPS, like “http://wp.xin.at/”, or from a Samba/Windows share server, or from local files, or FTP etc. There is also a more complex, extremely configurable and powerful crawler, but I’ve only used the simple one so far. And it also visualizes what it does, look here:

So the web interface is pretty cool, and it actually works, too! The Crawler also has parsers for tons of file types, like PDF, Office documents (Microsoft and Open-/LibreOffice), media files, ZIP files etc., so it can index the contents and/or meta data of such files too, full text!

While I do not need it, you may actually also disconnect YaCy from the “freeworld” network entirely and use it as an intranet search engine. There is even professional support for that if you’d like to use it in that context within your company.

So there we go, a free, decentralized search engine, that lies not in the hand of some opaque megacorporation, but in our very own hands. How could I’ve missed this?! I have no idea. But it seems even I have walked the world in blindness too, for the three pillars of my vision are more real than I’d have thought; Independence, Self-determination, Freedom. It’s all right there!

And you don’t even need a home server for that. You can just run it on your desktop or laptop too. Not perfect, but this works due to the massively fail-proof nature of the DHT network, as described in my earlier publication.

Seriously, this is pretty damn awesome! We’re far closer to my “stage II” than I would’ve believed just 2 weeks ago. All we need to do now is to solve the social problem and make people actually migrate to freedom! Yeah, it’s the hardest of problems, but at least we have the tech sitting there, ready to be used.

So now it’s your turn (and mine actually): Let’s inform people, lets educate whomever we can, and help ourselves lose the chains!!

Goweb Counter