https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 is the current state of the effort to encrypt SNI. It's a good overview of which obvious ideas can't work and why, plus some complicated ideas that might work, with two of them expanded to a state where it's reasonable to start developing opinions about them as engineers or cryptographers.

Ultimately the destination is that one of these two (or potentially some upset newcomer if it's written up and presented soon) becomes the agreed way to do SNI encryption, and perhaps in 2019-2020 we start seeing clients & servers that can really do it.

For the short term it remains unclear which of the following three things will happen, both generally and in particular environments:

1. (Bad) Organisations bite the bullet and MitM Proxy everything, expenditure on MitM proxies sky-rockets, lawyers spend lots of time & money in court arguing that they _had_ to MitM proxy everything even though it violated employees legal rights.

2. (Good) Organisations suck it up and get rid of MitM proxies almost everywhere, preferring edge solutions that actually still work with TLS 1.3 without needing to spend loads of cash on MitM proxies for everything.

3. (Meh) Organisations refuse to use TLS 1.3, insisting on downgrading everything to TLS 1.2 and crossing their fingers that never becomes obsolete or insecure (see also Windows XP)

With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat or at https://en.wikipedia.org/wiki/Pornography (just looking at the size is not enough; Wikipedia has millions of pages, thousands of then are changed every day, it has a variable-sized HTML comment, and the HTML size also changes when you're logged in), while with the triple handshake attack, they can see the full HTTP request and response headers, while avoiding most of the cost of being "in the middle" during the actual content transfer.