On Thu, Jan 20, 2022 at 6:30 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > Harri, > > On 1/20/22 11:37, Harri Pesonen wrote: > > Vault for Apache Tomcat: > > > > https://github.com/web-servers/tomcat-vault > > > > It hides the secrets in another encrypted file, and password for that > > file is then in another file... So it just makes it more difficult to > > access the secrets, but at least they are not in plain text. > What this does is satisfy the following "security" requirement: > > [ ] Have you ensured that no credentials are stored unencrypted in > Tomcat's conf/server.xml file? > > [X] Check! > > Nice job. It doesn't answer the question "do you have plaintext > credentials in any configuration files" because whatever auditor is > asking would give you a bad grade. > > As soon as that auditor learns about Vault for Apache Tomcat, they will ask: > > [ ] Have you ensured that no credentials are stored unencrypted in > Tomcat's conf/server.xml file? > [ ] Have you ensured that no credentials are stored unencrypted in Vault > for Tomcat's vault-config.xml file? > > Then we'll get questions about whether there is a Vault for Vault for > Apache Tomcat. > > Someone should patch VfAT so it has a new feature which is the number of > configuration files it should use for encryption. So you can set it to > e.g. "4" and then you get these files: > > vault-config.xml > vault-config-1.xml > vault-config-2.xml > vault-config-3.xml > > And the -3 file contains the plaintext password used to unlock -2 which > unlocks -1 which unlocks vault-config.xml. Hey, three layers of > encryption! Super secure!
So I guess this means you're still not interested in that awesome potential contribution we could make to Tomcat :D Rémy Rémy > > -chris > > > -----Original Message----- > > From: Orendt, John <john.p.ore...@medtronic.com.INVALID> > > Sent: torstai 20. tammikuuta 2022 18.11 > > To: users@tomcat.apache.org > > Subject: RE: Tomcat 9 Encrpytion of JDBC > > > > [Et saa yleensä sähköpostia osoitteesta > > john.p.ore...@medtronic.com.invalid. Lue lisää siitä, miksi tämä on > > tärkeää, osoitteesta http://aka.ms/LearnAboutSenderIdentification.] > > > > Hi > > > > There are at least two types of mutual authentication. > > > > 1. Device Client A and Server B > > 2. Human A via browser and Server B > > > > All the scenarios you mention have been solved. You just need to know how. > > X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the > > solution for both types. > > > > Internet Banking does exist. > > > > John Orendt > > john.p.ore...@medtronic.com > > > > -----Original Message----- > > From: Christopher Schultz <ch...@christopherschultz.net> > > Sent: Tuesday, January 18, 2022 11:32 AM > > To: users@tomcat.apache.org > > Subject: Re: Tomcat 9 Encrpytion of JDBC > > > > John, > > > > On 1/18/22 08:37, Orendt, John wrote: > >> Secrets are more secure with the use of a Trusted Platform Module > >> (TPM) and / or a Hardware Security Module (HSM). > >> > >> Secrets need to be protected both at rest and in transit. > > Sure. Where you put the password for the TPM or HSM? Or do you enter the > > password for your HSM/TPM every time you start a process that needs access > > to secrets? How do you handle unattended restarts? > > > > How do you handle massive deployments? Do you manually-enter a password on > > 1000 servers as they all launch together? > > > > On all these kinds of deployments, you usually use a key server. But then > > how do you authenticate to the key server? With another secret. > > It's secrets all the way down. At some point, you must trust something, and > > that something you trust can't be a human, because that doesn't scale or > > isn't practical for some other reason. > > > > I'd love to hear a practical solution to the "secret at rest" problem that > > actually makes some sense and doesn't just hand-wave the problem off to > > another component that is Somebody Else's Problem. > > > > -chris > > > >> -----Original Message----- > >> From: Alan F <shiva...@hotmail.com> > >> Sent: Friday, January 14, 2022 2:05 PM > >> To: Tomcat Users List <users@tomcat.apache.org> > >> Subject: RE: Tomcat 9 Encrpytion of JDBC > >> > >> OK thanks Bill! > >> > >> -----Original Message----- > >> From: Bill Stewart <bstew...@iname.com> > >> Sent: 14 January 2022 19:02 > >> To: Tomcat Users List <users@tomcat.apache.org> > >> Subject: Re: Tomcat 9 Encrpytion of JDBC > >> > >> On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote: > >> > >> > >>> Interested to know your best practices on securing jdbc plain text > >>> passwords, in my last place they used a mechanism to encrypt all > >>> passwords. > >>> Is this the best method as I read some people don't recommend this. > >>> Any details or procs on best practice appreciated. > >>> > >> > >> The "best practice," generally speaking, is that doing so is basically > >> pointless from a security perspective. > >> > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > >> efense.com%2Fv3%2F__https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisp > >> la&data=04%7C01%7Charri.pesonen%40sinch.com%7C318adb49672e4fe13aa1 > >> 08d9dc2f9971%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0%7C637782919266 > >> 275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mMjmECMDtbO%2Fa5ovQgdahIl > >> aq%2FZdVBEnzoRAyy7oYQA%3D&reserved=0 > >> y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn > >> Fa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$ > >> > >> Bill > >> [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this > >> email is proprietary to Medtronic and is intended for use only by the > >> individual or entity to which it is addressed, and may contain > >> information that is private, privileged, confidential or exempt from > >> disclosure under applicable law. If you are not the intended recipient > >> or it appears that this mail has been forwarded to you without proper > >> authority, you are notified that any use or dissemination of this > >> information in any manner is strictly prohibited. In such cases, > >> please delete this mail from your records. To view this notice in > >> other languages you can either select the following link or manually > >> copy and paste the link into the address bar of a web browser: > >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Femail > >> disclaimer.medtronic.com%2F&data=04%7C01%7Charri.pesonen%40sinch.c > >> om%7C318adb49672e4fe13aa108d9dc2f9971%7C3b518aae89214a7b8497619d756ce2 > >> 0e%7C0%7C0%7C637782919266275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > >> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata= > >> %2Fcv%2B6vRuz8ox1ipRnMTOWZxpz2%2BBKJ%2BHlfBh8iDg5m4%3D&reserved=0 > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
