SSL encryption between parent and child squid proxy

February 22, 2011 · Posted in Linux, Projects · 1 Comment

I use squid proxy server for a long time. Recently, I had to forward several requests to a child proxy but these requests must be sent encrypted. Using a VPN connection between the two proxies was my first thought. However, adding one more tunnel to that server would make the whole network configuration really nasty so I had to think of an alternative solution. That was SSL.

First a little background info

How does SSL work:

In SSL client-server authentication we use x.509 certificates. Ok but what is that? Think of an actual certificate. It is pretty much the same thing except it is digital and includes information related to the specific host. For example, a x509 certificate includes the signature algorithm, the version, the validity period, the subject name, the subject’s public key and some other information as well. Why do we need it? Simple. Take a look on the following illustration.

So what is going on here?

The client sends a “hello” message to the server containing some preferences such as supported ciphers and a random value A. The server replies with a “hello” message containing the chosen cipher, his certificate and another random value B. The server also requests the client’s certificate. The client verifies the certificate of the server ( we won’t ) and generates a master key based on his private key and the random value B. Then it uses the server’s public key ( embedded on the server’s certificate that he received before ) to encrypt the master key which forwards it to server. At this point a shared secret key has been established between the server and the client. They will use this key + the A,B randoms respectively to computer the MAC and encryption keys. Finally, the client will use the chosen cipher ( as selected by server in the first step ) to encrypt the upcoming packages.

How does this apply to our case:

Imagine that the parent squid proxy is the client and the child is the server. This is because the parent (client) contacts the child (server) to send the packages in the first place. I assume you have a working squid configuration on both ends

Generate certificates:

This applies to both hosts

Create the private key:

openssl genrsa  -out server.key 4096

Create certificate:

openssl req -new -x509 -key server.key -out server.crt -days 365

Now you should have two working certificates ( lets assume parent.crt and child.crt ) for your squid hosts.

Child configuration:

The child proxy must be configured to listen to an https port along with this new certificates

https_port 4443 cert=/etc/squid/child.crt key=/etc/squid/child.key \

 sslflags=NO_DEFAULT_CA

Parent Configuration

The parent proxy should be configured as follows:

cache_peer remote.proxy.example.com parent 4443 4443 ssl \

sslcert=/etc/squid/parent.crt \

sslkey=/etc/squid/parent.key sslflags=DONT_VERIFY_PEER

You are done :)

Tags: <Linux, security, squid, ssl>

Shutdown hosts remotely on power failure – A Christmas project!

January 13, 2011 · Posted in Gentoo, Linux · 4 Comments

The electricity network in my island is by far the worst in the entire planet. Seriously. In order to minimize the hardware failures, I bought two UPS units (Mustek & Trust). Sadly, the Trust one does not have a serial/usb port interface so I can’t control it in any way. Therefore, I came up with a neat solution. It would be cool to shutdown both computers when the battery of the Mustek UPS goes low. But how can I do that?

Legend:

Phoenix -> Host attached to Mustek UPS unit via usb

Mystical -> Host connected to Trust UPS but there is no usb/serial port to control it

Step 1: Install NUT on the Phoenix host

echo "sys-power/nut usb" >> /etc/portage/package.use/nut
emerge -av nut

Step 2: Allow user on Mystical host to shutdown the host using sudo

Mystical ~ # grep -v ^# /etc/sudoers|grep -v '^$'
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
%users ALL= NOPASSWD: /sbin/shutdown -h now, /sbin/shutdown -r now

Step 3: Configure NUT

Nex@Phoenix ~ $ grep -v ^# /etc/nut/ups.conf

[mustek]

driver = blazer_usb

port = auto

desc = “UPS”

Nex@Phoenix ~ $ grep -v ^# /etc/nut/upsmon.conf

RUN_AS_USER Nex
MONITOR mustek@localhost 1 server CHANGEME master
MINSUPPLIES 1
SHUTDOWNCMD "ssh -l user -p XXXXX Mystical "sudo /sbin/shutdown -h now"

&& /sbin/shutdown -h +0"

POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

Now, every time the Mustek’s battery goes low, the Phoenix host will shutdown the Mystical host remotely, by sending a shutdown command via ssh. I may have failed when I chose a UPS unit without a usb/serial port but I am quite happy that I managed to sort this out.

