[Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[S. I. Becker]

Daniel P. Berrange wrote:
> Having repeatedly said that we should be doing TLS encryption for VNC, I 
> figured I ought to get down & implement it. So, in the spirit of 'release
> early, release often', here is the very first cut of my patch for QEMU.
> This isn't suitable for inclusion in CVS yet - I just want to put it out
> for people to see / experiment with.

<snip>

>  - There is support for the current 'None' auth type, the standard 'VNC'
>    challenge/response auth type, and finally the VeNCrypt extension which
>    implements a TLS layer with several sub-auth types. Since it can now
>    do any protocol version, and negotiate auth types, we should be able
>    to easily add more auth types if we want compatability with other 
>    RFB auth extensions from projects like UltraVNC/TightVNC/etc. 
> 
>  - When choosing the VeNCrypt auth type, the client/server then negotiate
>    which sub-auth type they want to use. Then they perform a standard
>    TLS handshake, and if this is successful move on to do the actual
>    authentication. So the actual auth data exchange, and all subsequent
>    RFB protocol traffic is TLS encrypted.
> 
>  - The sub-auth types supported by VeNCrypt are:
> 
>      - Plain  - username & password - no TLS at all
>      - TLS Anon + None - TLS anonymous credential exchange, followed
>                          by standard 'None' auth type.
>      - TLS Anon + VNC  - TLS anonymous credential exchange, followed
>                          by standard 'VNC' auth type.
>      - TLS Anon + Plain - TLS anonymous credential exchange, followed
>                           by customer 'Plain' username/password auth type.
>      - TLS X509 + None - TLS x509 cert credential exchange, followed
>                          by standard 'None' auth type.
>      - TLS X509 + VNC  - TLS x509 cert credential exchange, followed
>                          by standard 'VNC' auth type.
>      - TLS X509 + Plain - TLS x509 cert credential exchange, followed
>                           by customer 'Plain' username/password auth type.
> 
>  - I did not implement any of the 'Plain' sub-auth types above. I may
>    add the TLS encrtyped Plain auth types, but certainly not the clear
>    text version.
> 
>  - The 3 TLS Anon subauth types use the basic diffie-hellman anonymous
>    credential exchange. Since there is no apriori trust relationship, 
>    this is subject to MITM attacks, so only marginally more useful than
>    the existing clear text wire format.
> 
>  - The 3 TLS x509 subauth types do a full x509 certificate exchange.
>    This is exactly the same top security model as used in the most 
>    recent HTTPS protocol implementationss, so the mode I'd recommend.
>    The server needs to be configured with a CA cert, a CA revocation
>    list (to block revoked clients), and its own server cert & key.
>    The server is currently setup to request a client cert and will
>    verify the cert against the CA cert & CRL. I need to make it 
>    possible to turn this client cert verification on/off. If you used
>    TLS X509 + None, then a whitelist of client CNAMEs and client 
>    cert verification could be your primary auth. If you use the TLS
>    X509 + VNC / Plain auth schemes, then client cert verification 
>    should be optional. So client programs connecting at very least
>    need access to the CA Cert, and if the server does cert verification
>    client programs will need to supply their own certificate too.

<snip>

>  - If configured to use the None, or VNC auth types, any of the 
>    standard VNC viewer programs will connect and if neccessary 
>    do the challenge/response authentication just fine. If the TLS
>    VeNCrypt authentication type is activated, then you will obviously
>    need a client program which supports this - the VeNCrypt project
>    on sourceforge supplies a vncviewer implementing this scheme.
>    I am also working with Anthony Ligouri to extend his awesome
>    GTK VNC widget to support all the different authentication types. 
>    This widget will provide a very easy way for people who want to
>    build GUI frontends around QEMU to drop in secure console support.
>    I intend to integrate it in virt-manager for example.
> 
> Regards,
> Dan.

I see that you are implementing VeNCrypt in your QEMU system.  I am 
flattered that you should choose it.  Please let me know how I can help.

Stewart Becker
aka
sibecker

Project Manager: VeNCrypt
http://sf.net/projects/vencrypt

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Daniel P. Berrange]

