shochanshochan Member Posts: 1,002 ■■■■■■■■□□
edited May 2021 in Cryptography & PKI
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!
CompTIA A+, Network+, i-Net+, MCP 70-210, CNA v5, Server+, Security+, Cloud+, CySA+, ISC² CC, ISC² SSCP


  • JDMurrayJDMurray Admin Posts: 13,012 Admin
    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.
  • FluffyBunnyFluffyBunny Member Posts: 230 ■■■■■□□□□□
    > "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 B) 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. 
  • JDMurrayJDMurray Admin Posts: 13,012 Admin
    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.
  • scascscasc Member Posts: 461 ■■■■■■■□□□
    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.
    AWS, Azure, GCP, ISC2, GIAC, ISACA, TOGAF, SABSA, EC-Council, Comptia...
  • UnixGuyUnixGuy Mod Posts: 4,564 Mod
    Sorry to Hijack this thread but a relevant questions...

    Any thoughts on "EV certs" ?


    Check out my YouTube channel: 

  • JDMurrayJDMurray Admin Posts: 13,012 Admin
    Software developers who use code signing use EV certs to identify their executable binary files.
Sign In or Register to comment.