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

AW: AW: AW: proxy access problem



Hello Scott,

I implemented your recommendation and it worked well !!! Thanks a lot.

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: Donnerstag, 08. September 2016 10:22
An: HTTPAPI and FTPAPI Projects
Betreff: 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
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------