Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

acceptedPushTransports limiting to HTTPS does not work when behind proxy. #1424

Open
urkle opened this issue Sep 2, 2022 · 10 comments
Open

Comments

@urkle
Copy link
Contributor

urkle commented Sep 2, 2022

I have gitblit configured behind a proxy server (traefik) which is providing HTTPS (so gitblit access is HTTP behind the proxy)

However when I configure this
acceptedPushTransports=SSH HTTPS

It does not allow pushes as it does not detect that we are in-fact really doing HTTPS.

Is there perhaps some header that needs to be set to make gitblit happy? (I'm using the docker container image on kubernetes)

In the end I had to change it to
acceptedPushTransports=SSH HTTPS HTTP

This was in an attempt to get LFS working correctly, as LFS wont work over SSH (and no clue how to force JUST LFS over https)

Now, further "oddities" is that now that I have it configured this way, it will periodically attempt to push to http:// (which of course is redirected to https by traefik), however now there are two entries stored in my keychain (one for http and one for https)

@flaix
Copy link
Member

flaix commented Sep 16, 2022

But, you are not using HTTPS. From Gitblit's viewpoint you are using HTTP. Because that is the connector it has open and is accepting connections from the proxy on. So I am not sure what you mean when you say that you "are in-fact really doing HTTPS".

As for the second part, that seems to be a question regarding whatever Git client you are using, and not Gitblit itself.

@urkle
Copy link
Contributor Author

urkle commented Sep 16, 2022

@flaix I can only make connections to Gitblit via my load balancer which is exposing only HTTPS. It itself is communication (internally only) to the HTTP port on gitblit. e.g. there should be no reason for met o setup SSL on that internal communication channel as well as that is in a secured setup (in my case it is in kubernetes).

Other applications I have used (or built) handle this by checking a X-Forwarded-Proto header to determine this. ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto )

@flaix
Copy link
Member

flaix commented Sep 17, 2022

Apparently I am totally missing what your actual problem is. What is the original problem you are dealing with, that makes you feel you have to enable HTTPS?

@urkle
Copy link
Contributor Author

urkle commented Sep 17, 2022

I wanted to have my gitblit configured with just SSH & HTTPS transports ( acceptedPushTransports=SSH HTTPS

But, that doesn't work if only the load balancer is providing SSL, as GitBlit does not check X-Forwarded-Proto headers to recognize that the client is indeed utilizing HTTPS. Gitblit assumes it is HTTP, and rejects the request.

@flaix
Copy link
Member

flaix commented Sep 18, 2022 via email

@urkle
Copy link
Contributor Author

urkle commented Sep 20, 2022

It is unexpected errors when you have it configured as SSH + HTTPS and it doesn't work. (with no clear indication that is why). I spent quite a while fighting with things trying to figure out why it wasn't working.

Further, being able to properly set it as SSH+HTTPS adds extra protection against misconfigurations.

Honestly, if you could point me to where about in the code the change would need to be made to support this I can make a PR to add the handling of the X-Fowarded-Proto header.

@flaix
Copy link
Member

flaix commented Sep 20, 2022

I probably can, I will have to look into it.
I can also check my setups, because I always have it running behind a nginx reverse proxy which handles the TLS. I did not have any unexpected errors with that. Could you be more specific about what errors these are exactly.

@urkle
Copy link
Contributor Author

urkle commented Sep 21, 2022

I was getting constant authentication errors as the GIT client was being refused to push content up as gitblit thought it was using http vs https (as I had restricted my acceptable push protocols). I had not noticed this before as I always use SSH to push content, but due to gitblit not implementing LFS over SSH I had to switch to HTTPS for one of my projects that I was switching to utilize LFS on.

I can change my configuration tomorrow and retest and dump client errors here.

@flaix
Copy link
Member

flaix commented Sep 21, 2022 via email

@flaix
Copy link
Member

flaix commented Oct 3, 2022

I can not reproduce this.
I have set up a new Gitblit server behind a nginx reverse proxy. The nginx proxy uses TLS towards the client. Gitblit only uses HTTP and the proxy uses HTTP towards the Gitblit instance.

server {
	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;

	include snippets/snakeoil.conf;
	server_name _;

	location / {
		proxy_pass http://127.0.0.1:8080;
	}
}
git.daemonPort = 0
git.acceptedPushTransports = HTTP SSH
server.httpPort = 8080
server.httpsPort = 0
web.canonicalUrl = https://10.2.3.4/

This works for me. I can access the web interface, I can clone via HTTPS and SSH and I can push via HTTPS and SSH.

flaix@mints:~/Devel$ git -c http.sslVerify=false clone https://flaix@10.2.3.4/r/test1.git
Cloning into 'test1'...
remote: Counting objects: 16, done
remote: Finding sources: 100% (16/16)
remote: Getting sizes: 100% (10/10)
remote: Compressing objects: 100% (278/278)
remote: Total 16 (delta 2), reused 12 (delta 1)
Unpacking objects: 100% (16/16), 1.49 KiB | 763.00 KiB/s, done.
flaix@mints:~/Devel$ cd test1
flaix@mints:~/Devel/test1$ echo "Hello" > world
flaix@mints:~/Devel/test1$ git add world
flaix@mints:~/Devel/test1$ git commit -m "Hello world"
[master 7117521] Hello world
 1 file changed, 1 insertion(+)
 create mode 100644 world
flaix@mints:~/Devel/test1$ git -c http.sslVerify=false push
Password for 'https://flaix@10.2.3.4': 
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 2 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 316 bytes | 316.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Updating references: 100% (1/1)
To https://10.2.3.4/r/test1.git
   d8d58c3..7117521  master -> master

If you are still having trouble with this, then you will need to post more precise error information. I have never used traeffic so I cannot say if that does anything special which would result in errors. But in general the setup behind a reverse proxy doing the HTTPS and connecting via HTTP to Gitblit is known to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants