What are the security implications of enabling a SNI-hole on a web server?

Question

A web server (let's say Apache 2.4) implements SNI. It is configured with a 4096 bit SHA384-signed Wildcard Certificate (*.land.org) with a Subject Alternative Name (land.org). The Certificate Authority has a trusted path to a SHA-2 signed root certificate as well as a second trusted path to a SHA-1 signed root certificate. Let's also say that this web server implements what is currently considered to be secure renegotiation.

The web server is configured for a default Virtual Host (wonder.land.org) with only SSLv3 enabled, with an SSL certificate containing a unique DH1024 key and all of the ancient, insecure ciphers in the book (112 bit down to export ciphers, etc. - so accommodating that even Netscape Communicator would be happy). The other Virtual Host is land.org with TLSv1.2 and TLSv1.0 enabled, with 128+ bit ciphers and a unique DH2048 key. The cipher orders for both Virtual Hosts are from strongest to weakest based on known vulnerabilities and cipher strength.

Bob is a user with a modern browser supporting TLSv1.2 Elliptic Curve encryption with contemporary paranoia. He accesses https://land.org on a daily basis.

Alice is a museum curator at the Smithsonian using with an ancient web browser supporting export encryption over SSLv3. She accesses https://land.org on a daily basis to make sure the 10BASE2 connection is still working on the 486DX2. Since the web browser doesn't support SNI, Alice's request falls through a "SNI-hole", returning the default Virtual Host (wonder.land.org), which is a static HTML 2.0 page stating "Your web client does not support Server Name Indication and is vulnerable to a poodle attack. Please consider upgrading your museum exhibit. However, your internet connection does indeed work."

Question (Yes/No): Does this web server compromise Bob's security, or its own (the server's) security? Consider only currently publicly-known vulnerabilities.

Answer 1

My gut feeling was that I would rather direct the SNI-less connections to a different server (not the same one serving Bob), and via means that are external from the same server. Something like a Deep Packet Inspection firewall actually looking at the ClientHello versions and the SNI part.

I can see two reasons against SNI-hole being parsed in the same server:

1) TLS Server Name Indication and Host headers are completely different features at different protocol layers, but serve a very similar purpose. Because of this, it may not be in the interest of server software creators to interpret them differently - and it might be somewhat difficult to keep testing that the behaviour of selecting the virtual host is happening at the TLS SNI level - so at a future upgrade, Bob might end up at the unsafe server with a cookie that was not supposed to be sent via this method (or Alice might receive an error instead of a relaxing explanation about her connection.)

2) By keeping all the weak ciphers and protocol variations in the same server you keep the server software complicated, and possibly open for so far unknown attack vectors somehow able to revert/rollback to unsafe versions of the protocol.