SSL and TLS

shochan · May 2021

I was just curious how some of you cybergurus are dealing with the many SSL and TLS vulns on your network. There seems to be like 10-15 different kinds. Most are mediums, so, its not that pressing on trying to figure out the best method to mitigate them. BUT it still is a loophole on your network.
Are you just creating your own TLS v1.3 certs, or purchasing them from Cert Auth? or simply accepting the risk they pose?
A lot of them are dealing with weak ciphers.
Obviously, you want to get away from SSL certs all together.
Please share how you are fixing them, if you want to.
Thoughts and comments are welcome!
Cheers & Hi5!

JDMurray · May 2021

Replacing certs as they expire, mandatory org metadata present, new certs use strong(er) encryption/hashing, and expiration date is maximum one-year. Always get certs from a prominent certificate authority.

FluffyBunny · May 2021

> "Are you just creating your own TLS v1.3 certs, or purchasing them from Cert Auth? or simply accepting the risk they pose? "

Anything out on the web gets bought via an external cert auth and as JDM says: replace when expire.

Anything internal gets certificates from one of our internal PKIs. With tens of thousands of servers, applications and identities we A) don't want the expense, and

don't want all those identities known to the outside world. For internal systems there's a two-pronged approach: replace-when-expired and vulnerability scanning reports which will flag anything at 1.1 and below as an issue.

JDMurray · May 2021

I forgot to include: no self-signed certs, and all software developed in-house must be signed when it is built and/or before it is run in a production enviroment.

scasc · May 2021

TLS 1.3 fixes the issues that reside with 1.2 - in that there is no support for PFS if you are not using ECDHE (i.e. using RSA for key exchange) and use of the vulnerable ciphers prone to downgrade attacks such as Beast, Drone etc.

As mentioned, internal PKI used for internal apps so identities not known outside and external CA used for public facing assets. When using AES - use it in GCM - which is authenticated encryption and not CBC for example.

There needs to be a process in place to roll over, revoke and disseminate your x509 certs. For example, AWS use ACM to manage this for you - place it on ALB/API-G/CDN.

You find servers still support less than TLS 1.2 for backward compatibility and the endpoints accessing those servers cannot negotiate 1.2. Which opens you to attack but its again a risk v benefit conversation.

UnixGuy · May 2021

Sorry to Hijack this thread but a relevant questions...

Any thoughts on "EV certs" ?

https://en.wikipedia.org/wiki/Extended_Validation_Certificate

JDMurray · May 2021

Software developers who use code signing use EV certs to identify their executable binary files.

SSL and TLS

Comments