It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Stash Apache Reverse Proxy - force https


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"

The VirtualHost looks like this:

<VirtualHost *:80>
   ServerAdmin xxx
   ErrorLog xxx
   CustomLog xxx

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

<VirtualHost *:443>
   ServerAdmin xxx
   ErrorLog xxx
   CustomLog xxx

   # SSL Config
   SSLEngine on
   SSLCertificateFile xxx
   SSLCertificateKeyFile xxx

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

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.



5 answers

1 accepted

3 votes
Answer accepted

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:// - - [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/" - - [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/" - - [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/" - - [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/" - - [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/" - - [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/" - - [26/Apr/2013:11:43:25 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 302 561 "-" "git/" - - [26/Apr/2013:11:43:25 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 200 30265161 "-" "git/"

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: - - [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/" - - [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/" - - [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/" - - [26/Apr/2013:11:47:03 +1000] "POST /scm/soke/stash-4273807918728176903.git/git-upload-pack HTTP/1.1" 200 30293850 "-" "git/"

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.


Dariusz Kordonski [Atlassian]

Just as a quick side note. Following HTTP redirects in git works only for clients that are at least version (#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

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/(.*)'.

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 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!


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

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
Published in Bitbucket

Powering DevOps with Bitbucket Server & Data Center

Hi everyone, The Cloud team recently announced 12 new DevOps features that help developers ship better code, faster   ! While we’re all excited about the new improvements to Bitbucket ...

1,526 views 0 6
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you