On Wed, Feb 28, 2007 at 09:27:30PM +0000, S. I. Becker wrote:
> Daniel P. Berrange wrote:
> >Having repeatedly said that we should be doing TLS encryption for VNC, I 
> >figured I ought to get down & implement it. So, in the spirit of 'release
> >early, release often', here is the very first cut of my patch for QEMU.
> >This isn't suitable for inclusion in CVS yet - I just want to put it out
> >for people to see / experiment with.
> 
> <snip>
> 
> > - There is support for the current 'None' auth type, the standard 'VNC'
> >   challenge/response auth type, and finally the VeNCrypt extension which
> >   implements a TLS layer with several sub-auth types. Since it can now
> >   do any protocol version, and negotiate auth types, we should be able
> >   to easily add more auth types if we want compatability with other 
> >   RFB auth extensions from projects like UltraVNC/TightVNC/etc. 
> >
> > - When choosing the VeNCrypt auth type, the client/server then negotiate
> >   which sub-auth type they want to use. Then they perform a standard
> >   TLS handshake, and if this is successful move on to do the actual
> >   authentication. So the actual auth data exchange, and all subsequent
> >   RFB protocol traffic is TLS encrypted.
> 
> I see that you are implementing VeNCrypt in your QEMU system.  I am 
> flattered that you should choose it.  Please let me know how I can help.

If there's any formal doc describing the VeNCrypt auth system in the
same style as the primary RFB protocol doc[1] that'd be very helpful.
I basically figured out the VeNCrypt protocol by reading the code and
the few mailing list notes about it. I've validated inter-operability
of the QEMU patches against the VeNCrypt viewer command, and validated
my GTK-VNC patches against the VeNCrypt server so pretty sure I've got
the normal cases correct. I've also tested a variety of error scenarios
and delibrate violations of protocol to ensure correct clien rejection.
It would still be useful to validate the code against a formal spec 
though to ensure I didn't miss an edge case somewhere.

Regards,
Dan.

[1] http://www.realvnc.com/docs/rfbproto.pdf
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[S. I. Becker]

Daniel P. Berrange wrote:
  > If there's any formal doc describing the VeNCrypt auth system in the
> same style as the primary RFB protocol doc[1] that'd be very helpful.
> I basically figured out the VeNCrypt protocol by reading the code and
> the few mailing list notes about it. I've validated inter-operability
> of the QEMU patches against the VeNCrypt viewer command, and validated
> my GTK-VNC patches against the VeNCrypt server so pretty sure I've got
> the normal cases correct. I've also tested a variety of error scenarios
> and delibrate violations of protocol to ensure correct clien rejection.
> It would still be useful to validate the code against a formal spec 
> though to ensure I didn't miss an edge case somewhere.
> 
> Regards,
> Dan.

Dan,

The closest I have to a formal spec are some emails going back-and-forth 
between Martin Koegler and myself over what the protocol should be. 
I've tried to collate and format these together below.  Please let me 
know if anything is not clear, or if you can spot any edge-cases that 
permit security flaws.

FYI: VeNCrypt protocols and version numbers of software releases will 
follow a pattern: a viewer/server with a software version number of 
x.y.z will implement all non-obsolete VeNCrypt protocol versions up to 
and including version x.y.  An even value for x means that the 
software/protocol is in "development" state.  An odd value for x means 
the software/protocol is in "production" state.  When a development 
protocol x.y is ready to be declared "production," it will be copied as 
version x+1.0.  This will be in tandem with a software release version 
x+1.0.0, which will be version x.y.z renumbered, plus a software change 
to communicate version x+1.0.0 as protocol number.

