GPLv3 beta 2

Posted in DRM, FLOSS, GPLv3, Legal at 4:12 pm by Jens Hardings

GPLv3So, the second draft of the GPLv3 is out. Changes include a rephrasing of the anti-DRM aspects of the code. In fact, the wording DRM is not there anymore. As Richard Stallman has made it clear in his presentation at barcelona, the purpose of these clauses is to avoid the “tivoisation” of programs. That is, even if the source code of the GPL software is available, you cannot change some bit and trust it to be installed on the same hardware it was distributed with, and work. This is because you need a special key to do so, or the hardware will refuse to run the modified code.

If we assume as a fact that software enforcing DRM will exist in the future, I would rather like to have the code available, and being able to reproduce the compilation exactly as to generate the same binary that has been signed as “trusted”. That way, at least I would have enough information to choose whether I could trust the system enough or not, and this would set abuses on the part of publishers to a minimum. This does not mean that the code should be under the GPL, though. So up to this point there is really no problem.

There are some issues, though, where I’m not so sure about. One phrase in particular states:

Read more »


Another reason to use SSL correctly

Posted in Security at 2:52 pm by Jens Hardings

This is yet another flame to the online banking systems in Chile (and elsewhere).

The problem is as follows: apparently to make the system faster for visitors (requiring only one click), many banks make their login form available on a non-secured page. When everything works as intended, the form directs the request to an SSL-enabled page, so the transmission is effectively encrypted before your browser begins to send any data. But what happens when you get to a web-page that seems exactly like the original but that doesn’t redirect you to that SSL-enabled page? Your data goes unencrypted, probably right to the hands of someone you should not trust. You might notice this if you pay attention, but it would probably be too late and there are many ways of how to make it look as if you really did go to the bank’s web after giving away your login credentials to some unknown server on the internet.
So, how are the odds of getting to a fake bank page? Not very high, unless you get some phishing e-mail or somebody plays with the DNS resolver you use, both very simple and common activities nowadays.

Many banks are using marketing strategies to show how secure they are by giving (actually, selling) tokens for enabling 2-factor authentication. This is good for avoiding your fixed password to be captured by some keylogger (either a software or hardware keylogger). But it does not protect you from a man-in-the-middle attack like the one published on Washington Post.
Ironically, to get to the login page of my bank (Banco de Chile), you have to make an extra click. I can understand that, since not everybody who connects to the main page of the bank needs authentication or encryption, the main page is not secured. Probably most customers would not care to make one extra click (or store a bookmark so they won’t have to) in order to get to the secure login page. But in my case, even when I have to click on the link to get to a second page, that second page is also not secured by SSL, even when the most common use for that page is for logging into the customers bank account. There is not even the alternative for a security-aware customer to go to a, maybe slower but secure, login page. The only way to log in securely is to first enter a valid ID and a fake password, verify the authenticity of the server, go back to the non-secure page and assume that the second time you will also connect to the right server (which is not necessarily true). Or, you may have come across a dark and upublished way to access the server and obtain the login form.