diff options
Diffstat (limited to 'posts')
| -rw-r--r-- | posts/curl-and-the-tls-sni-extension.rst | 53 |
1 files changed, 27 insertions, 26 deletions
diff --git a/posts/curl-and-the-tls-sni-extension.rst b/posts/curl-and-the-tls-sni-extension.rst index 6bea31a..39d3f35 100644 --- a/posts/curl-and-the-tls-sni-extension.rst +++ b/posts/curl-and-the-tls-sni-extension.rst @@ -86,7 +86,7 @@ Let's try that out with HTTP:: $ curl http://176.31.99.217 default -The default server is served because 172.31.99.217 does not match any +The default website is served because 172.31.99.217 does not match any virtualhost *server_name* directive:: $ curl http://vhost1.example.org @@ -112,7 +112,7 @@ We are offered (at least) two possibilities: vhost2 * specifying the **Host** header manually using the option **-H** of cURL. This - is the recommended way in most cases. + is my favorite way in most cases. Example:: $ curl http://176.31.99.217 -H 'Host: vhost1.example.org' @@ -150,8 +150,8 @@ certificate, but it is not valid for *176.31.99.217*, only *example.org*. This is a normal behaviour. We can solve this issue by creating a certificate valid for *example.org* and *176.31.99.217* for example. -But what about requesting our virtualhosts ? Well, pretty much the same as -before (unless you didn't clear your */etc/hosts* file.:: +But what about requesting our virtualhosts ? Well, pretty much the same happens +as it did before (unless you didn't clear your */etc/hosts* file).:: $ curl https://vhost1.example.org curl: (6) Could not resolve host: vhost1.example.org @@ -160,22 +160,22 @@ before (unless you didn't clear your */etc/hosts* file.:: The good news is: it will still work if you modify your */etc/hosts* file (huray):: - $ cat /etc/hosts - 127.0.0.1 localhost - 176.31.99.217 vhost1.example.org - 176.31.99.217 vhost2.example.org + $ cat /etc/hosts + 127.0.0.1 localhost + 176.31.99.217 vhost1.example.org + 176.31.99.217 vhost2.example.org - $ curl https://vhost1.example.org - vhost1 - $ curl https://vhost2.example.org - vhost2 + $ curl https://vhost1.example.org + vhost1 + $ curl https://vhost2.example.org + vhost2 And the bad news is:: - $ curl https://176.31.99.217 -H 'Host: vhost1.example.org' - curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217' - $ curl https://176.31.99.217 -H 'Host: vhost2.example.org' - curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217' + $ curl https://176.31.99.217 -H 'Host: vhost1.example.org' + curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217' + $ curl https://176.31.99.217 -H 'Host: vhost2.example.org' + curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217' So why does it fail ? @@ -184,22 +184,23 @@ website to serve. Nevertheless, when HTTPS is being used, the first thing that the user agent and the server have to do is negociate the certificate. At this point, the HTTP headers have just NOT been sent yet. -So how does the webserver decides which certificate to send ? +So how does the webserver decide which certificate to send ? -.. note:: 10 years ago, it was simply not possible. The webservers had to send the same certificate for every virtualhost behind the same address and port. +.. note:: 10 years ago, that was simply not possible. The webservers had to send the same certificate for every virtualhost behind the same address and port. -Nowadays, there is a TLS extension, SNI (which stands for Server Name -Indication) that is supported by most browsers and operating systems. The TLS -stack present in Windows XP does not support it. As a consequence, Internet -Explorer under Windows XP cannot use SNI. But most other browsers use their own +Nowadays, there is a TLS extension named **SNI**, which stands for Server +Name Indication, which has been created to address this issue. SNI is supported +by most browsers and operating systems. However, the TLS stack present in +Windows XP does not support it. As a consequence, Internet Explorer under +Windows XP cannot use SNI. But most other browsers use their own TLS stack and can thus use SNI even under XP. .. note:: See more on Wikipedia: https://en.wikipedia.org/wiki/Server_Name_Indication Briefly, the extension works by sending the server name along with the first TLS packet. This way, the remote server knows which certificate to reply with. -Only then, after the certificate has been negociated, that the server can -analyse the *Host* header. +Only then, after the certificate has been negociated, the server can receives +the HTTP headers and is able to analyse the *Host* header. .. note:: The host header does not require to match with the server name that has been sent in the TLS packet. @@ -207,8 +208,8 @@ So what can we do ? * We can still use the */etc/hosts* file as previously stated. * We can also use the **--resolve** option of cURL (which does pretty much the - same thing as modyfiying the */etc/hosts* file (the 443 is the port being - used): example:: + same thing as modyfiying the */etc/hosts* file). The 443 is the port being + used: example:: $ curl https://vhost1.example.org --resolve vhost1.example.org:443:176.31.99.217 > vhost1 |