I'd be quite interested if you make headway on the unix side of things, 
in particular implementing a the username/password checking part of 
"Plain" types, since I primarily have a Windows background.  It's not 
that I won't do the unix stuff, more that I can't (or at least, find it 
more difficult).  (FWIW, I run debian and Redhat on a couple of 
machines, but don't use them on anything like a day-to-day basis).   The 
fact that someone other than myself is using VeNCrypt - particular from 
the the unix/Linux world - has led me to put a "Help wanted" ad on 
sourceforge for precisely this.

Stewart


RFB Protocol section 6.2.19 - VeNCrypt Security Type:

After the VeNCrypt security type (19) is chosen, the server then sends 
the highest version of the VeNCrypt RFB extension it supports, as two 
U8s (major version followed by minor version)

No. of bytes	Type	[Value]		Description
1		U8			Highest VeNCrypt major version
1		U8			Highest VeNCrypt minor version

Currently the only defined versions are 0.1 and 0.2.
NB ideally, servers should support all VeNCrypt versions up to and 
including this version, with the execption of protocol versions that 
have been declared obsolete.

The client then responds with two U8s (major followed by minor) 
indicating the version to be used (anything up to and including that 
given by the server), or 0.0 if for some reason it can't support the 
protocol:

No. of bytes	Type	[Value]		Description
1		U8			Chosen VeNCrypt major version
1		U8			Chosen VeNCrypt minor version

In the case of 0.0 the connection is closed at this point.


RFB Protocol section 6.2.19.0 - VeNCrypt Security Sub-type negotiation:

The server then responds with either a single U8, 0 for indicating that 
the server can support the version chosen by the client or non-zero 
(typically 255) for failure.  If non-zero, the connection is closed at 
this point:

No. of bytes	Type	[Value]		Description
1		U8			Success/Failure

Depending on the VeNCrypt version chosen and acknowledged by the server, 
communication continues at section 6.2.19.0.1 (VeNCrypt protocol 0.1) or 
6.2.19.0.2 (VeNCrypt protocol 0.1)


RFB Protocol Section 6.2.19.0.1 - VeNCrypt protocol 0.1

VeNCrypt protocol 0.1 is now obsolete, servers that show numbers higher 
than 0.1 need not support it.

The server sends a U8 listing the number of sub-types supported.  If 
this is zero, the connection terminates, otherwise it is followed by the 
sub-types it supports/permits as U8s:

No. of bytes	Type	[Value]		Description
1		U8	[n]		Number of supported sub-types
n		U8 array		Supported sub-types

The sub-types are as follows:
19: Plain
20: TLSNone
21: TLSVnc
22: TLSPlain
23: X509None
24: X509Vnc
25: X509Plain

The client chooses one of these by sending back a single U8, or 0 for it 
being unable to choose one.  If 0 is sent, the connection is closed at 
this point:

No. of bytes	Type	[Value]		Description
1		U8			Chosen sub-type

If 0 is sent, then the connection here is closed.  Otherwise, 
communication continues as defined at:

Plain: section 6.2.19.256
TLSNone: section 6.2.19.257
TLSVnc: section 6.2.19.258
TLSPlain: section 6.2.19.259
X509None: section 6.2.19.260
X509Vnc: section 6.2.19.261
X509Plain: section 6.2.19.262

Other - typically 0, but might (maliciously) be something else: 
Connection is closed


RFB Protocol Section 6.2.19.0.2 - VeNCrypt protocol 0.2

The server sends a U8 listing the number of sub-types supported.  If 
this is zero, the connection terminates, otherwise it is followed by the 
sub-types it supports/permits as U32s:

No. of bytes	Type	[Value]		Description
1		U8	[n]		Number of supported sub-types
4*n		U32 array		Supported sub-types

The sub-types are as follows:
0: Failure
256: Plain
257: TLSNone
258: TLSVnc
259: TLSPlain
260: X509None
261: X509Vnc
262: X509Plain

Note on version 0.2 sub-types: Sub-types 1 to 255 are reserved for 
standard RFB types, should it be deemed useful to have them chosen at 
this point in the in the VeNCrypt protocol (choosing 19 at this point 
will never be be allowed since it causes looping).  Sub-types 256 to 
2^31 - 1 (i.e. values with the most significant [sign] bit not set) are 
reserved as "official" future VeNCrypt sub-types, and may be requested 
from VeNCrypt in the same way that new RFB types may be requested from 
RealVNC Ltd.  Sub-types 2^31 to 2^32 - 1 (i.e. values with the most 
significant [sign] bit set) may be used as "unofficial" types, allowing 
the protocol to be extended without reference to VeNCrypt.

The client chooses one of these by sending back a single U32, or 0 for 
it being unable to choose one.  If 0 is sent, the connection is closed 
at this point:

No. of bytes	Type	[Value]		Description
4		U32			Chosen sub-type

If 0 is sent, then the connection here is closed.  Otherwise, 
communication continues as defined at:

Plain: section 6.2.19.256
TLSNone: section 6.2.19.257
TLSVnc: section 6.2.19.258
TLSPlain: section 6.2.19.259
X509None: section 6.2.19.260
X509Vnc: section 6.2.19.261
X509Plain: section 6.2.19.262

"Unofficial" sub-types - Any further behaviour is implementation 
defined, however it is advised that any unsupported "unofficial" types 
will be treated as "Other" below.

Other - typically 0, but might (maliciously) be something else: 
Connection is closed.


RFB Protocol Section 6.2.19.256 - Plain VeNCrypt sub-type

If the Plain, TLSPlain or X509Plain sub-types have been chosen, the 
client sends the username and password for the connection as follows:

No. of bytes	Type	[Value]		Description
4		U32			Username Length
4		U32			Password Length
Username Length	U8 array		Username
Password Length	U8 array		Password

The server then verifies:
a) that the specified user is permitted to connect
b) that the specified username and password are valid

