[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: AW: proxy access problem

Another "kludge" that would work, maybe better than the host file approach would be replace http_url_post() with calls to http_persist_open(), http_persist_post() and http_persist_close(). On the call to http_persist_open() use a URL containing "app-proxy.eb.lan.at", and on the call to http_persist_post() use a URL containing "secure.armstrongconsulting.com".
The http_persist_open() routine is what makes the actual network connection, so it would contain the host/port of your internal port fowarder. the http_persist_post() routine is what creates the host: header, so should have the host/port that you want to see in the host: header.
HTTPAPI attempts to allow SSL/TLS errors, so this may actually work. Again, not the "right" way to do it, but may be better than the hosts file approach. (The right way is to install a proper proxy server.) 

-SK

On 9/8/2016 3:12 AM, Scott Klement wrote:

Alexander,
It sounds to me like you're not actually using a proxy, but instead you're simply forwarding a port to the destination system.
Technically, the HTTP protocol does not allow you to do that! What you're doing violates the rules of the HTTP protocol. (Those rules are defined in RFC 2616). If I changed HTTPAPI to put a different host: header than the one you are connecting to, then I would be publishing a product that violates RFC 2616 rules.
It's also not technically allowed by the SSL/TLS protocol. In that protocol, the common name of the SSL/TLS certificate is supposed to match the host you connected to. So you'd be violating that protocol as well! Hackers try to use this type of thing to "hijack" and take over people's internet connections, so it is definitely a security violation.
If you really want to trick the whole process into working, what you could do is add an entry in your HOSTS table that points secure.armstrongconsulting.com to the IP address of app-proxy.eb.lan.at, then whenever you connect to the former site, it'll really go to the latter site. That will work around the security restrictions by lying to the computer... but is a kludge at best.
The "right" fix is to use a proper proxy server instead of just forwarding a port. 



On 9/7/2016 2:16 PM, Alexander Grünwald wrote:

Hello Scott,
yes, that´s what I would like to have. Due to security rules, our System i may not connect directly to a server outside the whole environment. So there is a server app-proxy.eb.lan.at that offers a port. This port forwards our requests to a fixed endpoint. So the setting is: port 10071 forwards to secure.armstrongconsulting.com:443. This works great for other partners with similar settings (also https), but with this partner we have the problem, that the host header would not have the correct value, if I do not use http_setproxy(). This procedure helps me connect tot he app-proxy.eb.lan.at and keep the original host value - fine. Nevertheless I do not get a connection tot he endpoint. I am uncertain, if this "forwarding" is similar to the standard process of a proxy and if HTTPAPI is expecting a response from such a proxy.
Generally communication tot he endpoint works. Packets are transferred tot hem, but they refuse to answer due tot he RFC2616 rules.
Maybe I can manipulate the host-value oft he communication. I have seen, there is a procedure to add values tot he header, but I cannot exchange values oft he header. 

Hope I could explain things a little bit better.

Mit freundlichen Grüßen/Best regards Mag. Alexander Grünwald

-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott Klement 
Gesendet: Mittwoch, 7. September 2016 20:27
An: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Betreff: Re: AW: proxy access problem

Alexander,

I'm sorry, I don't understand what you are asking.

Are you saying that you want HTTPAPI to connect to
app-proxy.eb.lan.at:10071 and send it the request as if it were the
end-point rather than a proxy?   But, you still want the host: header to
point to secure.armstrongconsulting.com?
That doesn't seem like it would be secure. But, I'm not certain that I understand correctly, so please clarify. 

-SK


On 9/7/2016 4:52 AM, Alexander Grünwald wrote:

Hello !!
Some additional information regarding this issue. It seems that the proxy_tunnel procedure has a problem, when waiting for proxy´s response. As this "proxy" is a forwarding proxy, which knows that every tcp-packet, I send to "app-proxy.eb.lan.at:10071" has to be forwarded directly to the https-port (443) of "secure.armstrongconsulting.com", I am uncertain, if I am using the proxy approach correctly. It seems, I won´t get any response from my poxy directly which ends in -1 when receiving and parsing proxy server's response in procedure proxy_tunnel. 

Any ideas ?

Thanks a lot, Alexander







----------------------------------------------------------------------
-------------

Hi Scott,
as announced earlier, I am actually testing access to a testserver via proxy. 
The situation in our environment is as following:

-        We may not access any server outside the network directly.

-        Therefore we have a proxy server and a port number to use
- Sending web-service requests to the proxy as host-url with the portnumber (https://app-proxy.eb.lan.at:10071) forwards our request to the destination host (works fine generally and we are using this approach for several years with other partners)
- Unfortunately our new partner wants to ensure RFC2616 conformity and checks the host header: when we send out our request using the proxy setting, we use as host the final destination (https://secure.armstrongconsulting.com/) and use http_setproxy('app-proxy.eb.lan.at':10071), the communication doesn´t work. What am I missing here ? 

Enclosed is the debug log for my proxy access:

HTTPAPI Ver 1.32 released 2016-02-10
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R1M0

New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819.
ProtLoc=0
http_setauth(): entered
https_init(): entered
QSSLPCL = *OPSYS
SSL version 2 support disabled
SSL version 3 support enabled
Old interface to TLS version 1.0 support enabled TLS version 1.0
support enabled TLS version 1.1 support enabled TLS version 1.2
support enabled
----------------------------------------------------------------------
--------------- Dump of local-side certificate information:
----------------------------------------------------------------------
---------------
http_url_post(): entered
http_persist_open(): entered
http_long_ParseURL(): entered
DNS resolver retrans: 2
DNS resolver retry  : 2
DNS resolver options: x'00000136'
DNS default domain: eb.lan.at
DNS server found: 10.3.42.1
DNS server found: 10.3.42.2
Nagle's algorithm (TCP_NODELAY) disabled.
CONNECT secure.armstrongconsulting.com:443 HTTP/1.1
Host: secure.armstrongconsulting.com HTTP/1.1
User-Agent: http-api/1.32
Proxy-Connection: keep-alive


recvresp(): entered
recvresp(): end with err
http_close(): entered


Thanks for your support.

Mit freundlichen Grüßen/Best regards Mag. Alexander Grünwald


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------