Printer

For the printer, there is a very convenient package in the universe/multiverse repos :

sudo aptitude install  brother-cups-wrapper-laser

That's about it, you can now add the printer using the usual gui, or you can add the printer in the shell

sudo  lpadmin -p Brother-MFC-7320 -E -v usb://Brother/MFC-7320 -P /usr/share/ppd/Brother/MFC7220.ppd -o PageSize=A4

Scanner

!!! First POWER OFF your Brother MFC-7320 !!!

Run following script :

 #!/bin/bash

# patch udev rules
cat <<EOF>> /lib/udev/rules.d/40-libsane.rules
ATTRS{idVendor}=="04f9", ENV{libsane_matched}="yes"
EOF

# restart udev
sudo service udev restart

# download driver
wget http://pub.brother.com/pub/com/bsc/linux/dlf/brscan3-0.2.11-4.i386.deb -P /tmp

# install driver
sudo dpkg -i /tmp/brscan3-0.2.11-4.i386.deb

!!! Now you can POWER ON your Brother MFC-7320 again !!!
Note : This is a howto that I adapted from here :

http://www.panticz.de/Install-Brother-MFC-7320-on-Ubuntu

http://www.dontmakemesteal.com/

I figured out that cookies are not suffisent since we cannot issue a cookie that would be readable by the plugins and scripts in the http pages but that would not be transmitted over the internet with every http request.

So I gave a little thoughts into this, and came up with a solution involving an html-5 functionality to implement my http-security : sessionStorage.

I will soon release a demo hoping to recieve some feedback on new security issues I couldn't think of.

The general idea is to inject a javascript with every html page sent using http. This script would then get a stack of http-request-tokens using https and SSL, and store this stack in the local sessionstorage.
Those http-request-tokens are now available to javascript and have never been transmitted in clear-text, nor will they automatically be transmitted with every http request.

This allows us to have our Javascript adding a http-request-token as POST parameter to each and every hettp-request the client will make, achieving protection against identity-theft.

The key feature of this design is that the token that definitely authorize the http request is valid for a single http request ! It makes it impossible for an attacker to guess the next token, and he could not have spied the tokens when the server negociated the stack of tokens since it happened in https. So the attacker is unable to forge a http request that will be accepted by the server.

But careful, any attacker can still see all tokens when they are used by the legitimate client. So be careful to use a token-generation algorithm that keeps any attacker from guessing tokens (use random tokens, and be careful since unsuffisent entropy might allow guessing of the upcoming generated tokens).

Another enjoyable aspect of this approach is that it can be made almost transparent to the web application if embedded in the webserver (the token-checking part at least, the application still must allow the javascript to add the http-token on each GET/POST request).

Stay tuned for the demo.

In this article, i'm going to review the technical fundaments of http-sessions, explain the problems encountered and offer a view on possible solutions.

A technical overview

We first need to remember that http is a clear-text protocol. This means that ther is no encryption between the user's browser and the webserver, unless both client and webserver uses https which is a simple ssl wrapping of http, encrypting the complete http request.

Another important characteristic of http is that it is a stateless protocol, so there is no built-in mechanism to handle things like sessions that require a logged-in state opposed to a default logged-out state.

Now you're thinking i'm telling stories since you've been browsing the web and loggin in on your facebook account using http... So let's have a look at following communication description for a better understanding.

Most common usecase for http/https login

This depicts the most common login scenario used on the web. We see that we establish a new encrypted https session to pass the credentials to the server. In response tou our https login request, we are going to recieve a cookie containing a "http session key" provided by the application behind the webserver (not the webserver itself).

This session key identifies at this point our https connexion, but since this cookie is also passed along with each and every http-request, it definitely also identifies our http session.

This is a necessary mechanism to have seamingly statefull http since this cookie is going to be recognized by the application executed by the webserver, alowwing it to identify the user at each request. This session-key becomes a time-restriced token, that identify the user, and it needs to be passed with every http request in order to sort out the several users sending requests to the server.

