SSL Vulnerability
Hi Guys,
We have a couple of "internal" servers with self-signed certificates. An IT audit raised concerns about the self-signed certificates as some are using SSL 2 & SSL 3 encryption methods. Services and applications running on these servers are only accessible internally.
A second scenario is a server which has external access, but do have a proper SH2 2048 public certificate installed. However, the report still picks up an issue with another self-signed certificate on the same server.
My question, does these self-signed certificates pose any security risks, or can it be safely ignored?
We have a couple of "internal" servers with self-signed certificates. An IT audit raised concerns about the self-signed certificates as some are using SSL 2 & SSL 3 encryption methods. Services and applications running on these servers are only accessible internally.
A second scenario is a server which has external access, but do have a proper SH2 2048 public certificate installed. However, the report still picks up an issue with another self-signed certificate on the same server.
My question, does these self-signed certificates pose any security risks, or can it be safely ignored?
The use of SSL2 & SSL3 are an issue though. These can be used to pry a private key from the server. (Issue is known already for a few years.)
So SSL2 / SSL3 are a no go area. effectively TLS 1.2 should be considered the minimal setting atm. (TLS 1, TLS 1.0 & TLS 1.1 have been declared unfit for future use).
From the current libraries SSL2 & SSL3 have effectively been removed so modern stacks might not be able to access old SSL stacks. The oldest TLS will be removed also in the near future.
Self signed is in issue in the sense that those certificates tell any one i do trust myself... Q is do they trust you.
CA Signed certificates tell anyone trusting that CA they have mutual trust in a third party....
Then again does everyone trust the same CA's, Should the Curds trust the Turkish Certificate authorities? (Using the a FAKE Turkish certificate a turkish entity could eaves drop on those connections.) The basic question is WHO DO YOU Trust. (and to what level)... Do you trust getting data from a website, Do you also trust those CA certificates when used for code signing?
Mind you it is about blind full trust.
So SSL2 / SSL3 are a no go area. effectively TLS 1.2 should be considered the minimal setting atm. (TLS 1, TLS 1.0 & TLS 1.1 have been declared unfit for future use).
From the current libraries SSL2 & SSL3 have effectively been removed so modern stacks might not be able to access old SSL stacks. The oldest TLS will be removed also in the near future.
Self signed is in issue in the sense that those certificates tell any one i do trust myself... Q is do they trust you.
CA Signed certificates tell anyone trusting that CA they have mutual trust in a third party....
Then again does everyone trust the same CA's, Should the Curds trust the Turkish Certificate authorities? (Using the a FAKE Turkish certificate a turkish entity could eaves drop on those connections.) The basic question is WHO DO YOU Trust. (and to what level)... Do you trust getting data from a website, Do you also trust those CA certificates when used for code signing?
Mind you it is about blind full trust.
An IT audit raised concerns about the self-signed certificates as some are using SSL 2 & SSL 3 encryption methods. Services and applications running on these servers are only accessible internally.The red flag would still revolve around SSL. PCI rules requires the usage of TLS 1.1 and up already. Matter of time before they require 1.2. So I agree 100% with noci's comment in this area.
We have a couple of "internal" servers with self-signed certificates.I'm curious as to why the word "internal" is in quotes.
1) As Dr. Klahn mentions, self signed certs are just as secure as any other cert.
2) As noci mentions, the real problem is not your cert security, it's your protocol. SSL2 + SSL3 have been deprecated/retired for years because they're highly insecure.
3) As masnrock said, now both TLSv1.0 and TLSv1.1 have both been deprecated/retired also, because of slight problems. Most PCI scanners report both these protocols as security breaches... because both have weaknesses.
Fix: Serving your certs via TLSv1.2 or TLSv1.3 protocols should clear the error.
2) As noci mentions, the real problem is not your cert security, it's your protocol. SSL2 + SSL3 have been deprecated/retired for years because they're highly insecure.
3) As masnrock said, now both TLSv1.0 and TLSv1.1 have both been deprecated/retired also, because of slight problems. Most PCI scanners report both these protocols as security breaches... because both have weaknesses.
Fix: Serving your certs via TLSv1.2 or TLSv1.3 protocols should clear the error.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
While self signed certs do guaranty the same encryption levels, the ability to verify the origin of the cert is a question. Self Signed certs can be used in internal sites where you can push the cert onto all the local systems, or if you have a few users that need to access an external site and are provided the cert manually to verify their access is to a legitimate site.
However, you just can't go trusting any random web site's self signed cert to be secured against a man in the middle attack. The certificate authority is used to verify that the owner of the cert is indeed the correct owner and not some hijacker.
However, you just can't go trusting any random web site's self signed cert to be secured against a man in the middle attack. The certificate authority is used to verify that the owner of the cert is indeed the correct owner and not some hijacker.
Addendum on self signed certificates....
Being a CA (for "internal" use) is NO Rocket science.
Using a tool like tinyCA, EasyCA, XCA makes signing Certificates a breeze. (or Microsoft Certificate manager or whatever it is called nowadays).
Then adding your own trusted CA to all systems is a once for all not once / certificate exercise.
Also it means there is some accountability to certificates used internally.
Being a CA (for "internal" use) is NO Rocket science.
Using a tool like tinyCA, EasyCA, XCA makes signing Certificates a breeze. (or Microsoft Certificate manager or whatever it is called nowadays).
Then adding your own trusted CA to all systems is a once for all not once / certificate exercise.
Also it means there is some accountability to certificates used internally.
Side note: To expand on noci's comment above, "SSL" is too often used interchangeably with TLS. SSL is the old version. TLS is the new version. Nobody should be using SSL at this point. But many (including certificate authorities) still call any security certificate an SSL certificate.
Technically the correct term for certificates associated with encryption & security are X.509 certificates.
They were once part of the X.500 Directory (OSI) definitions.
X.500 was abandoned for LDAP (which nowadays resembles the X.500 ideas, with IP as carrier in stead of OSI).
They were once part of the X.500 Directory (OSI) definitions.
X.500 was abandoned for LDAP (which nowadays resembles the X.500 ideas, with IP as carrier in stead of OSI).
ASKER
Hi Guys,
Thanks for your assistance!
With the self-signed certificates, we had the following findings:
SSL Certificate Cannot Be Trusted
SSL Medium Strength Cipher Suites Supported (SWEET32)
SSL Certificate Signed Using Weak Hashing Algorithm
SSL Certificate Expiry
Some of these certificates were automatically installed with a 3rd party software installation.
For exampe: I've noticed Backup Exec & Veritas have their own self-signed certificates installed.
Some automatically installed certificates expired, but has not been causing any issues and were left on the servers, which now seems to cause a finding.
Regarding SSL2 / SSL3:
I've added the "enabled" (Dword 0) to the Server key under SSL2 & SSL3 in the registry to alleviate POODLE vulnerability.
Should the same entry work for TLS 1.0 and TLS 2.0 under the key TLS1 / TLS2 respectively?
Thanks for your assistance!
With the self-signed certificates, we had the following findings:
SSL Certificate Cannot Be Trusted
SSL Medium Strength Cipher Suites Supported (SWEET32)
SSL Certificate Signed Using Weak Hashing Algorithm
SSL Certificate Expiry
Some of these certificates were automatically installed with a 3rd party software installation.
For exampe: I've noticed Backup Exec & Veritas have their own self-signed certificates installed.
Some automatically installed certificates expired, but has not been causing any issues and were left on the servers, which now seems to cause a finding.
Regarding SSL2 / SSL3:
I've added the "enabled" (Dword 0) to the Server key under SSL2 & SSL3 in the registry to alleviate POODLE vulnerability.
Should the same entry work for TLS 1.0 and TLS 2.0 under the key TLS1 / TLS2 respectively?
Yes for TLS 1.0 as it has had its share of vulnerabilities, and more and more organizations are beginning to turn this off as a choice for negotiation of encryption between client and server.
As for TLS1.2, I recommend that you hols first though there are already the more secure versions like TLS 1.3. But due to legacy and interoperability, many has try not to so big bang approach and trial for a period till all issue are settled and slowly transit out to the more secure version where possible.
As for TLS1.2, I recommend that you hols first though there are already the more secure versions like TLS 1.3. But due to legacy and interoperability, many has try not to so big bang approach and trial for a period till all issue are settled and slowly transit out to the more secure version where possible.
Self signed certificates for Veritas/Backup exec are meant to immediately start (demo/test) . For production use your internal CA certificates.
However, they definitely do look cheap to people looking at a web site when the browser brings up that warning block in the address bar stating that it can't rely on this certificate because it's not from a major certificate authority.
You stated ...
Services and applications running on these servers are only accessible internally.
In this situation I don't see why self-signed certificates would not be suitable for those systems. You can change them as often as you like (which gets prohibitively expensive with commercial certificates) and nobody outside your company should be seeing the sites using those certificates, so the browser whining is only an annoyance.