NB See section 6.2.19.259 or 6.2.19.262 for communication that occurs 
prior to this if the TLSPlain or X509Plain sub-types have been chosen.

Communication continues with the SecurityResult message


RFB Protocol Section 6.2.19.257 - TLSNone VeNCrypt sub-type

If the TLSNone, TLSVnc or TLSPlain sub-types have been chosen, Anonymous 
TLS authentication is initiated as described in the TLS protocol.

If the TLS authentication was not successful, the connection is closed. 
   Otherwise, all further communication takes place over the encrypted 
TLS channel.

If the TLSNone sub-type was chosen, authentication continues as for the 
None type described in section 6.2.1.


RFB Protocol Section 6.2.19.258 - TLSVnc VeNCrypt sub-type

TLSNone authentication takes place, as described in section 6.2.19.257, 
followed by VNC authentication as described in section 6.2.2


RFB Protocol Section 6.2.19.259 - TLSPlain VeNCrypt sub-type

TLSNone authentication takes place, as described in section 6.2.19.257, 
followed by Plain authentication as described in section 6.2.19.256


RFB Protocol Section 6.2.19.260 - X509None VeNCrypt sub-type

If the X509None, X509Vnc or X509Plain sub-types have been chosen, X509 
certification based TLS authentication is initiated as described in the 
TLS protocol.

If the X509/TLS authentication was not successful, the connection is 
closed.   Otherwise, all further communication takes place over the 
encrypted TLS channel.

If the X509None sub-type was chosen, authentication continues as for the 
None type described in section 6.2.1.


RFB Protocol Section 6.2.19.261 - X509Vnc VeNCrypt sub-type

X509None authentication takes place, as described in section 6.2.19.260, 
followed by VNC authentication as described in section 6.2.2


RFB Protocol Section 6.2.19.262 - X509Plain VeNCrypt sub-type

X509None authentication takes place, as described in section 6.2.19.260, 
followed by Plain authentication as described in section 6.2.19.256

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Peter Rosin]

Hi!

Sorry for the response to this old post, but since it seems to be the
best reference for the VeNCrypt protocol on the web, I don't feel too
bad. Hopefully I got the message-id correct so that this post is
properly linked.

