Re: [OT] Custom protocol implementation not found
> Op 14 okt. 2020 om 21:09 heeft Christopher Schultz > het volgende geschreven: > > Maartin, > >> On 10/14/20 09:07, Maarten van den Broek wrote: >> Op 14-10-2020 om 14:10 schreef Rémy Maucherat: >>> On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek < >>> mbr...@messagedesign.nl> wrote: >>> >>>> I use tomcat 9.0.33 with windows10 home and amazon corretto >>>> jdk1.8.0_212. >>>> >>>> Below a snapshot of two different Connector definitions in server.xml >>>> >>>> >>> maxThreads="150" SSLEnabled="true" scheme="https" >>>> secure="true" >>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" >>>> >>>> clientAuth="false" sslEnabledProtocols="TLSv1.2" >>>> minSpareThreads="5" >>>> enableLookups="true" disableUploadTimeout="true" >>>> keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" >>>> keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" >>>> /> >>>> >>>> >>> disableUploadTimeout="true" enableLookups="true" maxThreads="150" >>>> minSpareThreads="5" port="443" >>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" >>>> >>>> SSLEnabled="true" scheme="https" secure="true"> >>>> >>>> >>> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" >>>> >>>> >>>> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" >>>> certificateKeystoreType="JKS"/> >>>> >>>> >>>> >>>> Using the first Connector everything is working fine. Debugging the >>>> setKeystorePass method of the class >>>> nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the >>>> protocol attribute shows that the encrypted password gets decrypted. >>>> >>>> Using the second connector with the SSLHostConfig element instead of the >>>> deprecated attributes debugging shows that the setKeystorePass method is >>>> not called and I get errors for the incorrect password of the keystore. >>>> >>>> What am I doing wrong in migrating to the configuration with the >>>> SSLHostConfig element? >>>> >>>> Sincerely yours,Maarten van den Broek >>>> >>> If you simply want to obfuscate server.xml attributes, you should look >>> into >>> the digester property sources instead of engaging in this sort of stuff. >>> One such property source out there: >>> https://github.com/web-servers/tomcat-vault >>> >>> Note: This capability is not included directly into Tomcat itself because >>> it provides no actual extra security. >>> >>> Rémy >> >> Dear Rémy, >> >> Thank you for your swift response. >> >> Customers are happy with this solution because they only need to provide >> these passwords during the first installation and it can be done by the >> owner of the certificate. The key for the en/decryption is in a keystore >> with a password, that can only be obtained by debugging the code. > > So you have the password for the keystore hard-coded into your Java > code? Doesn't that mean it's in revision-control? > >> In a production environment this is in most cases impossible. This >> mechanism is also used to encrypt columns in the database and it is >> easy to reuse for the encryption of the keystore passwords. I prefer >> this over the use of a tomcat vault, because there is increased >> complexity installing tomcat. Alas, it may break with major releases >> and then you have to fix it again, but with your swift help it is no >> problem. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Hello Chris, The password is generated with an algoritm that can only be cracked by reverse engineering the code from a seed given by the user unknown to the makers of the code. So only reverse engineering the code is a liability. Maarten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom protocol implementation not found
Op 14-10-2020 om 14:10 schreef Rémy Maucherat: On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek < mbr...@messagedesign.nl> wrote: I use tomcat 9.0.33 with windows10 home and amazon corretto jdk1.8.0_212. Below a snapshot of two different Connector definitions in server.xml Using the first Connector everything is working fine. Debugging the setKeystorePass method of the class nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the protocol attribute shows that the encrypted password gets decrypted. Using the second connector with the SSLHostConfig element instead of the deprecated attributes debugging shows that the setKeystorePass method is not called and I get errors for the incorrect password of the keystore. What am I doing wrong in migrating to the configuration with the SSLHostConfig element? Sincerely yours,Maarten van den Broek If you simply want to obfuscate server.xml attributes, you should look into the digester property sources instead of engaging in this sort of stuff. One such property source out there: https://github.com/web-servers/tomcat-vault Note: This capability is not included directly into Tomcat itself because it provides no actual extra security. Rémy Dear Rémy, Thank you for your swift response. Customers are happy with this solution because they only need to provide these passwords during the first installation and it can be done by the owner of the certificate. The key for the en/decryption is in a keystore with a password, that can only be obtained by debugging the code. In a production environment this is in most cases impossible. This mechanism is also used to encrypt columns in the database and it is easy to reuse for the encryption of the keystore passwords. I prefer this over the use of a tomcat vault, because there is increased complexity installing tomcat. Alas, it may break with major releases and then you have to fix it again, but with your swift help it is no problem. Maarten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Custom protocol implementation not found
I use tomcat 9.0.33 with windows10 home and amazon corretto jdk1.8.0_212. Below a snapshot of two different Connector definitions in server.xml maxThreads="150" SSLEnabled="true" scheme="https" secure="true" protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" clientAuth="false" sslEnabledProtocols="TLSv1.2" minSpareThreads="5" enableLookups="true" disableUploadTimeout="true" keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" /> disableUploadTimeout="true" enableLookups="true" maxThreads="150" minSpareThreads="5" port="443" protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" SSLEnabled="true" scheme="https" secure="true"> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" certificateKeystoreType="JKS"/> Using the first Connector everything is working fine. Debugging the setKeystorePass method of the class nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the protocol attribute shows that the encrypted password gets decrypted. Using the second connector with the SSLHostConfig element instead of the deprecated attributes debugging shows that the setKeystorePass method is not called and I get errors for the incorrect password of the keystore. What am I doing wrong in migrating to the configuration with the SSLHostConfig element? Sincerely yours, Maarten van den Broek - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org