search

fusioninventory / fusioninventory-agent

FusionInventory Agent
http://fusioninventory.org/
GNU General Public License v2.0
254 stars 126 forks source link

Idea to make it easier to use SSL. #926

Closed SteadEXE closed 3 years ago

SteadEXE commented 3 years ago

Hello, I am an IT tech, I manage almost 500 computers with Fusion Inventory. We are using the agent with deploy module.

My GLPI server is using public CA signed certificate. To make the agent work I have to put /no-ssl-check otherwise the agent ends up with a bad file descriptor while contacting GLPI. We cannot deploy the cert on each agent, because it expires every year and we also cannot deploy it with a GPO because a lot of computers almost never come back to office. They are logged with a VPN most of the time.

It seems that everybody ends up using /no-ssl-check because there is no easy maintainable solution. Web browser can detect MITM attacks without having to download certificate from each website, because they detect if certificate are self-signed. Maybe we should add a flag to disable self-signed certificate. So if agent connect to a MITM host, the hacker will have to self sign a certificate to make a fake HTTPS GLPI server. And the agent will reject it.

Sorry for my english. Have a nice day everyone.

g-bougard commented 3 years ago

Hi @SteadEXE you are saying you're using a public CA signed certificate. The agent (at least recent one) should know every thing about recent public CA. For that, the agent is using Mozilla::CA perl module. So maybe you're not using a well-know or supported CA. Maybe your CA is missing in Mozilla::CA supported ones. Or even maybe you're using very old agents with outdated supported CA list.

MITM attacks could be done with fully legit certificate as, for example, it is really easy to obtain a publicly signed certificate with fully supported Let's Encrypt authority. So just rejecting self-signed certificate is not a solution and even legit people still want to be able to use self-signed certificate... but they then provide the server certificate to the agent.

The SSL solution is just to reject any not trusted certificate. This is just how is working SSL. We can't just make agent unsecure to ease people life. You must handle by yourself any certificate problem. If you don't want security, just use HTTP and forget SSL.

You may have to implement a process to automatically synchronize the server certificate. GPO is not the only solution for that.

This is not easy, we are agree, but security is not an easy problem and this is not the agent purpose to make it easy. This is your purpose as IT tech ;-)

guillomovitch commented 3 years ago

Just for the record, the whole interest of the hierarchical trust model used in TLS means that you're not supposed to deploy the server certificate on the client, but the certificate of the authority which ensures its authenticity. Which means that as long as you're using the same authority to renew the server certificate, you don't have to change anything on client side.

But I fully agree with Guillaume: if you don't understand how TLS works, and what kind of benefits it is providing, you'll only suffer from its complexity, and you may as well avoid it completly.

SteadEXE commented 3 years ago

I understand how TLS works. But I am not sure to agree with your statement "MITM attacks could be done with fully legit certificate as". I don't think any public CA will issue certificate for a domain/hostname not owned by the customer. The only way to do it with Let's Encrypt for example is to hack into the server or hack the DNS zone of the domain. Otherwise, anybody could issue certificate for Google, Facebook, etc.

We ended up deploying a self issued CA certificate that expires in 10 years with a deploy task.

Anyway thanks for your replies guys.

g-bougard commented 3 years ago

But I am not sure to agree with your statement "MITM attacks could be done with fully legit certificate as". I don't think any public CA will issue certificate for a domain/hostname not owned by the customer. The only way to do it with Let's Encrypt for example is to hack into the server or hack the DNS zone of the domain.

Yes, I agree, I missed the point where you still need to configure another server on the agent toward the malicious or hack the dns zone requested by the agent. Sorry for the confusion, was probably tired ;-)

SteadEXE commented 3 years ago

This is why I tought a flag to reject self signed certificate would be enough. As long as the hacker cannot issue a certificate inside the network where the agent operates.

Have a nice week-end :)