Simon Josefsson wrote: > > One attack could works like this: > > 1) Client establish an client-authenticated HTTPS session with a TLS SNI > for blog.example.org and sends a HTTP GET with a Host: header for > internal-website.example.org. > > 2) The server TLS code authenticate and authorize the client (using the > certificate) for use with the blog.example.org domain. The server HTTP > code serves the internal-website.example.org web page to the client. > > This system would be insecure but still compliant with RFC 4366bis as > far as I can tell, which seems suboptimal. Adding a requirement for > servers to check for this attack would solve the problem. I do not see why you consider this a vulnerability in the _server_! This is exactly how virtual hosting works. Virtual hosting does NOT seperate content. And neither will the use of TLS provide any such content seperation. The use or non-use of server name indication does not make a difference. Server Name Indication is a feature for the _client_ side, and was invented to accomodate virtual hosting when HTTP over TLS is used and the client performs weak server endpoint identification that is suggested by rfc-2818, section 3.1. If you can coerce a Browser into sending a Host: header field different to the host that is used for server endpoint identification, then this might possibly be considered a problem in the *client*. When using Reverse Proxies with re-encryption, there may be a by-design difference in the SNI as supplied by the client (matching the hostname of the reverse proxy) and the host header field that the backend server is going to see/use. -Martin _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf