[squid-users] SSTP_DUPLEX_POST method

[Amos Jeffries]

On 17/12/2015 4:57 p.m., Wayne Gillan wrote:
> Yes SSTP is a type of SSL VPN. Why behind a reverse proxy? Well just like other SSL services I need to share port 443 with one public IP address.
> 

Port 443 is not a generic SSL port. It is the registered port for HTTPS.
Any protocol using that port MUST be able to handle HTTP transformations


> I've run packet captures on the client, vpn server and squid. The request is getting through ok and the vpn server is sending a reply. But squid is not forwarding the reply to the client I believe. Here's some snippets of the squid log:
> 
> 2015/12/17 14:26:48.550| http.cc(762) processReplyHeader: HTTP Server REPLY:
> ---------
> HTTP/1.1 200
> Content-Length: 18446744073709551615
> Server: Microsoft-HTTPAPI/2.0
> Date: Thu, 17 Dec 2015 03:26:48 GMT
> ----------
> 2015/12/17 14:26:48.556| client_side.cc(1377) sendStartOfMessage: HTTP Client local=ip.of.squid:443 remote=1.2.3.4:44582 FD 9 flags=1
> 2015/12/17 14:26:48.556| client_side.cc(1378) sendStartOfMessage: HTTP Client REPLY:
> ---------
> HTTP/1.1 200 OK
> Content-Length: 18446744073709551615
> Server: Microsoft-HTTPAPI/2.0
> Date: Thu, 17 Dec 2015 03:26:48 GMT
> X-Cache: MISS from 
> X-Cache-Lookup: MISS from :443
> Connection: keep-alive
> ----------

This is what Squid sent to the client.

> 2015/12/17 14:26:48.557| client_side_reply.cc(1114) storeNotOKTransferDone: storeNotOKTransferDone  out.size=240 expectedLength=-9223372036854775569

Note the very large negative number. That is a 64-bit wrap.

It is wrong for the application to be sending that value. It is claiming
that it has an object of size 18.4 Exabytes ready to send. What it
actually has is a non-HTTP tunnel, of *unknown* length.

Regardless, with 2^64 bytes of data object plus 240 bytes of headers
there is no way Squid can represent the message size. Let alone log it
properly if it ever completes. Squid should be detecting that and
producing a 5xx error.



> 2015/12/17 14:26:48.557| client_side.cc(1827) stopSending: sending error (local=ip.of.squid:443 remote=1.2.3.4:44582 FD 9 flags=1): STREAM_UNPLANNED_COMPLETE; old receiving error: none
> 
> 2015/12/17 14:26:48.673| Server.cc(362) sentRequestBody: sentRequestBody called
> 2015/12/17 14:26:48.673| Server.cc(423) sendMoreRequestBody: will wait for more request body bytes or eof
> 
> 
> Seems like the large value of the Content-Length header field is causing issues. Squid waits for more data but the server never sends it because it's waiting for something from the client. 
> 
> Is there any way to make squid just pass traffic exactly as it comes in?

By the application using HTTP syntax properly. *Omitting* Content-Length
header on responses where there is no in-advance known object size.

Amos