So even if you never send your username & password in clear text, every time  you make a http request you are going to send this session-key in cleartext over the internet, allowing the application to recognize you and serve you specific content, allow you to trigger actions on the applications and any other application-specifig things you can do...

To sum up, http-session are used in this scenario as a temporary username&password that are send in clear-text with every http request. The 2 only advantages of the http-session-id is that it does not leak informations about your username&password (talking about the string here), and that it is time-restricted.

The problem

Now that you understand that with every http-request, a session-key is passed along in clear-text, playing the role of your credentials, the problem is well known in the télécommunication world : spies.

Internet has never been a secure communication channnel, spying is not so hard, but the problem has become more and more frequent since the arrival of public networks.

Now that lots of people uses public wifi hotspots, it has become very easy to spy on them since you can connect to the very same network and simply listen to everything.

Firesheep has'nt caused the problem, it has just pointed out how easy you can be spied on and the consequences it can have !

Abandon http for the benefit of https ?

There are some technical reasons to why companies are not willing to use exclusively https. A simple explanation is that https is consuming a lot more computing ressources that http since the whole http request is encrypted.

Decyphering requires lots of CPU time but also causes problems with load-balancing and ssl-certificates.

Load balancing problematic

A loadbalancer is an dpecialized proxy that is going to read the incoming http request and distribute it to a backend server depending on the load of those servers.

In most cases, a loadbalancer will read the http session-id and make a permanent link between a session-id and a backend server so that backend webservers don't neet to share the session ids.

The problem with https is that this loadbalancer will need to be an encrytption endpoint in order to keep doing this job. Since the whole http-request is encrypted when using https, the session-id is too, and in order to dispatch the request to the correct backend server, the loadbalancer will need to decypher it first, causing the ssl computing overhead to happen at the loadbalancer.

This would require trumendest computing power since a loadbalancer is only used when the amount of incoming requests is too important to be handeled by a single server, and is not an acceptable scenario for most companies.

Possible solutions

Defining the actual security issues is the key

To find an acceptable solution, we need to reconsider the problem and point out what is realy disturbing.

In most cases, the spying is not the real problem since the data passed in the http request is going to become public or almost public at some point in time. For example, when you post something on your facebook wall, well you meant to send it so others can see it online... The idea is that in most cases you can accept the fact that an attacker can spy on what you published or what you read.

The realy ennoying thing is the identity theft. The fact that an attacker is able to hicjack your session and thereby gain your online credentials is realy problematic. You can never accept that an attacker is able to send a mail in your name, or change your ogin/password...

So the real problem is not the session hijacking, it's more the fact that the server relies _only_ on this session-id that can so easily be stolen. And there we might have a solution !

A first solution proposal

The same way that client and server negociate a token during the https requests, we can easily imagine that they also negociate something else.

During the https phase of the login, we can easily have the server negociate the client a method to generete a http-request-authentication keys.

The idea here is that with each next clear-text http request, the client is going to pass a kind of token which time-restriction is limited to one http request. This way, identity theft can be prevented since the method for generating those tokens have been negociated using a secure connexion and is only known by the real user and the server.

The generation of those http-request-authentication keys can then take different forms. A complex unique password generation algorithm can be used, deriving the unique passwords from a key shared during the https phase.

This method have several advantages :

• the amount of encrypted data is minimal
• the (possible) encryption is offloaded on the webserver, and transparent to the loadbalancers.

I said "possible encryption" because we actually don't need encryption. We can negociate an ordered set of token, each token to be used with one http-request and then thrown away. In this case there is almost no computing overhead to the actual solution, just a bit more data stored in the session-file on the server and in the browser of the client.

Moreover, this solution doesn't require updated browers, since the logic on the client side can be achieved using javascript to add the http-request-authentication in the DOM before the browsers makes the next request.

Conclusion

http sessions are not enought to identify a user. But there are possible ways to overcome the biggest problem of the http-session, making identity theft impossible without encryption. More important : we can find solution that will work even on old crappy browsers, using old technologies and creating very little overhead to the current non-suffisent security measures.

