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

Improve this question
2
  • are you sure that you typed in http : //stuff.mydomain.com in the addressbar instead of https : //stuff.mydomain.com ?
    – JOW
    Commented Mar 31, 2017 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
    Commented Mar 31, 2017 at 17:02

2 Answers 2

Reset to default
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)

Improve this answer
3
  • 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.
    Commented Aug 22, 2017 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 ♦
    Commented Aug 22, 2017 at 11:59
  • Alright, didn't notice the ID in the URL.
    – Tom K.
    Commented Aug 22, 2017 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).

Improve this answer
9
  • Thank you. Is there a way to force the redirect before the authentication request?
    – Michael Biro
    Commented Mar 31, 2017 at 17:10
  • @MichaelBiro I'm not sure, but there are questions about this on stackoverflow and serverfault.
    – tim
    Commented Mar 31, 2017 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
    Commented Mar 31, 2017 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
    Commented Apr 1, 2017 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
    Commented Apr 3, 2017 at 16:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .