1

I'm accessing a SSL-protected web-service.

On the one hand, if I access this web-service with openssl s_client, copying the relevant http POST request from a file html-request, I get a HTTP/1.1 200 OK response.

On the other hand, if I set up the SSL-Layer with stunnel (listening on local port 1443 and forwarding the encrypted traffic to the server) and then use

cat html-request | nc localhost 1443

the server responds with HTTP/1.1 400 Bad Request.

I assumed that both tools to not pre-process the content from the html-request-file. But this assumption seems to be wrong - otherwise I would get the same response in both cases.

Two questions:

1) how do openssl s_tunnel and nc differ in processing the input data from html-request?

2) is there a way to get a hexdump of the unencrypted traffic from openssl s_client, considering that I use Elliptic Curve private keys (so wireshark is unable to decrypt the traffic)? The -debug option seems to dump the encrypted traffic.

DoRe
  • 13
  • 1
  • 3
  • Neither stunnel nor s_client do any pre-processing (unless you use s_client with `-crlf`) and they have no idea what HTTP looks like anyway. Unfortunately with the current information it is impossible to reproduce the issue. And, I cannot see any relation to information security (just because it uses s_client or stunnel does not make it relevant here, and if you don't find a command line option to get what you want there probably is none) so I propose to close it. – Steffen Ullrich Dec 07 '16 at 16:48
  • @DoRe my guess it's not a security issue but an issue with the payload, like whitespace. – Z.T. Dec 07 '16 at 17:19
  • Wireshark CAN decrypt a particular EC/DHE (PFS) session if you get the premaster or master secret from either endpoint, and `s_client` conveniently displays 'master-key' and 'session-id' in its handshake summary. See https://wiki.wireshark.org/SSL#Using_the_.28Pre.29-Master-Secret which actually links back here to http://security.stackexchange.com/a/42350/39571 . But I concur it will be exactly what was in the input file, at least on Unix; on Windows there _might_ be a CRLF-vs-LF issue. – dave_thompson_085 Dec 08 '16 at 06:46

1 Answers1

1

Neither tool modifies the traffic inside the encrypted connection. So the problem isn't related to what is happening at the HTTP layer. And thus even if there is a way to get the unencrypted data you are asking for, chances are it isn't going to help you.

There is however another possible explanation, which relates to what happens at the TLS layer. The SNI extension for TLS will allow the client to communicate the hostname unencrypted to the server before the server sends any data back to the client. This extension is needed for name based reverse proxies and for servers hosting multiple domains with different certificates from a single IP address.

For security reasons Apache (and possibly other HTTP servers as well) will verify that any client sending a hostname using SNI repeats the same hostname in the HTTP Host header. If the client does not repeat the same hostname, Apache will respond with an error code 400.

s_client does not use SNI by default, but it has an option to turn it on. And you can instruct s_client to send anything you want in the SNI field. That way you could reproduce the 400 error with s_client.

I found one report about stunnel sending an incorrect SNI header causing the same problem that you are seeing.

By inspecting the encrypted traffic using Wireshark or any other network capture utility, you can see which host name is being sent using SNI (if any) and that way verify if the problem you are seeing is due to incorrect usage of SNI as in the linked question.

Community
  • 1
kasperd
  • 5,442
  • 1
  • 19
  • 38
  • in wireshark, using the filter `ssl.handshake.extension.type == "server_name"` I see that `stunnel` sends an SNI with the correct server name in the `Client Hello`. `s_client` does not send the SNI by default. And indeed, if I use the `-servername` option in `s_client` I can reproduce the 400 error. – DoRe Dec 08 '16 at 13:26
  • I further tested the issue by commenting out the part in `stunnel client` that sets the sni server name (just search for sni in client.c of stunnel) and recompiling. And indeed I get a HTTP 200 OK response. Thanks to kasperd – DoRe Dec 08 '16 at 15:19