0
votes

According to RFC 2818, Section 2: http://www.ietf.org/rfc/rfc2818.txt

"Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP."

I have an application that connects to a web server on port 443 with a TLS/SSL client. After connecting, the TLS client sends an HTTP header and associated HTTP payload (all contained as application payload for the TLS/SSL client).

POST https://www.somehost.com/pubs/m_login HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Host: www.somehost.com
User-Agent: NativeHost
Content-Length: 50

username=user%40example.com&password=password

I receive a 200 response from the server, indicating it got my request. However, the HTTP response body contains the actual server application response and this indicates a failure.

HTTP/1.1 200 OK
Date: Tue, 18 Mar 2014 02:47:43 GMT
Server: Apache/2.2.24 (FreeBSD) mod_fastcgi/2.4.6 mod_ssl/2.2.24 OpenSSL/0.9.8e DAV/2 mod_perl/2.0.8 Perl/v5.12.5
Cache-Control: no-cache, max-age=0
Pragma: no-cache0
Content-Length: 118
Set-Cookie: bcdb_session=cd12abe27a5c55e3a076763329cc0cd31e246751; path=/; expires=Tue, 01-Apr-2014 02:47:43 GMT; HttpOnly
Vary: Accept-Encoding
Connection: close
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<appname>
<error>not_logged_in</error>
<status>error</status>
</appname>

When I use a client capable of HTTPS and send the send request headers and body, I get a successful response (Both a http 200 response and the response body indicates success).

HTTP/1.1 200 OK
Date: Tue, 18 Mar 2014 03:04:22 GMT
Server: Apache/2.2.24 (FreeBSD) mod_fastcgi/2.4.6 mod_ssl/2.2.24 OpenSSL/0.9.8e DAV/2 mod_perl/2.0.8 Perl/v5.12.5
Cache-Control: no-cache, max-age=0
Pragma: no-cache0
Content-Length: 84
Set-Cookie: bcdb_session=9c0e22a54d7fc28dbd19b748c287d1b25166d78c; path=/; expires=Tue, 01-Apr-2014 03:04:22 GMT; HttpOnly
Vary: Accept-Encoding
Connection: close
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<appname>
<status>ok</status>
</appname>

I have tried to capture the network data for the two scenarios and compare them. I can capture the HTTPS client as it supports an HTTP-proxy (and I use Fiddler). The SSL/TLS client cannot use an HTTP proxy solution, but it supports a SOCKS proxy.

Two questions:

1) Any idea why there may be a different result using an HTTPS client vs. a TLS/SSL client?

2) Can someone recommend a SOCKS proxy to use that will provide similar access to the request/response data as Fiddler does?

Thanks, Mike

1
Please show the actual requests and responses. What does the failure actually say? Some servers really do send error messages using success response codes like 2xx instead of a more suitable 4xx/5xx response code. The fact that you are getting a valid HTTP response at all means the TLS portion is working correctly.Remy Lebeau
There might be several HTTPS servers behind the same IP. One client might use SNI (server name indication) to indicate the required hostname and thus gets its certificate and the server data. But, if your client connects without SNI it will probably get another certificate (don't need to be) and will be connected to another virtual server.Steffen Ullrich
Thanks for looking at my problem. I've updated the original post to include the request and both the working response I get when using an HTTPS client and the error response when using a TLS client.Mike G
The solution to this problem was to leave the protocol scheme and host name from the POST command and just include the relative Url portion.Mike G

1 Answers

0
votes

Are you sure the request is the same in both cases? Eg. the first line is not correct for valid HTTP request. If you connect directly, the request line should be POST /pubs/m_login HTTP/1.0 and NOT POST https://www.somehost.com/pubs/m_login HTTP/1.0.

Unfortunately SOCKS server won't help you dump the request, because TLS connection is secured against this. SOCKS server offers an opaque tunnel.