•  
      request #22669 Allow to disable HTTP->HTTPS redirection
    Infos
    #22669
    Guilhem Bonnefille (CS) (gbonnefille)
    2021-11-30 11:50
    2021-08-23 17:32
    24130
    Details
    Allow to disable HTTP->HTTPS redirection

    When deploying the Docker image in an orchestrator (Kubernetes?) that manages the TLS termination, HTTP->HTTPS redirection is cumbersome.

    It should be possible to disable this feature and let the orchestrator to deal with TLS.

    PS: see previous discussion https://chat.tuleap.org/channel/general?msg=uksTipNj44GvqjwbD

    Docker images
    12.12
    CentOS 7
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    Acknowledged
    Empty
    Attachments
    Empty
    References

    Follow-ups

    User avatar

    (Disclaimer: I'm not really aware of nginx & co.)

    I have some success by changing the /etc/nginx/conf.d/tuleap.conf:

    server {
        listen       80;
        listen       [::]:80;
        server_name  %sys_default_domain%;
    
        if ($http_x_forwarded_proto != "https") {
            return 301 https://$server_name:443$request_uri;
        }
            include conf.d/tuleap.d/*.conf;
    }
    

    As you can see, I have to adapt a little bit and I'm not sure what I break. But I think such static configuration will help dealing with deployment with and without reverse proxy (like Ingress Controller in Kubernetes).

    User avatar
    Thomas Gerbet (tgerbet)2021-08-30 13:45

    How will we achieve that ?

    It's what we do now but to work correctly it is expected the X-Forwarded-Proto header is correctly set when Tuleap is executed behind a reverse proxy. Since it might be misconfigured (the sys_trusted_proxies cannot be set when the starting the container it's likely to not be set at all in a container setup today) that's why I advocate for removing it and just assume Tuleap is always running under HTTPS while giving a hint to browsers they should upgrade insecure requests if that is not the case.

    User avatar

    I generally agree on the fact that it shouldn't be Tuleap business to decide if it's used over TLS or not

    I disagree on that. It should be Tuleap business. Tuleap should always be sure it runs under HTTPS

    Agreed.

    or have the capability to determine if it is accessed with HTTPS or not.

    How will we achieve that ?

    We could also set sys_trusted_proxies to 0.0.0.0/4 and the the problem with trusted proxy would be gone ;)

    Not sure why the /4 specifically

    Typo. Plus it was mainly :troll:

    User avatar
    Thomas Gerbet (tgerbet)2021-08-30 12:07

    I generally agree on the fact that it shouldn't be Tuleap business to decide if it's used over TLS or not, esp in a container environment.

    I disagree on that. It should be Tuleap business. Tuleap should always be sure it runs under HTTPS or have the capability to determine if it is accessed with HTTPS or not. We need to know that to set appropriate flags on cookies for example and some of our features such as OIDC/OAuth2 are required by the specifications to be only accessible when HTTPS is present (the security of the whole thing rely on it).

    Since we already set the upgrade-insecure-requests CSP directive on most of our responses, the browsers already try to upgrade you to HTTPS whenever they can. My main point is that Tuleap should just stop caring about whether or not it is accessed under HTTPS and just consider it is always the case: by doing that, even if Tuleap is somehow accessed over HTTP because of a broken setup we reduce the impacts (user will not authenticated because cookies wont be sent by browsers).

    I'm a bit more concerned about classical installs where we do know that most admins don't understand what they are doing (for the record, pick-up any thread on chat for a good laugh or cry). That said they would be better served with an automatic integration with let's encrypt and no easy way to disable HTTPS with the regular setup process.

    Yes that why I want to make pretty sure Tuleap is accessed with HTTPS in a way that cannot be disabled even if it is with self signed cert. It is still a protection against passive attacks and I'm guessing that the annoyance of the self signed can nudge the admin to do a proper setup.

    On the nitpicking side, I would prefer to keep sys_default_domain only to avoid potential confusion like "but I though I setup https because it's the name of the variable".

    Fine by me, anyway if an instance uses two different values for it today it's likely to be semi-broken already.

    We could also set sys_trusted_proxies to 0.0.0.0/4 and the the problem with trusted proxy would be gone ;)

    Not sure why the /4 specifically but anyway we cannot really do that because we cannot guarantee Tuleap is accessible by only one specific network and we should not trust blindly the forwarded headers.

    User avatar

    I generally agree on the fact that it shouldn't be Tuleap business to decide if it's used over TLS or not, esp in a container environment.

    I'm a bit more concerned about classical installs where we do know that most admins don't understand what they are doing (for the record, pick-up any thread on chat for a good laugh or cry). That said they would be better served with an automatic integration with let's encrypt and no easy way to disable HTTPS with the regular setup process.

    On the nitpicking side, I would prefer to keep sys_default_domain only to avoid potential confusion like "but I though I setup https because it's the name of the variable".

    There is also another related issue with our existing setup: there is no way to easily set sys_trusted_proxies

    We could also set sys_trusted_proxies to 0.0.0.0/4 and the the problem with trusted proxy would be gone ;)

    User avatar
    Thomas Gerbet (tgerbet)2021-08-27 16:55

    Hi,

    So I started to give this issue some thoughts and I agree that the current situation is less than ideal for multiple reasons.

    • The setup can be cumbersome in a situation where you want to end the TLS connection elsewhere. I would prefer that Tuleap continue to only listen over HTTPS to at least prevent passive attacks when the traffic is not encrypted between the TLS termination proxy and the Tuleap container but with the existing ecosystem it makes things harder than they need to be.
    • The self signed cert we deploy by default is not really a great default anymore: it generates confusion and it's not really you can use in production environment.
    • The Tuleap codebase itself is unnecessary complicated when it try to deal with HTTP vs HTTPS mainly because of the accumulation of hacks we had to do over the years. The existing checks Tuleap try to do are a bit of lie anyway, e.g. your reverse proxy could accept HTTP request and then transfer the request over HTTPS and Tuleap will be happy if you do not set the X_FORWARDED_PROTO header correctly.

    Based on the fact that as of today there are no good reasons to try to use Tuleap over HTTP and that anyway any of the browsers Tuleap supports will upgrade the requests to HTTPS due the CSP (see request #17966) I propose the following:

    1. We make sure all of our Content-Security-Policy headers have the upgrade-insecure-requests directive set
    2. We clean the codebase, since we only expect HTTPS requests it means that we can keep only sys_https_host and drop sys_default_domain, remove the handling of the X_FORWARDED_PROTO header and HTTPRequest::isSecure (as well as other similar implementations we might have...)
    3. We add the possibility to also listen on HTTP and not only on HTTPS when doing the setup and of course we add the possibility to activate this option when starting the container
    4. We update the docker-compose.yml example we give in the documentation to add a TLS termination proxy. Instances deployed this way will expose a certificate signed by a recognized CA so we reduce the friction for users deploying Tuleap this way and it also serves as an example for more advanced users deploying with an orchestrator/cloud service. (Can be done now)
    5. For installations not relying on the container image we might want to think about proposing to get a cert signed by a CA automatically. This can be done at a later stage/in a separate set of contributions.

    There is also another related issue with our existing setup: there is no way to easily set sys_trusted_proxies, so even if the reverse proxy set the X_FORWARDED_FOR header the IPs we collect and display are going to be incorrect. We should also fix that but it should probably go in its dedicated request/bugfix.

    @vaceletm: WDYT?


    • Status changed from New to Acknowledged