Ask a Question

Host property on HttpRequestCreator.Proxy throws ArgumentException when host assigned contains "https"

0 votes
by (150 points)

Hi,

When I assign "https://xxx.xx.xx.x:809" to host property on HttpRequestCreator.Proxy, it throws "System.ArgumentException: Hostname is invalid. Parameter name: value"

If I assign just plain HTTP url, it works fine. So, issue is only when I assign URL that has HTTPS.

Could you please help me on this?

Thanks,

Ajay

Applies to: Rebex HTTPS

1 Answer

0 votes
by (147k points)

Hi,

The error message is misleading - sorry for that, we will fix it. But what are you trying to achieve? HttpRequestCreator.Proxy supports HTTP CONNECT proxy protocol which initially runs over HTTP, not over HTTPS. That's why HTTPS URLs are rejected. Additionally, when using a HTTP CONNECT proxy, make sure to set creator's ProxyType to ProxyType.HttpConnect.

by (150 points)
edited by
Hi Lukas,

Thank you so much for getting back on this.  I accidentally marked answered by clicking link on email.

We have a product being used by customers, which will upload data to SOAP webservice.

So far, we are using proxy property on SoapHttpClientProtocol which allows us to set "HTTPS".  To ensure customer's equipment communicates to us over TLS1.2, we planned to use Rebex HTTPS.

Our product allows customers to set up proxy.  So if I want to allow customers setting up both HTTP and HTTPS proxies, how can I achieve that?

Appreciate any guidance on this.
by (147k points)
Actually, the primary purpose of "HTTP CONNECT" proxies is to provide proper HTTPS support. HTTP is only used to establish a tunnel. After that, TLS negotiation with the target server occurs just like when connected directly, including server certificate validation. HTTP CONNECT proxies are not content-aware, they just proxy TCP data between the client and the server. When using "HTTP CONNECT" proxies with "http://" URLs, Rebex HTTPS client would actually be communicating using TLS 1.2 with the target server. It looks like this is precisely what you are trying to achieve.

This said, are you sure that setting SoapHttpClientProtocol to a "https://" URL actually works? When I tried running a simple WebService code snippet to see what it does, I got an exception indicating lack of support for this: "System.NotSupportedException: The ServicePointManager does not support proxies with the https scheme." The code I used:
            var soap = new WsSimple();
            soap.Url = "http://win03.test.rebex.net/SampleWs/WsSimple.asmx";
            soap.Proxy = new WebProxy("https://proxy01.test.rebex.net");
            soap.Echo("Hello!");
by (150 points)
Thank you so much Lukas, I really appreciate support you are providing.  I decompiled  .Net 3.5 "System" DLL, and understand that it would throw exception.  But, "System" DLL that we are using related to "CompactFramework" which seems to be light, and does not have this restriction.  Our product has customers who configured HTTPS proxies.

While I understand HTTP CONNECT means only HTTP proxy, is there any way with Rebex HTTPS DLLs that I can make HTTPS Proxy to work?
by (147k points)
It looks like you are right - .NET CF's HttpWebRequest really seems to support HTTPS proxies (I wonder whether this is in fact an intended behavior or rather an accidental feature).

There is a way to make Rebex HTTPS work with there proxies - by implementing a custom ISocketFactory - but that would be rather complicated and require in-depth knowledge of the underlying protocols.

We plan to add support for classic HTTP proxies next year and we will make our implementation accept classic proxies that use HTTPS as well.

However, is this in fact desirable? You stated that you wanted to "ensure customer's equipment communicates to us over TLS1.2", but using a "classic HTTPS proxy" goes against this requirement. When using such a proxy, your application would be using TLS 1.2 to communicate with the proxy, and the connection would be secure using the proxy's certificate instead of the target server's certificate. The proxy would then establish connection to the target server, negotiate a TLS session of its own (according to its own settings), and finally it would operate be decrypting and reencrypting all HTTP data that travels between the client and the server through it (in both directions). The mode of operation of such proxy is essentially equivalent to a "man-in-the-middle attack" - it enables anyone in control of the proxy to intercept and/or modify the supposedly-encrypted traffic. Is this really acceptable? On the other hand, the "HTTP CONNECT" proxy type does not suffer from these shortcomings and provides a proper end-to-end encryption.
by (150 points)
Thanks Lukas, got it.  I will have it reviewed internally by our team, and get back to you if I have any questions.
by (110 points)
hi Lukas,
 We are trying to connect the server with HTTPS through TLS1.2 -from my WINCE 6.0 device.
