Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: guest22 on March 04, 2017, 06:50:54 PM
-
It appears that Letsencrypt secured websites on SME Server CAN be accessed via un secure http when one uses the IP address opposed to the FQDN. Can some readers check this on their own sites please? I may be at fault here, don't know.
-
Probably depends on your ibay settings. See modssl.
It isn't an issue with letsencrypt but your server setup I think.
-
Probably depends on your ibay settings. See modssl.
It isn't an issue with letsencrypt but your server setup I think.
I have no ibays on this test server, clean install, updates and then letsencrypt.
-
I have no ibays on this test server, clean install, updates and then letsencrypt.
so can you make an example?
how did you setup the websites?
are they using https?
are you forcing https?
-
so can you make an example?
how did you setup the websites?
are they using https?
are you forcing https?
As per my earlier comment above. Clean install, updates and manually letsencrypt according to how-to. That's all. No ibays, no websites, nothing, just the primary by default
-
I remember a bug about SSL and Primary ibay.. check BZ, please
-
The _only_ way around this is to set the main domain to be served from an ibay, and leave the Primary 'empty'/not use it.
-
The _only_ way around this is to set the main domain to be served from an ibay, and leave the Primary 'empty'/not use it.
That has been "recommended" practice for many years.
This is the bug I think Stefano is referring to.
https://bugs.contribs.org/show_bug.cgi?id=9193
-
Then I guess we have a serious security issue with SME Server out of the box with the Primary ibay. Especially since letsencrypt wants to write to it's acme directory via http and when the Primary is set to httpS only, it won't fly. Chicken and egg?
-
I guess especially when self signed certificates are less and less accepted and present scary warnings to browser users such as Chrome and Firefox.
-
Then I guess we have a serious security issue with SME Server out of the box with the Primary ibay. Especially since letsencrypt wants to write to it's acme directory via http and when the Primary is set to httpS only, it won't fly. Chicken and egg?
That shouldn't be a problem--the Let's Encrypt servers will follow redirects, and won't complain about self-signed certificates.
What I think you're running into, though, is the fact that the server's IP addresses (internal and external) aren't on the certificate, so if you try to browse to your SME server by IP address (i.e., going to https://$IPADDR), you'll get an error. If you go to my server, for example, https://www.familybrown.org, you'll get an https page with a valid Let's Encrypt certificate, and no issues. If you instead try to go to https://96.91.11.81, you'll get a certificate error. That's normal, and it's just part of how TLS certs work. No CA will issue a cert for an IP address, so if you browse to a secure server by IP address, you'll see an error that the hostname doesn't match the cert.
-
If you instead try to go to https://96.91.11.81 (https://96.91.11.81), you'll get a certificate error. That's normal, and it's just part of how TLS certs work. No CA will issue a cert for an IP address, so if you browse to a secure server by IP address, you'll see an error that the hostname doesn't match the cert.
Thanks. That is correct, but I can still proceed to your website by clicking advanced and proceed..... I am not blocked in any way and can access your site unsecure.
-
I am not blocked in any way and can access your site unsecure.
Yes, but "unsecure" means, in this case, that the hostnames don't match. The connection, and all traffic through it, are still encrypted. If that's your concern, it's simply a result of the way that public CAs (any public CA, not only Let's Encrypt) operate--they don't issue certificates for IP addresses, they issue certificates for hostnames. If you buy an OV or EV cert, the cert contains additional information, but the CN and SAN fields will still only contain hostnames, never IP addresses.
Don't want the error? Browse by FQDN, not by IP address. That really is the only way to avoid it.
Edit: What is the "serious security issue" you see? Because nothing you're describing sounds like a security issue at all.
-
Edit: What is the "serious security issue" you see? Because nothing you're describing sounds like a security issue at all.
Let me get this right based on what you are describing. So I go to your server to access an web application. I do this via IP and not via FQDN. I get the warning, bypass the warning and access the web application, let's say Nextcloud. Do you mean to say that all http traffic is secured?? Whilst there is no green lock? (let's forget about the internal Nextcloud redirects to FQDN)
-
Do you mean to say that all http traffic is secured?? Whilst there is no green lock?
Does the URL say https:// ? If so, then yes, all the traffic is encrypted. You can confirm this yourself on my site, depending on which browser you're using. Using Chrome, I don't see any easy way to confirm it; it just gives you the red "not secure" warning. But if you use Firefox, you'll get the green lock (after you add the security exception).
The problem is that security isn't binary. Chrome says the site is insecure, because the hostnames on the certificate don't match the hostname in the address bar. In most cases, that would indicate a MitM attack. Firefox says the site is secure, because the connection is encrypted. Which is right? It depends on what you're trying to do. If you go to your bank's website and get a certificate mismatch, you have a problem, because you probably aren't communicating with who you think you're communicating with. But if you browse to the known IP address of your server and get that error, and the certificate doesn't have the hostnames that belong to your server, you really don't have a problem.
This could be avoided by implementing a redirect from https://$IPADDR to https://$FQDN, but that raises the question of which FQDN to use--a stock installation of SME Server will have several hostnames assigned to it, and it's very common for the server to be hosting multiple domains as well (each with its own set of hostnames).
-
Does the URL say https:// ?
http://picpaste.com/notsecure-4OLzNObn.png
-
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.
-
Sigh, how to convince the public that are getting educated to be focussed on the 'green lock' that this is not always the case...
-
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.
-
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.
-
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..
-
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.
-
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...
-
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.
-
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..
-
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 ?
-
I just don't get it. What would be the purpose ?
Well, simply put to avoid insecure web traffic.
-
It's not unsecure, as it is already been told
-
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.
-
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.
-
moving to General discussion section
-
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
-
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?
-
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 :-)
-
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
-
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.
-
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
-
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.
-
well, IMO, who cares?
this is something common people won't understand, never
this is something skilled people will understand
-
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.
-
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
-
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.
-
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"
-
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.
-
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.
-
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.
No, not really. There's no case where an (unmodified) SME Server is going to serve different certs depending on the requested hostname--that would require SNI, which SME doesn't support out of the box. There's a bug open requesting that be added; I'm uncertain of the value of doing so, but in any case it isn't there now. SME serves a single cert on any https connection, irrespective of the requested hostname. You can verify this most easily on my site using Firefox--browse to the IP link I gave, Firefox will give you a warning, and let you view the cert. The cert you'll see is a Let's Encrypt cert.
At this point the user is issued a warning by the browser that the certificate (self signed locally generated) is insecure.
No, the warning is given because the hostname requested (the IP address) doesn't appear on the cert.
-
How about we combine this all valuable knowledge into a wiki page. Terry indicated the importance/interesting nature already.
-
No, not really. There's no case where an (unmodified) SME Server is going to serve different certs depending on the requested hostname--that would require SNI, which SME doesn't support out of the box. There's a bug open requesting that be added; I'm uncertain of the value of doing so, but in any case it isn't there now. SME serves a single cert on any https connection, irrespective of the requested hostname. You can verify this most easily on my site using Firefox--browse to the IP link I gave, Firefox will give you a warning, and let you view the cert. The cert you'll see is a Let's Encrypt cert.
No, the warning is given because the hostname requested (the IP address) doesn't appear on the cert.
Thanks Dan. I just got back and tested and indeed this is correct.
Go to the IP and you get a privacy error. Check the certificate and you can see that the certificate is a Letsencrypt cert and the browser throws the error as the cert is for a FQDN and not the IP.
The browser continues to complain, despite the connection being https.
It reports:
Certificate Error
There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).
Secure TLS connection
The connection to this site is using a strong protocol version and cipher suite.
Secure Resources
All resources on this page are served securely.
So, yes the connection is secure, but the browser doesn't like it.
Possibly in the short term it may be easier to add a template fragment to redirect IP addresses to the FQDN is that is a concern for some ?
Inevitable StackOverflow:
http://stackoverflow.com/questions/11649944/apache-httpd-conf-for-redirecting-ip-to-hostname#11651783
There are lots of pages on the subject.
-
Possibly in the short term it may be easier to add a template fragment to redirect IP addresses to the FQDN is that is a concern for some ?
Sure, though that does leave a couple of issues:
- You'll still get the certificate warning when you first connect, as it's the redirect happens once the connection has already been negotiated--but once it redirects you, everything in the address bar should look fine.
- Since every SME server has multiple hostnames, it may be difficult to determine the appropriate FQDN. A reasonable first guess would probably be www.$PRIMARYDOMAIN, but even with only one domain that might not be the best answer. If you're serving multiple domains, the odds of that being right drop rapidly.
-
Sure, though that does leave a couple of issues:
- You'll still get the certificate warning when you first connect, as it's the redirect happens once the connection has already been negotiated--but once it redirects you, everything in the address bar should look fine.
- Since every SME server has multiple hostnames, it may be difficult to determine the appropriate FQDN. A reasonable first guess would probably be www.$PRIMARYDOMAIN, but even with only one domain that might not be the best answer. If you're serving multiple domains, the odds of that being right drop rapidly.
that's why, IMO, this is not an issue with a technical solution
-
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.
RequestedDeletion, my question from yesterday morning remains: what do you mean by "secure" in this context? Only with your answer to that question can this conversation reasonably continue.
-
RequestedDeletion, my question from yesterday morning remains: what do you mean by "secure" in this context? Only with your answer to that question can this conversation reasonably continue.
Well, secure has indeed a broad spectrum, so let me limit it to the meaning of a certificate by means of using http traffic.
So 'secure' in this respect is the connection between the client browser and webserver that is browsed to. Secure connection... This commonly shown as the 'green lock' (banks etc stress this very much). So the consensus is a green lock is 'safe', and all other scary screens are NOT safe. The 'green lock' concept will have users say 'That site is not safe' if it is not there.
-
as it has been explained before, the green lock is not strictly related to https cert..
for example, a mixed content (https served page with some http content inside) issue will be reported with no green lock..
it's not a technical issue: you have to know how to decipher what your browser is telling you, reading the error message
-
So 'secure' in this respect is the connection between the client browser and webserver that is browsed to. Secure connection...
Using the word "secure" to define the word "secure" is not valid. But it sounds like you're saying one of two things, and I can't tell which:
- You have no personal definition of "secure" in this context at all, or
- "Secure" means that a browser says it's secure
If the former is the case, I don't know that the discussion can continue, at least until you do decide what characteristics define a "secure" connection. If the latter is the case, then the scenario we're describing is simultaneously secure and insecure.