Forum OpenACS Q&A: Re: AOLserver 4 not yet ready for prime time if you need SSL

Hi Mark (and all others having experience with AOLServer4 and SSL),

we, University Heidelberg, want to upgrade to dotlrn 2.1 soon.
Right now, AOLServer (3.3ad13) and Oracle db (8.1.7) are located on same Sun Solaris engine, but we want to split front-end and db because of several severe performance problems, which seem hardly be caused by dotlrn-/acs-code.
So we installed AOLServer4 on a Linux (Suse) box and kept Sun for oracle, but before going into production, I have a question:
Is your AOLServer-instance still stable and does you/your users often make use of SSL connections?
Heidelberg is extensively using ssl, so I want to be sure, former problems with AOLServer4 are fixed...

Thanks in advance for a short answer.

Regards,
Martin

martin,

allthough i am not answering your question,
our setup might be an option for you in case there are still
problems with ns_ssl. On our setup, all user requests are
using SSL and we are using multiple aolserver 4.* in
production. However, we use the reverse proxy pound
on all incoming requests. Pound does the ssl-decoding,
and forwards the requests in plain HTTP to the backup
servers depending on the URL.

This configuration based on pound works without problems
on our server since more than 1.5 years, i have seen up to 300 concurrent pound connections.

So, the ssl issue - if it still exists - should not
be a show stopper...

greetings
-gustaf

I can second Gustav's experience with Pound and SSL. Running a similar setup I haven't seen any SSL related problems when Pound handles SSL requests.

I can contribute code to make SSL requests accepted by Pound transparent to OpenACS.

/Bart
the Code Mill

Bart, Being curious: what did you do to achieve transparency?

If i remember correctly, we just added in the
oacs code the following switch to rp_filter in the
request processor procs, such it returns the
forwarded-for address instead of the
proxy in an [ad_conn peeraddr].

We handle redirections in the proxy and use the
access logfile of pound instead of the aolserver.

-gustaf

if { [ns_config -bool ns/parameters ReverseProxyMode 0] } {
  set addr [lindex [ns_set iget [ns_conn headers] x-forwarded-for] end]
  if {[string length $addr] == 0} {
    set addr [ns_conn peeraddr]
  }
  ad_conn -set peeraddr $addr
} else {
  ad_conn -set peeraddr [ns_conn peeraddr]
}

Hi Gustaf, hi Bart,

thanks for this hint. Right now, I hope, we can just deal without a third tool in order to keep system as "simple" as possible. But it is good to know that there's another option.

Thanks!
/Martin

Gustav,

I let Pound add an extra X header when the client has a HTTPS connection to Pound. X-SSL-Request is set to true to indicate that the connection to the browser is secure.

The request processor and the security procs of OpenACS then treat the connection as if directly connection over HTTPS to AOLserver. Or in a schema:

HTTPS -> Pound -> HTTP + X-SSL-Request: true -> AOLserver

is treated the same as:

HTTPS -> AOLserver

For now the mods to OpenACS don't verify that the IP address of the request coming from Pound is indeed originating from a trusted proxy. A hacker knowing the (internal) IP address of the proxy could potentially spoof a secure connection. Cross-referencing the IP address against a (list of) trusted IP address(es), however, is trivial to add.

Did you know that AOLserver 4.x automatically records the X-Forwarded-For IP address?

Bart
the Code Mill

Hi Bart,

i was not aware that OACS treats secure connections differently. We only allow ip traffice to the backend
from trusted machines (e.g. the proxy) via firewall.
Since all oacs applications uses ad_conn peeraddr,
the mentioned fix was easy enough.

Concerning 4.x & forwarded-for: no, i was not aware
of this either. I once brought it up on the aolserver
list, but got the impression that people were mostly
objecting the idea, since it would in the general
case leave room for spoofing.

We strip from the pound configuration all incoming
X-Forwarded-For headers, together with the firewall
rules, i believe we are on the safe side.

-gustaf