ps: The tutorial assumes that you have a working ssh public-key configuration between the two hosts.

Tags: <Gentoo, Linux, Nut, UPS>

Interview: Dimitris Glezos

April 14, 2009 · Posted in Interviews · Comment

One of the reasons I like open source so much , is the relationships that are developed between users and developers. Through irc, blogs, forums, etc, users can contact us directly and discuss with us about almost anything :) . This is why I try to be quite active on these areas. As a user, I also really enjoy reading interviews from various open source developers. Learning more about their character and personality leads effectively to more creative discussions with them.

In order to turn the above thoughts into actions, I am planning to get involved with the Gentoo userrel project :)

Bringing users and developers closer is a nice way to keep them motivated and recruit highly active users as future developers.

Today, I have the honor and the pleasure to interview Dimitris Glezos, a Fedoras’ board member and the founder of Indifex. He is also the lead developer of Transifex.

* Could you briefly introduce yourself?

I’m Dimitris Glezos, 28 years old, living in sunny Greece. I’m the founder of
Indifex, a new software company which researches and develops scalable
solutions for content translation and distribution. I’ve been quite active in
the Fedora Project as a member of the Board and a member of the Fedora
Localization and Documentation Steering Committees.

I graduated as a Computer Engineer from Greece and specialized on Advanced
Information Systems, before deciding to try out research and study Semantic
Web and Fuzzy Logic for a year and half. After finally admitting to myself
that my true love is open source, I switched to work full-time on it.

In the non-technology world, I enjoy design, photography and rock climbing
quite a lot. Lately I’ve been trying to learn Contract Bridge too — hard
game. But that’s true for most of the great games, right?

* Tell us about your opensource contribution.

The first contribution I remember came at least a year after I started being
attracted to the free software culture from projects like Mozilla. I took the
lead in localizing the PHP programming language manual, and proceeded to
translating Fedora and GNOME in Greek. Around that time, together with Nikos
Charonitakis and others, the Greek Fedora Team was founded.

In terms of code contributions, I’ve sent a few patches to the i18n toolchain
of the Fedora Docs Project and some improvements to Fedora’s Websites and
default Firefox homepage. Seeing how much Fedora’s Localization infrastructure
could be improved, I decided to expose myself in more trouble by leading the
effort to move the Fedora development code, which was hosted on an internal
CVS server, to servers managed by the community. Boy, that was fun!

At that point Transifex started being built, with support from the Google
Summer of Code, and soon became the Localization Platform for Fedora. Today,
the Tx development website has more than 70 people registered and the project
has grown to 15K lines of code and a strong core team of committers.

Oh, and one of the most fun stuff I did about open source and ‘digital
freedom’ in general was my involvement with the FFII opposition to the
legislation of software patents in the EU. Lots of trips to the European
Parliament, which, to all’s satisfaction and excitement, led to the rejection
of the directive.

* Recently you became a member of Fedoras’ Board. What is your area of
responsibility now?

The Fedora Project Board is the highest level of decision-making within
Fedora, and together, as a group, its members are empowered to decide on the
Project’s policies, to steer it to a good direction, to set priorities, and to
allow the rest of the Fedora sub-projects do their work with efficiency and
accountability.

While I’m a firm believer that the most successful organizations are those
which do not need a centralized decision center (a good read on the topic is
“The Starfish and the Spider” by Brafman and Beckstrom), the Board *is*
eventually accountable for everything that might go wrong in Fedora.

One of the roles I’m taking in the Board is helping the team and the Fedora
Project Leader have the best view of the needs, feelings and requests of the
community. Also, I’m working in continuing to increase the Project’s openness
in every decision taken, and in expanding our community reach by proposing
(sometimes drastic) changes in the way we’re doing things.

Being a guy who lives in Europe and doesn’t work with Red Hat allows me to
give different input to the Board, eventually chipping in the balance of the
team in a way which represents and benefits our community the most.

* What’s the status of Fedora at this moment? How do you see its future in
the next 2-3 years?

The Feature process we have in Fedora is completely open, and anyone can apply
for having a feature. You can take a look at the upcoming Fedora 11 feature
list at http://fedoraproject.org/wiki/Releases/11/FeatureList.

