Stash Apache Reverse Proxy - force https

Hi,

I followed this tutorials for setting up Stash behind an Apache reverse proxy (SSL variant). My Problem is that I'd like to redirect all http requests to https. I recon this is more of a Apache question than Stash, but while fiddeling with various options I have seen some weird url rewriting cases and I guess Stash isn't completely innocent regarding this matter :)

I have the following connector config in my server.xml:

<Connector port="7990"
                   protocol="HTTP/1.1"
                   connectionTimeout="20000"
                   useBodyEncodingForURI="true"
                   redirectPort="443"
                   compression="on"
                   scheme="https"
                   secure="true"
                   proxyName="source.spielhaus-ftw.com"
                   proxyPort="443"
                   compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript"
                        />

The VirtualHost looks like this:

<VirtualHost *:80>
   ServerName source.spielhaus-ftw.com
   ServerAdmin xxx
   ErrorLog xxx
   CustomLog xxx

   RewriteEngine on
   RewriteCond %{HTTPS} !=on
   RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
   ServerName source.spielhaus-ftw.com
   ServerAdmin xxx
   ErrorLog xxx
   CustomLog xxx

   # SSL Config
   SSLEngine on
   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile xxx
   SSLCertificateKeyFile xxx

   ProxyRequests Off
   <Proxy *>
       Order deny,allow
       Allow from all
   </Proxy>
   ProxyPass / http://localhost:7990/ connectiontimeout=5 timeout=300
   ProxyPassReverse / http://localhost:7990/
</VirtualHost>

The interesting bit is the RewriteRule in the :80 VirtualHost. If I leave this in, everything works but I am still able to git clone stuff via http - and that's not what I want. My actual solution is to completely ditch the :80 VirtualHost and only listen on :443. This works, but has the downside that my users will need to remember to add https to the URL or else it won't work.

So to sum up. I'd like to force redirect the entire traffic to Stash via https - even when users try to access it via http.

Thanks,

Stefan

5 answers

1 accepted

This widget could not be displayed.

Hi Stefan,

I've tried to reproduce the configuration you have and I think what really happens is that git is being not very imformative about the fact that it actually follows the redirect to http :) So it is actually going to https (port 443) to perform the HTTP requests required for clone, but the git clone output says it's cloning from http.

One proof of this is access logs from your Apache. For me it looked liked this for a clone from http://

127.0.0.1 - - [26/Apr/2013:11:40:58 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 302 592 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:21 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 302 592 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:21 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 401 1909 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:24 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 302 592 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:25 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 401 1022 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:25 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 200 1338 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:25 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 302 561 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:43:25 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 200 30265161 "-" "git/1.8.2.1"

You can see a lot of 302s followed by 401s in there, which indicates that the requests are being redirected and followed correctly. A direct clone from https (port 443), in turn, only leaves:

127.0.0.1 - - [26/Apr/2013:11:47:01 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 401 1909 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:47:01 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 401 948 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:47:03 +1000] "GET /scm/soke/stash-4273807918728176903.git/info/refs?service=git-upload-pack HTTP/1.1" 200 1476 "-" "git/1.8.2.1"
127.0.0.1 - - [26/Apr/2013:11:47:03 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 200 30293850 "-" "git/1.8.2.1"

in the access Apache logs. No 30x responses in this case.

You can also double-check it by running:

GIT_CURL_VERBOSE=1 git clone http://<your stash repo clone url>

This will leave a detailed curl trace of each request made as part of the clone operation, in which you will find the 302 responses and how they are followed appropriately.

So, in short, I'm pretty sure your configuration is working as expected, but git 'hides' the fact that it has been redirected to the https port when cloning from http (in fact since curl is handling the redirects, git has probably no idea that they even happened - that's my guess anyway).

Hope this helps.

Cheers,

Dariusz Kordonski [Atlassian]

Just as a quick side note. Following HTTP redirects in git works only for clients that are at least version 1.7.3.4 (#311e2ea is the required change that makes this work).

Clients older than that will fail with:

error: RPC failed; result=22, HTTP code = 501
fatal: The remote end hung up unexpectedly

This widget could not be displayed.

Another consideration is that users trying to perform git operations via HTTP are likely to leak sensitive information (usernames, passwords) in unencrypted requests, even though they get redirected to HTTPS.

This should not really be a big concern, since with the above setup the clone URL should be displayed as https:// (in other word you'd have to intentionally edit the clone URL provided by Stash to use bare HTTP instead), but you can still block it entirely by not applying the rewrite rule you have defined for the requests to '/scm/(.*)'.

This widget could not be displayed.

Hey guys,

Thank you for the very informative answers.

@Stefan: I am fine with older clients failing :) I can expect the "latest" git version from my (few) users.

@Dariusz: About git cloning via https when redirected - I thought that too but I was proven wrong. To be completely sure I used Wireshark to sniff the traffic while cloning via http, and indeed it was all clear text. I have git 1.7.12.4 on my Mac but it still cloned in clear text :/ I didn't check the logs though.

And Dariusz you are right - the last thing I want is the leak of sensitive user credentials when git operations are redirected from http to https. I will try your suggestion about the /scm/ bit and sniff the traffic again. If it fails I will ditch http for good.

Thanks again guys, you rock!

Stefan

This widget could not be displayed.

A listtle update. I was unable to redirect http to https and ditched it alltogether. I have now only the https virtualhost.

This widget could not be displayed.

Just a little question? How do I close or accept a question? The "Answers" mailer keeps bugging me about this question...

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted yesterday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

40 views 0 1
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you