Will it be safer to use self sign CA and client certification in the company for a private website?

Question

Our company have 10+ private websites and 20+ person and need to open a different one automatic when the developers are testing some functional. We do not want anyone outside the company to view the content of the private websites.The websites is access with ip and port.Those websites have public ip, can be access from any place.

So there is two options:

• We can open http websites and use a http basic auth with a fixed username and password to login. When someone leave the company the password will change.
• We can create a self sign CA and a client certification , and use that ca to sign a https server certification to the websites, and the websites need the client certification to view. We will continue using the fixed username and password and http basic auth in the https websites.

Will option 2 safer than option 1? Or it is just a illusion of safer because of https?

Is there any bigger safe problem in the option2?

additions

• We put the server of websites in big datacenter with public ip to access data faster, put the server internally will make it access the data too slow to work. So the websites will access from public ip, I do not know any way to prevent it.

• Using vpn can make the websites easy to not work when the vpn server itself dead. And it make the end user difficult to use the websites, as we already use vpn to do some jobs, two vpns is impossible in some operation system. (like android/ios)

• We use the fixed username and password to prevent the left person have the access to the private website. They are fixed , so we can use less time to manage it.

Answer 1

Simplification

Neither option is remotely secure. But you present those as THE options, so I'll address them first, then present you an option 3.

Security: Technical

Given your two options, neither is technically superior. The addition of SSL/TLS would only be security theater.

In regards to your public internet exposure, neither option provides reduction of attack surface or hardens your underlying systems from attack. An attacker accessing your sites from the public internet would be able to simply accept any self-signed certificate if you have one, and would not worry about it if you do not.

In regards to your internal exposure, SSL/TLS is primarily intended to mitigate man-in-the-middle attacks (not its only use, but primary). Since this is internal and all persons log in using shared user/pass, there is minimal gain for a potential internal attacker. If the internal attacker has access to the shared user/pass, the attacker can generate any traffic any other user would generate.

Note: I yield a TINY amount of extra security with the SSL/TLS (at least our attacker can't see what others are doing). Given the described scenario, I evaluate the worth of that tiny sliver to be otherwise not worth mentioning.

Security: Procedural

In terms of process, leaving SSL/TLS out is actually more secure. Given the above technical lack of additional security, you've now added management of a security resource to the mix.

Unnecessary complexity is an enemy of security.

Security: Human Factor

In terms of process, leaving out self-signed certs is more secure.

Consider what you will be training users to do: adopt a workflow where self-signed certs are to be accepted. You want users to always, ALWAYS seek guidance when they receive a browser warning regarding certificates - be that from the company's help desk or from the site's help desk.

Regardless of cert or no cert, you say that you will change the password whenever someone leaves the company. This requires all users every time to adopt a new password. If your turnover is high, users will inevitably start writing down the current password.

Do not train your users into bad patterns.

If ONLY the two options are options...

Leave out the SSL/TLS. The described scenario is severely security deficient, and adding security theater only provides a false sense of doing something.

Changing perspective...

So Option #3, as promised, requires you, the asker, to adopt a security-minded approach. Big factors I see as problematic in the situation you describe:

Technical Gap: Adding SSL/TLS does not necessarily add security (or at least, any amount worth mentioning). The reasoning behind shared user/pass is faulty. This indicates the overall system was designed by someone lacking technical cybersecurity knowledge and understanding.

Attack Surface: Having these internally used sites publicly available is a massive attack surface. If they are to be used only internally, they should be accessible only internally.

Shared credentials: While there are certainly some edge cases where I'd entertain the prospect of shared credentials, it is a bad design pattern. If a person leaves your company, you have to change a password -- it does not matter if it is their personal password or if it is the shared password. The risk of overlooking this step is identical for both shared and individual credentials.

Taking the given scenario, the following corrective actions would help reduce risks (listed in order of greatest value to least value):

• Any and all technical staff should seek cybersecurity training. This should include engineers, systems administrators (OS, DB, network, etc...), architects, developers/coders, even help desk. All users should also receive basic security training (which should be broader in scope than cybersecurity training, but shallower in depth).
• Use an edge firewall to block access to the sites IPs from outside. Most modems/bridges have a basic firewall built in; while a dedicated appliance that can create external, internal, and DMZ zones would be better, using the existing built-in firewall is a step in the right direction.
• As soon as feasible, retool the system to use individual credentials. Realize that an account has to be updated whenever a person leaves the company anyways -- choose the option that least inconveniences other users.
• If you've implemented individual credentials, SSL/TLS finally offers a reasonable addition of security. Self-signed certs are not HORRIBLE, but given the low costs of getting a proper chained cert from a public CA, a public CA vs a self-signed cert would be the superior option of the two. If you MUST use self-signed certificates, ensure these are pre-bundled when a new system is deployed; this prevents training users to ignore certificate warnings.

Answer 2

I'm coming from the assumption that you don't leave any backdoor open in either of the methods, and choose high-entropy passwords for Basic Auth. In that case, the biggest difference between the methods is that HTTPS will encrypt the traffic and prevent Man-in-the-Middle Attacks, making it impossible for anyone to eavesdrop, whereas Basic Auth will not.

So in that sense, the HTTPS based method is more secure.

You could get the same benefits regarding encrypted traffic for Basic Auth by adding HTTPS with a certificate that is commonly trusted by browsers (not requiring client-side authentication apart from Basic Auth)

In practical terms, you don't have to have the same password for everyone in the company. I think this is the greatest security flaw apart from any method, if security is a concern. Instead, you could have individual accounts (or client-side certificates) for each person. If a person leaves, you only have to invalidate that account. It also gives you the ability to detect who, and from where, uses certain accounts, and if an account is identified as compromised, you can close that account without affecting others.

The best of all worlds, also counting practicality, would be Basic Auth with individual accounts combined with a commonly trusted HTTPS cert.

If you are willing to compromise security, for example by having a single account for everyone, quote "so we can use less time to manage it", then I don't know why there is a debate about TLS/Basic Auth in the first place, because no encryption can compensate for an insecure handling of information.

Answer 3

If something is not meant to be public it shouldn't be public in any way and there is no security-plan that can assure you that your public websites will be 100% safe. Security depends on a LOT of things. What you're describing in your post is to use authentication and encryption to make sure that your data will be accessed only by those that have the authority to do so. But what happens if e.g. a 0day come out for a small plugin that you may use etc... What happens then? What part of the plan (auth & traffic encryption) makes sure that the data are still protected?

Everything that faces the internet can immediately be considered a possible target. And even if you are safe today that doesn't mean that you will be safe e.g. after an update etc...

Since I don't have enough information about your infrastructure/situation I cannot really provide you a solution that will be a suit for your needs but some thoughts are:

• Create an intranet
• Use a VPN software on the servers that host your websites and connect through that.
• ssh to the non-public network that those servers are part of and work from there.