When i send the request we getting response as

2018-01-09 18:42:01 INFO HttpRequest(8)[117244586] TLS: Connection secured using cipher: TLS 1.2, RSA, AES with 256-bit key in CBC mode, SHA1
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] TLS: Session ID:
 0000 |00-28-00-00-98-29-D8-57 F7-6B-84-AE-57-26-A1-C5| .(...).W.k..W&..
 0010 |9D-60-A9-4F-F6-BE-99-49 70-A1-B9-DF-2C-92-FE-3E| .`.O...Ip...,..>
2018-01-09 18:42:01 VERBOSE HttpRequest(8)[117244586] TLS: Received TLS packet:
 0000 |17-03-02-00-71-48-54-54 50-2F-31-2E-31-20-34-30| ....qHTTP/1.1 40
 0010 |33-20-46-6F-72-62-69-64 64-65-6E-0D-0A-43-6F-6E| 3 Forbidden..Con
 0020 |74-65-6E-74-2D-4C-65-6E 67-74-68-3A-20-30-0D-0A| tent-Length: 0..
 0030 |53-65-72-76-65-72-3A-20 4D-69-63-72-6F-73-6F-66| Server: Microsof
 0040 |74-2D-48-54-54-50-41-50 49-2F-32-2E-30-0D-0A-44| t-HTTPAPI/2.0..D
 0050 |61-74-65-3A-20-54-75-65 2C-20-30-39-20-4A-61-6E| ate: Tue, 09 Jan
 0060 |20-32-30-31-38-20-32-33 3A-34-32-3A-30-32-20-47|  2018 23:42:02 G
 0070 |4D-54-0D-0A-0D-0A                              | MT....
2018-01-09 18:42:01 VERBOSE HttpRequest(8)[117244586] HTTP: Received data:
 0000 |48-54-54-50-2F-31-2E-31 20-34-30-33-20-46-6F-72| HTTP/1.1 403 For
 0010 |62-69-64-64-65-6E-0D-0A 43-6F-6E-74-65-6E-74-2D| bidden..Content-
 0020 |4C-65-6E-67-74-68-3A-20 30-0D-0A-53-65-72-76-65| Length: 0..Serve
 0030 |72-3A-20-4D-69-63-72-6F 73-6F-66-74-2D-48-54-54| r: Microsoft-HTT
 0040 |50-41-50-49-2F-32-2E-30 0D-0A-44-61-74-65-3A-20| PAPI/2.0..Date:
 0050 |54-75-65-2C-20-30-39-20 4A-61-6E-20-32-30-31-38| Tue, 09 Jan 2018
 0060 |20-32-33-3A-34-32-3A-30 32-20-47-4D-54-0D-0A-0D|  23:42:02 GMT...
 0070 |0A                                             | .
2018-01-09 18:42:01 INFO HttpRequest(8)[117244586] HTTP: Received response: 403 Forbidden.
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] HTTP: Received 3 headers.
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] HTTP: Response Content-Length: 0 bytes.
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] HTTP: Response Transfer-Encoding not specified.
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] HTTP: Received content (0 bytes).
2018-01-09 18:42:01 DEBUG HttpRequest(8)[117244586] HTTP: Caching HTTP session (5).

 - kindly suggest on this.

i used below settinng.
 var binding = new Rebex.Samples.WcfBinding();
                binding.RequestCreator.Settings.SslAcceptAllCertificates = true;
                binding.RequestCreator.Settings.SslAllowedVersions = Rebex.Net.TlsVersion.TLS11;
              //  binding.RequestCreator.Settings.SslSessionCacheEnabled = false;
                binding.RequestCreator.Proxy.ProxyType = ProxyType.None;
                         binding.RequestCreator.Register();
                binding.RequestCreator.LogWriter = new Rebex.FileLogWriter(@"/log.txt", Rebex.LogLevel.Verbose);
by (8.6k points)
We copied your question to http://forum.rebex.net/7670/403-forbidden-error-with-rebex-https-on-wince-6-0 because it doesn't seem to be related to issues with Host property on HttpRequestCreator.Proxy (the subject of this thread). We'll reply there shortly. Sorry for inconvenience.
...