Forum OpenACS Development: ssl(https) bug-Enhancement

Collapse
1: ssl(https) bug-Enhancement
Posted by Byron Linares on 07/25/09 03:04 AM
Hi all, as result of our upgrade processes in Galileo, I have posted 2 bug-Enhancement for acs-tcl, related with ssl(https) procs
Bug
http://www.openacs.org/bugtracker/openacs/bug?bug_number=3183

Enhancement
http://www.openacs.org/bugtracker/openacs/bug?bug_number=3184
If someone have any comments or suggestions for this matters I’ll be grateful

best,
Byron Linares

Collapse
2: Re: ssl(https) bug-Enhancement (response to 1)
Posted by Torben Brosten on 07/25/09 10:22 PM
Byron Linares, see comments in bug tracker. Although now that there's a bug tracker issue, perhaps we should use this thread to continue with the issue.
Collapse
3: Re: ssl(https) bug-Enhancement (response to 2)
Posted by Torben Brosten on 07/25/09 10:51 PM
By the way, it's imperative that you are using the latest code here. There are at least 4 different ways that SSL can be setup. The latest code has been tested on at least 3 different versions, including a couple of variants via reverseproxy (using apache).

Can you tell us a little more about this configuration?

Collapse
4: Re: ssl(https) bug-Enhancement (response to 3)
Posted by Byron Linares on 07/28/09 05:47 PM
Hi Torben,
Ok I will give you more details about my configuration.
I’m using a fresh checkout of openacs “HEAD”
Postgres 8.2.4
AOLserver 4.0.10
And pound as a reverse Proxy
In my config.tcl file have none of the ssl modules configured (pound is doing the
job)
So for the firs bug, when I call security::get_https_port it return null because
nsssl, nsopenssl, nsssle are not set in modules section in my config file and
security::get_secure_location doesn’t validate a null return From
security::get_https_port
I don’t know if there is something wrong with not setting nsssl, nsopenssl.nsssle
in my config file. ?
Collapse
5: Re: ssl(https) bug-Enhancement (response to 1)
Posted by Dave Bauer on 07/28/09 05:50 PM
Ok, so somehow we need to nofity the security system that pound is doing the HTTPS and allow the redirect to the same URL with a different authorized port.

This looks like an actual bug.

Collapse
6: Re: ssl(https) bug-Enhancement (response to 1)
Posted by Dave Bauer on 07/28/09 05:53 PM
Wait, how could this ever possibly work?

OpenACS can't even know anything about your SSL configuration. It should not be genearting secure URLs since you don't have SSL enabled at all in AOLserver.

So I am not seeing how you get his behavior.

Collapse
7: Re: ssl(https) bug-Enhancement (response to 6)
Posted by Byron Linares on 07/28/09 06:04 PM
Ok, for this to work I change some security procs, that check is pound in being used and examining the connection headers looking for especial header seted in pound ListenHTTPS redirection.

That is the work I submitted in the second bug

Collapse
8: Re: ssl(https) bug-Enhancement (response to 1)
Posted by Torben Brosten on 07/28/09 06:23 PM
Byron Linares,

This page shows how to change some OpenACS internals to have pound handle SSL:
http://jamesthornton.com/writing/openacs-pound.html

The page is linked from here:
https://openacs.org/xowiki/pound

Collapse
9: Re: ssl(https) bug-Enhancement (response to 8)
Posted by Byron Linares on 07/28/09 07:48 PM
Ok, that works great that’s exactly how I have my configuration,
My contribution is with the purpose, that this filters and automatic redirection to ssl works with pound whitout the need of changing manualy security::secure_conn_p, util_current_location, util_current_location but rather that oacs-core provides it
Collapse
10: Re: ssl(https) bug-Enhancement (response to 1)
Posted by Byron Linares on 07/30/09 11:06 PM
I’m wondering if i Could proceed to commit this to HEAD ??

best,

Collapse
11: Re: ssl(https) bug-Enhancement (response to 10)
Posted by Torben Brosten on 07/30/09 11:58 PM
Byron Linares,

Are the changes optional, ie do they *not* affect existing code behavior?

How are these options switch on, by parameter?

Can you publish the code to be reviewed? or direct to: tor ben at de kka. Net without spaces.

Thank you,

Torben

Collapse
12: Re: ssl(https) bug-Enhancement (response to 11)
Posted by Byron Linares on 07/31/09 12:57 AM
That’s right they are optional, I added a parameter in acs-tcl for this.
The patch is in the bug-tracker
http://www.openacs.org/bugtracker/openacs/bug?bug_number=3184

you can find it here:

http://home.galileo.edu/~bhlr/security-procs.tcl

modified procs

security::https_available_p
security::secure_conn_p
security::locations
security::get_secure_location

Collapse
13: Re: ssl(https) bug-Enhancement (response to 12)
Posted by Torben Brosten on 07/31/09 03:08 AM

Byron Linares,

It seems it doesn't affect other cases. I'd recommend this change to your file to simplify the logic: 

1672c1672
<     if { $sdriver ne "" || [parameter::get -parameter ReverseProxyForSsl -package_id [apm_package_id_from_key acs-tcl] -default 0] } {
---
>     if { $sdriver ne "" } {
1678c1678,1681
<     } 
---
>     } elseif {[parameter::get -parameter ReverseProxyForSsl -package_id [apm_package_id_from_key acs-tcl] -default 0] } {
>       # cosider if we are behind a reverse proxy and don't uses the aolserver ssl modules
>         lappend locations "https://${host_name}"
>     }

Assuming that revision works, I would say go ahead with the change on head since it doesn't (or isn't supposed to) affect existing systems... be sure to also add the new parameter and increase the version number in acs-tcl/acs-tcl.info.

cheers,
Torben