Re: [OT] Custom protocol implementation not found
Maarten, On 10/14/20 16:21, Maarten Van Den Broek wrote: > > >> 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. Beware: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: [OT] Custom protocol implementation not found
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
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
Re: Custom protocol implementation not found
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
Re: Custom protocol implementation not found
On 14/10/2020 10:38, Maarten van den Broek wrote: > I use tomcat 9.0.33 with windows10 home and amazon corretto jdk1.8.0_212. > 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? I do wonder a) what risk(s) you are attempting to mitigate with this and b) where that custom connector obtains the necessary pass-phrase to decrypt the supplied value. I am assuming you have extended the existing Http11Nio2Protocol implementation and over-ridden setKeystorePass() as that won't get called when an SSLHostConfig element is explicitly configured. Based on the assumptions above, the following approach should work: - override init() - iterate over the results of findSslHostConfigs() - for each SSLHostConfig instance - call getCertificateKeystorePassword() - decrypt it - call setCertificateKeystorePassword() If you have multiple certificates per host you'll need to iterate over the nested SSLHostConfigCertificate instances rather than use the short-cut methods above that work with the default certificate instance. Mark - 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
