full-disclosure - FW: looking for a HTTPS redirect server

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri May 20 16:00:19 2005
From: var at deny-all.com (Vincent Archer)
Subject: FW: looking for a HTTPS redirect server

On Fri, May 20, 2005 at 08:08:46PM +0530, Gaurav Kumar wrote:
> wait.. fedric solution is not gonna work...beacuse the client is a
> thick application and only allows ip address of the web server to be
> entered, there is no option i can change ssl port 443 also.
> 
> in short,
> 
> the client send HTTPS request directly to the webserver, and the
> client doesnt allow to change anything other than server address.
> 
> how do i edit these https requests?

You don't need to. A simple TCP redirector should do the job, listening
on port 443 on whatever IP you can use, which forwards everything to
the real server.

You have about 90% chances of it working. What fails is if there are
replies from the web server that include URL to connect to, and those
specify the web server. If so, the odds are that your client application
will try to connect to the server directly, bypassing the connection.

Our product at DenyAll does what you want out of the box (full MITM, with
rewriting of URI), but it might be a bit overboard for what you want.

You can probably tinker an basic apache server with proxy mode enabled,
and use it as a reverse proxy (the apache server acts as a normal server,
but forwards some or all requests to one or more different servers instead
of serving them on its own).

Then, your application can be a bit "more than HTML", and merely use the
HTTP protocol as a conduit for its own protocol. That category of
applications often fails because it assumes that the client always speaks
directly to the server, without any alteration to content, connection and
timing, and sometimes this assumption fails. If that's the case, you're
out of luck.

-- 
Vincent ARCHER
varcher@...yall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 23, rue Notre Dame des Victoires - 75002 Paris - France