- From: Dirk-Willem van Gulik <Dirk-willem.Van.gulik@bbc.co.uk>
- Date: Sun, 30 Jan 2011 16:16:51 +0100
- To: Peter Williams <home_pw@msn.com>
- Cc: László Török <ltorokjr@gmail.com>, Henry Story <henry.story@bblfish.net>, WebID XG <public-xg-webid@w3.org>, "foaf-protocols@lists.foaf-project.org" <foaf-protocols@lists.foaf-project.org>
On 29 jan 2011, at 04:49, Peter Williams wrote: > I want to infer - on a sni-empowered tls channel - that sni@tls => hostheader@http > Is it true, in general (because servers refuse to deliver http requests unless sni == hostheader (while also doing what sni also implies in the ssl handshake). You can check this fairly easily - take openssl and use s_client to test that things work: 1. Check that your version of openssl supports SNI openssl s_client -h should return (4 lines before the end) a line: -servername host - Set TLS extension servername in ClientHello This lets you set the SNI data in the request. 2. Now run it with the correct settings: openssl s_client -connect foo.bar.com:443 -servername foo.bar.com have it connect and then enter GET / HTTP/1.0 Host: foo.bar.com And observe that all is well. 3. Now try to 'cheat' - i.e. mismatch between TLS level FQDN and HTTP level FQDN in Host header: openssl s_client -connect foo.bar.com:443 -servername not-foo.bar.com have it connect and then enter GET / HTTP/1.0 Host: foo.bar.com And check that you do get some error - as the vhost and SNI name do not match. 4. For added bonus; doing above without "-servername ..." will mimic a non SNI supporting client. Note that above exposes a design flaw - the Host: header does not carry the port. So Bob needs to be quite aware of his upstream infrastructure - and fully understand what "his" loadbalancers and other kit may do. Thanks, Dw
Received on Monday, 31 January 2011 08:24:55 UTC