S. I. Becker skrev:
> Daniel P. Berrange wrote:
> > If there's any formal doc describing the VeNCrypt auth system in the
> > same style as the primary RFB protocol doc[1] that'd be very helpful.

*snip*

> Dan,
> 
> The closest I have to a formal spec are some emails going back-and-forth
> between Martin Koegler and myself over what the protocol should be.
> I've tried to collate and format these together below.  Please let me
> know if anything is not clear, or if you can spot any edge-cases that
> permit security flaws.

*snip*

> RFB Protocol Section 6.2.19.257 - TLSNone VeNCrypt sub-type
> 
> If the TLSNone, TLSVnc or TLSPlain sub-types have been chosen, Anonymous
> TLS authentication is initiated as described in the TLS protocol.
> 
> If the TLS authentication was not successful, the connection is closed.
>    Otherwise, all further communication takes place over the encrypted
> TLS channel.
> 
> If the TLSNone sub-type was chosen, authentication continues as for the
> None type described in section 6.2.1.

*snip*

I would like to point out that vencserver seems to be sending an
extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
the SSL/TLS handshake is started. The QEMU implementation does
this also, so the bug is clearly in this "spec". This also affects
sub-types 258, 259, 260, 261 and 262.


Cheers,
Peter (not subscribed)

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Stewart Becker]

On Tue, 2008-06-03 at 12:31 +0200, Peter Rosin wrote:
> Hi!
> 
> Sorry for the response to this old post, but since it seems to be the
> best reference for the VeNCrypt protocol on the web, I don't feel too
> bad. Hopefully I got the message-id correct so that this post is
> properly linked.
> 

<snip>

> I would like to point out that vencserver seems to be sending an
> extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
> the SSL/TLS handshake is started. The QEMU implementation does
> this also, so the bug is clearly in this "spec". This also affects
> sub-types 258, 259, 260, 261 and 262.
> 
> 
> Cheers,
> Peter (not subscribed)

Peter,

It's been a while since I looked at it, and don't have time immediately
to check it in detail, but I think that this is the SecurityResult
message as detailed in section 6.1.3 of the RFB specification.
Re-reading it, I could probably have been more clear in my mail to Dan
about where the VenCrypt extension rejoins the RFB protocol.  The reason
that I put this in the extension code instead of the "main" VNC code is
that only the extension knows whether the success of failure message
should be sent.

Yours,

Stewart

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Daniel P. Berrange]

On Tue, Jun 03, 2008 at 07:48:10PM +0100, Stewart Becker wrote:
> On Tue, 2008-06-03 at 12:31 +0200, Peter Rosin wrote:
> > Hi!
> > 
> > Sorry for the response to this old post, but since it seems to be the
> > best reference for the VeNCrypt protocol on the web, I don't feel too
> > bad. Hopefully I got the message-id correct so that this post is
> > properly linked.
> > 
> 
> <snip>
> 
> > I would like to point out that vencserver seems to be sending an
> > extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
> > the SSL/TLS handshake is started. The QEMU implementation does
> > this also, so the bug is clearly in this "spec". This also affects
> > sub-types 258, 259, 260, 261 and 262.
> 
> It's been a while since I looked at it, and don't have time immediately
> to check it in detail, but I think that this is the SecurityResult
> message as detailed in section 6.1.3 of the RFB specification.
> Re-reading it, I could probably have been more clear in my mail to Dan
> about where the VenCrypt extension rejoins the RFB protocol.  The reason
> that I put this in the extension code instead of the "main" VNC code is
> that only the extension knows whether the success of failure message
> should be sent.

When I wrote the code I checked the interoperability of QEMU against the 
VeNCrypt client, and the GTK-VNC  client agains the VeNCrypt server and
QEMU server, so the impl is the defacto spec :-)

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Peter Rosin]

