> Matus UHLAR - fantomas wrote: > >However, what I am repeating here is, that the difference between this: > > > >client ====> server > > HTTPS > > > >and this: > > > >client ====> proxy ====> server > > HTTPS HTTPS > > > >network structure is, that second one has one more weak place - the proxy. > >Although the second structure CAN work and possibly DOES work somewhere, > >it MAY be just a result of wrong decision or implementation On 12.10 14:03, Neil A. Hillard wrote: > There are a couple of reasons that I can think of that require this > configuration: > > 1) Where you don't trust the security of the connection between the > reverse proxy and backend web server and Yes, but I already told that :) > 2) Where the backend web server insists on generating URLs based on the > protocol used to communicate with it. e.g. https to the reverse proxy, > http to the web server and it generates HTML with http:// URLs. In such case it's problem of braindead dynamic pages, that use absolute URIs ;) Yes, this problem can be avoided by having ssl in outgoing requests from proxy. But that's a workaround to this problem... > We moved away from squid as a reverse proxy to Apache with mod_proxy, > mod_rewrite and mod_proxy_html (from Nick Kew). This allows us to fully > rewrite the HTML from the backend web server and change links for > external access. This way we can consolidate multiple backend servers > into a single certificate and we use strong authentication so this > ensures that the users only have to authenticate once. ... and this is another workaround :-) the fix is: change the scripts to generate only relative URIs ;) -- Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that.
