When I saw the title of the paper I expected it would be about what the parent comment describes. Instead, they deliberately omit the case of SNI and state tha

When I saw the title of the paper I expected it would be about what the parent comment describes. Instead, they deliberately omit the case of SNI and state that this issue "deserves its own paper". I think any serious consideration of the issue cannot proceed on the assumption that the SNI extension is a "must-have". It is optional. Users can prefer websites that do not use SNI. There are still plenty of TLS-protected websites not using CDNs and SNI. CDNs often do not check the Host header against the SNI name. For example, request a page from www.globalsign.com from host marketcircle.com. echo -e "GET /en/ HTTP/1.1\r\nHost: www.globalsign.com\r\nConnection: close\r\n\r\n"|openssl s_client -no_tls1 -no_tls1_1 -no_ssl2 -no_ssl3 -ign_eof -no_ticket -host marketcircle.com -port 443 -tlsextdebug -servername marketcircle.com -verify 9