5

I've set up an NGINX reverse proxy on my home server with dynamic DNS from my website 'stuff.mydomain.com' along with a certificate from letsencrypt. I'm using basic auth to authenticate users.

When I go to my domain and the authentication box pops up, chrome does not indicate that the connection is secure (I get the "Info or Not secure" 'i' symbol). If I log in or click cancel it immediately turns into the green lock symbol and stays that way.

Is this the way it is supposed to work, or did I mess up the setup and am transmitting login information unencrypted?

Edit: The same thing happens when I enter https:// for the URL. Any ideas?

Edit 2: After messing around with wireshark for a while, I'm pretty sure everything is actually encrypted (I checked both http and https in the URL bar). I still don't know what's causing chrome to show it as insecure.

enter image description here

  • are you sure that you typed in http : //stuff.mydomain.com in the addressbar instead of https : //stuff.mydomain.com ? – JOW Mar 31 '17 at 16:58
  • I did type in http but I have a 301 redirect of all http to https. The url does read https except without the green lock. – Michael Biro Mar 31 '17 at 17:02
7

A late response, but this is a long-standing bug in Chrome. Chrome doesn't update the security indicator in the address bar before showing the basic auth dialog (though it does validate the security correctly, so an expired certificate is correctly marked).

https://bugs.chromium.org/p/chromium/issues/detail?id=700748 https://bugs.chromium.org/p/chromium/issues/detail?id=667021 (see also 395050)

  • Please quote the most important parts from the linked sites (but don't delete the links). The links might expire and then this answer is useless for people researching this specific or related problems. – Tom K. Aug 22 '17 at 10:44
  • 1
    @Tom I think this is fine. There is a summary, and the links contain the bug number, which should be sufficient for future research if these particular links go dead. – schroeder Aug 22 '17 at 11:59
  • Alright, didn't notice the ID in the URL. – Tom K. Aug 22 '17 at 13:17
5

The authentication request is likely happening before the redirect. If you enter your credentials, they will likely be send in plaintext, after which you will be redirected to HTTPS.

You can easily check if you send credentials unencrypted via eg wireshark.

If you do, you should either enter HTTPS in your browser (not the best approach, as you may forget), use HSTS to force HTTPS automatically, or reconfigure your server (eg block all access via HTTP).

  • Thank you. Is there a way to force the redirect before the authentication request? – Michael Biro Mar 31 '17 at 17:10
  • @MichaelBiro I'm not sure, but there are questions about this on stackoverflow and serverfault. – tim Mar 31 '17 at 17:13
  • I tried entering https for my domain and get the same result. I'm going to try to see what happens with wireshark – Michael Biro Mar 31 '17 at 18:16
  • The dialog shows https:// so I would check in Chrome -> Tools -> Developer Tools and see why the connection is considered "not" secure. This could be an issues with the Certificate chain or any number of other issues with HTTPS. – jwilleke Apr 1 '17 at 9:39
  • 1
    You dont really need wireshark, you can see what is going on with Chrome developer tools. For Basic auth, server will respond to first request with 401 and include WWW-Authenticate header for authentication challenge. This will provoke a pop up for credentials. In network page of dev tools it should be fairly simple to see if challenge was done before or after redirect. – Marko Vodopija Apr 3 '17 at 16:01

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.