Lighttpd

As the config can represent strings, i really think an array should be used instead of splitting (it is what a user familiar with the config style will expect).

Perhaps the "X-" prefix could be added only once (and the lookup be done with ptr+2); modifying a array from the config might be "unsafe" (+= might reuse entries).

I also needed functionality like that (forwarding authentication information from an SSL enabled lighttpd) and really would like a patch like this integrated in forthcoming releases.

But please note:
Especially when forwarding such SSL context information like the authenticated user (SSL_CLIENT_S_DN_CN), certificate fingerprints, E-Mail-Adress and so on (see initial usecase), it should be avoided that one can spoof this information by just posting the resulting
"X-%s", *forward_env_vars_ptr
header in the initial request.

By using
proxy_set_header(con, forward_env_header, key_ds->value->ptr); (see all patches below up to today)
old values from the original request are kept and the new information is appended comma-separated!

This might be
a) unexpected
b) insecure
if you rely on those information at the destination.

It would be good to implement another helper function like

static void proxy_replace_header(connection *con, const char *key, const char *value) {
     data_string *ds_dst;

if (NULL == (ds_dst = (data_string *)array_get_unused_element(con->request.headers, TYPE_STRING))) {
           ds_dst = data_string_init();
     }

buffer_copy_string(ds_dst->key, key);
     buffer_copy_string(ds_dst->value, value);
     array_replace(con->request.headers, (data_unset *)ds_dst);
 }

instead of the proxy_set_header() call at least for those headers that should not be "injectable". This function replaces any old header content when the new one is set.

For other environmental information to be forwarded one might see this "append to pre-existing X- Headers" more relaxed, maybe even wanted (?) behaviour.
For the SSL environemnt usecase it definitively isn't.

Thanks for your comments, tlange.

Indeed, our initial testing was insufficient, and we didn't catch that spoofing possibility (joys of HTTP_, X-, X_ etc. prefixes).

I have an upcoming patch to also set SSL_CLIENT_I_* based on the the certificate issuer's data (in addition to SSL_CLIENT_S_* for the subject). Given the sensitive nature of those SSL_CLIENT_* variables, I'm wondering if I shouldn't simply propose a patch which implement an “I am a reverse SSL proxy” flag, which would kill any SSL_CLIENT_* in the headers (to be implemented), set those from the certificate if there's anything to extract from there (which is already done), and forward those (which was the purpose of that patch).

Here's what we could do:
1. Implement environment variable forwarding in mod_proxy, as originally intended; but using an array instead of a string holding a comma-separated list of variables to export.
2. Implement that “I'm a reverse SSL proxy” flag, which would kill SSL_CLIENT_* in the incoming headers (but where? I didn't check where that would make sense), and automatically export SSL_CLIENT_* in mod_proxy (in addition to any configured variable, using the first mechanism).

What do you think?

Mraw,
KiBi.

If by popular web servers you mean apache, yes it supports such setups, see e.g.

%{VARNAME}e     The contents of the environment variable VARNAME.
%{VARNAME}s     The contents of the SSL environment variable VARNAME, if mod_ssl is enabled.

in https://httpd.apache.org/docs/current/en/mod/mod_headers.html

Overall, due to various limitations and lack of feedback, we did not think lighttpd was a great idea.

I'm not exactly sure how we implemented it when we switched to apache though; that was years ago. And I'm no longer working for that company.

Feel free to close this bug report if nobody is interesting in picking up this topic.

KiBi.

Thank you for your feedback.

I understand that lighttpd did not meet your needs.

I'll close this in another week or two if there is no additional interest.

Recent lighttpd versions provide various SSL variables to CGI env but not to mod_proxy. However, lighttpd 1.4.46 and later support receiving HAProxy PROXY protocol.

If a patch were written to lighttpd mod_proxy to support sending HAProxy PROXY protocol to proxy backends, the patch would be considered for inclusion in upstream lighttpd mod_proxy.