Stewart Becker skrev:
> On Tue, 2008-06-03 at 12:31 +0200, Peter Rosin wrote:
>> Hi!
>>
>> Sorry for the response to this old post, but since it seems to be the
>> best reference for the VeNCrypt protocol on the web, I don't feel too
>> bad. Hopefully I got the message-id correct so that this post is
>> properly linked.
>>
> 
> <snip>
> 
>> I would like to point out that vencserver seems to be sending an
>> extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
>> the SSL/TLS handshake is started. The QEMU implementation does
>> this also, so the bug is clearly in this "spec". This also affects
>> sub-types 258, 259, 260, 261 and 262.
>>
>>
>> Cheers,
>> Peter (not subscribed)
> 
> Peter,
> 
> It's been a while since I looked at it, and don't have time immediately
> to check it in detail, but I think that this is the SecurityResult
> message as detailed in section 6.1.3 of the RFB specification.
> Re-reading it, I could probably have been more clear in my mail to Dan
> about where the VenCrypt extension rejoins the RFB protocol.  The reason
> that I put this in the extension code instead of the "main" VNC code is
> that only the extension knows whether the success of failure message
> should be sent.

I don't think it's the security result, because the security result
comes after the TLS handshake. This is apparent if you consider the
variants based on Vnc-Auth and Plain where the security result comes
after the authentication and the authentication is clearly inside the
encrypted tunnel. But the security result comes inside the TLS tunnel
for the variants based on None as well, that's a fact. Another piece
of evidence that it is not the security result is the fact that the
security result is U32 and this "missing element" is a U8. Pretty
strong hint in my book :-)

Cheers,
Peter

Re: [Qemu-devel] Re: PATCH: Secure TLS encrypted authentication for VNC

[Daniel P. Berrange]

On Tue, Jun 03, 2008 at 11:27:58PM +0200, Peter Rosin wrote:
> Stewart Becker skrev:
> >On Tue, 2008-06-03 at 12:31 +0200, Peter Rosin wrote:
> >>Hi!
> >>
> >>Sorry for the response to this old post, but since it seems to be the
> >>best reference for the VeNCrypt protocol on the web, I don't feel too
> >>bad. Hopefully I got the message-id correct so that this post is
> >>properly linked.
> >>
> >
> ><snip>
> >
> >>I would like to point out that vencserver seems to be sending an
> >>extra U8 (== 0x01. Is that a boolean? 0x00 means failure?) before
> >>the SSL/TLS handshake is started. The QEMU implementation does
> >>this also, so the bug is clearly in this "spec". This also affects
> >>sub-types 258, 259, 260, 261 and 262.
> >>
> >>
> >>Cheers,
> >>Peter (not subscribed)
> >
> >Peter,
> >
> >It's been a while since I looked at it, and don't have time immediately
> >to check it in detail, but I think that this is the SecurityResult
> >message as detailed in section 6.1.3 of the RFB specification.
> >Re-reading it, I could probably have been more clear in my mail to Dan
> >about where the VenCrypt extension rejoins the RFB protocol.  The reason
> >that I put this in the extension code instead of the "main" VNC code is
> >that only the extension knows whether the success of failure message
> >should be sent.
> 
> I don't think it's the security result, because the security result
> comes after the TLS handshake. This is apparent if you consider the
> variants based on Vnc-Auth and Plain where the security result comes
> after the authentication and the authentication is clearly inside the
> encrypted tunnel. But the security result comes inside the TLS tunnel
> for the variants based on None as well, that's a fact. Another piece
> of evidence that it is not the security result is the fact that the
> security result is U32 and this "missing element" is a U8. Pretty
> strong hint in my book :-)

It is not *the* security result, rather it is an intermediate result. 
Basically the client has chosen to do VeNCrypt auth and has sent its
request for the particular VeNCrypt sub-type it wants to use. This U8
is basically a  boolean indication of whether the server accepts the
clients choice of sub-type. If it accepts it, then the TLS handshake
will proceed, the sub-type specific auth process takes place and you'll
eventually get the final security result. If the server rejected the
choice of sub-type, then it will be closing the connection anyway. So
this u8 doesn't technically add any security to the protocol - it could
have been left out and things would have worked just as well.

Regards,
Daniel.
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|