Notable features are:

• GLib friendly API for proxy configuration (GProxyResolver)
• Configuration powered by LibProxy (requires installation of glib-networking)
• Transparent support for SOCKS version 5, 4a and 4
• Support for application side proxy such as HTTP (using g_socket_client_add_application_proxy(…))
• Proxy information available inside the GSocket’s remote address
• Plug-in based configuration and protocol support

So I decided to restart my analyses with both features together (Proxy and TLS).  I’m far from being done but I’d like to share my findings so far. Let’s start with a simplified representation of a “normal” network connection.

The goal with that little timeline was to prove myself that both features fits well together. Some may notice that this is exactly what would happen if you connect through SOCKSv5 to an XMPP server doing TLS auto-negotiation. This use case is important for me since I would like to remove TLS code from Wocky (Telepathy Gabble XMPP stack) and use GLib in the future.

That’s all very interesting but where’s the problem ? Well the thing is that both proxy and TLS handshake requires information about the original destination address. For proxy handshake, we have to send the original hostname and port to the proxy server. For proxy protocol like HTTP, you need to know the destination protocol in order to decide if you leave the connection as-is (e.g HTTP, Gopher and FTP) or if you have to use HTTP Connect method. For TLS handshake, you need to check server certificate against the original destination address (not against the proxy server address). You also need to take in consideration the scheme if an URI was used to connect.

On proxy side, the implementation is using the GProxyAddress (a subclass of GSocketAddress). It is used to memorize the destination hostname and port. On TLS side a method get_name() was added to GSocketConnectable interface. The first thing I told myself when I started writing this was: Why a program can’t just remember that information ? Well the answer is that in both cases this information might be acquired dynamically during the address enumeration. As an example, if you use GNetworkService class, you will never know what hostname was really used since the returned GSocketAddress does not contain it.

Basically, this is what I need to work on to pursue my way trough a more complete network stack in GLib (and get Proxy/TLS support from GLib in Telepathy Gabble ).

A few months ago, I was asked to implement proxy support for Telepathy Gabble. While reading about socket based proxies, I asked myself why should Gabble cares about proxies ? It does not change anything in the way XMPP is being used. The only difference is at connection time. As GLib offers an abstraction to socket connections why GLib can’t take care of them ?

That’s why I started hacking on GLib to implement transparent proxies. I came up with a set of patches that can be found in my git tree.

The problem can be split in two:

1. Which proxies should I use ?
2. How do I connect through these proxy servers ?

The first problem is configuration. There is at least three types of proxy configuration. The network provided proxy WPAD (e.g. often through DHCP), the JavaScript configuration files (PAC) and the static configuration (e.g. system network configuration). This problem can be solved using LibProxy. While its name is a little generic, LibProxy only deals with proxy configuration. You give it an URI and it gives you back one or more proxy URIs.

The second problem is the connection. Some proxy protocols are dialects of other protocols. As those are very specific, it’s normal to leave to specialized library the task of handling them (e.g. libsoup will care of HTTP proxy). For other protocols like SOCKS, every application should support them. Currently, every application and library implements their own partial support for SOCKS and some just don’t. If you are lucky like me, you may end-up with Evolution not using SOCKS except when rendering emails external images because libsoup does support it.

Quickly the problem gets bigger and code more complicated. At some point, having this in a centralized library should help desktop applications to just work. But my idea has some limitations since we can’t force anyone from using BSD sockets directly. So far, I can only encourage maintainers to port over GIO,  basing their code on a  well tested network abstraction.

The feature is as been made possible by Telepathy draft API for mail notification. Meego provides the premiere integration of this API in a user interface. It fills a long standing gap in the Telepathy framework.

Enjoy!