We released our Beta a few days ago, which looks quite promising. Some of the
features I’m excited about are automatic font and application installation,
kernel-based mode setting, faster startup (20 seconds?!), and the built-in
support for Delta RPMs, which allows users to update their packages by
downloading only what has changed in the update instead of a whole new version
of the package.

I’m also excited to see Python 2.6 being shipped with Fedora 11, a feature led
by Indifex’s own Ignacio Vazquez-Abrams.

Fedora’s development pace seems to be increasing, with more features landing
with each release. We see a lot of innovation happening in Fedora, and that’s
great, because that’s what our users like to see and need. In a few years I
see Fedora being even more influential in the state of the Linux Desktop,
having a stronger developer community and with improvements on the things we
need to continue improving.

* Transifex is being used more and more for translating purposes. How do you
feel about that?

Well, it feels great of course. :) The promises Transifex makes are quite
simple: I’ll be the robot to which translators can request everything they
need to translate, and the servant to take those files and silently put them
into the developer’s knitting pattern. Gradually we see more projects being
interested to use Transifex, and this will allow us to do some pretty cool
stuff in the future.

I’m also very excited to see that there is interest to use Transifex as a
platform and extend it to build other tools which extend and compliment its
functionality. This is also one of the reasons I’d like us to release a public
API soon too: to allow even more projects to interoperate with Tx and offer
users more features than today.

* How do you see the future of Transifex?

Bigger, better, faster. We’re working hard in listening to feedback from
translators and developers, in order to make Tx the best tool for large
communities of users like Fedora, Maemo, GNOME, OpenSUSE etc.

I also see the spur of side-projects which use Transifex to do cool stuff that
couldn’t be done before in the Open Source L10n landscape.

* What is the purpose of your company, Indifex? Do you have any projecs
running already?

At Indifex, we’re working on solutions that eventually will enable millions of
people to easily publish material to the web in the user’s native language.

Indifex also hires some very talented code hackers, among others, who develop
Transifex to the needs of various large organizations. We provide support for
the translation workflow of enterprises and big projects like Fedora, making
sure the translators and developers have the infrastructure they need to work
efficiently.

One of our biggest projects at this moment is the development of
transifex.net, a one-stop place and open platform for crowdsourcing
translations.

For us, Indifex is the place where we can have fun hacking great solutions
together using cutting-edge tools like Python, Linux, distributed version
control systems, and scalable internationalization techniques. It’s been a
great time so far, and I’m super excited about the upcoming months and years.

Patching with Quilt

December 27, 2008 · Posted in Linux · 8 Comments

Quilt is a great program to create patches. This post is a quick ‘n’ dirty tutorial on how to create a quick patch

Assuming you have Quilt installed ,

quilt new my.patch

will create a new empty patch named my.patch

Lets say that this patch is going to affect the main.cpp file. So ,

quilt edit main.cpp

Will open the main.cpp files using your predifined editor ( $EDITOR ), allowing you to make any changes you like. When you are done , exit the editor. Now, my.patch is a ready-to-apply patch for the main.cpp file.

If you want to apply it , you should refresh the patch by doing

quilt refresh

and

quilt push

to apply it. Now you have your new main.cpp file ready to use :)

The patch is stored under patches/ folder

If you want to revert the patch you can use

quilt pop

This quide was ment to give you the main idea about the quilt program

A great guide about quilt can be found here.

Happy patching

Tags: <Linux, patch, quilt>

Gentoo kernel bug hunting

December 4, 2008 · Posted in Gentoo · 2 Comments

After Daniels Drake call on November issue of Gentoo Monthly Newsletter I decided to join and help gentoo kernel team to hunt, catch, and kill several kernel bugs.

So far I like the whole development process. Daniel and the rest of the guys ( on #gentoo-kernel irc room ) are trying to show us the correct ways to deal with a possible kernel bug. There is no much coding to do ( hopefully ). We just try to understand why a bug is happening without dealing with source files ( until now ).

I think that this is a good way to understand the whole Linux kernel’s tree and become more familiar with it .

If someone would like to join us, join #gentoo-kernel irc room on freenode servers . Furthermore you can read this guide about the whole kernel maintenance process

Tags: <bugs, Gentoo, kernel, Linux>