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

[Stefano]

moving to General discussion section

[Stefano]

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.

ok.. let's make a recap:

1) if you go to https://IP the traffic is encrypted so it is secured.. pretending the browser to accept the certificate is quite silly because certificate doesn't know anything about IP (see above).. so, there's no technical reason to say it's unsecure

2) if you go to https://FQDN but the certificate is a self signed one, again, the traffic is encrypted and so it is secure

3) if you have a site driven by, let's say, wordpress and you open it via https but some elements (images) are linked using http, your browser will tell you that the site is unsecure because of mixed content.. but https traffic is encrypted, so it is secure

now.. what's the point? what are you afraid of? MITM? you'll never know, never

you can't know what is right out there, the only things you can do is use your brain and trust.

there's no need of indipendent technical proof.. how things work is clear

[guest22]

there's no need of indipendent technical proof.. how things work is clear

There is. One needs to prove that traffic is secure, for there is no 'green lock', or even worse the browse days 'Danger' 'Unsecure' Watch it' etc. etc.


So how can one PROVE that traffic is secure? Wireshark? Any other tools?

[Stefano]

no one can.. you  can't know how the things are running outside your lan.. you can't know if the traffic isn't sniffed by NSA or other.. so, again, use the best AV/IDS you have (which is between your ears) and simply "use internet"

having this kind of concerns let me think you don't use CC, or ATM, or automated toll paying systems, and it's hard to believe nowadays

[Daniel B.]

You can check with wireshark. But there's ni doubt: if https is used (in the address bar), then the traffic is encrypted. Now the problem is that there's no definitive definition for secure. Is encryption enough to consider things secure ? Or is certificate validation also needed? It depends

[guest22]

You can check with wireshark. But there's ni doubt: if https is used (in the address bar), then the traffic is encrypted. Now the problem is that there's no definitive definition for secure. Is encryption enough to consider things secure ? Or is certificate validation also needed? It depends

All fair, BUT the business world out there does not have the 'intelligence' to see that and are being brain washed by a 'green lock'.


So if in an RFP is being asked: Is all web traffic encrypted? If yes, prove it. They will compare the answer against the 'green lock' and other warnings.

[Stefano]

All fair, BUT the business world out there does not have the 'intelligence' to see that and are being brain washed by a 'green lock'.


So if in an RFP is being asked: Is all web traffic encrypted? If yes, prove it. They will compare the answer against the 'green lock' and other warnings.

again, I can't see the point here.. you have to know how things work.. you can explain it to the user, you can teach him what to check, but there's nothing you can do more

[guest22]

again, I can't see the point here.. you have to know how things work.. you can explain it to the user, you can teach him what to check, but there's nothing you can do more

That's not a proper RFP response.

[Stefano]

well, IMO, who cares?

this is something common people won't understand, never
this is something skilled people will understand

[guest22]

well, IMO, who cares?

I do, and my potential clients do, so do local governments, banks, issurance comapnies etc etc, for they have to be compliant to a bunch of set rules.


No proper answer will lose you any deal.

[Stefano]

I do, and my potential clients do, so do local governments, banks, issurance comapnies etc etc, for they have to be compliant to a bunch of set rules.

well, in which way this is a SME related issue? I mean, it's how internet works

[guest22]

well, in which way this is a SME related issue? I mean, it's how internet works

So it effects SME Server. I'm simply asking IF it is secure to access SME Served websites, and IF in doubt, HOW to prove it.

[janet]

RequestedDeletion

I'm simply asking IF it is secure to access SME Served websites, and IF in doubt, HOW to prove it.

Daniel answered a few posts back
"You can check with wireshark"

[DanB35]

It is not according Google, it is according Firefox. Who knows what IE says.

It would be very easy for you to find out what IE says--have you tried?  Never mind, I just fired up a VM and tried it.  IE shows probably the most useful status of any of the browsers--the background of the address bar is red, and to the right side there's a badge saying "Certificate Error".  If you click on that badge, it tells you what the error is (namely, the hostname you're requesting doesn't match any hostname on the certificate).

You keep talking about security as though it's an objective, binary thing--either something is secure or it isn't.  That isn't the case.  It isn't the case in the physical world, and it isn't the case in the digital world.  Security is a continuum, and it's often in tension with accessibility.  But you continue to write as though you don't understand this, and as though you don't understand what HTTPS does.

So, is https://$IPADDR secure?  Neither I, nor Chrome, nor Firefox, can tell you; only you can determine that.  What do you mean by secure?  That question isn't rhetorical--what do you mean by it?  Only then can anyone answer your question.

[ReetP]

I've read this through a few times and think there is some confusion.

The issue was accessing SME via IP rather than FQDN was insecure.

On the basis that you have configured your server to only serve https via

"db accounts setprop Primary SSL enabled"

As far as I can see when testing if you go to a IP address you get served a locally generated certificate rather than a Letsencrypt one as Letsencrypt certs are only generated for a FQDN whereas you are trying to access the site via IP.

At this point the user is issued a warning by the browser that the certificate (self signed locally generated) is insecure.

If the user then ignores this advice (and there is no fixing user stupidity) they then connect using https, but using the self signed certificate.

So the connection IS https and encrypted, but the veracity of the certificate cannot be guaranteed by the browser. See the test to Dans IP address for this.

So the issue is really "how do I prevent locally signed certs being served to an IP address" and the answer to that would be a redirect in Apache.

There are plenty of configuration examples online. You might have to get a bit creative in instances say like accessing the SM via a local IP.

I'm still not sure why the Primary ibay does not have a switch for https enable/disable in SM when you can for other ibays. That is illogical, and a bug IMHO.

As for accessing via IP this could be a NFR.

I may have misunderstood the issues so quite prepared to stand corrected.