SSL Forwarding/port translation - what's best?

[wyvern]

I have an unusual situation. I manage an IIS web server (don't scream, hear me out first, this *is* a Gentoo question) that hosts multiple sites that need to be secured with SSL. IIS requires that each virtual site using SSL have its own port for SSL (i.e. can't share the SSL port). So I've been assigning SSL ports starting at 443 and going up.

I assigned port 447 to a particular client's web site, only to have the client come back and claim they can't open port 447 on their firewall (apparently they don't have a firewall capable of outbound connection tracking) and that the only acceptable port they had open was port 80, the standard HTTP port. They won't even open the standard SSL port. (Security conscious? Incompentent? Who knows.)

I can't put SSL on port 80 on our web site, so I need something (a proxy?) to translate incoming HTTPS requests to port 80 on that domain to port 447 on our server, and translate back. I have Gentoo server available to act as the proxy, but I have no idea what software to use. Squid seems like a logical choice, but a brief scan of the documentation seemed to indicate that Squid is used for HTTP caching and logging, as well as proxying.

Is there another, more suitable option? Or should I just try and set up Squid as non-caching, non-logging proxy? Is iptables a better choice? I'm still pretty new to networking.

Any advice would be appreciated.

(BTW, the reason my company uses IIS is because its flagship application is an ASP.NET product.)
_________________
---
ex nihilo nihil fit

[Chris W]

My first reaction is that since the customer cannot access any standard SSL site they can hardly expect to access the one you have set up (regardless of your choice of port).

Typically, HTTP proxies like Squid allow connections only to certain ports (incl. 443 but not 447) to avoid wholesale abuse of the CONNECT command. Properly configured firewalls will only allow outgoing connections to specific ports, which may not include 443 or 447. If your customer is behind such a proxy or firewall, and they don't control it, then they are stuck. As an aside, this inability to use non-standard ports would not be an uncommon restriction on your customer's customers either.

There's no way I'm aware of that Netfilter rules can distinguish an inbound connection attempt to port 80 for HTTP from one for HTTPS. The machine would have to accept the connection and attempt to interpret the payload before it could make such a decision. I'm not aware of software that will do this, but I'll gladly accept education.

If that customer's connections always come from a single IP address, and it is acceptable that they always get the secure site, and the customer always uses "https://www.somesite.tld:80", then you could possibly use Netfilter to DNAT anything coming port 80 from there to port 447.
_________________
Cheers,
Chris W
"Common sense: The collection of prejudices acquired by age 18." -- Einstein

[wyvern]

[Chris W]

Glad to be at least mildly useful.
_________________
Cheers,
Chris W
"Common sense: The collection of prejudices acquired by age 18." -- Einstein