Proposal for TLS config sanity check

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for TLS config sanity check

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

Looking at the legacy-versus-modern TLS configuration (Connector vs
SSLHostConfig), it seems easy for an admin to create a configuration
that looks like this (paraphrasing):

<Connector SSLEngine="on" SSLEnabledProtocols="TLSv1.2" [...]>
  <SSLHostConfig
       hostname="mysite.com"
       SSLCertificateFile="keystore.p12" />
</Connector>

Where the expectation is that only TLSv1.2 will be enabled for virsual
host mysite.com when in fact only the virtual host named ("_default_")
will actually be limited to TLSv1.2 and other hosts will accept
connections using a TLS handshake with all default enabled protocols
(currently TLSv*).

This may be surprising and there is no indication that there is
something "wrong" with the configuration. Only a TLS handshake probe
such as SSL Labs's testing tool will expose the oversight.

I propose the following change to the <Connector> and <SSLHostConfig>
initialization process:

If the <Connector> contains any TLS/SSL-related configuration AND at
least one <SSLHostConfig> element is configured, refuse to start the
connector (with an appropriate error message).

This may cause a small number of configurations to fail to start. The
"workaround" is to re-evaluate one's configuration to (a) determine if
there was a misconfiguration where expectation and reality don't match
and (b) move all TLS/SSL-related configuration options from the
<Connector> to each of the <SSLHostConfig> elements.

Any objections?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzkY74ACgkQHPApP6U8
pFhC2hAAn4mw6c/TVXIfeornjhtE6nQY/2iAjp+fK5OxWpNW09LmDIK6Z/6rIfgS
9kUmfWWaslfUf04f1wmt0G599dQF1gyqHhy3XttgcUER21zpvDzeW9VVBKl7t1uh
zoaXii1ClMoY7Cg3iyuV+ULW0ETI6IyFVhWzecrwPbmWvKbw47s3VDXkimM66nJV
ZEcq47yOG3fogaadflU2GMMlvnAIJBcoW4qvQ7OHEzYliCpUFfP0ZmWPd9ufLP6G
U1otUw0yjaxsItae/PfKr4oiDPhu0pW1MdPhCBgBRS1UyByqn0fE4jf3xvng+OV9
WKxAVHObOUkI8GwNSTHqC2q8OJYrAiucGjYHM8/vPzA6RxpR0qWGO4mbD5NhD9HE
Nv178HEgrL1msuJPqCX7UYil5G8HHpTcXGnKe2jx9OJDoTv0BGmjDVOb+Xd8eIWB
il1DGTh73xe0mB0irLZxRYWME7u4pdMsbB2wkFpr8TGic6wYU0ZXXeVM+0xm/bDN
jy9FNEoQYkU2vu4eFyKLmm0/C1JbJfLRtUtPpoCk+QPt5v6TPjAONweCYy+LVi0c
IaBDmxixG/9l1sRNWr9+vYuR7pVnqAPQMggrlXQU6bBEJ3NU0F/CSWB+fOTTcGhe
BS0AP+gi8+Fsc0cw/yCPodO9VIbDuJw0IGsPxk12pwLm9c7g0LI=
=BuMa
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for TLS config sanity check

markt
On 21/05/2019 21:46, Christopher Schultz wrote:

> All,
>
> Looking at the legacy-versus-modern TLS configuration (Connector vs
> SSLHostConfig), it seems easy for an admin to create a configuration
> that looks like this (paraphrasing):
>
> <Connector SSLEngine="on" SSLEnabledProtocols="TLSv1.2" [...]>
>   <SSLHostConfig
>        hostname="mysite.com"
>        SSLCertificateFile="keystore.p12" />
> </Connector>
>
> Where the expectation is that only TLSv1.2 will be enabled for virsual
> host mysite.com when in fact only the virtual host named ("_default_")
> will actually be limited to TLSv1.2 and other hosts will accept
> connections using a TLS handshake with all default enabled protocols
> (currently TLSv*).
>
> This may be surprising and there is no indication that there is
> something "wrong" with the configuration. Only a TLS handshake probe
> such as SSL Labs's testing tool will expose the oversight.
>
> I propose the following change to the <Connector> and <SSLHostConfig>
> initialization process:
>
> If the <Connector> contains any TLS/SSL-related configuration AND at
> least one <SSLHostConfig> element is configured, refuse to start the
> connector (with an appropriate error message).
>
> This may cause a small number of configurations to fail to start. The
> "workaround" is to re-evaluate one's configuration to (a) determine if
> there was a misconfiguration where expectation and reality don't match
> and (b) move all TLS/SSL-related configuration options from the
> <Connector> to each of the <SSLHostConfig> elements.
>
> Any objections?

None.

Given that the old style configuration is due to be removed in Tomcat
10, now is probably a good time to start doing this. I'd add logging a
warning if the deprecated config style is used.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for TLS config sanity check

csutherl
On Tue, May 21, 2019 at 5:43 PM Mark Thomas <[hidden email]> wrote:
On 21/05/2019 21:46, Christopher Schultz wrote:
> All,
>
> Looking at the legacy-versus-modern TLS configuration (Connector vs
> SSLHostConfig), it seems easy for an admin to create a configuration
> that looks like this (paraphrasing):
>
> <Connector SSLEngine="on" SSLEnabledProtocols="TLSv1.2" [...]>
>   <SSLHostConfig
>        hostname="mysite.com"
>        SSLCertificateFile="keystore.p12" />
> </Connector>
>
> Where the expectation is that only TLSv1.2 will be enabled for virsual
> host mysite.com when in fact only the virtual host named ("_default_")
> will actually be limited to TLSv1.2 and other hosts will accept
> connections using a TLS handshake with all default enabled protocols
> (currently TLSv*).
>
> This may be surprising and there is no indication that there is
> something "wrong" with the configuration. Only a TLS handshake probe
> such as SSL Labs's testing tool will expose the oversight.
>
> I propose the following change to the <Connector> and <SSLHostConfig>
> initialization process:
>
> If the <Connector> contains any TLS/SSL-related configuration AND at
> least one <SSLHostConfig> element is configured, refuse to start the
> connector (with an appropriate error message).
>
> This may cause a small number of configurations to fail to start. The
> "workaround" is to re-evaluate one's configuration to (a) determine if
> there was a misconfiguration where expectation and reality don't match
> and (b) move all TLS/SSL-related configuration options from the
> <Connector> to each of the <SSLHostConfig> elements.
>
> Any objections?

Seems like a good idea to me.
 

None.

Given that the old style configuration is due to be removed in Tomcat
10, now is probably a good time to start doing this. I'd add logging a
warning if the deprecated config style is used.

+1
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]