TL;DR: Let's rip out the false assumption that an SSLv23 client cannot connect to an SSLv3/TLSv1 server.

I now believe this is simply an erroneous assumption on the part of the Python test suite, namely that SSLv23 method clients cannot connect to SSLv3 or TLSv1 servers.  Here is an excerpt from openssl's CHANGES file:


 Changes between 0.9.7g and 0.9.7h  [11 Oct 2005]
...

  *) Change the client implementation for SSLv23_method() and
     SSLv23_client_method() so that is uses the SSL 3.0/TLS 1.0
     Client Hello message format if the SSL_OP_NO_SSLv2 option is set.
     (Previously, the SSL 2.0 backwards compatible Client Hello
     message format would be used even with SSL_OP_NO_SSLv2.)
     [Bodo Moeller]

It looks like it's been this way for a long time too.  What may have changed recently on Debian/Ubuntu though is that, as of Ubuntu version 1.0.0d-2ubuntu1 (in Ubuntu 11.04), we now use the no-ssl configuration option to disable SSLv2.  My guess is that "the SSL_OP_NO_SSLv2 option" gets set by this configuration option, which is what switches the client hello to use SSLv3/TLSv1 format, thus enabling such connections.  I'm not entirely sure which Debian version of the package this got changed in, but it certainly works the same way on Wheezy as it does in Oneiric.

It's probably too difficult, and not really Python's responsibility, to determine whether SSL_OP_NO_SSLv2 is set.  Rather, I think the test is simply bogus and should be disabled or removed.  Antoine implies as such in 

http://bugs.python.org/issue13218#msg145912

A couple of other things: it is not true that Ubuntu (or Debian for that matter) is changing the semantics of a library here.  It's simply using a supported upstream configuration option to disable SSLv2, and the openssl library itself changes the semantics of client/server connection success based on that.

Also, I think @skip_if_broken_ubuntu_ssl is both a misnomer (since all that behavior is inherited from Debian) and besides, it's useless now since on Debian/Ubuntu, ssl.PROTOCOL_SSLv2 will never be defined, at least with modernish versions of both OS's.  But I guess ripping that out is a task for a different bug.