This article is the sommary of my latest thought, but I must admit I didn't give a lot of effort to find my "solution", so any constructive critic is welcome !

So opera fighted back and always stayed first with the rendering engine. But the JS-engine was getting oooold... Powerfull enought for any web usage, but still, Opera decided to give some developpment effort and strike back.

And they did ! The latest JS-engine is again the fastest engine, here some test results on my Unix Platform :
Opera, Firefox, and Chrome. Note (as the url of the test suggest) that chrome have been heavily optimized for this specific test, and still doesn't achieve any significant speed difference to opera, and is beated on lots of  others tests.

This just repeats that Opera have the best core-components, but still, what's important is the User Interface, and the browser's functionality... And here, once again, Opera is first with heavy Desktop integration on Windows, Linux and Mac, the only browser to natively support all functionnality needed to surf the web : non exhaustive list : SpeedDial, intelligent SearchBar, OperaLink : Bookmarks,  Notes, Personalized SearchEngines and much more, all sync online and aviable with a single clic on each Opera instance, even mobile ones ! Mouse gestures and lots of other features !

I have been Testing (with a great 'T')all browsers avbiable for my platform, and by testing, I mean using them for over 2 weeks and longer, untill I cannot bear it anymore to miss some critical features that were sadly implemented through buggy extensions. So stop listening to poor experienced people claiming they have "tested" opera and still preffer Firefox when all they did was install Opera and run it twice. Opera is THE browser, and the only thing that you could miss is the multi-threads-downloads from DownThemAll, which let say it clear, is not worth staying with Firefox.

Well, if you're running linux or ubuntu, and that you don't want to exceed your quota and be blocked, I have the perfect thing for you !

It's a script that watches your quota for you, and if it's too high, it locks internet untill the quota gets down. While you'r locked, you can still use the ressources on the university network (as they are illimited, only internet traffic is limited by the university...) and you can still use your LAN (no point in restraining that ;] )

So, let's get started and install the script...

First thing : download the script.

Then, let's configure it a little, read the file and fill it with the correct values for you. Here's a summary of what you should edit :

• QUOTA_URL : fill it with the url where you can see your traffic, it should end with mytraffic.php
• NETWORK_INTERFACE : eth0 or the interface you're using to connect to internet.
• LOCALNETWORK : Describes your LAN network, change it if your local IP is not like 192.168.0.x, it should be the same as your IP, but end with a 0.

You can also edit the values NOTIFY_XXX to change the language. Right now it's french. Thoses messages will be displayed every time the scripts locks or unlocks the network.

Once it's donc, copy the script in /etc/init.d and make it executable :

sudo cp iptables-dresden /etc/init.d
sudo chmod +x /etc/init.d/iptables-dresden

Now we just have to start the script on bootup so we're sure we don't forget it :

sudo update-rc.d iptables-dresden defaults

Note that if you don't want the script to be run at startup but only at session-opening, you're on your own, keep in mind that the script uses iptables, and must be run with root privileges...

Good job ! You're done, now your Traffic is monitored , and you will not be blocked for many days ! Worst case you're blocked for one day, the time that your quota gets down...

You can modify the script as you want, change the limit to 90% for example, but keep in mind that the webpage does not update every 30 seconds, so you should make sure that you cannot exceed your traffic (jump from 89% to 101%) without beeing able to see it in the webpage, because if the webpage isn't updated fast enough BY THE SERVER, you could exceed your quota even using this script (changing the delay of the script is not a solution for this issue...) !

Je me place dans le cas ou votre système a planté, ou que vous ayez réinstallé votre OS et donc perdu la configuration mdadm.

Rien de plus simple pour récupérer votre RAID, mdadm fait tout tout seul : une fois les disques durs branchés, dans une console :

sudo mdadm --examine --scan /dev/sda /dev/sdc /dev/sdd /dev/sde

Normalement, la ligne ne renvoie rien si tout se passe bien, par contre, un rapide coup d'oeil dans /prod/mdstat vous prouvera que votre RAID est bien reconnu désormais.

Vous pouvez maintenant le monter :

sudo mount /dev/md0 /media/raid