Maarten,

On 10/14/20 16:21, Maarten Van Den Broek wrote:
> 
> 
>> Op 14 okt. 2020 om 21:09 heeft Christopher Schultz 
>> <ch...@christopherschultz.net> 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
>>>>>
>>>>>       <Connector port="443" connectionTimeout="20000" acceptCount="100"
>>>>>                  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"
>>>>>                  />
>>>>>
>>>>>       <Connector acceptCount="100" connectionTimeout="20000"
>>>>> disableUploadTimeout="true" enableLookups="true" maxThreads="150"
>>>>> minSpareThreads="5" port="443"
>>>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
>>>>>
>>>>> SSLEnabled="true" scheme="https" secure="true">
>>>>>           <SSLHostConfig protocols="TLSv1.2">
>>>>>               <Certificate
>>>>> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>>>>>
>>>>>
>>>>> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
>>>>> certificateKeystoreType="JKS"/>
>>>>>           </SSLHostConfig>
>>>>>       </Connector>
>>>>>
>>>>> 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

Reply via email to