none
WinINet, Proxy, either add extra headers or hide proxy URL

    Pergunta

  • Hello all,

    Another conundrum for you guys to ponder on.


    Background: I am trying to transparently proxy http/https requests. There are several available options:


    (1) InternetSetOption INTERNET_OPTION_PROXY_SERVER

    Does work for this process, but only for non-SSL connections, because my proxy requires extra non-standard headers to authenticate connecting user.


    Question 1: How do I add extra custom headers to HTTPS/SSL stream when CONNECT verb is sent?


    (2) Pluggable protocol or hook WinINet (InternetConnect lpszServerName replaced with my proxy and then original server + object is passed to InternetOpenRequest)

    Does work for both SSL and non-SSL connections, however since UrlMon sees the proxy URL in in InternetConnect, cookies are jacked up.

    I tested that if I open an SSL connection to my proxy and send GET <FQDN>/object HTTP/1.1 with proper custom headers, it does work.


    Question 2: How do I make a proxy connection and then trick WinINet to use an already open socket that my proxy already athenticated?

    Thank you,

    Yuriy

    • Editado Yuriy Gettya segunda-feira, 2 de abril de 2012 16:49
    segunda-feira, 2 de abril de 2012 16:44

Todas as Respostas

  • On 4/2/2012 12:44 PM, Yuriy Gettya wrote:

    Background: I am trying to transparently proxy http/https requests. There are several available options:

    (1) InternetSetOption INTERNET_OPTION_PROXY_SERVER

    Does work for this process, but only for non-SSL connections, because my proxy requires extra non-standard headers to authenticate connecting user.

    *Question 1*: How do I add extra custom headers to HTTPS/SSL when CONNECT verb is sent?

    Basically, you don't. You are, in effect, attempting a man-in-the-middle attack - precisely what SSL was designed to prevent.

    However, see

    http://wiki.squid-cache.org/Features/SslBump

    If you own the system where the browser runs, and you can get it to accept your certificate, you can pull off a man-in-the-middle attack successfully.

    (2) Pluggable protocol or hook WinINet (InternetConnect
    lpszServerName replaced with my proxy and then original server +
    object is passed to InternetOpenRequest)

    Do work for both SSL and non-SSL connections, however since UrlMon sees the proxy URL in in InternetConnect, cookies are jacked up.

    Can't you have this pluggable protocol or WinInet interceptor add your custom headers directly? Why do you need a proxy?


    Igor Tandetnik

    segunda-feira, 2 de abril de 2012 21:06

  • Hello Igor,

    If you own the system where the browser runs, and you can get it to accept your certificate, you can pull off a man-in-the-middle attack successfully.

    This is too invasive, can't do.

    Can't you have this pluggable protocol or WinInet interceptor add your custom headers directly? Why do you need a proxy?

    I am doing it now, the problem is in the cookies. Here's how an in-line proxy request looks like:

    GET https://<proxy>/http[s]://<original-request> HTTP/1.1

    UrlMon, deep in its bowels somewhere apparently has some code (probably written by either Richard L Firth or Johann Posch) that remembers how the original request url looked like and uses that as reference for its cookie jar. That effectively kills cookie-crazy sites like gmail, facebook, etc. I managed to work around most of the stuff with INTERNET_FLAG_NO_COOKIES, parsing request/response headers, etc, however there's something somewhere that just doesn't work.


    I think that I can get around this by creating a connection to the proxy, before WinINet and somewehow forcing WinINet to use an already open socket. This approach works in a test app, where I open SSL connection to proxy and just send the request with all proper auth headers appended

    Yuriy


    Microsoft: please replace this POS comment editor with something decent! The only usable mode is HTML.
    • Editado Yuriy Gettya segunda-feira, 2 de abril de 2012 21:29
    segunda-feira, 2 de abril de 2012 21:26
  • On 4/2/2012 5:26 PM, Yuriy Gettya wrote:

    If you own the system where the browser runs, and you can get it to accept your certificate, you can pull off a man-in-the-middle attack successfully.

    This is too invasive, can't do.

    Can't you have this pluggable protocol or WinInet interceptor add your custom headers directly? Why do you need a proxy?

    I am doing it now, the problem is in the cookies. Here's how an in-line proxy request looks like:

    GET https://<proxy>/http[s]://<original-request>  HTTP/1.1

    Lose the proxy. You have your code running inside the browser already - just have it add your custom headers directly to the request. The request would go straight to the destination server, as it normally would.


    Igor Tandetnik

    segunda-feira, 2 de abril de 2012 21:47
  • Proxy is me exploring other options. I can't get it to work via APP alone. For example I don't even see 204's, coming from server in my OnResponse, and GMail sets cookies with 204 ...

    Can you think of a way two make WinINet use an established connection?

    segunda-feira, 2 de abril de 2012 22:06
  • On 4/2/2012 6:06 PM, Yuriy Gettya wrote:

    Proxy is me exploring other options. I can't get it to work via APP
    alone. For example I don't even see 204's, coming from server in my
    OnResponse, and GMail sets cookies with 204 ...

    Well, you don't need to see a response in order to add headers to a request.

    Can you think of a way two make WinINet use an established connection?

    You mean, you are going to connect a WinSocket, and then somehow get WinInet to send/receive on it? No, no way I could think of.


    Igor Tandetnik

    segunda-feira, 2 de abril de 2012 22:21
  • Lose the proxy. You have your code running inside the browser already - just have it add your custom headers directly to the request. The request would go straight to the destination server, as it normally would.

    I just realized that I should've been more clear : proxy is the heart of all of this. It is not local, but running in a "cloud". It's ssl-only, obviously. I got my interception to work for like 75-80% of sites, but GMail, FB + some others are being difficult.

    Well, you don't need to see a response in order to add headers to a request.

    You're correct, however I do need cookies from the headers, since InternetGetCookie[Ex] doesn't want to give them up because host doesn't match ...

    segunda-feira, 2 de abril de 2012 23:39