3

If a user tries git commands pointed at an http://gitlab.example.com address (and they have not connected to this domain before), the gitlab.example.com server redirects (or rewrites) to https://gitlab.example.com (note the s) and requires a correct username and password.

What information has the user sent in the clear? Has the user compromised their, username, password or project files and data?

E.g.

  • git remote add origin http://gitlab.example.com/namespace/projectname.git
  • git push https://gitlab.example.com/namespace/projectname.git
  • git clone http://gitlab.example.com/namespace/projectname.git
  • When they have connected at least once to this domain:
    • git checkout -b feature1
    • git push master
1

They should be fine, as git won't send username/password (even if stored in a preconfigured credential file), unless the web server indicates that authentication is required in order to proceed. The redirect to https happens before the server requests credentials, so at no point anything other than the path of the repository requested is being sent in the clear.

  • This is only true if you assume you really are talking to the server, and not to a MITM attacker (which is not guaranteed for a plain HTTP connection). If you are talking to a MITM, they can easily decide to not redirect you to HTTP, and to instead just ask your git client for its credentials, which it will happily send to the attacker in the clear. – Ajedi32 Feb 21 '18 at 15:58
  • Yes, this is correct -- but not exactly what the author asked. The question was about what is exposed over a cleartext connection, vs. what are possible risks if someone actively tries to MITM the connection. – mricon Feb 21 '18 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.