> Hi,[...]

IIRC Pound never speaks anything else than plain HTTP. It also doesn't
speak POP3 to the backend just because you specify port 110 :)
[...]

I guess you want to hide several websites behind one public virtual SSL
host. I played with something like this some time ago. Looks like a job
for Apache mod_rewrite/proxy. I think Pound is not made to do this.
[...]

I think stunnel could do the trick here.

HTH
Simon
[...]

[OT]
your mailinglist-software should add a header like
X-BeenThere: pound(at)apsis.ch (and/or the list-* headers)
that would make filtering and replying to mailinglist mails much easierr.
[/OT]

On Saturday 01 November 2003 00:30, Simon Matter wrote:[...]
yea, but it could autoenable HTTPS, if it sees port is 443... pop3 would 
probably be a bit problematic for serving web content.
[...]
yes, I could do so, just that apache is a pretty bloated solution for doing 
this.
[...]
yes, good idea. But, wouldn't it be trivial to advance Pound to connect to 
BackEnds via SSL, as it already depends on libssl anyways?
[...]
[...]

On Saturday 01 November 2003 02:51, Felix Buenemann wrote:[...]

Thank you for your suggestion - I'm sure we'll look into it. However, 
considering that it comes from "atmosFear" and was delivered from 
"evil.astral.lan" you'll allow us to take it with a grain of salt.
[...]

Glad you agree with that.
[...]

Correct.
[...]

I wonder if you thought this idea all the way through: the basic question is 
"should Pound decrypt the stream or not"?

If it does not - you loose all the nice Pound features, such as session 
tracking, URL validation, header matching, etc.

If it does - you loose SSL authentication: the client would be talking to 
Pound (with its certificate), which in turn would be talking to the back-end 
server(s). The back-end sees only the Pound certificate - there is no secure 
way to authenticate a client.

Bottom line: Pound does NOT talk HTTPS to the back-ends, nor will it in the 
forseeable future.

For bonus points: why on earth do you need to talk HTTPS on your internal LAN? 
Why can't you have Pound talk plain HTTP to the back-ends? At worst, why 
don't you set-up a VPN between the Pound server and the back-ends?
[...]

Not currently.[...]

On Saturday 01 November 2003 13:06, Robert Segall wrote:[...]
I dunno what the above has to do with flaming about my private eMail-Account. 
If you prefer I can continued mailing from my company-eMail 
Felix.Buenemann(at)netconsult-TechNet.de, but I don't at all prefer Outlook or 
Outlook Web Access as a Mailer =) Besides even then intenal hostname of the 
sender would not use internet registered domain, why? Anyways the flaming is 
pointless here.
[...]
[snip][...]
And it doesn't work, it also only supports http, otherwise you'll get 
unhandled protocol handler error (tested mod_proxy).
[...]

I'd be fine with pound uncrypting and reencrypting the data, my main goal is 
enrypted connection, I'm not using client certificates. For now I've set up a 
solution using stunnel4 and it works nicely.

I don't use plain html, because I don't at all like sending authentication 
user/password in cleartext over the corporate lan, I guess you would agree 
with that. VPN could be a solution but is pretty bloated/slow for this aswell 
(slow would probably be neglible here). Anyways IPsec is a big misconception 
form the whole protocol if you ask me, and other VPN solutions are either 
badly/not implemented on either windows or linux and I have to deal with both 
types of servers.
[...]

Felix,

I'm using delegated to proxy my https WebServers as http. Under 
daemontools (run file):

#!/bin/sh
exec 2>&1
exec envuidgid nobody /usr/local/sbin/delegated -f -P9443 \
          SERVER=http FSV=sslway \
          MOUNT="/* https://your.server.name:443/*" \
          ADMIN="you(at)your.domain"

So, Pound is configured to talk to the server at http port and a 
firewall rule is used to redirect it to localhost on port 9443...
I think I did it also with stunnel, but on this machine it didn't work 
very well...

I'm doing this because some servers use an IBM software that use 
hard-coded-absolute-uggly-pain-in-the-ass URL's and also only speaks 
https.

Maybe it's a good idea to insert https client support in Pound. Maybe 
it's hard work and perhaps it's a better idea to use some lib 
(libcurl???) to implement this feature...

Well, anyway, you can do as I did and it work's very well.

Best Regards,
Guilherme[...]

On Saturday 01 November 2003 20:39, Guilherme Monteiro wrote:[...]

Thx for the tip, I tested my setup today on win and neither Internet Explorer 
nor MozillaFirebird work ok. On Linux I used Konqueror which works just fine.

Btw. I found another program that could be the solution called zorp, it's an 
multipurpose apllication-level gateway coded in python. I didn't yet set it 
up as it has quite complex configuration syntax, that you need some time to 
learn/get used to. It support a stacking scheme so you can put a http 
translation scheme on top of a ssl scheme. Or something like that X-)

I hope I'm not getting too offtopic here...
[...]
[...]

On Saturday 01 November 2003 19:11, Felix Buenemann wrote:[...]

Hardly flaming - gentle fun is more like it. Don't take it too seriously, and 
next time I'll put some smileys in to make sure..
[...]

Glad to hear you have a solution.
[...]

I can't really agree with your opinion of IPSec, but that's a matter of taste. 
Starting with Win2k and on (there even was an experimental version for 98SE) 
MS offers a standard IPSec add-on at no extra cost - just download it. It 
operates cleanly with isakmpd (OpenBSD) and FreeSWan (Linux). In my 
experience IPSec works rather well and the overhead is not bad (encryption is 
compensated by compression, so on a slow link you come out ahead).[...]

On Tuesday 04 November 2003 13:00, Robert Segall wrote:[...]
Or it seemed so, unfortunately only Konqueror like it, while MozillaFirebird 
and InternetExplorer give error ("Document contains no data" and alike).

As I didn't find a well working solution for my specific problem, I wrappeb 
out vim and wrote a transparent reverse proxy for (http/https) <->
frontend 
<-> { backend1, backend2, ...} in perl. It's still under development, but

it's already working fine with all browsers tested.
I'm using preforked processes to handle the requests, so performance is ok, 
just non html (so non mangled) files need to be fetched/pushed chunkwise to 
make memory usage much smaller for big files and keep the client from 
timeouts while the frontend is fetching the data.
Another nice effect is, that html/plaintext data is compressed, if the client 
announced support for gzip.
I do mangle header fields like host or location, etc.
If content-type is text/html (probably advance this list later) I do mangling 
of full and relative urls (eg. https://backend/blah and /blub) to relative 
urls matching the frontends baseurl for that backend. It will latter support 
mapping a backend server into a different namespace (so https://frontend/
server1base/some/url/ <=> https://backend/some/url/, currently, it
only works 
with same baseurl on the backend (as I had some problem with my complex 
multiline regex for doing this X-).
The backend-mapping urls use reqex on request
Some other features I will add:
 - support for http backends :-)
 - support for vhosts (analyze Host: on frontend, trivial)
 - dunno, at least optimize the code, it's far from clean now

I probably could have added this to/fixed this in Pound aswell, but I found 
the learning curve of Pounds code base vs. an interesting perl project too 
big.
If others are interested in my stuff, I'll probably add project/cvs on SF or 
mplayerhq.hu.

[...]
In my experience IPsec has big disadvantages especially when dealing with 
dynamic IP adresses on one ore more sides. The implementation in Win2k/later 
is quite flaky, when you try to debug/control anything. There are tools that 
help a bit here, eg. ipsec.exe which eases configuration (from 
vpn.ebootis.de), even on the linux FreeS/WAN side debugging the handshaking 
is hell. Besides I still found ipsec vpn to behave badly eg. on regular 
ras-disconnects, it cannot traverse nat without special configuration on the 
routers, etc. I admit I'm not a vpn specialist, but I found solutions, that 
were much easier to use and implement, cipe eg. would be nice, if only the 
win32 client would be more stable (eg. not causing bluescreens...).
You might be right, that ipsec would work well in static ip lan enviroment, 
but for dynamic ip wan, it certainly does not.
[...]
[...]

> On Tuesday 04 November 2003 13:00, Robert Segall wrote:[...][...]

I'm interested :)
[...][...][...]

I strongly recommend you to try OpenVPN. I'm using it on Linux with great
success and I know from the shorewall list that others made the same
experience. There is also a Windows client which I've been told works
surprisingly well.

Simon