No, in order to multi-host SSL sites the host name has to be sent first in order for the correct certificate to be presented.

https://en.wikipedia.org/wiki/Server_Name_Indication

You don't even need SNI; the initial Server Hello, which contains the server's certificate (which contains the DNS name the certificate is issued for) is sent in the clear.

No longer true in TLS 1.3 as I understand it

The ServerHello starts out by finishing key agreement and then (in the same message) it assumes its peer now knows the session key and encrypts the rest of the message, including Certificate.

Interesting; do you have a reference? In particular, how does it complete key agreement without the certificate? The first thing that comes to my mind is that in order to build the encrypted connection, you need to know who you're building it with, i.e., you need the certificate. You could build an encrypted connection with just whoever is on the other end, and then exchange the cert, but I would wonder then how you would prevent a MitM from just building two connections and forwarding the content across. (Though that would defeat a passive listener, at least.)

(Essentially, the problem is that prior to requesting the certificate for X.com, you need to know that you're talking to X.com; a sort of authentication chicken and egg.)

The TLS 1.3 drafts (and given they're in Last Call, presumably the RFC itself once published) use different types of brackets to indicate whether and how things are encrypted in the ASCII art diagrams. The curly braces {} are used for the Certificate structure, meaning it is encrypted using the session keys but it is NOT authenticated application data yet. We'll see why in a moment.

So, firstly I'm going to say, go read the drafts for yourself https://tools.ietf.org/html/draft-ietf-tls-tls13-23 because I am pretty sure that's the most snarky response and also hey, it's right there, if I'm wrong that's a great place to start in proving so.

But then I'll answer your substantive question, because the answer is pretty interesting (and quite unlike earlier versions of TLS).

So, you are correct that we can (and TLS does) do DH without knowing who we're talking to, and that our problem is that although our session is encrypted and can't be eavesdropped, this seems useless because we don't know who the heck we're talking to, surely we can be subject to a Man in the Middle attack.

However, TLS 1.3 has a trick here, after sending Certificate the server sends CertificateVerify. CertificateVerify signs the entire key agreement (which we just did) with the identity from the Certificate. So, a client receiving CertificateVerify either gets a matching signature (the party we did our DH key agreement with _was_ the owner of the Certificate - good) or they don't (we're being MitM'd the phone call is coming from inside the house - get out!)

Once the client has checked CertificateVerify (and presuming they're happy with whatever was inside Certificate) they're truly secure and Application Data can begin to be processed.

In TLS, the server will send its certificate — and thus the domain name — in the clear.