This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

SSL Stream Order of Conversation

0

I'm trying to decipher why my HTTP POST connection works but HTTPS POST will not. When doing HTTPS, the SSL stream seems to indicate the server responds prior to all of the headers being provided. I'm wondering if the SSL Stream is showing me the true order in which packets are being transmitted.

Client:

POST  HTTP/1.0
Content-type: text/xml
Content-length: 1505
host: somewhere.com:443

Server:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 05 Feb 2016 19:16:31 GMT
Connection: close
Content-Length: 324

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"> < HTML>< HEAD>< TITLE>Bad Request< /TITLE> < META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii">< /HEAD> < BODY>< h2>Bad Request - Invalid URL< /h2> <hr><p>HTTP Error 400. The request URL is invalid.</p> < /BODY>< /HTML>

Client:

< ?xml version = '1.0' encoding = 'UTF-8'?>
And so on…

asked 09 Feb ‘16, 13:10

Chad%20Bozeman's gravatar image

Chad Bozeman
6113
accept rate: 0%


One Answer:

1

I can imagine that the server answers as soon as it has got enough information to decide to reject the request and that the client does not get (or process) the response early enough to stop sending the rest of the message. Can you provide the timestamp information for the individual packets, and if you send the POST from the same client to the same server as both http and https, can you compare the headers of the POST messages in both cases?

answered 09 Feb '16, 13:47

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

I was able to verify as you suggested that the server is responding as soon as it has enough information to reject.

The server is a different VM than the client. I've tried both from within my Network and coming from the internet with the same results. I'll go back and see if I can pull the headers for both test cases.

(10 Feb '16, 07:28) Chad Bozeman

The "same" was related to "same client for both http and https", not "client and server processes running at the same machine". I.e. more or less I wanted to point your attention to whether the client application and its configuration is the same for both http and https requests or whether you send http from one client application and https from another client application, with possibly different behaviour and settings, and the fact that the use of tls may not be the real reason of different reaction of the server.

(10 Feb '16, 07:39) sindy