Topic: Letsencrypt protected websites accessible unsecure via direct IP opposed to FQDN

[guest22]

Does the URL say https:// ?

http://picpaste.com/notsecure-4OLzNObn.png

[DanB35]

Yep, that's exactly what I see.  And yes, the connect and traffic are encrypted in that case.  It's Chrome being more paranoid than other browsers.  Like I said, try it in Firefox and see what it says.

[guest22]

Sigh, how to convince the public that are getting educated to be focussed on the 'green lock' that this is not always the case...

[DanB35]

Sigh, how to convince the public that are getting educated to be focussed on the 'green lock' that this is not always the case...

In what circumstance do you expect your users to be browsing to your IP address?  Doesn't seem like it's something that would happen very often.

But yes, the industry has (knowingly or otherwise) led users to believe that the green lock means everything is great with the site, and that simply isn't true (and it never has been).  All it means is that, minimally, traffic between the user's computer and the website is encrypted.  If they didn't have to click through a warning to get to the site, it also means that the computer on the other end of the connection is actually the site that you typed into the address bar.  That's it--that's all the lock means, and that's all it has ever meant.

[guest22]

When talking to IT guys or CxO level discussing an RFP, a green lock is mandatory via any method. Wise guys will show that you are not compliant..


But I understand what you are saying.

[janet]

RequestedDeletion

I think the issue you are referring to is really the self signed certificate issue.
That is not a sme server fault but the problem of, or responsibility of, the person setting up the server & would/will apply to any brand of (web) server.

If you are doing demos then perhaps you need to get yourself a certificate of any sort for a test domain that you can configure on your demo server.

Those wise guys you refer to are usually reading from a script & do not have real technical knowledge.

When talking to IT guys or CxO level discussing an RFP, a green lock is mandatory via any method. Wise guys will show that you are not compliant..

[DanB35]

When talking to IT guys or CxO level discussing an RFP, a green lock is mandatory via any method.

If you have a requirement that the site be accessible, by IP address, using the current version of Chrome, and have a green lock, the person who wrote the requirement is an idiot.  It simply can't be done.  OK, it could if you use a self-signed cert, but that brings up its own set of warnings, or you need to install your (self-signed) root CA cert manually on every client computer.

You could probably simply refuse to serve pages at all where the request was made by (external, at least) IP address rather than by FQDN; I'd expect that would be a relatively straightforward Apache configuration change.

[guest22]

You could probably simply refuse to serve pages at all where the request was made by (external, at least) IP address rather than by FQDN; I'd expect that would be a relatively straightforward Apache configuration change.

That would be a good solution. Simply refuse direct access on IP in any case if set to true...

[DanB35]

I think the issue you are referring to is really the self signed certificate issue.

No, he's dealing with a certificate issued by Let's Encrypt (as I have on my own server, linked to above).  The issue is, as I said, that the IP address isn't in the CN or SAN fields of the cert (and it never will be in any cert issued by any trusted CA, though it easily could be in a self-signed cert), so browsers will warn you about the hostname mismatch.  Chrome is more aggressive about this than Firefox or Safari.

[TerryF]

This is a discussion well worth stickying/pining, or whatever the term is perhaps alter the subject header a little to reflect the issue being discussed..

[Daniel B.]

That would be a good solution. Simply refuse direct access on IP in any case if set to true...

I just don't get it. What would be the purpose ?

[guest22]

I just don't get it. What would be the purpose ?

Well, simply put to avoid insecure web traffic.

[Stefano]

It's not unsecure, as it is already been told

[Daniel B.]

That's the browser's role. The server has absolutely no way to check if the certificate has been successfuly validated by the client anyway (if accessed via FQDN). There's nothing inherently insecure when accessing the server with it's IP address. The trafic will be encrypted just the same. But, you'll have to manually verify the certificate is the correct one (which can be done by comparing the hash to a known value for example). preventing access to some site would add absolutely no additional security. And BTW, the warning about the hostname not matching the IP address would still be shown to users, as TLS is negopciated before anything else.

[guest22]

It's not unsecure, as it is already been told

It is not according Google, it is according Firefox. Who knows what IE says. Now what would be a definite independent technical proof? Because 'from hear saying' is not a really strong argument.